Bug 30080 - Logitech Unifying devices "toggle" HDD power state, removing pm-utils solves the problem
Summary: Logitech Unifying devices "toggle" HDD power state, removing pm-utils solves...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
Depends on:
Reported: 2022-02-22 01:39 CET by John L. ten Wolde
Modified: 2023-06-19 01:28 CEST (History)
3 users (show)

See Also:
Source RPM: pm-utils-1.4.1-14.mga8.src.rpm
Status comment:


Description John L. ten Wolde 2022-02-22 01:39:36 CET
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.
Comment 1 sturmvogel 2022-02-22 08:22:13 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.
Comment 2 Lewis Smith 2022-02-22 20:18:05 CET
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

Comment 3 John L. ten Wolde 2022-02-22 23:49:39 CET
@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.
Comment 4 Dave Hodgins 2022-02-23 00:09:56 CET
I can confirm the behaviour. My mouse is an M310.

With the mouse on ...
hdparm -B /dev/sd?|grep -v ^$
 APM_level      = not supported
 APM_level      = not supported
 APM_level      = 254
 APM_level      = 254
 APM_level      = 254

With the mouse off ...
# hdparm -B /dev/sd?|grep -v ^$
 APM_level      = not supported
 APM_level      = not supported
 APM_level      = 1
 APM_level      = 1
 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

Comment 5 John L. ten Wolde 2022-02-23 00:28:30 CET
@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...?
Comment 6 John L. ten Wolde 2022-02-23 00:31:49 CET
@Dave :  Oops, mid-air collision!  Thanks for confirming and looking into the matter.
Comment 7 Dave Hodgins 2022-02-23 00:34:05 CET
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.
Comment 8 Dave Hodgins 2022-02-23 00:35:46 CET
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

Comment 9 sturmvogel 2022-02-23 11:10:26 CET
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.
Comment 10 Lewis Smith 2022-02-23 21:14:43 CET
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

Comment 11 John L. ten Wolde 2022-02-23 22:23:31 CET

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?
Comment 12 Dave Hodgins 2022-02-23 22:24:28 CET
Uninstalling pm-utils also uninstalls pm-fallback-policy. With those two
uninstalled, confirming the problem does not happen.
Comment 13 Lewis Smith 2022-02-26 09:47:25 CET
Thanks for confirming this.

CC: lewyssmith => (none)

Marja Van Waes 2022-03-16 16:04:40 CET

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=30179

Comment 14 Marja Van Waes 2022-03-16 16:12:48 CET
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
CC: (none) => marja11

Comment 15 David GEIGER 2023-06-19 01:28:24 CEST
pm-utils and pm-fallback-policy was removed from cauldron!

CC: (none) => geiger.david68210

Note You need to log in before you can comment on or make changes to this bug.