On 1/8/24 09:56, Kevin Locke wrote:
Hi all,
On a ThinkPad T430 running Linux 6.7, when I attempt to delete the ATA
device for a hard drive in the Ultrabay slot (to hotswap/undock it[1])
the process freezes in an unterruptible sleep. Specifically, if I run
echo 1 >/sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/delete
The shell process hangs in the write(2) syscall. The last dmesg
entries post hang are:
sd 1:0:0:0: [sda] Synchronizing SCSI cache
ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata2.00: ACPI cmd f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
ata2.00: ACPI cmd ef/10:03:00:00:00:a0(SET FEATURES) filtered out
ata2.00: ACPI cmd f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
ata2.00: ACPI cmd ef/10:03:00:00:00:a0(SET FEATURES) filtered out
ata2.00: configured for UDMA/133
ata2.00: retrying FLUSH 0xea Emask 0x0
On kernel versions prior to 6.5-rc1, dmesg would subsequently contain:
sd 1:0:0:0: [sda] Stopping disk
ata2.00: disable device
Note that the hang only occurs when deleting a hard disk drive. It
does not occur when deleting an optical disk drive.
I bisected the regression to 8b566edbdbfb5cde31a322c57932694ff48125ed.
I know very little about the SCSI/ATA subsystems or the internals of
ATA hotswapping/undocking. I'd appreciate any help investigating the
issue, or properly undocking.
Thanks,
Kevin
[1]: https://www.thinkwiki.org/wiki/How_to_hotswap_Ultrabay_devices
Hi Kevin,
Thank you for having bisected this issue.
The "Synchronizing SCSI cache" message probably comes from sd_shutdown().
sd_shutdown() is called by sd_remove(). sd_remove() is called by
__scsi_remove_device(). __scsi_remove_device() is called by
sdev_store_delete(). It's not clear to me how commit 8b566edbdbfb
("scsi: core: Only kick the requeue list if necessary") can affect that
call path.
It would help if more information about the hang could be provided by
running the following command after having reproduced the hang and by
sharing the dmesg output triggered by this command:
echo w > /proc/sysrq-trigger
Thank you,
Bart.
