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@xxxxxxxxxxxxxxx/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-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
