Re: Default IDENTIFY timeout is 5000ms which is too short for enterprise disks

[Niklas Cassel <cassel@kernel.org>]

On Thu, Apr 16, 2026 at 08:59:30PM +0800, AlanCui4080 wrote:

[...]

> [12961.113196] ata2: link is slow to respond, please be patient (ready=0)
> [12961.114200] ata4: link is slow to respond, please be patient (ready=0)
> [12963.428372] r8169 0000:07:00.0 enp7s0: Link is Up - 1Gbps/Full - flow control rx/tx
> [12965.816162] ata2: found unknown device (class 0)
> [12965.816180] ata4: found unknown device (class 0)
> [12965.969160] ata2: found unknown device (class 0)
> [12965.969171] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [12965.970159] ata4: found unknown device (class 0)
> [12965.970167] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [12981.369196] ata2.00: qc timeout after 15000 msecs (cmd 0xec)
> [12981.369207] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> [12981.369210] ata2.00: revalidation failed (errno=-5)
> [12981.369226] ata4.00: qc timeout after 15000 msecs (cmd 0xec)
> [12981.369236] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> [12981.369238] ata4.00: revalidation failed (errno=-5)
> [12981.833047] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [12981.833134] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [12981.869506] ata2.00: configured for UDMA/133
> [12981.879537] ata4.00: configured for UDMA/133

From this it seems that it is simply the first IDENTIFY that times out.
On the second try, it seems that the IDENTIFY passes, otherwise we would
have seen more "revalidation failed (errno=-5)" prints for the same drive.

So, from this log alone, I don't see any problem. We will try to do IDENTIFY
up to three times, so just a single IDENTIFY failing should not be a problem.

So I think the question is, at this point, can you read from the drive?

E.g.:
# dd if=/dev/sda of=/dev/null iflag=direct bs=4K count=1

replace /dev/sda with the drive connected to ata2.00 or ata4.00.

If you can read from the device, then this seem like a problem with zpool
kicking the device off the RAID array (perhaps because it is taking longer
than some zpool defined timeout value?), rather than a libata problem.


Kind regards,
Niklas