I'm testing Linus' tree as the merge window happens, and I've hit an
issue with what I believe is USB device power management (or something)
that is causing my mouse and keyboard to become unresponsive. After a
very short time of non-use, either device will cut out. I can move the
mouse around but it doesn't relay to the screen and I noticed this is
because the laser is turned off. If I click a button on it, it will
turn back on and function again until a small period of non-use. The
keyboard exhibits similar behavior, "ignoring" the first few key strokes
until it wakes back up.
I found this thread:
http://thread.gmane.org/gmane.linux.usb.general/64292
and
http://marc.info/?t=133552726500001&r=1&w=2
which have similar symptoms, but the kernels I'm using have the
subsequent patches applied. I'm doing a git bisect at the moment, with
72c04af as the starting good commit and 61011677 as the first bad. I'll
let you know what comes of this, but I thought I'd mail about it now in
case anyone has any ideas.
josh
On Thu, 24 May 2012, Josh Boyer wrote:
> I'm testing Linus' tree as the merge window happens, and I've hit an
> issue with what I believe is USB device power management (or something)
> that is causing my mouse and keyboard to become unresponsive. After a
> very short time of non-use, either device will cut out. I can move the
> mouse around but it doesn't relay to the screen and I noticed this is
> because the laser is turned off. If I click a button on it, it will
> turn back on and function again until a small period of non-use. The
> keyboard exhibits similar behavior, "ignoring" the first few key strokes
> until it wakes back up.
>
> I found this thread:
>
> http://thread.gmane.org/gmane.linux.usb.general/64292
> and
> http://marc.info/?t=133552726500001&r=1&w=2
>
> which have similar symptoms, but the kernels I'm using have the
> subsequent patches applied. I'm doing a git bisect at the moment, with
> 72c04af as the starting good commit and 61011677 as the first bad. I'll
> let you know what comes of this, but I thought I'd mail about it now in
> case anyone has any ideas.
It sounds like you have autosuspend enabled on the mouse and keyboard,
and they don't work very well with it. Setting the sysfs power/control
attributes for the two devices to "on" will prevent autosuspend.
I don't know why this would have started happening after a kernel
upgrade. Those settings are normally controlled by userspace apps.
Let us know what you find.
Alan Stern
On Thu, May 24, 2012 at 04:48:26PM -0400, Alan Stern wrote:
> On Thu, 24 May 2012, Josh Boyer wrote:
>
> > I'm testing Linus' tree as the merge window happens, and I've hit an
> > issue with what I believe is USB device power management (or something)
> > that is causing my mouse and keyboard to become unresponsive. After a
> > very short time of non-use, either device will cut out. I can move the
> > mouse around but it doesn't relay to the screen and I noticed this is
> > because the laser is turned off. If I click a button on it, it will
> > turn back on and function again until a small period of non-use. The
> > keyboard exhibits similar behavior, "ignoring" the first few key strokes
> > until it wakes back up.
> >
> > I found this thread:
> >
> > http://thread.gmane.org/gmane.linux.usb.general/64292
> > and
> > http://marc.info/?t=133552726500001&r=1&w=2
> >
> > which have similar symptoms, but the kernels I'm using have the
> > subsequent patches applied. I'm doing a git bisect at the moment, with
> > 72c04af as the starting good commit and 61011677 as the first bad. I'll
> > let you know what comes of this, but I thought I'd mail about it now in
> > case anyone has any ideas.
>
> It sounds like you have autosuspend enabled on the mouse and keyboard,
> and they don't work very well with it. Setting the sysfs power/control
> attributes for the two devices to "on" will prevent autosuspend.
>
> I don't know why this would have started happening after a kernel
> upgrade. Those settings are normally controlled by userspace apps.
> Let us know what you find.
OK, the bisect turned up this as the first bad commit:
54d3f8c63d6940966217b807972778fb17c3fa82 is the first bad commit
commit 54d3f8c63d6940966217b807972778fb17c3fa82
Author: Matthew Garrett <[email protected]>
Date: Fri May 11 16:08:28 2012 +0800
usb: Set device removable state based on ACPI USB data
ACPI offers two methods that allow us to infer whether or not a USB port
is removable. The _PLD method gives us information on whether the port is
"user visible" or not. If that's not present then we can fall back to the
_UPC method which tells us whether or not a port is connectable.
Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by: Lan Tianyu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
:040000 040000 d0845dc1e64bafbdc069d80edf1b43958e091b25 6cc92b4dd1f957d91572bbc60ebbff20e325d52f M drivers
At this point I'm not really sure what I should be poking at to figure
out what/how the power is getting turned off to the keyboard and mouse.
I can provide acpidump output, etc. Let me know what to check for and
I'll happily dig more.
josh
The kernel's fine, udev isn't. Let me push the patch for that.
--
Matthew Garrett | [email protected]
On Fri, May 25, 2012 at 12:41:52PM +0100, Matthew Garrett wrote:
> The kernel's fine, udev isn't. Let me push the patch for that.
Er... can you be more verbose? Or point me to a previous discussion?
>From a packaging standpoint, are distributions going to have to require
a newer udev package before the 3.5 kernel can be used?
josh
On Fri, May 25, 2012 at 07:45:12AM -0400, Josh Boyer wrote:
> On Fri, May 25, 2012 at 12:41:52PM +0100, Matthew Garrett wrote:
> > The kernel's fine, udev isn't. Let me push the patch for that.
>
> Er... can you be more verbose? Or point me to a previous discussion?
>
> From a packaging standpoint, are distributions going to have to require
> a newer udev package before the 3.5 kernel can be used?
I think I mentioned this previously, but this is the 3.5 kernel running
on F17 userspace. So:
udev-182-1.fc17.x86_64
Rawhide is on the same major version.
josh
On Fri, May 25, 2012 at 07:45:12AM -0400, Josh Boyer wrote:
> On Fri, May 25, 2012 at 12:41:52PM +0100, Matthew Garrett wrote:
> > The kernel's fine, udev isn't. Let me push the patch for that.
>
> Er... can you be more verbose? Or point me to a previous discussion?
>
> From a packaging standpoint, are distributions going to have to require
> a newer udev package before the 3.5 kernel can be used?
No, you'll only see this if you're running very new udev.
--
Matthew Garrett | [email protected]
On 2012/5/25 19:39, Josh Boyer wrote:
> On Thu, May 24, 2012 at 04:48:26PM -0400, Alan Stern wrote:
>> On Thu, 24 May 2012, Josh Boyer wrote:
>>
>>> I'm testing Linus' tree as the merge window happens, and I've hit an
>>> issue with what I believe is USB device power management (or something)
>>> that is causing my mouse and keyboard to become unresponsive. After a
>>> very short time of non-use, either device will cut out. I can move the
>>> mouse around but it doesn't relay to the screen and I noticed this is
>>> because the laser is turned off. If I click a button on it, it will
>>> turn back on and function again until a small period of non-use. The
>>> keyboard exhibits similar behavior, "ignoring" the first few key strokes
>>> until it wakes back up.
>>>
>>> I found this thread:
>>>
>>> http://thread.gmane.org/gmane.linux.usb.general/64292
>>> and
>>> http://marc.info/?t=133552726500001&r=1&w=2
>>>
>>> which have similar symptoms, but the kernels I'm using have the
>>> subsequent patches applied. I'm doing a git bisect at the moment, with
>>> 72c04af as the starting good commit and 61011677 as the first bad. I'll
>>> let you know what comes of this, but I thought I'd mail about it now in
>>> case anyone has any ideas.
>>
>> It sounds like you have autosuspend enabled on the mouse and keyboard,
>> and they don't work very well with it. Setting the sysfs power/control
>> attributes for the two devices to "on" will prevent autosuspend.
>>
>> I don't know why this would have started happening after a kernel
>> upgrade. Those settings are normally controlled by userspace apps.
>> Let us know what you find.
>
> OK, the bisect turned up this as the first bad commit:
>
> 54d3f8c63d6940966217b807972778fb17c3fa82 is the first bad commit
> commit 54d3f8c63d6940966217b807972778fb17c3fa82
> Author: Matthew Garrett<[email protected]>
> Date: Fri May 11 16:08:28 2012 +0800
>
> usb: Set device removable state based on ACPI USB data
>
> ACPI offers two methods that allow us to infer whether or not a USB port
> is removable. The _PLD method gives us information on whether the port is
> "user visible" or not. If that's not present then we can fall back to the
> _UPC method which tells us whether or not a port is connectable.
>
> Signed-off-by: Matthew Garrett<[email protected]>
> Signed-off-by: Lan Tianyu<[email protected]>
> Signed-off-by: Greg Kroah-Hartman<[email protected]>
>
> :040000 040000 d0845dc1e64bafbdc069d80edf1b43958e091b25 6cc92b4dd1f957d91572bbc60ebbff20e325d52f M drivers
>
> At this point I'm not really sure what I should be poking at to figure
> out what/how the power is getting turned off to the keyboard and mouse.
> I can provide acpidump output, etc. Let me know what to check for and
> I'll happily dig more.
hi josh:
Have you cat power/runtime_status and control under usb device sys
directory when the issue happen? We can determine which state the usb
device is in when the issue is takeing place.
>
> josh
--
Best Regards
Tianyu Lan
linux kernel enabling team
udev is being a little too aggressive in enabling autosuspend. I've just
sent a patch upstream, but here it is:
commit 35c62663b93adb6ab321ca1e6ac6f1ba580b37aa
Author: Matthew Garrett <[email protected]>
Date: Fri May 25 08:00:05 2012 -0400
rules: Limit USB autosuspend on USB HID devices
Some USB ports on external hubs may be reported as "fixed". We only want
to auto-enable this on ports that are internal to the machine, so check
the parent state as well.
diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
index d5d5897..fc44b94 100644
--- a/rules/42-usb-hid-pm.rules
+++ b/rules/42-usb-hid-pm.rules
@@ -46,4 +46,10 @@ ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="04b3", ATTR{idProduct}=="4012
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="14dd", ATTR{idProduct}="0002", TEST=="power/control", ATTR{power/control}="auto"
# USB HID devices that are internal to the machine should also be safe to autosuspend
+
+ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="removable", GOTO="usb_hid_pm_end"
+ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="unknown", GOTO="usb_hid_pm_end"
+
ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="03", ATTRS{removable}=="fixed", TEST=="../power/control", ATTR{../power/control}="auto"
+
+LABEL="usb_add_pm_end"
--
Matthew Garrett | [email protected]
On Fri, May 25, 2012 at 02:08:26PM +0100, Matthew Garrett wrote:
> udev is being a little too aggressive in enabling autosuspend. I've just
> sent a patch upstream, but here it is:
Aside from the small buglet in the rule below, this seems to solve the
issue. I've booted Linus' tree as of this morning with a fixed udev and
initramfs and the keyboard and mouse are working well now.
> diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
> index d5d5897..fc44b94 100644
> --- a/rules/42-usb-hid-pm.rules
> +++ b/rules/42-usb-hid-pm.rules
> @@ -46,4 +46,10 @@ ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="04b3", ATTR{idProduct}=="4012
> ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="14dd", ATTR{idProduct}="0002", TEST=="power/control", ATTR{power/control}="auto"
>
> # USB HID devices that are internal to the machine should also be safe to autosuspend
> +
> +ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="removable", GOTO="usb_hid_pm_end"
> +ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="unknown", GOTO="usb_hid_pm_end"
> +
> ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="03", ATTRS{removable}=="fixed", TEST=="../power/control", ATTR{../power/control}="auto"
> +
> +LABEL="usb_add_pm_end"
LABEL should be "usb_hid_pm_end" here.
josh