On 2025-08-27 17:01:49 [+0900], Damien Le Moal wrote:
> Don't read a file. Read the disk directly. So please use "if=/dev/sdX".
> Also, there is no way that a 1GiB I/O will be done as a single large command.
> That is not going to happen.
>
> With 345c5091ffec reverted, what does:
>
> cat /sys/block/sdX/queue/max_sectors_kb
> cat /sys/block/sdX/queue/max_hw_sectors_kb
>
> say ?
| # cat /sys/block/sda/queue/max_sectors_kb
| 1280
| # cat /sys/block/sda/queue/max_hw_sectors_kb
| 32767
> Likely, the first one is "1280". So before running dd, you need to do:
>
> echo 4096 > /sys/block/sdX/queue/max_sectors_kb
>
> and then
>
> dd if=/dev/sdX of=/dev/null bs=4M count=1 iflag=direct
| # echo 4096 > /sys/block/sda/queue/max_sectors_kb
| # cat /sys/block/sda/queue/max_sectors_kb
| 4096
| # dd if=/dev/sda of=/dev/null bs=4M count=1 iflag=direct
| 1+0 records in
| 1+0 records out
| 4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.00966543 s, 434 MB/s
It passed.
After a reboot I issued the same dd command five times and all came
back. Then I increased the sector size and issued it again. The first
two came back and then
| root@zen3:~# dd if=/dev/sda of=/dev/null bs=4M count=1 iflag=direct
| 1+0 records in
| 1+0 records out
| 4194304 bytes (4.2 MB, 4.0 MiB) copied, 33.1699 s, 126 kB/s
| root@zen3:~# dd if=/dev/sda of=/dev/null bs=4M count=1 iflag=direct
| 1+0 records in
| 1+0 records out
| 4194304 bytes (4.2 MB, 4.0 MiB) copied, 57.3711 s, 73.1 kB/s
| root@zen3:~# dd if=/dev/sda of=/dev/null bs=4M count=1 iflag=direct
| 1+0 records in
| 1+0 records out
| 4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.0264171 s, 159 MB/s
They all came back but as you see on the speed side, it took while. And
I see
| [ 191.641315] ata1.00: exception Emask 0x0 SAct 0x800000 SErr 0x0 action 0x6 frozen
| [ 191.648839] ata1.00: failed command: READ FPDMA QUEUED
| [ 191.653995] ata1.00: cmd 60/00:b8:00:00:00/20:00:00:00:00/40 tag 23 ncq dma 4194304 in
| res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
| [ 191.669306] ata1.00: status: { DRDY }
| [ 191.672981] ata1: hard resetting link
| [ 192.702763] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
| [ 192.702964] ata1.00: Security Log not supported
| [ 192.703207] ata1.00: Security Log not supported
| [ 192.703215] ata1.00: configured for UDMA/133
| [ 192.703282] ata1: EH complete
| [ 248.985303] ata1.00: exception Emask 0x0 SAct 0x10001 SErr 0x0 action 0x6 frozen
| [ 248.992733] ata1.00: failed command: READ FPDMA QUEUED
| [ 248.997889] ata1.00: cmd 60/00:00:00:00:00/20:00:00:00:00/40 tag 0 ncq dma 4194304 in
| res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
| [ 249.013107] ata1.00: status: { DRDY }
| [ 249.016775] ata1.00: failed command: WRITE FPDMA QUEUED
| [ 249.022011] ata1.00: cmd 61/08:80:40:d1:18/00:00:00:00:00/40 tag 16 ncq dma 4096 out
| res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
| [ 249.037135] ata1.00: status: { DRDY }
| [ 249.040802] ata1: hard resetting link
| [ 250.076059] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
| [ 250.076258] ata1.00: Security Log not supported
| [ 250.076471] ata1.00: Security Log not supported
| [ 250.076478] ata1.00: configured for UDMA/133
| [ 250.076537] ata1: EH complete
> And you will likely trigger the issue, even with 345c5091ffec reverted.
> The issue is likely caused by a FW bug handling large commands.
> Please try.
Done. It seems the firmware is not always dedicated to fulfill larger
requests.
Sebastian
