On Thu, 28 Mar 2024, Michael Schmitz wrote:
On 28/03/24 12:29, Finn Thain wrote:
On Wed, 27 Mar 2024, Michael Schmitz wrote:
Now none of this has got us any closer to a solution for the spinlock
recursion bug...
It appears that the spinlock recursion check really works: I am able
to reproduce the following failure every time I paste too much text
into the qemu console.
This looks like a straight-forward driver bug, whereby the "irq flood"
printk() results in pmz_console_write() attempting to lock the
spinlock already locked by pmz_interrupt(). The spinlock at 0x62e140
is the one in struct uart_port.
That's a legitimate recursion warning then. pmz_console_write() should
not retake the lock already held when called from interrupt context.
I agree the recursion checks did work correctly in this case.
Spinlock recursion in scheduler_tick() doesn't look possible from
reentering scheduler_tick() through code in its call path, so the
mechanism there would be different.
We did rule out the VIA timer interrupt (or MFP timer A interrupt)
getting reentered, right?
I never added an assertion to prove that because I don't have a way to
reproduce the "spinlock recursion" BUG reported by Guenter.
