Messages in this thread | | | From | Jeff Moyer <> | Date | Fri, 25 Jun 2004 11:50:25 -0400 | Subject | Re: netconsole hangs w/ alt-sysrq-t |
| |
==> Regarding Re: netconsole hangs w/ alt-sysrq-t; Jeff Moyer <jmoyer@redhat.com> adds:
==> Regarding Re: netconsole hangs w/ alt-sysrq-t; Matt Mackall <mpm@selenic.com> adds: jmoyer> [snip]
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().
mpm> Fair enough. Turning on trapped basically short circuits the rest of mpm> the NAPI code so that stuff doesn't hit the stack when we call ->poll. mpm> Could you try doing a netpoll_set_trap(1)/(0) around the call to mpm> ->poll and see if that actually lets the thing work? Then we can try mpm> to figure out the right way to do this.
You will still hit the stack in the case of netconsole, since it doesn't register an rx hook and netif_receive_skb has this:
#ifdef CONFIG_NETPOLL_RX if (skb->dev->netpoll_rx && skb->dev->poll && netpoll_rx(skb)) { kfree_skb(skb); return NET_RX_DROP; } #endif
So we fall through and end up calling code which doesn't want to run in interrupt context.
One solution that I've come up with, but may not be in the spirit of netpoll, is to change that test above to the following:
if (unlikely(netpoll_trap())) { if (skb->dev->netpoll_rx && skb->dev->poll) netpoll_rx(skb); kfree_skb(skb); return NET_RX_DROP; }
This changes semantics, in that the rx routine will only be called if we've decided to "trap" the network stack. Note also that this will cause us to drop packets while doing our logging.
Matt, any thoughts on this?
Regards,
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/
| |