| Summary: | Logitech Unifying devices "toggle" HDD power state, removing pm-utils solves the problem | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | John L. ten Wolde <johnltw> |
| Component: | RPM Packages | Assignee: | Kernel and Drivers maintainers <kernel> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, geiger.david68210, marja11 |
| Version: | 8 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.mageia.org/show_bug.cgi?id=30179 | ||
| Whiteboard: | |||
| Source RPM: | pm-utils-1.4.1-14.mga8.src.rpm | CVE: | |
| Status comment: | |||
|
Description
John L. ten Wolde
2022-02-22 01:39:36 CET
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.
Marja Van Waes
2022-03-16 16:04:40 CET
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 problem pm-utils and pm-fallback-policy was removed from cauldron! CC:
(none) =>
geiger.david68210 |