TL;DR: When switched on or off (or coming in/out of "sleep"), Logitech devices paired with the Unifying Receiver cause HDDs on the machine they're linked with to power up or down along with them! By "Unifying Receiver", I mean this gadget here: https://upload.wikimedia.org/wikipedia/commons/thumb/7/7d/Logitech_unifying_receiver.jpg/640px-Logitech_unifying_receiver.jpg --- For years I've been annoyed and frustrated by mysterious alternations in the APM states of my hard drives. By pure accident I've now discovered that the cause of this problem, the whole time, has been my Logitech Unifying devices. I have four cordless Logitech devices at my disposal. Two older (pre-2010) USB radio mice which do *not* exhibit the behaviour I'm describing here, and two newer (yet now described as "old") Unifying devices. One is an M570 Trackball and the other is an M325 mouse. These last two *do* exhibit the problem. If you have a machine with a Logitech device paired to this (or a similar) USB receiver, and you have the hdparm tools installed) you should be able to see the problem for yourself as follows: 1. Open a root terminal and check your hard drive's APM level: ┌──── │ # hdparm -B /dev/sd? │ │ /dev/sda: │ APM_level = 254 └──── 2. Switch off your cordless Logitech device. You'll quite likely hear your drive spin down. Check its APM level again: ┌──── │ # hdparm -B /dev/sd? │ │ /dev/sda: │ APM_level = 1 └──── 3. Switch the Logitech device on again. Be amazed as you hear and see that the drive has spun back up along with your mouse or whatever: ┌──── │ # hdparm -B /dev/sd? │ │ /dev/sda: │ APM_level = 254 └──── 4. Occupy yourself at your machine without touching the Logitech device for a minute or two so that it powers itself down to conserved its battery power. Check the APM status again and you'll see that again it took the HDD with it. Re-awaken the Logitech device and the HDD will power back up too. --- I was able to reproduce this behaviour on two 64bit machines and one ancient 32bit machine. All are running Mageia 8 with Kernel 5.15.23-desktop-1.mga8. I've filed bug reports and complained about pm-utils issues in the past, but never in a million years would I have expected this to be the cause of my remaining frustration, and can't imagine how (over a decade?) I've never discovered this before today. I don't know about you folks, but IMO turning on/off a mouse should *never* influence a machine's HDDs. >:( The Wikipedia article about Logitech's Unifying Receivers (from where I grabbed the photo above) is an interesting read in and of itself given the security concerns raised by these gadgets. Hopefully our kernels already include all the various firmware fixes described there... Full article here: https://en.wikipedia.org/wiki/Logitech_Unifying_receiver Anyway, I hope this report proves informative or useful. Presumably this issue will need to be reported further upstream? As always, thanks to everyone on the Mageia team for all their hard work.
Did you also check your BIOS/UEFI settings? I checked on one of my new machine and was not able to reproduce this issue with an Logitech M705. But i also have "Wake on USB" in UEFI Bios disabled.
Thank you John for your very instructive & fullsome report; and kind remark. I think it worth awaiting your reply to sturmvogel's question before forwarding this. And one from me, to test if possible whether the Unifying Receiver is responsible: if you happen to have a different cordless USB connector, does the problem still happen with one of the troublesome devices? @sturmvogel : is it worth testing the issue with "Wake on USB" in your UEFI Bios ENabled? Just to see. Maybe your Logitech M705 would not show it anyway.
CC: (none) => lewyssmith
@Lewis : Hi, and thanks for your reply. Yep, the Unifying Receivers (plural) are responsible. I'd already stated in Comment 0 that I have four (4) cordless Logitech devices at my disposal. From oldest to newest years of purchase (as best as I can remember) they are as follows: 1. M-RBS136 Mouse from pre-2006. No branded "tech" on this one yet at that time. Its antenna is of the full-length USB-stick-sized variety. NO PROBLEMS with this one. 2. VX Nano Notebook Mouse from ~2008. Has branded "Nano Reciever". Again, NO PROBLEMS. It's sitting next to me right now, quietly behaving itself, as I type this. 3. M570 Trackball from ~2012 (?). First Generation "Unifying Receiver" (as according to Wikipedia and shown in the photo linked in Comment 0). Normally connected to my old 32bit rig. It's what's been causing the mysterious HDD spin-down woes on that machine all these years. :( 4. M325 Mouse from ~2017. Also First Generation "Unifying Receiver". Connected to the newest machine of the bunch, an Acer Aspire 3 laptop, and confirmed to spin-down/up that machine's HDD as well. Since they're the newest, I'll be using that mouse and laptop as the lead guinea pig pair in any experiments that might arise from this report.
I can confirm the behaviour. My mouse is an M310. With the mouse on ... hdparm -B /dev/sd?|grep -v ^$ /dev/sda: APM_level = not supported /dev/sdb: APM_level = not supported /dev/sdc: APM_level = 254 /dev/sdd: APM_level = 254 /dev/sde: APM_level = 254 With the mouse off ... # hdparm -B /dev/sd?|grep -v ^$ /dev/sda: APM_level = not supported /dev/sdb: APM_level = not supported /dev/sdc: APM_level = 1 /dev/sdd: APM_level = 1 /dev/sde: APM_level = 1 In my case sda is a spinning rust drive. The other 4 are ssd drives, so it has no impact for me. I suspect it has to be something in the usbhid kernel module.
CC: (none) => davidwhodgins
@sturmvogel : Hi and thank you for your suggestion. Digging around in the BIOS for a fix or workaround wouldn't have occurred to me. Unfortunately it didn't help either. As I said to Lewis in Comment 3, above, I'll be using a newish Acer Aspire 3 laptop as the test subject for any experiments related to this bug report. The closest option matching your suggestion to be found in its BIOS settings was: "Wake on USB when lid closed: [DISABLED]" Why on Earth someone would want to wake a laptop by plugging in a USB device while its lid is closed is beyond me, but whatever. Suffice it to say I left the option as is. Anyway, I can think of three reasons why you might not be having the same problems with your M705. 1. Your M705 is a First Generation Unifying device with newer firmware. 2. Your M705 is a Second Generation Unifying device which is happily unaffected by this bug. 3. A question: do you have the pm-utils package installed? Regarding #3, I always do on my machines, but have seen off-and-on weirdness with it in the past and filed a couple of bug reports accordingly (both since resolved). Both involved HDD spin-down, so I'm wondering if this is more pm-utils related "fun". And regarding #1, I misunderstood the Wikipedia article yesterday. It seems to suggest I need to update the firmware *inside* my devices. I guess I'll have to scrounge around on the Logitech website. Who knows, maybe that will resolve my issue...?
@Dave : Oops, mid-air collision! Thanks for confirming and looking into the matter.
I double checked my bios settings, and this desktop system does not have settings for wake on anything, that I've seen in other systems. No wake on usb, network, etc.
Assigning to the kernel team as it's most likely the usbhid module somehow triggering the changes to the hard drive APM level.
Assignee: bugsquad => kernel
The culprit seems to be pm-utils. I found out why i wasn't able to reproduce it. On two machines where i testet, pm-utils and deps where not installed, so APM_level was always 128. After installation of pm-utils and its deps (pm-fallback-policy, suspend), the same problems reported by John and David occured on both systems. Mouse off -> APM_Level 1 Mouse on -> APM_level 254 After removal of pm-utils, pm-fallback-policy and suspend the systems returned to the original behaviour that APM_level 128 is active all the time.
This is an important discovery (or confirmation of John's doubts). It would be easy for John & Dave to temporarily remove 'pm-utils' to confirm whether the problem then goes, as per the previous comment. Worth doing, I think. pm-utils has no maintainer.
Source RPM: (none) => pm-utils-1.4.1-14.mga8.src.rpm
***facepalm*** Seriously? It *really* is pm-utils... again? Ungh! That's just embarrassing. I only tossed the suggestion in as a possibility given my prior troubled history with that package. Thank you sturmvogel for narrowing the source of the problem down as I should have done right from the start! @Lewis : Okay, I've removed pm-utils from the Aspire 3 and the "toggling" of the APM state is indeed gone. Given its HDD is subjected to the most wear and tear from this bug, I'll leave it off that one altogether for now. I'll remove it from the old 32bit rig at first opportunity as well, but will keep it on the machine connected to the trouble-free Nano mouse so I can experiment on it as need be using the trackball. I'm not sure where we go with this report from here though. The last couple of times pm-utils gave me grief it was, iirc, José Jorge who ironed out the wrinkles. Is he no longer around?
Uninstalling pm-utils also uninstalls pm-fallback-policy. With those two uninstalled, confirming the problem does not happen.
Thanks for confirming this.
CC: lewyssmith => (none)
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=30179
IINM, we never obsolete a package in stable, so keeping this report open in case a user hits it in Mageia 8. It won't be available in Mageia 9
Summary: Logitech Unifying devices "toggle" HDD power state => Logitech Unifying devices "toggle" HDD power state, removing pm-utils solves the problemCC: (none) => marja11
pm-utils and pm-fallback-policy was removed from cauldron!
CC: (none) => geiger.david68210
We stopped supporting Mageia 8 almost 8 months ago https://blog.mageia.org/en/2023/12/30/mageia-8-end-of-life/ That means we also stopped fixing Mageia 8 bugs and that this bug report needs to be closed, regardless of whether it was fixed for Mageia 8 or not. If this particular bug did not get fixed for Mageia 8, then we do regret that. If this issue is still present in Mageia 9 or cauldron, then please reopen this report, write a comment and adjust the "Version:" field. If you are not yet a member of one or our teams, then please consider becoming one. https://wiki.mageia.org/en/Contributing Mageia is a community project, meaning that we, the users, make Mageia together. The more active contributors we have, the more bug reports will get fixed. Besides, being active in a team can be very rewarding. It was and is certainly rewarding to me :-D
Status: NEW => RESOLVEDResolution: (none) => OLD