> > again, please let the -rt maintainers sort out which patches need to be > > propagated to upstream maintainers. > > This appears to be not only RT issue though. In theory, this can be Agreed - RT is showing up a real bug here. > triggered on SMP also. Thanks to Daniel Walker for pointing this out. It looks correct to me except that you cannot use spin_lock/disable_irq in that way safely. You must always disable_irq before taking the lock, or prove it is safe and use disable_irq_nosync The reason: CPU#0 spin_lock_... [taken] CPU#1 IRQ CPU#1 spin_lock [waits] CPU#0 disable_irq (deadlock) Note that is also not generally safe to do disable IRQ on device spin_lock disable_irq because IRQ propogation occurs asynchronously to PCI bus traffic even on PC class systems (especially Pentium-PII era boxes with SMP). You can disable the device IRQ and still have an IRQ 'in flight' that arrives afterwards. So the fix needs some reworking in its ordering I think Alan -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
