> > On Mon, 26 Nov 2007 13:39:41 -0800 (PST) > Aaron Young <[EMAIL PROTECTED]> wrote: > > > > > > > Konstantin, some comments: > > > > 3. Why can't you use the HID URB? Locking? Using the HID URB seems > > to work fine for OHCI and EHCI. This is the reason that > > seems to cause so much complication in your code. Back > > in the 2.4 timeframe, Intel did a UHCI KDB implementation > > that used the HID URB. Perhaps it would be useful to dig up that > > old code and compare it? I can possibly pass that code on to you > > if you want... > > > > Also, does enqueing two URBs for the same device cause any > > problems (is it "legal")? > > > > > > -Aaron > > > > > > I explained it earlier: > http://oss.sgi.com/archives/kdb/2007-11/msg00003.html > > KDB Poll driver should not depend on USB kernel code because (in case > when KDB driver uses the same code with kernel USB driver) if CPU0 > executes kernel USB driver and, in the same time, CPU1 hits breakpoint, > CPU0 would be frozen in kernel USB driver. USB spinlocks would be > locked by CPU0, so KDB USB code couldn't get lock and deadlock would > occur. Or, if we don't use lock, kernel USB driver data can't be > corrupted.
Yes - you're right - it's *possible* to get into kdb while locks are held which, if timed just perfectly, could result in kdb crashing trying to walk lists, etc. This is also true of EHCI and OHCI (I think). I've never seen it happen, but it could in theory... I'm not sure it's worth it to rewrite all this code to cover this possibility, so what I might consider doing is just to check for the critical locks being held out of the poll functions and if so, give an error and punt (return -1) - i.e. the keyboard(s) for that HC will not be useable in this case. Much easier and probably sufficient for a debugger IMO. Jay, prepare for another patch for this! ;-) -Aaron --------------------------- Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
