Tejun Heo wrote:
Mark Lord wrote:
That's an IDENTIFY (0xEC) command timing out.
The hddtemp program does it's work by issuing IDENTIFY and SMART
commands to the target drive, /dev/sdb in this case.
ioctl(3, 0x30d, 0xbfd2c418)
ioctl(3, 0x31f, 0xbfd2c60c)
ioctl(3, 0x31f, 0xbfd2c614)
ioctl(3, 0x31f, 0xbfd2c408)
So that 0xEC most likely came from the hddtemp program,
since libata doesn't normally issue them after probing.
So why is it timing out? Well, these drives have 32MB onboard caches,
and I'm guessing that something (firmware, whatever) tries to empty that
cache before processing the issued IDENTIFY command. And we time out
before the drive has a chance to actually process the IDENTIFY.
..
Another possibility could be some kind of bug in libata or ahci.c.
It seems unlikely -- .qc_defer ought to prevent issues -- but I haven't
really poked around in there. And this is a "production" machine :)
so we don't like to use it (much) for debugging kernels if we can help it.
Can you please hack up a program to issue IDENTIFY with different
timeouts and see when the condition triggers?
..
Yeah, there's a bunch of stuff like that for me to do, someday. :)
Meanwhile, summer finally arrived here today, so..
Cheers
--
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
