linux-kernel - Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 3 Aug 2007 13:47:17 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jiri Kosina <jikos@...os.cz>
cc:	David Brownell <david-b@...bell.net>,
	<linux-usb-devel@...ts.sourceforge.net>,
	Dave Jones <davej@...hat.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Oliver Neukum <oliver@...kum.org>,
	Rogan Dawes <lists@...es.za.net>, Greg KH <gregkh@...e.de>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend
 by	default on certain device classes

On Fri, 3 Aug 2007, Jiri Kosina wrote:

> What I have been seeing with both these keyboards was: if connected to 
> UHCI controller, root hub not auto-suspended, as soon as they got 
> autosuspended, and keys were pressed on them rapidly, very often some 
> keypressess got lost. I didn't experience this on OHCI, but I remember 
> Alan saying that he triggered it on OHCI too, right?
> 
> Seemed like a timing issue - by lowering the polling timeout we were able 
> to make things much better, but that of course costs us more power etc. 
> and it's even not sure if it is an ultimate solution.

Jiri and I ran a few tests at OLS, and we each did additional testing
on our own.  We looked at a small selection of keyboards; the ones I
tested were by Apple and HP.  Some keyboards had embedded hubs and
others didn't.  Some of our testing was with the keyboard behind an
external hub.  Sometimes only the keyboard controller was suspended,
sometimes the controller and the embedded hub were, sometimes the
external hub and everything downstream of it were, and sometimes the
root hub was.  We tested with both UHCI and OHCI -- I may even have
done some tests with EHCI and a high-speed hub, I don't remember now.

The end result was that some scenarios worked more reliably than 
others.  There were lots of variables and it was hard to tie overall 
behavior with system settings.  It did seem that in situations where 
the topmost suspended device was plugged into a UHCI root hub, 
increasing the the root hub's polling rate helped.  But it didn't 
always help, and in any case we certainly don't want to change a kernel 
timer from 250 ms to 32 ms whenever a device is suspended!

The bad behavior we observed, as Jiri described, was that rapid typing 
on a suspended keyboard would often cause one or more of the keystrokes 
to be lost.  The probability of this happening varied with the 
circumstances, but I don't think I ever found a combination that was 
100% reliable.  It could well be a timing issue, or buffering -- 
there's no real way to know.

An additional drawback to autosuspend for keyboards is the fact that 
the NumLock, CapsLock, etc. LEDs go out.

We didn't test any mice (at least, I didn't).  However it has been
reported that while some suspended mice will send wakeup requests when
they are moved, others won't.  Certainly an optical mouse won't.

All in all, it appears that the simplest and most user-friendly
approach is just not to autosuspend keyboards and mice.

Alan Stern

-
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/