On Wed, 13 Feb 2013, Tim Sander wrote: > Hi Thomas > > > Just another update on this stuff. I noticed that there has been a patch > > > added* with spinlocks to the imx.c serial driver. I reverted this patch > > > and now my serialfuz programm "only" kills the serial port with a not so > > > nice oom condition. But at least it does not show the runaway interrupt > > > problem. > > That does not make any sense, really. The runnaway interrupt issue is > > completely unrelated to this commit. > One thing that puzzles me is the fact that it does! So removing the mentioned > spinlock patch creates the same result as using your fixed patch. > > As the other problem with the driver i posted shows the same interrupt runaway > symptom as this i have a very bad gut feeling about this... > Or probably its not a runnaway interrupt problem but a double > spin_lock_irqsave. Well, you claimed that it is a runnaway interrupt. So much for the theory :) The issue with the recursive locking is not an RT issue. You can observe the problem on mainline, when you enable PROVE_LOCKING and issue a sysrq or oopsing in a section which holds the port.lock already. The reason why you can't observe it with PREEMPT_RT_FULL=n and PROVE_LOCKING=n is, that the spinlocks on UP machines are compiled away, so recursive locking does not lead to an observable dead lock. > Also the fact that my serialfuz program i posted is able to give the system an > Out Of Memory condition is strange. I mean throwing random chars at a getty > should'nt exhaust memory so fast. That's true, but w/o seing the OOM output I can't tell what's exhausting the memory. 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
