Cheers for that David. Those patches still apply cleanly, but don't seem to affect this particular problem. I'm now using the 2.6.29.1 patch and the 2.6.29.1-rt5 patch against Linux-omap 90e758af52ba803cba233fabee81176d99589f09. Here is the log now: http://hugovincent.com/files/lkml-20090407/boot4.log I've spent enough time on this already, so I think I'll wait and see if anyone takes on fixing these issues, and hope that my MUSB Rx DMA problems go away when the pending patches hit. The RT patchset already is working well enough for me in my application, and the only reason I would absolutely *need* to fix it is because of nagging doubts about possible deadlocks or crashes after I've deployed my board into the field... Thanks for all your help. Hugo On Thu, Apr 9, 2009 at 10:21 AM, David Brownell <david-b@xxxxxxxxxxx> wrote: > On Tuesday 07 April 2009, Hugo Vincent wrote: >> > http://hugovincent.com/files/lkml-20090407/boot3.log >> >> Can anyone give me any pointers on where to start for fixing the >> problems shown in the above boot log? > > You'll have to start finding out about all the funky rules > which apply to the -RT kernels, I think. > > As a rule, getting drivers to work in RT kernels involves > some changes. Not all of those changes can work in mainline > kernels. Some of the changes are driver issues; while some > are changes in RT framework code. Some are bugfixes. > > There are a lot of reasons why not all the RT patches have > made it to mainline ... > > >> It looks like some fairly low level locking bugs (spinlock vs >> raw_spinlock maybe?) in twl4030 IRQ handling and GP timer/clock event >> source setup. > > The first lockdep warning is about some IRQ dispatch code. > > I happen to have the appended patches sitting around; they > might affect this particular problem (or might not). I don't > know if they'd even apply to the RT kernel. > > Alternatively, there's some odd rule about using workqueues > in the current RT code. Like not being able to trigger them > from all the usual contexts. If so, that seems buglike to me. > > - Dave > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
