Messages in this thread Patch in this message | | | From | Christian Borntraeger <> | Subject | Re: Spinlock recursion in hvc_poll | Date | Tue, 5 Aug 2008 22:53:10 +0200 |
| |
Am Dienstag, 5. August 2008 schrieb Jeremy Fitzhardinge: > Alex Nixon wrote: > >>> Well I say fixed - it just means I can proceed to a spinlock recursion > >>> BUG() 2 secs into the boot process, but it should be easier to track down > >>> with printks and a coherent stack dump at my disposal. > >>> > >>> > >> What's the backtrace on this? > >> > > > > I just turned DEBUG_SPINLOCKS back on to try catch this bug again, and it > > seems to occur (very roughly) 1/10 of the time, with nothing changing between > > runs.
Ok, this is a guess, I dont fully understand the backtrace.
request_irq tries to call the handler if the IRQ is shared. The irq handler calls hvc_poll and hvc_kill which might take the same spinlock. Can you test it this patch fixes the problem?
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> --- drivers/char/hvc_console.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/char/hvc_console.c =================================================================== --- linux-2.6.orig/drivers/char/hvc_console.c +++ linux-2.6/drivers/char/hvc_console.c @@ -322,10 +322,11 @@ static int hvc_open(struct tty_struct *t hp->tty = tty; + spin_unlock_irqrestore(&hp->lock, flags); + if (hp->ops->notifier_add) rc = hp->ops->notifier_add(hp, hp->data); - spin_unlock_irqrestore(&hp->lock, flags); /*
| |