on 18/12/2011 19:39 Hans Petter Selasky said the following: > 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?
Yes :-) I want to see a non-polled code path in the keyboard layer where Giant is not locked. >>> 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! Hope it won't be long. Thank you! -- Andriy Gapon _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[email protected]"
