svn commit: r195960 - in head/sys/dev/usb: . controller input

[M. Warner Losh]

In message: <200908070830.47894.hselasky at c2i.net>
            Hans Petter Selasky <hselasky at c2i.net> writes:
: On Thursday 06 August 2009 21:47:16 Navdeep Parhar wrote:
: > >> See attached patch. Please test and report back.
: > >
: > > This patch fixes my problem.  The machine is remote and I'm unable
: > > to test whether the USB keyboard and keystroke repetition works, but
: > > core dumps to a SATA disk are now as fast as they were before
: > > r195960.  Thanks.
: >
: > I finally got a chance to try a USB keyboard with ddb, and things did
: > not go too well overall.  While inside ddb, keystrokes were recognized
: > properly and repetition worked too.  But after exiting ddb, the
: > keyboard wouldn't work - there wasn't any visible response to
: > keystrokes.  Also, I kept seeing the login prompt continually scroll
: > up, as if someone was pressing <return> repeatedly.  It certainly
: > wasn't me :-)
: >
: > Are you assuming that a user will not resume normal operation after
: > entering the debugger?  A panic/reboot isn't the only exit route from
: > ddb.....
: >
: > Simple sequence of steps to reproduce problem:
: > ctrl-alt-esc on the USB keyboard
: > db> c<return>
: 
: This is like expected.
: 
: Once paniced, USB operation is blocked on the USB controller which the 
: keyboard belongs to, because USB does not receive any polling-complete call, 
: so that it can clean up the state in the USB controller! This mainly has to do 
: with avoid calling wakeup() during polling.
: 
: To avoid wakeup() calls, USB sets some bits, which must be cleared when 
: polling is complete, which is currently not done, because USB doesn't know 
: when polling is complete ...

Polling isn't supposed to work like this...  The rest of the system
effects a poll without these side effects.

Warner