Date: Sun, 18 Dec 2011 18:39:24 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Andriy Gapon <avg@freebsd.org> Cc: usb@freebsd.org, freebsd-hackers@freebsd.org, mdf@freebsd.org Subject: Re: kern_yield vs ukbd_yield Message-ID: <201112181839.24813.hselasky@c2i.net> In-Reply-To: <4EEDC771.800@FreeBSD.org> References: <4EE51CB5.1060505@FreeBSD.org> <201112171806.43764.hselasky@c2i.net> <4EEDC771.800@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 18 December 2011 11:58:57 Andriy Gapon wrote: > on 17/12/2011 19:06 Hans Petter Selasky said the following: > > If the problem is only in UKBD driver, I don't think this is a big > > problem to solve. The reason for the auto-magic locking, is that I've > > sometimes seen callers in non-polling mode call into UKBD without Giant > > locked. And this causes a panic when starting USB transfers, because the > > code expects Giant to be locked. > > Hmm, do you have an example of such a panic? I couldn't find how this could > be possible in my examination of non-polling entry points into syscons and > kbd drives. mtx_assert(&Giant, MTX_OWNED); will panic if Giant is not locked. Do you need an example? > > > Requirement: I would say that to use UKBD polling mode, the scheduler > > must be stopped. Else you should not use polling mode at all. I think > > that mountroot is getting characters the wrong way in this regard. > > I think that this is a too strong / unnecessary requirement. I think that > now (after my recent syscons commits) ukbd should work correctly and > optimally in this context. > > I have written a small article about my analysis of locking in syscons, > underlying kbd drivers and ukbd in particular: > http://wiki.freebsd.org/AvgSyscons > I could have misunderstood or missed things, so I will appreciate a review > and discussion of my observations. Thank you! I will have a look at it when I find some time! --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112181839.24813.hselasky>