linux-kernel - Re: port multiplier problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <da824cf31002040959y63f3484cv6d551acd49b80fa7@mail.gmail.com>
Date:	Thu, 4 Feb 2010 09:59:14 -0800
From:	Grant Grundler <grundler@...gle.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Chandra Shekhar Sah <edu4madh@...il.com>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: port multiplier problem

On Wed, Feb 3, 2010 at 7:24 PM, Tejun Heo <tj@...nel.org> wrote:
> On 02/04/2010 11:37 AM, Grant Grundler wrote:
>> I had two questions on that thread that never got answered:
>>    http://markmail.org/message/snpekoj4qexrslk5
>>
>> | How can we find out if anyone has the SEMB properly wired up?
>> | Would it be hard to make libata aware of "SEMB port not responding" case?
>> | ie if the SEMB port times out or has no link, reduce the port count of
>> | the sil3726 PMP by one.
>> |
>> | Maybe add a "enable_sil24_semb" flag to libata?
>> | (avoid checking unless someone asks for it). I hate magic flags but also
>> | don't want to subject most people to the timeout delay.
>>
>> I (or Gwendal) can post a patch (and lightly test) for any of the above.
>> Just need to get some guidance so we don't waste our time.
>
> It's not really sil24 tho.  But anyways, I think we can just disable
> them altogether.  It's not like they have ever worked.  Just limiting
> both 3726 and 4726 to 5 ports should be fine.

Sorry - You are right. I meant "enable_sil3726_semb".

I'm not sure we need to limit the SEMB ports anymore either. See below.

>  That said, I'm not
> quite sure this is relevant to the reported problem but it's worth a
> shot.

I didn't have a better idea.

I'm seeing this in sata_pmp_quirks() since ATA_LFLAG_NO_SRST was introduced:
 337 static void sata_pmp_quirks(struct ata_port *ap)
 338 {
 339         u32 *gscr = ap->link.device->gscr;
 340         u16 vendor = sata_pmp_gscr_vendor(gscr);
 341         u16 devid = sata_pmp_gscr_devid(gscr);
 342         struct ata_link *link;
 343
 344         if (vendor == 0x1095 && devid == 0x3726) {
 345                 /* sil3726 quirks */
 346                 ata_for_each_link(link, ap, EDGE) {
 347                         /* Class code report is unreliable and SRST
 348                          * times out under certain configurations.
 349                          */
 350                         if (link->pmp < 5)
 351                                 link->flags |= ATA_LFLAG_NO_SRST |
 352                                                ATA_LFLAG_ASSUME_ATA;
 353
 354                         /* port 5 is for SEMB device and it
doesn't like SR     ST */
 355                         if (link->pmp == 5)
 356                                 link->flags |= ATA_LFLAG_NO_SRST |
 357                                                ATA_LFLAG_ASSUME_SEMB;
 358                 }


But the ATA_LFLAG_NO_SRST used in line 351 is not present in the
2.6.26 tree I know works with PMPs. The original commit comment isn't
specific about exactly which HW had problems:
    http://www.mail-archive.com/git-commits-head@vger.kernel.org/msg24335.html

   "Some links on some PMPs locks up on SRST and/or report incorrect
    device signature.  Implement ATA_LFLAG_NO_SRST, ASSUME_ATA and
    ASSUME_SEMB to handle these quirky links.  NO_SRST makes EH avoid
    SRST.  ASSUME_ATA and SEMB forces class code to ATA and SEMB_UNSUP
    respectively.  Note that SEMB isn't currently supported yet so the
    _UNSUP variant is used."


Can you publish which PMP implementations sometimes lock up on SRST?

I doubt this is related to the problem Chandra is seeing but again,
don't have better ideas.

BTW, this same kernel works fine without disabling port 5 (SEMB port).
I didn't know
this until I just looked. I know previous source trees Google used
ignored SEMB port
on 3726 and I mistakenly assumed this one did too. :(

thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/