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

[Niklas Cassel <cassel@kernel.org>]

Hello Alan, Damien,

On Thu, Apr 09, 2026 at 02:01:03PM +0200, Damien Le Moal wrote:
> On 2026/04/09 12:21, AlanCui4080 wrote:

[...]

> And no, we should not introduce a quirk for this. Rather, we should do the same
> 3-steps timeout for revalidation after a resume from suspend in the same manner
> as a regular probe does. Or add a check/wait for "drive ready" when resuming,
> similar to the PUIS handling (power up in standby).

Just like regular ata_dev_read_id() (called during probe),
ata_dev_reread_id() (called during revalidate) already does increase the
timeout with each retry:

# echo +10 > /sys/class/rtc/rtc0/wakealarm
# echo mem > /sys/power/state

[   22.709542] PM: suspend entry (deep)
[   22.734353] Filesystems sync: 0.024 seconds
[   22.749431] Freezing user space processes
[   22.750703] Freezing user space processes completed (elapsed 0.000 seconds)
[   22.751533] OOM killer disabled.
[   22.751939] Freezing remaining freezable tasks
[   22.753553] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[   22.763375] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[   22.764396] ata1.00: Entering standby power mode
[   22.775472] PM: suspend devices took 0.021 seconds

...
...
...

[   28.826052] PM: suspend exit
[   29.063513] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

QEMU: cmd_identify: IDENTIFY count: 4, intentionally not sending completion

[   29.064800] ata2: SATA link down (SStatus 0 SControl 300)
[   29.071055] ata3: SATA link down (SStatus 0 SControl 300)
[   29.072053] ata6: SATA link down (SStatus 0 SControl 300)
[   29.073009] ata5: SATA link down (SStatus 0 SControl 300)
[   29.074038] ata4: SATA link down (SStatus 0 SControl 300)
[   34.168702] ata1.00: qc timeout after 5000 msecs (cmd 0xec)
[   34.169820] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x5)
[   34.170754] ata1.00: revalidation failed (errno=-5)
[   34.481679] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

QEMU: cmd_identify: IDENTIFY count: 5, intentionally not sending completion

[   44.920692] ata1.00: qc timeout after 10000 msecs (cmd 0xec)
[   44.921814] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x5)
[   44.922647] ata1.00: revalidation failed (errno=-5)
[   45.232872] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

QEMU: cmd_identify: IDENTIFY count: 6, intentionally not sending completion

[   75.640934] ata1.00: qc timeout after 30000 msecs (cmd 0xec)
[   75.642127] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x5)
[   75.643091] ata1.00: revalidation failed (errno=-5)
[   75.643893] ata1.00: disable device
[   75.950433] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)



Alan,
could you please provide a full dmesg (dmesg that has not been cut)
when reproducing your problem on kernel v7.0.

And please explain your problem as detailed as you can, including which
drive/port (ataX.YY) that you are having a problem with.

ZFS is not a filesystem in the kernel, so we don't really care about it.

Are you saying that you see something like:
[   75.643893] ata1.00: disable device

instead of something like:
[   75.068077] sd 0:0:0:0: [sda] Starting disk
[   75.069628] ata1.00: configured for UDMA/100



Note that if you specify an explicit probe timeout value, e.g.
libata.ata_probe_timeout=10

Then that timeout value will be used for each retry:
https://github.com/torvalds/linux/blob/v7.0/drivers/ata/libata-core.c#L1612-L1617

I.e. if you specify an explicit probe timeout value, you will not
automatically get a larger timeout timeout for each retry.


Kind regards,
Niklas