On 9/17/07, Tejun Heo <htejun@xxxxxxxxx> wrote: > Andrew Paprocki wrote: > > boot configuration more complicated if booting off the pata drive. Is > > there any way to control which order the drives are assigned when not > > building w/ modules? > > Please use mount-by-LABEL or UUID. Thanks, wasn't aware of that functionality. Works like a charm. > > ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x2400000 action 0x2 frozen > > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x280000 action 0x0 > > In both cases, SError is indicating transmission problem. Handshake > error and Unrecognized FIS type in the first case, 10b to 8b decode > error and CRC error on the second case. I can't tell why but signals > flying through those redish cables are getting corrupted. I've replaced the cables with a different brand I had laying around, and I haven't seen a problem yet. I'll need to test it heavily, though to see if I can trigger anything to pop up. I didn't mention it before, but I'm also getting these errors every time I boot. I'm thinking they're related to the drive not supporting cmds that smartd is sending it. If so, is there any way that libata/smartd can handle this more gracefully? This stuff spews into dmesg and gives a scare that there is a real hardware problem that may cause data corruption. I get exactly 6 instances of each of these two blocks of output prior to reaching the login prompt: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata1.00: cmd b0/db:f8:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 0 res 51/04:f8:00:4f:c2/00:00:00:00:00/00 Emask 0x1 (device error) ata1.00: configured for UDMA/100 ata1: EH complete ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata2.00: cmd b0/db:f8:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 0 res 51/04:f8:00:4f:c2/00:00:00:00:00/00 Emask 0x1 (device error) ata2.00: configured for UDMA/100 ata2: EH complete Thanks, -Andrew - 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