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. > >
Hi, > > 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 further. 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. --HPS _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
