Date: Fri, 7 Aug 2009 11:24:44 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: src-committers@freebsd.org, nparhar@gmail.com, svn-src-all@freebsd.org, alfred@freebsd.org, rwatson@freebsd.org, brde@optusnet.com.au, svn-src-head@freebsd.org Subject: Re: svn commit: r195960 - in head/sys/dev/usb: . controller input Message-ID: <200908071124.47955.hselasky@c2i.net> In-Reply-To: <20090807.005400.-1749708164.imp@bsdimp.com> References: <20090804031407.GA8974@hub.freebsd.org> <200908070830.47894.hselasky@c2i.net> <20090807.005400.-1749708164.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 07 August 2009 08:54:00 M. Warner Losh wrote: > In message: <200908070830.47894.hselasky@c2i.net> > > Hans Petter Selasky <hselasky@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. Please try the following patch and report back. There is some Giant fuzz which you can ignore. I will see if I can followup a patch against -current later today. http://perforce.freebsd.org/chv.cgi?CH=167084 --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200908071124.47955.hselasky>