On 8/17/22 12:07, Vlastimil Babka wrote:
In my case it's
/sys/devices/pci0000:00/0000:00:17.0/ata1/host0/scsi_host/host0/proc_name:ahci
/sys/devices/pci0000:00/0000:00:17.0/ata2/host1/scsi_host/host1/proc_name:ahci
Some more details from dmesg
[ 0.849373] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 0.852849] ata2.00: ACPI cmd f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
[ 0.854671] ata2.00: supports DRM functions and may not be fully accessible
[ 0.856181] ata2.00: ATA-9: SAMSUNG MZ7LN512HMJP-000L7, MAV01L6Q, max UDMA/133
[ 0.858115] ata2.00: 1000215216 sectors, multi 1: LBA48 NCQ (depth 32), AA
[ 0.861584] ata2.00: Features: Trust Dev-Sleep NCQ-sndrcv
[ 0.863749] ata2.00: ACPI cmd f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
[ 0.865481] ata2.00: supports DRM functions and may not be fully accessible
[ 0.870043] ata2.00: configured for UDMA/133
[ 0.871871] scsi 1:0:0:0: Direct-Access ATA SAMSUNG MZ7LN512 1L6Q PQ: 0 ANSI: 5
Please Cc me on further questions/steps to try/patches to test.
Hi Vlastimil,
Thank you for having provided the above information. The root cause of
the hang is not yet clear to me. I was wondering whether the hang
perhaps would be triggered by controllers that only support queue depth
1. However, in the above output I see "depth 32".
As already reported in this email thread a revert for commit
88f1669019bd62b3 has been posted on the linux-scsi mailing list.
Additionally, Greg KH has been asked to drop that patch from the stable
trees.
Thanks,
Bart.
