Hello, On 08/20/2010 09:22 PM, Jeff Garzik wrote: > On 08/20/2010 12:24 PM, Jan Beulich wrote: >> on one of my systems (the only one with that sort of controller) boot >> fails with .35 due to an identify failure for the drive that has the root >> partition (and others): >> >> libata version 3.00 loaded. >> sata_sil 0000:00:12.0: version 2.4 >> sata_sil 0000:00:12.0: enabling device (0005 -> 0007) >> alloc irq_desc for 22 on node -1 >> alloc kstat_irqs on node -1 >> sata_sil 0000:00:12.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 >> scsi0 : sata_sil >> scsi1 : sata_sil >> ata1: SATA max UDMA/100 mmio m512@0xc0000000 tf 0xc0000080 irq 22 >> ata2: SATA max UDMA/100 mmio m512@0xc0000000 tf 0xc00000c0 irq 22 >> input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input1 >> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) >> ata1.00: NODEV after polling detection >> ata2: SATA link down (SStatus 0 SControl 300) >> >> With some debugging printk-s added I found that "status" as passed >> from ata_sff_pio_task() to ata_sff_hsm_move() is 0x50 (instead of >> the expected 0x58), and I also found that adding a certain delay >> at the top of ata_sff_pio_task() for just the very first invocation >> makes the problem go away: putting udelay(400) there works, >> while udelay(300) isn't sufficient. >> >> 2.6.34.x is working fine. >> >> The controller is reported as >> >> 00:12.0 IDE interface [0101]: ATI Technologies Inc IXP SB400 Serial ATA Controller [1002:4379] >> >> Thanks for any hints towards debugging or resolving this problem. > > sata_sil has been stable for a while, for most people. The only post-2.6.34 major changes to sata_sil's operations are the SFF/BMDMA separation changes, AFAICT. > > Unfortunately, that's a very large patch series, with no easy "try to revert <this>" point. Is there any chance you can bisect this? This apparently is not an isolated case. https://bugzilla.kernel.org/show_bug.cgi?id=16606 For some reason, the NODEV detection is getting triggered spuriously which is really strange given that that part of code has been *really* stable for very long time now. Jan, can you please apply the following patch and attach the kernel log? https://bugzilla.kernel.org/attachment.cgi?id=27513 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
