On Fri, Aug 07, 2009 at 08:30:45AM +0200, Hans Petter Selasky wrote: > 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
Note that I did not enter ddb on a panic. I entered it voluntarily to take a look at some things. After that I was hoping to continue with business as usual. > board 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 ... ok. And my question, just like with the previous problem, is: Can something be done about it or are we expected to learn to live with this? All of this is much much better than having *no* USB keyboard with ddb, but there definitely are some kinks to be ironed out. Regards, Navdeep _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
