On Saturday 17 December 2011 15:57:30 Andriy Gapon wrote:
> Replying further...
> > Not directly, but indirect. You know, if you pause thread 1 (which I
> > thought was thread 0), then other thread will get a chance to run.
> pause() could be a sufficient action to let other thread run, but it is not
> a required action.  As we've already discusses earlier all the USB threads
> have sufficiently high priorities to get runnable while other kernel
> threads are runnable.  Only certain interrupt threads could have prevented
> them from running, but that's definitely not the case.
> > It might also be that Giant is locked by syscons, and that unless you
> > pause or yield, then Giant will block other parts of USB, like the
> > callback thread, which is Giant locked for ukbd only to run.
> > 


> > Maybe that is the explanation?
> Not sure if you are hypothesizing or if this is something that you
> experienced during development and testing.

I have only observed that no key-presses are returned by the UKBD polling 
mechanism, if the ukbd_yield() is removed. I have not investigated this 

If you use pause() that will slowdown dumphandling which is also polling for 
key-presses, so this must be added conditionally.

> Let's consider a few observations.
> First, syscons doesn't acquire Giant anywhere in the path started from
> cngetc. Actually, I believe that the only place where Giant is now
> explicitly acquired in the whole syscons code can be safely replaced with
> an assert that the Giant is already held.
> Second, the polling mode is designed to be usable in situations where other
> threads are not running.  So in general it should not depend on other
> threads being able to make any progress.

Sure, but it is not that simple to poll a key-press from USB like with AT 
keyboards. You need to go through a bunch of stuff, including busdma before 
you get the keypress.

freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to