> Hm, unrelated to this...
quoted text
> But I am wondering what happens if the driver adds a device header to the=
 skb.
quoted text
> Is that header then also passed up netif_rx()?
> This doesn't happen for b43, as we use the DMA fragmentation to transmit =
the header,
quoted text
> but it might happen for zd1211rw and others.

Hmm. I thought we said that it was supposed to be removed again by the
hardware before TX status reporting. That's what most drivers seem to do
anyway.

I'm considering turning off this transmit status reporting for now but
that will make hostapd not work.


quoted text
> Seems the skb->destructor messes it up.

Actually, it seems to be outside of mac80211, I put in a WARN_ON() and
got this:

Badness at include/linux/skbuff.h:392
NIP: c026ea14 LR: c0273d54 CTR: c026e9e4
REGS: edfc7c00 TRAP: 0700   Not tainted  (2.6.25-wl-06841-g6b3d5c6-dirty)
MSR: 00029032 <EE,ME,IR,DR>  CR: 82022444  XER: 00000000
TASK =3D edf50e20[3453] 'tcpdump' THREAD: edfc6000
GPR00: 00000001 edfc7cb0 edf50e20 edfd7700 edfd7700 00000002 edfc7e75 03230=
306=20
GPR08: 02000100 00000168 4dff0200 00000150 22022442 100a6290 100783f8 10078=
e18=20
GPR16: 10078e14 10078e10 100a0000 00000000 00000000 bfe2c9d2 1004d320 bfe2c=
4b0=20
GPR24: 10165070 edfd7724 00000060 00000020 ed8157f0 edfd7700 ed8157f0 edfd7=
700=20
NIP [c026ea14] sock_rfree+0x30/0x94
LR [c0273d54] skb_release_all+0x98/0x128
Call Trace:
[edfc7cb0] [10078e10] 0x10078e10 (unreliable)
[edfc7cc0] [c0273d54] skb_release_all+0x98/0x128
[edfc7cd0] [c0273034] __kfree_skb+0x18/0xc8
[edfc7ce0] [c02760d0] skb_free_datagram+0x1c/0x54
[edfc7cf0] [f264d068] packet_recvmsg+0x170/0x1e8 [af_packet]
[edfc7d40] [c026b69c] sock_recvmsg+0xb8/0xf0
[edfc7e30] [c026b9d0] sys_recvfrom+0x94/0x100
[edfc7f00] [c026ca08] sys_socketcall+0x114/0x1dc
[edfc7f40] [c00124cc] ret_from_syscall+0x0/0x38

johannes