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? 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
