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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 05 Feb 2010 11:44:50 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Grant Grundler <grundler@...gle.com>
CC:	Chandra Shekhar Sah <edu4madh@...il.com>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: port multiplier problem

Hello,

On 02/05/2010 02:59 AM, Grant Grundler wrote:
>> 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.

Heh... yeah, me neither.  If that doesn't work, I'll dig out 3726s I
have and see whether the new kernels are having problems with them but
I can't think of anything which could have effects like this.

> 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 SRST */
>  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 don't remember the details but it was a 3726 or 4726 with slightly
different firmware revision.

> 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. :(

But the other report where the PMP device failed hardreset too was a
3/4726.  I don't know what the variables are (firmware revision
definitely is one but there seem to be others) but these pseudo
devices are extremely fragile.  Certain configurations just don't work
or work with strange quirks.  I think it would be best to just stay
away from those.

Thanks.

-- 
tejun
--
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/