linux-kernel - Logitech autosuspend + runtime

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikSwviozL+ezdvqengQpag4cpbLxR+vgs_JKXbZ@mail.gmail.com>
Date:	Sat, 5 Feb 2011 13:01:57 -0500
From:	Andrew Lutomirski <luto@....edu>
To:	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	pm list <linux-pm@...ts.linux-foundation.org>
Subject: Logitech autosuspend + runtime_pm loses input

I have a Logitech MX Revolution (a cordless mouse receiver) plugged
into a Logitech G15 (a keyboard w/ a hub) plugged into an Intel Cougar
Point EHCI controller.  (Results are the same on an xHCI controller,
though.)

With autosuspend *or* runtime PM off, everything works.  (Well, the
G15 is buggy and occasionally crashes and doesn't recover until
powercycled, but that even happens on Windows.)  With runtime PM
enabled on the whole tree, I have problems with autosuspend.

If I enable autosuspend on just the mouse by doing:

echo 2 >./1-1/1-1.2/1-1.2.3/power/autosuspend
(where that device is Bus 001 Device 005: ID 046d:c51a Logitech, Inc.
MX Revolution/G7 Cordless Mouse), then after about two seconds of not
moving the mouse, the mouse ignores the first second or so of motion
when I start moving it again.

If I enable autosuspend on just part of the keyboard by doing:

echo 2 >./1-1/1-1.2/1-1.2.1/power/autosuspend
(that's Bus 001 Device 004: ID 046d:c221 Logitech, Inc. G11/G15
Keyboard / Keyboard)

then after a couple seconds of not typing, my next keystroke is lost or delayed.

It seems to be enough to turn off runtime PM (via power/control) OR
turn off autosuspend on the keyboard device to make the keyboard work
and on the mouse device to make the mouse work.

Is this a case of "don't do that, you fool," or is there a legitimate
bug to be fixed in the runtime pm code?

My motherboard is Intel DH67GD (ordered just before they canceled
production) with latest BIOS.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/