From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 15 23:19:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39D201065672; Thu, 15 Dec 2011 23:19:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id E294F8FC12; Thu, 15 Dec 2011 23:19:06 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 216457661; Fri, 16 Dec 2011 00:19:04 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Fri, 16 Dec 2011 00:16:33 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EE51CB5.1060505@FreeBSD.org> <201112152356.35336.hselasky@c2i.net> <4EEA7D52.4000503@FreeBSD.org> In-Reply-To: <4EEA7D52.4000503@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112160016.33776.hselasky@c2i.net> Cc: usb@freebsd.org, mdf@freebsd.org, Andriy Gapon Subject: Re: kern_yield vs ukbd_yield X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 23:19:08 -0000 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