On Friday 16 December 2011 00:05:54 Andriy Gapon wrote:
> on 16/12/2011 00:56 Hans Petter Selasky said the following:
> > On Thursday 15 December 2011 15:17:01 Andriy Gapon wrote:
> >> Hmm... I looked at the history of ukbd.c (which I should have done from
> >> the very start) and I see two relevant revisions:
> >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=199816&r
> >> 2=2 03896&pathrev=203896
> >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=223755&r
> >> 2= 223989&pathrev=223989
> >>
> >> So, first use of pause(9) was introduced to work around current broken
> >> syscons polling mechanism. Then pause(9) was replaced with the
> >> hand-rolled yield to fix a problem at shutdown, which supposedly was
> >> caused by times being stopped.
> >>
> >> None of the commits seems to be directly related to thread priorities.
> >
> > 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.
> >
> > 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?
>
> Maybe. Perhaps even. But let me quote the commit messages just in case.
>
> Commit message #1:
> Detect when we are polling from kernel via cngetc() in the boot process and
> reserve the keypresses so they do not get passed to syscons.
>
> Commit message #2:
> Fix for dump after shutdown with USB keyboard plugged in. It appears that
> the system timer is stopped during shutdown and that the pause() statement
> in ukbd causes infinite hang in this regard. The fix is to use mi_switch()
> instead of pause() to do the required task switch to ensure that the
> required USB processes get executed.
>
> So the reason I asked the above question was that the issues that we are
> discussing now were never mentioned before. So if you know that those
> issue really exist, then maybe it is worthwhile describing and documenting
> them in detail. As you can see the commit messages mention neither thread
> priorities nor Giant, instead they talk about other rather specific (and
> plausible) issues.
Hi,
I think I was not aware about the Giant locking maybe having something to do
about this. I was just thinking about this recently, that syscons and all
keyboard stuff, currently is Giant locked. Scary?
I can always become better writing commit messages! What is your plan forward
then with regard to the Giant lock problem?
If one thread is like:
while (1)
{
lock(Giant);
c = get nonblocking key from console();
unlock(Giant);
}
And the other is like:
if (callback complete) {
lock(Giant);
run callback();
unlock(Giant);
}
Who gets to run?
--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"
