It has come to my attention that the link that I posted previously was
nonfunctional. It has been fixed.
As well, here are some other pertinent details:
This is kernel 2.6.13-rc2, the latest that works with MIPS SMP.
Here is a trace:
Debug: sleeping function called from invalid context at
arch/mips/math-emu/dsemul.c:137
in_atomic():1, irqs_disabled():0
Call Trace:
[<ffffffff801406e0>] __might_sleep+0x180/0x198
[<ffffffff802cec00>] ipv6_rcv+0xc0/0x440
[<ffffffff80140428>] do_dsemulret+0x68/0x1a0
[<ffffffff8010b3a4>] do_ade+0x24/0x550
[<ffffffff80102964>] handle_adel_int+0x3c/0x58
[<ffffffff80268160>] netif_receive_skb+0x1b0/0x2e0
[<ffffffff802cec04>] ipv6_rcv+0xc4/0x440
[<ffffffff80268160>] netif_receive_skb+0x1b0/0x2e0
[<ffffffff802572c8>] lanlan_poll+0x3e0/0x440
[<ffffffff8026868c>] net_rx_action+0x16c/0x370
[<ffffffff802686a8>] net_rx_action+0x188/0x370
[<ffffffff80154f28>] __do_softirq+0x118/0x250
[<ffffffff80154f28>] __do_softirq+0x118/0x250
[<ffffffff80155110>] do_softirq+0xb0/0xe0
[<ffffffff80101930>] mipsIRQ+0x130/0x1e0
[<ffffffff80101c90>] r4k_wait+0x0/0x10
[<ffffffff80103e6c>] cpu_idle+0x4c/0x68
[<ffffffff80103e64>] cpu_idle+0x44/0x68
[<ffffffff8037fcfc>] start_kernel+0x454/0x4e8
[<ffffffff8037fcf4>] start_kernel+0x44c/0x4e8
Apologies for any inconvenience.
joshua
On Wednesday 17 August 2005 09:32, Joshua Wise wrote:
> Hello LKML,
>
> I have recently been working on a network driver for an emulated
> ultra-simple network card, and I've run into a few snags with the NAPI. My
> current issue is that it seems to me that my poll routine is being called
> from an atomic context, so when poll calls rx, and rx calls
> netif_receive_skb, I end up with lots of __might_sleep warnings in the
> various network layers.
>
> This is not so good. I need every cycle I can get, as this emulator is
> incredibly slow, so burning cycles by printing out the reported badness is
> not really acceptible. Conceivably the badness itself is also an issue.
>
> Before posting here, I did search Google for "lkml napi poll interrupt",
> although I did not find anything relevant to my issue.
>
> If interested, the code is available at http://joshuawise.com/lanlan.c .
> Some notes:
>
> The virtual lan-lan is a very very simple device. It consists of an ioreg
> that maintains state of the device, as described by the ioreg bit defines.
> It also has an ioctlreg that can pass through ioctls to the Linux kernel
> tap device that it's sitting on top of. (This goes with the ifreq seen in
> the struct.) One must always write and read in word-aligned chunks to and
> from it, for simplicity's sake.
>
> Feel free to suggest any modifications that this device might need to make
> it more fully functional. Hopefully we can bring this driver to such a
> state where it will be usable as a replacement skeleton driver for the
> NAPI.
>
> Please cc: Aaron and myself, as neither of us are subscribed to lkml.
>
> Thanks in advance,
> joshua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |