lkml.org 
[lkml]   [2004]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: netpoll trapped question
==> Regarding Re: netpoll trapped question; Herbert Xu <herbert@gondor.apana.org.au> adds:

herbert> Herbert Xu <herbert@gondor.apana.org.au> wrote:
>> Jeff Moyer <jmoyer@redhat.com> wrote:
>>>
mpm> Yes, true. But we're still in trouble if we have nic irq handler ->
mpm> take private lock -> printk -> netconsole -> nic irq handler -> take
mpm> private lock. See?
>>> Okay, so that one has to be addressed on a per-driver basis. There's
>>> no way for us to detect that situation. And how do drivers address
>>> this? Simply don't printk inside the lock? I think that's reasonable.

>> Why not queue the message whenever you're in IRQ context, and only print
>> when you are not?

This question has been answered before. We don't want to defer the output
of say an oops or panic message, since we may never get back to process
context.

herbert> Actually how can this happen at all? The IRQ handler should've
herbert> disabled local IRQs which prevents the second handler from
herbert> occuring.

The netpoll infrastructure calls into the device's netpoll routine. This
will, in turn, call the interrupt routine for the device.

-Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.039 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site