From owner-freebsd-usb@FreeBSD.ORG Sat Dec 17 17:14:45 2011 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EAA41065670; Sat, 17 Dec 2011 17:14:45 +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 5D7868FC15; Sat, 17 Dec 2011 17:14:41 +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 217175245; Sat, 17 Dec 2011 18:14:38 +0100 From: Hans Petter Selasky To: Andriy Gapon Date: Sat, 17 Dec 2011 18:12:09 +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> <4EECADDA.4070704@FreeBSD.org> In-Reply-To: <4EECADDA.4070704@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: <201112171812.09652.hselasky@c2i.net> Cc: usb@freebsd.org, freebsd-hackers@freebsd.org, John Baldwin , mdf@freebsd.org Subject: Re: kern_yield vs ukbd_yield X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 17:14:45 -0000 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