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

[Damien Le Moal <dlemoal@kernel.org>]

On 2026/04/09 12:21, AlanCui4080 wrote:
> Hi,
> 
> I have two ST4000NM000A-2HZ100 on my computer which is of seagate enterprise 
> line.  But when i recovery from suspend, the kernel complains about that and 
> the zpool kicks the disk off:
> 
> ```
> ata2: found unknown device (class 0)
> ata4: found unknown device (class 0)
> ata2: found unknown device (class 0)
> ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> ata4: found unknown device (class 0)
> ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> ata4.00: qc timeout after 5000 msecs (cmd 0xec)
> ata4.00: qc timeout after 5000 msecs (cmd 0xec)
> ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> ata4.00: revalidation failed (errno=-5)
> ata2.00: qc timeout after 5000 msecs (cmd 0xec)
> ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> ata2.00: revalidation failed (errno=-5)
> ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> ata2.00: configured for UDMA/133
> ata4.00: configured for UDMA/133
> ```
> I think that's cause by the too slow spinup for my disk.
> After make libata to wait longer, the warning disappeared.
> 
> ```
> # cat /proc/cmdline
> libata.ata_probe_timeout=10
> ```
> 
> ```
> ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> sd 1:0:0:0: [sda] Starting disk
> ata2.00: configured for UDMA/133
> ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> sd 3:0:0:0: [sdb] Starting disk
> ata4.00: configured for UDMA/133
> ```
> 
> 
> Meanwhile, the seachest reports that the startup time from standby is 9sec, 
> which is longer that the default ATA IDENTIFY timeout.
> 
> ```
> /dev/sg0 - ST4000NM000A-2HZ100 - **** - TN04 - ATA
> 
> Standby Z : Recovery Time : 90 (in 100msecs)
> ```
> 
> ```
> static const unsigned int ata_eh_identify_timeouts[] = {
>          5000,  /* covers > 99% of successes and not too boring on failures */
>         10000,  /* combined time till here is enough even for media access */
>         30000,  /* for true idiots */
>         UINT_MAX,
> };
> ```
> 
> I tested the hard drive, and as long as it's never set to STANDBY_Z (disk 
> stops spinning, requiring 9 seconds to recover) and kept in IDLE_C (platter 
> slows down, requiring 3.2 seconds to recover), this error never occurs.
> 
> It's been seen many users complaining about this elsewhere, should we quirk 
> for those "heavy" disk? Or print some warnings about how to relax this 
> problem.

Elsewhere ? I have not seen any complaints/problem reports on the linux-ide list
recently. So I do not know where "elsewhere" is.

And no, we should not quirk the disk but rather improve resume from suspend to
issue identify with increasing timeouts, like regular probe does, or to issue
identify only once we see the drive ready, which is a check that exist for
spundown startups. That should solve the issue.




-- 
Damien Le Moal
Western Digital Research