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

[Hans Petter Selasky]

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

--HPS