You are not logged in.
Pages: 1
Hallo. Half a day now spent to find an answer to this.
Hot swapping of my SATA drives had always function properly on Arch, it was sufficient to enable it from within the BIOS the first time I've needed it, a couple of years ago.
Today I've discovered that they did not get detected automatically, lsblk output just does not list hot plugged SATA devices.
So after some investigation I've found this post at https://forum.level1techs.com/t/sata-ho … 0-p/189719, where the author tells to use:
echo 0 0 0 > /sys/class/scsi_host/host*/scanto perform a rescan, as also stated by the Arch Wiki page at https://wiki.archlinux.org/title/Udev#D … ATA_drives.
So this simply works, I just need to issue the command after each reboot and
dmesg -wtells me now that the drives are correctly detected and are effectively shown by the lsblk output at each unplug/re-plug during the current session.
As stated by the author of the aformentioned post at the forum.level1techs.com forum, after
reading some notion about the ALPM (see: https://access.redhat.com/documentation … guide/alpm), I've also tried the following:
echo 'max_performance' | sudo tee /sys/class/scsi_host/host*/link_power_management_policybut this did not change anything, so at each reboot I needed to recall the above command:
echo 0 0 0 | sudo tee /sys/class/scsi_host/host<host_number>/scanI'm using the 6.8.1-arch1-1 kernel version but cannot say at which update the issue came in, as I've discovered it after a long time while I didn't needed the hot swapping funcionality.
I can tell also that other OS platform (non Linux based) on the same machine does correctly auto detect hot-plugged SATA devices.
I'm just curious if someone else have encountered the same issue and/or if someone knows a better approach to correct/change such behavior without
scripting/automate the SCSI rescan at system reboot.
Last edited by etherdolphin (2024-03-20 09:42:41)
Offline
other OS platform (non Linux based) on the same machine does correctly auto detect hot-plugged SATA devices.
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
but this did not change anything, so at each reboot
The sysfs is transient and won't survive reboots, however: https://wiki.archlinux.org/title/Solid_ … ted_errors
Check the values after a reboot, it's supposed to be disabled but your might have a PM tool that enables it?
Offline
Thank you very much for your answer, I really apprechiate it
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
I've never booted the other OS and thus I've never changed any of its settings from the last time I've used the
hot plug functionality.
Anyway, try to disable fast start seems to me a "voodoo" explanation to the missing "hot plug" capability of my desktop system.
The sysfs is transient and won't survive reboots, however: https://wiki.archlinux.org/title/Solid_ … ted_errors
Check the values after a reboot, it's supposed to be disabled but your might have a PM tool that enables it?
Speaking about the Resolving_SATA_power_management_related_errors, the Arch Wiki troubleshoot article is related to
a disk failure shown by some SSD drives with ALPM enabled.
Anyway I can tell that if I give:
$ cat /sys/class/scsi_host/host*/link_power_management_policythe result is:
max_performancefor each SATA host, after every reboot, meaning it keeps the setting I've written to.
As stated by the Red Hat documentation article (https://access.redhat.com/documentation … guide/alpm), the ALPM is set
in a manner that the "hot plug" feature should not be disabled as with min_power or medium_power settings.
I've never explicitly installed power saving tools on Arch
Last edited by etherdolphin (2024-03-20 10:06:37)
Offline
meaning it keeps the setting I've written to
No, meaning it's the default. Try some other value, will be gone after a reboot.
But it also means no PM tool is altering it during/after the boot, so that's moot.
Anyway, try to disable fast start seems to me a "voodoo" explanation to the missing "hot plug" capability of my desktop system.
Fast-start is disguised hibernation, ie. two OS are controlling the same HW at the same time and the BIOS/ACPI is easily "confused" about what the current state of affairs is.
I've never booted the other OS and thus I've never changed any of its settings from the last time I've used the hot plug functionality.
I can tell also that other OS platform (non Linux based) on the same machine does correctly auto detect hot-plugged SATA devices.
Only one of those is true. Which?
Offline
Only one of those is true. Which?
Both!
I booted the other OS only to test its behavior regarding the hot plug feature and only when I've realized that something was changed with Arch (initially I thought with the kernel) during the last year of updates.
But it also means no PM tool is altering it during/after the boot, so that's moot.
This seems to prove that some other mechanism Is interfering with the hot plug feature, as ALPM Is configured correctly. Right?
Thanks for your time.
Last edited by etherdolphin (2024-03-20 20:11:52)
Offline
Tis is more "hot-plugging" than "hot-swapping", right?
Tried to disable "pcie_aspm=off", https://wiki.archlinux.org/title/Kernel_parameters
You could also try to lie to the ACPI
acpi_osi=! acpi_osi="Windows 2015"https://learn.microsoft.com/en-us/windo … inacpi-osi
And, since this is apparently a regression, have you tried the LTS kernel?
What's the about timeframe between the last time this actually worked and now?
Offline
Tried to disable "pcie_aspm=off", https://wiki.archlinux.org/title/Kernel_parameters
The above setting makes no difference, but:
since this is apparently a regression, have you tried the LTS kernel?
Yes! The LTS kernel, version 6.6.22-1-lts, just brings the SATA hot-swap (or hot-plug if we prefer) feature back.
I'll try to keep using it for some time, at least until I discover some other feature that I'm renouncing to with the bleeding edge kernel, which currently is version 6.8.1.arch1-1.
Thank you again for your effort.
Last edited by etherdolphin (2024-03-21 15:40:46)
Offline
If you can, you should check the behavior w/ the last 6.7 kernel (downgrading the kernel in isolation is reasonably safe and you've the LTS kernel anyway, but nb. that you'll have to downgrade OOT modules and/or the kernel headers for dkms along it)
Offline
If you can, you should check the behavior w/ the last 6.7 kernel (downgrading the kernel in isolation is reasonably safe and you've the LTS kernel anyway, but nb. that you'll have to downgrade...
The Arch installation in question is currently used for some critical jobs, so this is actually not doable for me.
I'll add it to the list of tests to be done on a "rainy day", on a less critical testing machine which will not be at my fingertips for the next days.
Thank you anyway for the suggestion.
Offline
Any difference in dmesg (journalctl), for example this line?
ahci 0000:02:00.1: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part sxs deso sadm sds apstWhat kind of sata controller are you using? There was an issue with asmedia, there's a proposed fix on the linux-ide list (ahci: asm1064: asm1166: don't limit reported ports). Should not affect you unless you're using an addon card with several sata ports / builtin port multiplier.
Online
What kind of sata controller are you using?
Only motherboard's on board SATA controller, an ASUS Z690 family motherboard:
10000:e0:17.0 SATA controller: Intel Corporation Alder Lake-S PCH SATA Controller [AHCI Mode] (rev 11)if that can help.
Any difference in dmesg (journalctl), for example this line?
ahci 0000:02:00.1: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part sxs deso sadm sds apst
No, nothing similiar to that line, neither with dmesg nor by journalctl.
Last edited by etherdolphin (2024-03-21 18:02:28)
Offline
Once it's raining in your location, also see whether plugging the drive causes *any* response in "dmesg -w" on the bad kernel (and if, how it's different from the good ones)
Offline
Once it's raining in your location, also see whether plugging the drive causes *any* response in "dmesg -w" on the bad kernel (and if, how it's different from the good ones)
This is an already done homework. On the "bad" kernel (6.8.1.arch1-1) dmesg put in following mode does output the absolute nothing, zero lines.
I needed to rescan:
echo 0 0 0 | sudo tee /sys/class/scsi_host/host*/scanto make alive the terminal where dmesg -w was running, outputting the same info as the LTS kernel does now when hot-plugging a SATA disk:
[ 561.381827] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 561.408975] ata5.00: ATA-10: ST500LX025-1U717D, SDM1, max UDMA/133
[ 561.418179] ata5.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[ 561.466984] ata5.00: configured for UDMA/133
[ 561.477256] scsi 4:0:0:0: Direct-Access ATA ST500LX025-1U717 SDM1 PQ: 0 ANSI: 5
[ 561.478114] sd 4:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[ 561.478125] sd 4:0:0:0: [sdb] 4096-byte physical blocks
[ 561.478141] sd 4:0:0:0: [sdb] Write Protect is off
[ 561.478146] sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 561.478165] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 561.478194] sd 4:0:0:0: [sdb] Preferred minimum I/O size 4096 bytes
[ 563.979293] sdb: sdb1
[ 563.979660] sd 4:0:0:0: [sdb] Attached SCSI diskOffline
It certainly feels powermanagement related, you could try "libata.force=nolpm pcie_port_pm=off", https://wiki.archlinux.org/title/Kernel_parameters
Offline
Pages: 1