Date: Fri, 07 Aug 2009 00:54:00 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: hselasky@c2i.net 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: <20090807.005400.-1749708164.imp@bsdimp.com> In-Reply-To: <200908070830.47894.hselasky@c2i.net> References: <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
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.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090807.005400.-1749708164.imp>