Date: Thu, 6 Aug 2009 23:57:44 -0700 From: Navdeep Parhar <nparhar@gmail.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, alfred@freebsd.org, rwatson@freebsd.org, Bruce Evans <brde@optusnet.com.au>, svn-src-head@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: svn commit: r195960 - in head/sys/dev/usb: . controller input Message-ID: <20090807065744.GA23942@doormat.home> In-Reply-To: <200908070830.47894.hselasky@c2i.net> References: <20090802192902.GS47463@elvis.mu.org> <20090804031407.GA8974@hub.freebsd.org> <d04e16b70908061247i7ceccefx37566df937b74eaa@mail.gmail.com> <200908070830.47894.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090807065744.GA23942>