Thomas, On Mon, Feb 4, 2013 at 6:40 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > Jacky, > > On Mon, 4 Feb 2013, Jacky Lam wrote: > >> Thanks. > > Please stop top posting! > Thanks for reminding. >> I finally find that if I disable interrupt during ata_qc_issue() in >> libata-scsi.c, my sata driver works without any problem. > > This is wrong. Which driver are you taling about ? > >> But I find USB EHCI driver is more complicated. Kernel crashes every >> where when RT is turned on. It seems whenever the stack spin_lock >> ehci->lock and interrupt comes at that moment, kernel will be crashes. >> The reason is EHCI interrupt handler will also take the same lock. If >> my point of view, USB stack seems no PREEMPT_RT safe. Is it correct? >> Am I miss anything? > > Probably. First of all you don't tell us which driver you are > using. And w/o seing the code and the output of the kernel crash, we > can't help you at all. > I am sorry for that. But it is a driver for our in-house hardware. It seems meaningless even I post the source here. Please tell me if it did help. From your statement above, it seems PREEMPT_RT patch do not work with USB stack. Is it true? I am happy to post the fix here if I can fix that. While I am porting my drivers to PREEMPT_RT patched kernel, I find a common problem. In stock kernel, whenever I need to touch some data structures in driver code and also in interrupt handler, we can protect them by spin_lock_irqsave(). But in PREEMT_RT kernel, while the driver code touching the data structures, interrupt can still come in. If I don't protect the data structure by spinlcok, the data structures will corrupt. If I put it, rt_spin_lock function will cause a kernel dump. Of course, I can use raw_spin_lock_irqsave() instead. But for the case like USB stack and SATA stack, if I disable the interrupt just like what I did for ata_qc_issue(). It seems not very good idea. Is there any rule to resolve such conflict? > Thanks, > > tglx -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
