This is a power management/sleep addition to this thread, based on some more that I have learned.
I have been participating in another thread, where a user with openSUSE Tumbleweed was experiencing issues with their computer going to sleep and not being able to respond afterward.
Recall in this ‘external enclosure’ thread, I have openSUSE LEAP-15.6 GNU/Linux installed on a Samsung 990 EVO Plus SSD in an USB external Orico M2PV-C3 enclosure, which I can use to boot GNU/Linux from my Lenovo X1 Carbon generation 4 laptop and also from my Lenovo X1 Carbon generation 9 laptop.
Initially, the SSD/enclosure, when running LEAP-15.6, was going to sleep, freezing access (presenting me a black screen).
I successfully stopped that behaviour where I added a combination of measures:
- added a USB quirk to Grub : " usbcore.quirks=0bda:9210:k "
- added a UDEV rule (created a script to prevent USB Autosuspend with a udev Rule …where it targets my Orico enclosure using its Vendor ID (0bda) and Product ID (9210). The RUN+ part of the script executes commands to set power/autosuspend to -1 (disabling autosuspend) and power/control to on (keeping it powered).
- added a cronjob that writes to the external SSD every 3 minutes
The ‘sleep’ thread (that I noted above) on this forum reminded my of the issues that I had with my external SSD enclosure as described in this thread. Currently, I proposed that user who has a freeze problem with an internal storage device running openSUSE Tumbleweed change the ‘sleep’ mode on their Tumbleweed from “deep” to “s2idle” to see if that might sort their issue.
How about my case?
So naturally, that had me thinking about my external SSD, and asking myself if my approach was correct? So I did a check of Leap-15.6 on my external SSD when it is running on my Lenovo X1 carbon generation-9 laptop.
I sent the following commands and received this output:
oldcpu@orico-samsung:~> cat /sys/bus/usb/devices/usb*/power/autosuspend
0
0
0
0
oldcpu@orico-samsung:~> cat /sys/bus/usb/devices/usb*/power/control
auto
auto
auto
auto
oldcpu@orico-samsung:~>
From what I read, that means my udev rule (which was intended to set power/autosuspend to -1 and power/control to on) is not working !!
If my udev rule was doing what I had wanted, I read that the command:
cat /sys/bus/usb/devices/usb*/power/autosuspend
should show -1 for my Orico enclosure (which it does not, it shows ‘0’ ).
and I read that the command:
cat /sys/bus/usb/devices/usb*/power/control
should show ‘on’ for the enclosure (which it does not, it shows ‘auto’).
I asked myself …
(1) For the command: ‘cat /sys/bus/usb/devices/usb*/power/autosuspend’ what is the difference between the autosuspend ‘0’ and ‘-1’?
I then read for autosuspend, a value of -1 means that autosuspend is disabled, while a value of 0 means that the device can be suspended immediately after a period of inactivity.
(2) For the command: ‘cat /sys/bus/usb/devices/usb*/power/control’ what is the difference between the power control ‘on’ and ‘auto’?
I then read for power control, a value of ‘on’ forces the device to be kept powered on at all times. The auto value means the kernel’s USB power management will decide whether to put the device into a low-power state based on its activity.
That being the case, why did my udev rule not work?
The answer? From what I can read, it was possibly overruled due to
(1) Timing Issues: The udev rule might be executed a split second before the power/ files are ready to be modified, or another kernel process might be resetting the values immediately after my UDEV rule runs.
(2) Kernel Quirk I applied in Grub: My usbcore.quirks=0bda:9210:k parameter in Grub is a low-level instruction to the kernel. This quirk might be setting its own power management behavior for my specific device that takes precedence over any settings from a udev rule.
I personally think a timing issue less likely, but the usbcore.quirks=0bda:9210:k parameter in Grub could be why my udev rule does nothing.
Still, my external SSD still thou does not freeze - which is good !!
Likely the reason my LEAP-15.6 running from the external SSD is stable (and does not freeze) is not because of the udev rule, but because of the two other measures I took: The USB Quirk and the Cronjob.
The USB Quirk (applied in Grub): This likely tells the kernel’s USB subsystem how to handle my specific SSD enclosure from the moment it’s detected, preventing it from entering an improper sleep state.
The Cronjob: This is a direct, brute-force solution that ensures there is never a period of inactivity long enough for the device to attempt to sleep.
I speculate that the combination of these two measures is likely what’s keeping my LEAP-15.6 running smoothly. The udev rule, while well-intentioned, appears to be redundant in this specific setup and over ruled by the USB Quirk.
I am not 100% certain that the answer, but it makes sense.
‘s2idle’ vs ‘deep’ (sleep modes) for my external LEAP-15.6 operation
So back to what had me looking at all of this again which is the sleep modes of ‘deep’ vs ‘s2idle’ for my use of running LEAP-15.6 from an external enclosure.
After reading up on ‘s2idle’ vs ‘deep’ for my very very specific use, I concluded that applying ‘s2idle’ likely would not have solved my external USB freeze issue,
S2idle
I read that s2idle (Suspend to Idle) is an ACPI (Advanced Configuration and Power Interface) sleep state for the entire system. It’s a software-controlled state where the CPU cores enter a very low-power C-state, and the system essentially remains “on” but at a much lower power consumption. It’s often referred to as an “always-on” or “connected standby” state.
Its purpose is to put the entire laptop into a low-power state while keeping the OS and memory powered, allowing for faster wake-up times than deep sleep.
What initially mislead me was I read USB-C introduces new power management behaviors that do not exist with older USB standards and that s2idle supported some of the new USB-C features. I mistakenly thought that maybe that would mean my external SSD enclosure (with its SSD inside) would remain powered due to the USB-C features.
But now after reading further, if I read this correctly (and I might have this wrong), this USB-C aspect more specifically includes these two features:
- USB Power Delivery (USB-PD): This allows for bi-directional power flow and high-wattage charging. A USB-C port acting as a power source might need to stay active to maintain a power contract, which could, in some cases, prevent the entire bus from being suspended.
- DisplayPort Alt-Mode: This allows a USB-C port to carry a DisplayPort video signal. A device acting as a display sink needs the port to remain powered to maintain the video link.
When reviewing that it suggests to me that this does not apply to my external enclosure (running LEAP-15.6) and it will not prevent it going to sleep (with its annoyingly freeze when LEAP-15.6 running from the external SSD).
Why?
My Orico SSD enclosure is a storage device. It does not use USB-PD to supply power to my laptop, nor does it use the DisplayPort Alt-Mode. In the absence of a specific power connection or video link, my SSD enclosure is just a standard USB device from the kernel’s perspective.
and how is that relevant to s2idle?
During s2idle, the kernel’s standard procedure is to save power by putting all idle devices to sleep. Since my SSD is seen as a standard storage device with no special power requirement, the kernel will send it a suspend command via the USB driver.
So my problem was that my specific hardware (the Samsung SSD with the Realtek chipset) was not able to handle this standard suspend command gracefully, leading to a freeze - a freeze that s2idle would not solve, but one that the CRON JOB and the USB Quirk (applied in Grub) did solve.
Conclusion?
So … I tentatively conclude, based on my current understanding (which is not guaranteed to be 100% correct) that it is the custom Grub USB Quirk and the custom Cronjob that is stopping my external SSD from freezing.
Perhaps this is a lot of research for nothing - but even at age-71 it can be fun to learn - especially if it involves a new toy 
, my external SSD enclosure running LEAP-15.6.
.
