Re: netconsole hangs w/ alt-sysrq-t

[Jeff Moyer]

==> Regarding Re: netconsole hangs w/ alt-sysrq-t; Matt Mackall <mpm@xxxxxxxxxxx> adds:

mpm> On Thu, Jul 01, 2004 at 12:54:50PM -0400, Jeff Moyer wrote:
>> ==> Regarding Re: netconsole hangs w/ alt-sysrq-t; Matt Mackall
>> <mpm@xxxxxxxxxxx> adds:
>> 
mpm> On Mon, Jun 28, 2004 at 12:58:22PM -0400, Jeff Moyer wrote:
>> >> ==> Regarding Re: netconsole hangs w/ alt-sysrq-t; Matt Mackall >>
>> <mpm@xxxxxxxxxxx> adds:
mpm> No, I think we get to this on the non-NAPI route as well. The ->poll
mpm> check keeps us from filtering twice.
>> >> I'll have to take your word for it on this one, as I can't find a way
>> >> into this code for the non-napi case.  Would anyone care to give an
>> >> authoritative answer on this?
>> 
mpm> I could be mistaken, but that's my recollection from last summer.
mpm> Hopefully I'll have some spare cycles for this next week.
>> >> One other thing we might consider is adding a call to >>
>> touch_nmi_watchdog() to zap_completion_queue.
>> 
mpm> Not sure how I feel about that yet. If we can't get out of the guts of
mpm> netpoll in a timely fashion, then perhaps that's an indication that
mpm> the watchdog should indeed fire. Describe the scenario where you think
mpm> we should do this, please.
>> Alt-Sysrq-t from the keyboard on a heavily-loaded UP system.

mpm> Is it because we're spinning for too long waiting for skbs or is it
mpm> just because sysrq-t takes that long to dump its guts? How does the
mpm> watchdog get tickled in the sysrq-t over slow serial console case?

mpm> In other words, would this better be done between dumps in the sysrq-t
mpm> loop where we actually know we're making forward progress?

Good point.  I tend to center my thinking too much around netdump.  You're
right, if we're waiting too long for skb's, we probably should trigger the
NMI watchdog.  It also appears that show_state includes a call to
touch_nmi_watchdog in its loop.

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