Re: netconsole hangs w/ alt-sysrq-t

[Matt Mackall <mpm@selenic.com>]

On Wed, Apr 28, 2004 at 10:07:17AM -0400, Jeff Moyer wrote:
> ==> Regarding Re: netconsole hangs w/ alt-sysrq-t; Matt Mackall <mpm@selenic.com> adds:
> 
> mpm> On Wed, Apr 28, 2004 at 08:44:47AM -0400, Jeff Moyer wrote:
> >> ==> Regarding Re: netconsole hangs w/ alt-sysrq-t; Matt Mackall
> >> <mpm@selenic.com> adds:
> >> 
> mpm> On Thu, Apr 22, 2004 at 11:29:33AM -0400, Jeff Moyer wrote:
> >> >> If netconsole is enabled, and you hit Alt-Sysrq-t, then it will print
> >> a >> small amount of output to the console(s) and then hang the system.
> >> In >> this case, I'm using the e100 driver, and we end up exhausting the
> >> >> available cbs.  Since we are in interrupt context, the driver's poll
> >> >> routine is never run, and we loop infinitely waiting for resources to
> >> >> free up that never will.  Kernel version is 2.6.5.
> >> 
> mpm> Can you try 2.6.6-rc2? It has a fix to congestion handling that should
> mpm> address this.
> >> Is the attached patch the change you are referring to?  If so, I don't
> >> see how this would fix the problem.  I ended up deferring netpoll writes
> >> to process context, which has been working fine for me.  Have I missed
> >> something?
> 
> mpm> Well process context defeats the purpose. Ok, I've more closely read
> mpm> your report and if I understand correctly, you're using the NAPI
> mpm> version of e100? There's some magic NAPI bits in netpoll_poll that
> mpm> might help here:
> 
> Yes, sorry I didn't specify that earlier.
> 
> mpm>         if(trapped && np->dev->poll && test_bit(__LINK_STATE_RX_SCHED,
> mpm> &np->dev->state))
> np-> dev->poll(np->dev, &budget);
> 
> mpm> Perhaps we need to pull the trapped test out of there. Then with any
> mpm> luck, dev->hard_start_xmit will return non-zero in netpoll_send_skb,
> mpm> we'll call netpoll_poll to pump the card, and we'll be able to flush
> mpm> it.
> 
> I don't think so.  You can end up in code running in interrupt context that
> is not designed to (ip routing code, etc).  I've been down that path
> already.  I only defer to process context if irqs_disabled().

Fair enough. Turning on trapped basically short circuits the rest of
the NAPI code so that stuff doesn't hit the stack when we call ->poll.
Could you try doing a netpoll_set_trap(1)/(0) around the call to ->poll
and see if that actually lets the thing work? Then we can try to
figure out the right way to do this.

My point about deferring still stands, as when we're dumping an oops,
we can't really expect that we'll ever get to a process context.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting