newbie rtl8187 question

newbie rtl8187 question

[Paul Thomas]

Hello,

I am trying to get the Trendnet TEW-424UB to work. I have hardware
version 3.1R which is based on the Realtek RTL8187B chip. I got the
latest wireless-testing git version. I added the Trendnet PID & VID to
drivers/net/wireless/rtl8187_dev.c (shown below) but I still can't it
to work.

static struct usb_device_id rtl8187_table[] __devinitdata = {
        /* Realtek */
        {USB_DEVICE(0x0bda, 0x8187)},
        /* Netgear */
        {USB_DEVICE(0x0846, 0x6100)},
        {USB_DEVICE(0x0846, 0x6a00)},
        /* HP */
        {USB_DEVICE(0x03f0, 0xca02)},
        /*Trendnet Vendor=0bda ProdID=8189*/
        {USB_DEVICE(0x0bda, 0x8189)},
        /* Sitecom */
        {USB_DEVICE(0x0df6, 0x000d)},
        {}
};

When I plug the adapter in I get this under /proc/bus/usb/devices

T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  3 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=8189 Rev= 2.00
S:  Manufacturer=Manufacturer_Realtek
S:  Product=RTL8187B_WLAN_Adapter
S:  SerialNumber=00e04c000001
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 9 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8187
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

The only other time I used wireless stuff under linux I used a distros
built in tools, so I hope I'm doing the config correctly. Here is what
I'm doing:

/sbin/iwconfig wlan0 key restricted MYKEY essid "ssid"
/sbin/ifconfig wlan0 up
/sbin/dhclient wlan0

Now #/sbin/iwconfig gives me this:
wlan0     IEEE 802.11  ESSID:""
          Mode:Managed  Frequency:2.412 GHz  Access Point: Not-Associated
          Tx-Power=27 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Encryption key:XXXX-XXXX-XX
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

I am using Fedora 8 on a x86_64 system. My initial goal in all this
was to get the adapter to work with my embedded linux project
(http://opencircuits.com/Linuxstamp), but when it didn't work there I
figured I'd try it on my host machine.

Has anyone else gotten the TEW-424UB to work?

thanks
Paul

Re: newbie rtl8187 question

[Pavel Roskin]

On Tue, 2008-05-13 at 20:14 -0700, Paul Thomas wrote:
> Hello,
> 
> I am trying to get the Trendnet TEW-424UB to work. I have hardware
> version 3.1R which is based on the Realtek RTL8187B chip.

Somebody reported earlier today success with that adapter:
http://marc.info/?l=linux-wireless&m=121066467513930&w=2

I understand that two patches are needed on top of linux-wireless.

>         {USB_DEVICE(0x0bda, 0x8189)},

That is already in the first patch.

-- 
Regards,
Pavel Roskin

Re: newbie rtl8187 question

[Pavel Roskin]

On Tue, 2008-05-13 at 20:50 -0700, Paul Thomas wrote:
[private e-mail not quoted]

You can apply patches with patch or with StGIT.  If you haven't used
StGIT before, run "stg init" in the top source directory of the kernel.

stg import -n rtl8187b -u 'https://bugzilla.redhat.com/attachment.cgi?id=304231'
stg import -n rtl8187b-fix -u 'https://bugzilla.redhat.com/attachment.cgi?id=305203'

There will be some warnings about whitespace from StGIT, but the driver
compiles fine, and even sparse doesn't report any warnings.  I'm away
from the adapter, but I assume it would work.

P.S. Please don't take the discussion private.  Others may be interested
in it.

-- 
Regards,
Pavel Roskin

Re: newbie rtl8187 question

[Paul Thomas]

Thanks,

That worked! I unplugged my ethernet cable, and I'm sending this via
the wireless adapter.

If I can get some other patches on this same tree I can test the
driver on an arm9 processor (Atmel AT91RM9200). I'll let you know.

Any idea when those patches will find there way to the main line kernel?

thanks,
Paul

On Tue, May 13, 2008 at 9:05 PM, Pavel Roskin <proski@gnu.org> wrote:
> On Tue, 2008-05-13 at 20:50 -0700, Paul Thomas wrote:
>  [private e-mail not quoted]
>
>  You can apply patches with patch or with StGIT.  If you haven't used
>  StGIT before, run "stg init" in the top source directory of the kernel.
>
>  stg import -n rtl8187b -u 'https://bugzilla.redhat.com/attachment.cgi?id=304231'
>  stg import -n rtl8187b-fix -u 'https://bugzilla.redhat.com/attachment.cgi?id=305203'
>
>  There will be some warnings about whitespace from StGIT, but the driver
>  compiles fine, and even sparse doesn't report any warnings.  I'm away
>  from the adapter, but I assume it would work.
>
>  P.S. Please don't take the discussion private.  Others may be interested
>  in it.
>
>  --
>  Regards,
>  Pavel Roskin
>

Re: newbie rtl8187 question

[Pavel Roskin]

On Tue, 2008-05-13 at 21:41 -0700, Paul Thomas wrote:
> Thanks,
> 
> That worked! I unplugged my ethernet cable, and I'm sending this via
> the wireless adapter.

Nice to hear that!!!

> If I can get some other patches on this same tree I can test the
> driver on an arm9 processor (Atmel AT91RM9200). I'll let you know.
> 
> Any idea when those patches will find there way to the main line kernel?

Since the code is working, it's likely to be in linux-wireless within
days, which means in will be scheduled for Linux 2.6.27.  2.6.26 is in
the RC phase now, but I've seen a similar patch for Broadcom going into
2.6.25 quite late in the game, so we can hope that 2.6.26 may have the
rtl8187b fix too.

-- 
Regards,
Pavel Roskin

Re: newbie rtl8187 question

[Paul Thomas]

Pavel,

I was finally able to test the driver with an ARM9 (AT91RM9200)
processor, but I wasn't able to make it work. Here is the error I get:

kernel BUG at net/core/skbuff.c:149!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 817 [#1] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (2.6.26-rc2-wl-dirty #2)
PC is at __bug+0x20/0x2c
LR is at vprintk+0x304/0x344
pc : [<c00255a8>]    lr : [<c0038ab8>]    psr: 20000013
sp : c1d7dd28  ip : c1d7dc8c  fp : c1d7dd34
r10: c1d40460  r9 : 00000000  r8 : c1d7de38
r7 : c1c57120  r6 : c1c57046  r5 : c1c56ffc  r4 : c1c57000
r3 : 00000000  r2 : 00000102  r1 : 00000001  r0 : 00000028
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: c000717f  Table: 21df0000  DAC: 00000017
Process rtl8187 (pid: 899, stack limit = 0xc1d7c260)
Stack: (0xc1d7dd28 to 0xc1d7e000)
dd20:                   c1d7dd68 c1d7dd38 c020ee54 c0025598 c1c57000 c1c56ffc
dd40: c1c57046 c1c57120 c1d3d800 00000020 c1d4be40 023a0000 c1d4be40 c1d7dd80
dd60: c1d7dd6c c020fce4 c020ee08 00000001 00000001 c1d7dddc c1d7dd84 c01ae2b8
dd80: c020fcb8 00000000 00000000 00000000 00000080 0000002a 00000001 c1d91300
dda0: c1d90160 00000006 00000007 00000005 00000004 c1d7de00 c1d7de38 c1d90160
ddc0: c1d4be40 c1d90160 c1d7de38 c1d3d000 c1d7ddfc c1d7dde0 c02a9d74 c01ae0c8
dde0: c0374894 c1d7c000 00000000 c1d4be40 c1d7de84 c1d7de00 c02aa170 c02a9d24
de00: c1d4be40 c1d3d000 c1d90160 c1d3d360 00000000 00000000 c1d7de38 c1d91310
de20: c1d914d0 c1d914d0 00000000 00000000 0b160040 00000000 c1d3d5dc c1d914d0
de40: 00000000 00000000 00000000 00000152 00000001 00000000 00000002 c1d7c000
de60: c1d4be40 c1d3d800 c1d4be40 c1d3d800 c1d91554 c038f298 c1d7deac c1d7de88
de80: c021627c c02a9e8c c1d7c000 c1d3d800 c1d3d800 c1d4be40 ffffeb45 c035ea94
dea0: c1d7ded4 c1d7deb0 c0225564 c02160b8 c1d7c000 c1d3d800 c1d4be40 00000000
dec0: c1d91560 00000090 c1d7def4 c1d7ded8 c02164b4 c0225490 c1d4be40 00000000
dee0: c1d3d360 c1d4be60 c1d7df14 c1d7def8 c029c570 c0216324 0000000c c1c57045
df00: c1d4be40 c1c57036 c1d7df4c c1d7df18 c029ca84 c029c518 c1c57040 c1d90e8c
df20: c1d3d000 c1d90160 c1d7c000 c1d2a240 c1d3d000 c02a2320 00000000 00000019
df40: c1d7df74 c1d7df50 c02a2490 c029c848 c1d90e5c c1d7c000 c1d2a240 c1d90e58
df60: c02a2320 00000000 c1d7df98 c1d7df78 c0048d38 c02a2330 c1d2a248 c1d7dfb0
df80: c1d2a240 00000000 00000000 c1d7dfdc c1d7df9c c0048ec0 c0048c60 00000000
dfa0: c1c26900 c004cf20 c1d7dfbc c1d7dfbc 00000000 c1c26900 c004cf20 c1d7dfbc
dfc0: c1d7dfbc fffffffc c0048e08 00000000 c1d7dff4 c1d7dfe0 c004c848 c0048e18
dfe0: 00000000 00000000 00000000 c1d7dff8 c003a398 c004c804 00000000 00000000
Backtrace:
[<c0025588>] (__bug+0x0/0x2c) from [<c020ee54>] (skb_under_panic+0x5c/0x68)
[<c020edf8>] (skb_under_panic+0x0/0x68) from [<c020fce4>] (skb_push+0x3c/0x44)
 r7:c1d4be40 r6:023a0000 r5:c1d4be40 r4:00000020
[<c020fca8>] (skb_push+0x0/0x44) from [<c01ae2b8>] (rtl8187_tx+0x200/0x324)
 r5:00000001 r4:00000001
[<c01ae0b8>] (rtl8187_tx+0x0/0x324) from [<c02a9d74>]
(__ieee80211_tx+0x60/0x168)
[<c02a9d14>] (__ieee80211_tx+0x0/0x168) from [<c02aa170>]
(ieee80211_master_start_xmit+0x2f4/0x468)
 r7:c1d4be40 r6:00000000 r5:c1d7c000 r4:c0374894
[<c02a9e7c>] (ieee80211_master_start_xmit+0x0/0x468) from [<c021627c>]
(dev_hard_start_xmit+0x1d4/0x26c)
[<c02160a8>] (dev_hard_start_xmit+0x0/0x26c) from [<c0225564>]
(__qdisc_run+0xe4/0x248)
[<c0225480>] (__qdisc_run+0x0/0x248) from [<c02164b4>]
(dev_queue_xmit+0x1a0/0x308)
[<c0216314>] (dev_queue_xmit+0x0/0x308) from [<c029c570>]
(ieee80211_sta_tx+0x68/0x6c)
 r7:c1d4be60 r6:c1d3d360 r5:00000000 r4:c1d4be40
[<c029c508>] (ieee80211_sta_tx+0x0/0x6c) from [<c029ca84>]
(ieee80211_send_probe_req+0x24c/0x260)
 r7:c1c57036 r6:c1d4be40 r5:c1c57045 r4:0000000c
[<c029c838>] (ieee80211_send_probe_req+0x0/0x260) from [<c02a2490>]
(ieee80211_sta_scan_work+0x170/0x1a4)
[<c02a2320>] (ieee80211_sta_scan_work+0x0/0x1a4) from [<c0048d38>]
(run_workqueue+0xe8/0x1b8)
[<c0048c50>] (run_workqueue+0x0/0x1b8) from [<c0048ec0>]
(worker_thread+0xb8/0xcc)
 r8:00000000 r7:00000000 r6:c1d2a240 r5:c1d7dfb0 r4:c1d2a248
[<c0048e08>] (worker_thread+0x0/0xcc) from [<c004c848>] (kthread+0x54/0x7c)
 r6:00000000 r5:c0048e08 r4:fffffffc
[<c004c7f4>] (kthread+0x0/0x7c) from [<c003a398>] (do_exit+0x0/0x65c)
 r5:00000000 r4:00000000
Code: e1a01000 e59f000c eb004d54 e3a03000 (e5833000)
Kernel panic - not syncing: Fatal exception in interrupt

thanks,
Paul

On Tue, May 13, 2008 at 9:52 PM, Pavel Roskin <proski@gnu.org> wrote:
> On Tue, 2008-05-13 at 21:41 -0700, Paul Thomas wrote:
>> Thanks,
>>
>> That worked! I unplugged my ethernet cable, and I'm sending this via
>> the wireless adapter.
>
> Nice to hear that!!!
>
>> If I can get some other patches on this same tree I can test the
>> driver on an arm9 processor (Atmel AT91RM9200). I'll let you know.
>>
>> Any idea when those patches will find there way to the main line kernel?
>
> Since the code is working, it's likely to be in linux-wireless within
> days, which means in will be scheduled for Linux 2.6.27.  2.6.26 is in
> the RC phase now, but I've seen a similar patch for Broadcom going into
> 2.6.25 quite late in the game, so we can hope that 2.6.26 may have the
> rtl8187b fix too.
>
> --
> Regards,
> Pavel Roskin
>

Re: newbie rtl8187 question

[Pavel Roskin]

On Sat, 2008-05-17 at 23:15 -0700, Paul Thomas wrote:

> I was finally able to test the driver with an ARM9 (AT91RM9200)
> processor, but I wasn't able to make it work. Here is the error I get:
> 
> kernel BUG at net/core/skbuff.c:149!

There should be a message starting with "skb_under_panic:" immediately
before this.  It prints information about the skb.

> Backtrace:
> [<c0025588>] (__bug+0x0/0x2c) from [<c020ee54>] (skb_under_panic+0x5c/0x68)
> [<c020edf8>] (skb_under_panic+0x0/0x68) from [<c020fce4>] (skb_push+0x3c/0x44)
>  r7:c1d4be40 r6:023a0000 r5:c1d4be40 r4:00000020
> [<c020fca8>] (skb_push+0x0/0x44) from [<c01ae2b8>] (rtl8187_tx+0x200/0x324)
>  r5:00000001 r4:00000001

So, we got there from skb_push().

> [<c01ae0b8>] (rtl8187_tx+0x0/0x324) from [<c02a9d74>]
> (__ieee80211_tx+0x60/0x168)

rtl8187_tx() doesn't call skb_push() directly, but I think that
rtl8187b_tx_buf() got inlined.

Perhaps there is too little headroom space in the skb.  I would check if
dev->extra_tx_headroom is correct in rtl8187_probe().

Try checking the available headroom in rtl8187b_tx_buf() by
skb_headroom().  If it's not enough, use skb_realloc_headroom() and
print how much is missing.

I know there were conflicts between the patch and the latest changes on
linux-wireless.  Maybe you didn't resolve them correctly.

Here's the patch for debugging the panic.

And by the way, please provide the kernel log part from the device
initialization time all the way to the panic.

diff --git a/drivers/net/wireless/rtl8187_dev.c b/drivers/net/wireless/rtl8187_dev.c
index 88e4d4b..8005651 100644
--- a/drivers/net/wireless/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl8187_dev.c
@@ -185,6 +185,13 @@ static void *rtl8187b_tx_buf(struct sk_buff *skb, __le32 flags,
 			     __le16 tx_dur)
 {
 	struct rtl8187b_tx_hdr *hdr;
+	int need_headroom;
+
+	need_headroom = sizeof(*hdr) - skb_headroom(skb);
+	printk("rtl8187: need headroom: %zd, have %d\n", sizeof(*hdr),
+	       skb_headroom(skb));
+	if (need_headroom)
+		skb = skb_realloc_headroom(skb, need_headroom);
 
 	hdr = (struct rtl8187b_tx_hdr *)skb_push(skb, sizeof(*hdr));
 	memset(hdr, 0, sizeof(*hdr));
@@ -1057,6 +1064,8 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
 	dev->extra_tx_headroom = (!priv->is_rtl8187b) ?
 				  sizeof(struct rtl8187_tx_hdr) :
 				  sizeof(struct rtl8187b_tx_hdr);
+	printk("rtl8187: need headroom: %d, priv->is_rtl8187b = %d\n",
+	       dev->extra_tx_headroom, priv->is_rtl8187b);
 	if (!priv->is_rtl8187b)
 		dev->queues = 1;
 	else


-- 
Regards,
Pavel Roskin

Re: newbie rtl8187 question

[Paul Thomas]

Thanks for the response. I was only able to add the first block to
rtl8187_dev.c. Here is the output.

thanks,
Paul

linuxstamp:~# skb_under_panic: text:c01ae2c4 len:74 put:32
head:c1ed0000 data:c1ecfffc tail:0xc1ed0046 end:0xc1ed0120
dev:wmaster0
kernel BUG at net/core/skbuff.c:149!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 817 [#1] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (2.6.26-rc2-wl-dirty #5)
PC is at __bug+0x20/0x2c
LR is at vprintk+0x304/0x344
pc : [<c00255a8>]    lr : [<c0038ab8>]    psr: 20000013
sp : c1db1d30  ip : c1db1c94  fp : c1db1d3c
r10: c1ed24a0  r9 : c1db1e38  r8 : 0000802a
r7 : c1ed0120  r6 : c1ed0046  r5 : c1ecfffc  r4 : c1ed0000
r3 : 00000000  r2 : 00000102  r1 : 00000001  r0 : 00000028
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: c000717f  Table: 21d98000  DAC: 00000017
Process rtl8187 (pid: 1226, stack limit = 0xc1db0260)
Stack: (0xc1db1d30 to 0xc1db2000)
1d20:                                     c1db1d70 c1db1d40 c020ee74 c0025598
1d40: c1ed0000 c1ecfffc c1ed0046 c1ed0120 c1e02800 00000020 c1ed24a0 023a0000
1d60: 00000001 c1db1d88 c1db1d74 c020fd04 c020ee28 c1db1e00 00000001 c1db1ddc
1d80: c1db1d8c c01ae2c4 c020fcd8 00000001 00000000 c1d399e0 c1db8160 c1db9300
1da0: c1db8160 00000006 00000007 00000005 00000004 c1db1e00 c1db1e38 c1db8160
1dc0: c1ed24a0 c1db8160 c1db1e38 c1e02000 c1db1dfc c1db1de0 c02a9d94 c01ae0c8
1de0: c0374894 c1db0000 00000000 c1ed24a0 c1db1e84 c1db1e00 c02aa190 c02a9d44
1e00: c1ed24a0 c1e02000 c1db8160 c1e02360 00000000 00000000 c1db1e38 c1db9310
1e20: c1db94d0 c1db94d0 00000000 00000000 0b160040 00000000 c1e025dc c1db94d0
1e40: 00000000 00000000 00000000 00000152 00000001 00000000 00000002 c1db0000
1e60: c1ed24a0 c1e02800 c1ed24a0 c1e02800 c1db9554 c038f298 c1db1eac c1db1e88
1e80: c021629c c02a9eac c1db0000 c1e02800 c1e02800 c1ed24a0 ffffd682 c035ea94
1ea0: c1db1ed4 c1db1eb0 c0225584 c02160d8 c1db0000 c1e02800 c1ed24a0 00000000
1ec0: c1db9560 00000090 c1db1ef4 c1db1ed8 c02164d4 c02254b0 c1ed24a0 00000000
1ee0: c1e02360 c1ed24c0 c1db1f14 c1db1ef8 c029c590 c0216344 0000000c c1ed0045
1f00: c1ed24a0 c1ed0036 c1db1f4c c1db1f18 c029caa4 c029c538 c1ed0040 c1db8e8c
1f20: c1e02000 c1db8160 c1db0000 c1cf3a00 c1e02000 c02a2340 00000000 00000019
1f40: c1db1f74 c1db1f50 c02a24b0 c029c868 c1db8e5c c1db0000 c1cf3a00 c1db8e58
1f60: c02a2340 00000000 c1db1f98 c1db1f78 c0048d38 c02a2350 c1cf3a08 c1db1fb0
1f80: c1cf3a00 00000000 00000000 c1db1fdc c1db1f9c c0048ec0 c0048c60 00000000
1fa0: c1ecd0e0 c004cf20 c1db1fbc c1db1fbc 00000000 c1ecd0e0 c004cf20 c1db1fbc
1fc0: c1db1fbc fffffffc c0048e08 00000000 c1db1ff4 c1db1fe0 c004c848 c0048e18
1fe0: 00000000 00000000 00000000 c1db1ff8 c003a398 c004c804 00000000 00000000
Backtrace:
[<c0025588>] (__bug+0x0/0x2c) from [<c020ee74>] (skb_under_panic+0x5c/0x68)
[<c020ee18>] (skb_under_panic+0x0/0x68) from [<c020fd04>] (skb_push+0x3c/0x44)
 r7:00000001 r6:023a0000 r5:c1ed24a0 r4:00000020
[<c020fcc8>] (skb_push+0x0/0x44) from [<c01ae2c4>] (rtl8187_tx+0x20c/0x344)
 r5:00000001 r4:c1db1e00
[<c01ae0b8>] (rtl8187_tx+0x0/0x344) from [<c02a9d94>]
(__ieee80211_tx+0x60/0x168)
[<c02a9d34>] (__ieee80211_tx+0x0/0x168) from [<c02aa190>]
(ieee80211_master_start_xmit+0x2f4/0x468)
 r7:c1ed24a0 r6:00000000 r5:c1db0000 r4:c0374894
[<c02a9e9c>] (ieee80211_master_start_xmit+0x0/0x468) from [<c021629c>]
(dev_hard_start_xmit+0x1d4/0x26c)
[<c02160c8>] (dev_hard_start_xmit+0x0/0x26c) from [<c0225584>]
(__qdisc_run+0xe4/0x248)
[<c02254a0>] (__qdisc_run+0x0/0x248) from [<c02164d4>]
(dev_queue_xmit+0x1a0/0x308)
[<c0216334>] (dev_queue_xmit+0x0/0x308) from [<c029c590>]
(ieee80211_sta_tx+0x68/0x6c)
 r7:c1ed24c0 r6:c1e02360 r5:00000000 r4:c1ed24a0
[<c029c528>] (ieee80211_sta_tx+0x0/0x6c) from [<c029caa4>]
(ieee80211_send_probe_req+0x24c/0x260)
 r7:c1ed0036 r6:c1ed24a0 r5:c1ed0045 r4:0000000c
[<c029c858>] (ieee80211_send_probe_req+0x0/0x260) from [<c02a24b0>]
(ieee80211_sta_scan_work+0x170/0x1a4)
[<c02a2340>] (ieee80211_sta_scan_work+0x0/0x1a4) from [<c0048d38>]
(run_workqueue+0xe8/0x1b8)
[<c0048c50>] (run_workqueue+0x0/0x1b8) from [<c0048ec0>]
(worker_thread+0xb8/0xcc)
 r8:00000000 r7:00000000 r6:c1cf3a00 r5:c1db1fb0 r4:c1cf3a08
[<c0048e08>] (worker_thread+0x0/0xcc) from [<c004c848>] (kthread+0x54/0x7c)
 r6:00000000 r5:c0048e08 r4:fffffffc
[<c004c7f4>] (kthread+0x0/0x7c) from [<c003a398>] (do_exit+0x0/0x65c)
 r5:00000000 r4:00000000
Code: e1a01000 e59f000c eb004d54 e3a03000 (e5833000)
Kernel panic - not syncing: Fatal exception in interrupt


On Tue, May 20, 2008 at 6:24 PM, Pavel Roskin <proski@gnu.org> wrote:
> On Sat, 2008-05-17 at 23:15 -0700, Paul Thomas wrote:
>
>> I was finally able to test the driver with an ARM9 (AT91RM9200)
>> processor, but I wasn't able to make it work. Here is the error I get:
>>
>> kernel BUG at net/core/skbuff.c:149!
>
> There should be a message starting with "skb_under_panic:" immediately
> before this.  It prints information about the skb.
>
>> Backtrace:
>> [<c0025588>] (__bug+0x0/0x2c) from [<c020ee54>] (skb_under_panic+0x5c/0x68)
>> [<c020edf8>] (skb_under_panic+0x0/0x68) from [<c020fce4>] (skb_push+0x3c/0x44)
>>  r7:c1d4be40 r6:023a0000 r5:c1d4be40 r4:00000020
>> [<c020fca8>] (skb_push+0x0/0x44) from [<c01ae2b8>] (rtl8187_tx+0x200/0x324)
>>  r5:00000001 r4:00000001
>
> So, we got there from skb_push().
>
>> [<c01ae0b8>] (rtl8187_tx+0x0/0x324) from [<c02a9d74>]
>> (__ieee80211_tx+0x60/0x168)
>
> rtl8187_tx() doesn't call skb_push() directly, but I think that
> rtl8187b_tx_buf() got inlined.
>
> Perhaps there is too little headroom space in the skb.  I would check if
> dev->extra_tx_headroom is correct in rtl8187_probe().
>
> Try checking the available headroom in rtl8187b_tx_buf() by
> skb_headroom().  If it's not enough, use skb_realloc_headroom() and
> print how much is missing.
>
> I know there were conflicts between the patch and the latest changes on
> linux-wireless.  Maybe you didn't resolve them correctly.
>
> Here's the patch for debugging the panic.
>
> And by the way, please provide the kernel log part from the device
> initialization time all the way to the panic.
>
> diff --git a/drivers/net/wireless/rtl8187_dev.c b/drivers/net/wireless/rtl8187_dev.c
> index 88e4d4b..8005651 100644
> --- a/drivers/net/wireless/rtl8187_dev.c
> +++ b/drivers/net/wireless/rtl8187_dev.c
> @@ -185,6 +185,13 @@ static void *rtl8187b_tx_buf(struct sk_buff *skb, __le32 flags,
>                             __le16 tx_dur)
>  {
>        struct rtl8187b_tx_hdr *hdr;
> +       int need_headroom;
> +
> +       need_headroom = sizeof(*hdr) - skb_headroom(skb);
> +       printk("rtl8187: need headroom: %zd, have %d\n", sizeof(*hdr),
> +              skb_headroom(skb));
> +       if (need_headroom)
> +               skb = skb_realloc_headroom(skb, need_headroom);
>
>        hdr = (struct rtl8187b_tx_hdr *)skb_push(skb, sizeof(*hdr));
>        memset(hdr, 0, sizeof(*hdr));
> @@ -1057,6 +1064,8 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
>        dev->extra_tx_headroom = (!priv->is_rtl8187b) ?
>                                  sizeof(struct rtl8187_tx_hdr) :
>                                  sizeof(struct rtl8187b_tx_hdr);
> +       printk("rtl8187: need headroom: %d, priv->is_rtl8187b = %d\n",
> +              dev->extra_tx_headroom, priv->is_rtl8187b);
>        if (!priv->is_rtl8187b)
>                dev->queues = 1;
>        else
>
>
> --
> Regards,
> Pavel Roskin
>