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:
>> 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!
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"