On 02/18/2011 03:50 PM, Tejun Heo wrote: > Hello, > > On Fri, Feb 18, 2011 at 01:58:09PM +0100, Stefan Bader wrote: >> We are hoping that those working more closely with the SATA code might >> be aware of this issue. As the symptoms are so severe (data corruption) >> we have ALPM disabled globally, but this does make it hard to get more >> targeted information on affected platforms. > > What do you mean by data corruption? File system ro remount or actual > fs corruption? If actual fs corruption is happening, it's highly > likely that there's an underlying issue with the hardware. If data > corruption can be reproduced, can you please run smartctl -a before > and after such failure and post the outputs? > Sorry that was not specific enough. It is remounting ro, which can leave the fs in a better or worse state. > As for ro remounts, I recall applying fixes for that months ago. I > don't remember the details but some configurations raised extra PHY > event afterwards and command was failed without retry. Anyways, it > got fixed. Please dig through the log for details. > > Also, the whole LPM thing got revamped several releases ago. Can you > please test how the recent kernels behave? There will be failures as > not all hardware can handle LPM well but those failures shouldn't lead > to any catastrophic failures like ro remounting of filesystem. > The example output given as footnotes in the original post were taken from the latest re-test someone did on a 2.6.38-rc5 kernel (same user also reported bad experience with a 2.6.35 based kernel). The comment we got on that was: "Here's what i get - the drive led lights continuously for about 10 seconds during which any hdd access results in hanging process:" [12348.040077] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x150000 action 0x6 frozen [12348.040086] ata3: SError: { PHYRdyChg CommWake Dispar } [12348.040091] ata3.00: failed command: READ FPDMA QUEUED [12348.040099] ata3.00: cmd 60/10:00:b0:94:c5/00:00:03:00:00/40 tag 0 ncq 8192 in [12348.040101] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) [12348.040104] ata3.00: status: { DRDY } [12348.040112] ata3: hard resetting link [12348.390082] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [12348.404414] ata3.00: configured for UDMA/133 [12348.404550] ata3.00: device reported invalid CHS sector 0 [12348.404570] ata3: EH complete I believe the details of the failures varied but "READ FPDMA QUEUED" and a timeout were usually involved. Stefan > Thanks. > -- 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