Hello I'm using the latest revision of compat wireless on a Debian Lenn=
y=20
with a 2.6.27.7 kernel downloaded from kernel.org.
uname -ra
Linux notebook 2.6.27.7 #1 SMP Thu Nov 27 15:12:29 ARST 2008 i686 GNU/L=
inux
My notebook is fabricated in Argentina by Bangh=F3. It has a rtl8187 us=
b=20
wireless card.
lsusb | grep Realtek
Bus 001 Device 003: ID 0bda:8187 Realtek Semiconductor Corp. RTL8187=20
Wireless Adapter
The thing is that when I'm downloading something using a bit torrent=20
client the connection falls. Network Manager (v0.7.0) still shows the=20
connection as active showing the intensity of the signal, but I can't=20
use the network.
I've search in the syslogs, messages and daemon.log and I can't find=20
anything unusual. At least form me.
When the connection stops I've to reload the driver with
rmmod rtl8187
modprobe rtl8187
I'm a little far from de AP but it becames stable at 11Mb/s and it only=
=20
falls with the bit torrent client.
The time it takes to fall is radom, and sometimes it happens after 10=20
minutes less or more.
I've tried to limit the torrent bitrate to 100KB/s and 80 KB/s and=20
nothing. Also tried to use a 5.5Mb/s connection to the Ap, but nothing=20
improves.
Ah! my conection is using WPA Personal for authentication. My wireless=20
router is a CNet.
I've already tried with ndiswrapper and it doesn't worked.
Sorry about my english and if my description of the problem is not=20
useful. Please tell me what information you need.
Please help me! Thanks!
--=20
*Mart=EDn Ernesto Barreyro*
Mart=EDn Ernesto Barreyro wrote:
> Hello I'm using the latest revision of compat wireless on a Debian Le=
nny
> with a 2.6.27.7 kernel downloaded from kernel.org.
>=20
> uname -ra
> Linux notebook 2.6.27.7 #1 SMP Thu Nov 27 15:12:29 ARST 2008 i686 GNU=
/Linux
>=20
> My notebook is fabricated in Argentina by Bangh=F3. It has a rtl8187 =
usb
> wireless card.
>=20
> lsusb | grep Realtek
>=20
> Bus 001 Device 003: ID 0bda:8187 Realtek Semiconductor Corp. RTL8187
> Wireless Adapter
>=20
> The thing is that when I'm downloading something using a bit torrent
> client the connection falls. Network Manager (v0.7.0) still shows the
> connection as active showing the intensity of the signal, but I can't
> use the network.
> I've search in the syslogs, messages and daemon.log and I can't find
> anything unusual. At least form me.
>=20
> When the connection stops I've to reload the driver with
>=20
> rmmod rtl8187
> modprobe rtl8187
>=20
> I'm a little far from de AP but it becames stable at 11Mb/s and it on=
ly
> falls with the bit torrent client.
> The time it takes to fall is radom, and sometimes it happens after 10
> minutes less or more.
> I've tried to limit the torrent bitrate to 100KB/s and 80 KB/s and
> nothing. Also tried to use a 5.5Mb/s connection to the Ap, but nothin=
g
> improves.
I have had the driver fail for my RTL8187B, but it usually takes 18-24 =
hours. It
is good to know that a torrent client makes it happen more frequently. =
Perhaps I
can capture the wireless packets and see where it fails.
Thanks for your report,
Larry
On Mon, 2009-01-05 at 15:10 -0600, Larry Finger wrote:
> Johannes Berg wrote:
> >
> > Does the backtrace continue beyond what you pasted?
>
> Yes, here is the whole thing.
Thanks.
> [<ffffffff8023afce>] warn_on_slowpath+0x58/0x7d
> [<ffffffffa029e98b>] ieee80211_master_start_xmit+0x41c/0x50d [mac80211]
> [<ffffffff803cf0a4>] dev_hard_start_xmit+0x214/0x28f
> [<ffffffff803cf584>] dev_queue_xmit+0x357/0x48f
> [<ffffffffa029fa0e>] ieee80211_tx_skb+0x60/0x62 [mac80211]
> [<ffffffffa0293c61>] ieee80211_send_probe_req+0x1d2/0x1e1 [mac80211]
> [<ffffffffa0290c1b>] ieee80211_scan_work+0x155/0x17a [mac80211]
> [<ffffffff8024ac68>] run_workqueue+0x103/0x20a
> [<ffffffff8024ae4f>] worker_thread+0xe0/0xf1
> [<ffffffff8024e664>] kthread+0x49/0x76
> [<ffffffff8020d0c9>] child_rip+0xa/0x11
That's rather strange, I see no way for this path to attempt sending an
SKB that has since been freed. Unless... yes, here's a problem:
rtl8187_tx is not supposed to return error codes, it's supposed to
return NETDEV_TX_{OK,BUSY}.
This should fix it:
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_dev.c 2009-01-05 22:22:04.000000000 +0100
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c 2009-01-05 22:22:59.000000000 +0100
@@ -213,7 +213,7 @@ static int rtl8187_tx(struct ieee80211_h
urb = usb_alloc_urb(0, GFP_ATOMIC);
if (!urb) {
kfree_skb(skb);
- return -ENOMEM;
+ return NETDEV_TX_OK;
}
flags = skb->len;
@@ -281,7 +281,7 @@ static int rtl8187_tx(struct ieee80211_h
}
usb_free_urb(urb);
- return rc;
+ return NETDEV_TX_OK;
}
static void rtl8187_rx_cb(struct urb *urb)
johannes
Johannes Berg wrote:
>
> Does the backtrace continue beyond what you pasted?
Yes, here is the whole thing.
------------[ cut here ]------------
WARNING: at net/mac80211/tx.c:1184 ieee80211_master_start_xmit+0x41c/0x50d
[mac80211]()
Modules linked in: rtl8187 eeprom_93cx6 af_packet snd_pcm_oss snd_mixer_oss
snd_seq snd_seq_device nfs lockd nfs_acl sunrpc
vboxnetflt vboxdrv cpufreq_conservative cpufreq_userspace cpufreq_powersave
powernow_k8 fuse loop dm_mod arc4 ecb b43 rfki
ll snd_hda_intel mac80211 led_class snd_pcm input_polldev snd_timer snd
ide_cd_mod k8temp soundcore cfg80211 serio_raw forc
edeth button battery hwmon ac snd_page_alloc ssb cdrom sg joydev sd_mod ohci_hcd
uhci_hcd ehci_hcd usbcore edd ext3 mbcache
jbd fan amd74xx ide_core ahci libata scsi_mod thermal processor [last unloaded:
eeprom_93cx6]
Pid: 17149, comm: phy6 Tainted: G W 2.6.28-rc9-wl #58
Call Trace:
[<ffffffff8023afce>] warn_on_slowpath+0x58/0x7d
[<ffffffff803c8c3c>] ? pskb_expand_head+0xe6/0x156
[<ffffffffa029dbff>] ? __ieee80211_tx+0x40/0x12a [mac80211]
[<ffffffffa029e98b>] ieee80211_master_start_xmit+0x41c/0x50d [mac80211]
[<ffffffffa029e8c5>] ? ieee80211_master_start_xmit+0x356/0x50d [mac80211]
[<ffffffff803cf0a4>] dev_hard_start_xmit+0x214/0x28f
[<ffffffff803dfb9b>] __qdisc_run+0xf3/0x1fe
[<ffffffff803cf584>] dev_queue_xmit+0x357/0x48f
[<ffffffff803cf375>] ? dev_queue_xmit+0x148/0x48f
[<ffffffffa029fa0e>] ieee80211_tx_skb+0x60/0x62 [mac80211]
[<ffffffffa0293c61>] ieee80211_send_probe_req+0x1d2/0x1e1 [mac80211]
[<ffffffff80236c1f>] ? finish_task_switch+0x5f/0xb9
[<ffffffff80236bc0>] ? finish_task_switch+0x0/0xb9
[<ffffffffa0290c1b>] ieee80211_scan_work+0x155/0x17a [mac80211]
[<ffffffff8024ac68>] run_workqueue+0x103/0x20a
[<ffffffff8024ac16>] ? run_workqueue+0xb1/0x20a
[<ffffffffa0290ac6>] ? ieee80211_scan_work+0x0/0x17a [mac80211]
[<ffffffff8024ae4f>] worker_thread+0xe0/0xf1
[<ffffffff8024e998>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8024ad6f>] ? worker_thread+0x0/0xf1
[<ffffffff8024e664>] kthread+0x49/0x76
[<ffffffff8020d0c9>] child_rip+0xa/0x11
[<ffffffff80236bc0>] ? finish_task_switch+0x0/0xb9
[<ffffffff8020c5e4>] ? restore_args+0x0/0x30
[<ffffffff8024e61b>] ? kthread+0x0/0x76
[<ffffffff8020d0bf>] ? child_rip+0x0/0x11
---[ end trace 19e8b89a6586bb14 ]---
Larry
On Mon, Jan 5, 2009 at 3:55 PM, Larry Finger <[email protected]> wrote:
> Johannes,
>
> I'm chasing a problem with suspend/resume on rtl8187; however, in my testing, I
> found that a simple "modprobe -r/modprobe" sequence fails, even though
> unplugging/replugging the stick with or without a "modprobe -r" works just fine.
> The last rtl8187 routine that was started was rtl8187_add_interface. From a
> debugging message, I see that info->flags = 0x6B6B6B6B - the SLUB debugging
> poison value. If I interpret the traceback correctly, a workqueue has been
> restarted without being properly initialized.
Is this with the current driver unmodified?
If by any chance it is with your proposed patch from last week that always
called start() or stop() in resume/suspend without some is_up flag,
you will definitely get oopses doing that because the register/unregister
will be unbalanced.
--
Bob Copeland %% http://www.bobcopeland.com
Larry,
> I'm chasing a problem with suspend/resume on rtl8187; however, in my testing, I
> found that a simple "modprobe -r/modprobe" sequence fails, even though
> unplugging/replugging the stick with or without a "modprobe -r" works just fine.
Strange, since modprobe -r/rmmod should unregister the driver just as
though it was unplugged, afaik.
> I'm running into the WARN-ON at net/mac80211/tx.c:1184. The start of the
> traceback is as follows:
>
> [<ffffffff8023afce>] warn_on_slowpath+0x58/0x7d
> [<ffffffff803c8c3c>] ? pskb_expand_head+0xe6/0x156
> [<ffffffffa029dbff>] ? __ieee80211_tx+0x40/0x12a [mac80211]
> [<ffffffffa029e98b>] ieee80211_master_start_xmit+0x41c/0x50d [mac80211]
> [<ffffffffa029e8c5>] ? ieee80211_master_start_xmit+0x356/0x50d [mac80211]
> [<ffffffff803cf0a4>] dev_hard_start_xmit+0x214/0x28f
> [<ffffffff803dfb9b>] __qdisc_run+0xf3/0x1fe
> [<ffffffff803cf584>] dev_queue_xmit+0x357/0x48f
>
> The last rtl8187 routine that was started was rtl8187_add_interface. From a
> debugging message, I see that info->flags = 0x6B6B6B6B - the SLUB debugging
> poison value.
The WARN_ON then triggers because IEEE80211_TX_CTL_AMPDU is 0x40 which
is set in 0x6b. The question is ... why are we trying to send a freed
skb??
> If I interpret the traceback correctly, a workqueue has been
> restarted without being properly initialized.
Does the backtrace continue beyond what you pasted?
> Is there any routine that needs to be called when shutting down that has been
> missed?
Just unregister_hw/free_hw ought to be fine, very strange.
johannes
Johannes Berg wrote:
> On Mon, 2009-01-05 at 16:04 -0600, Larry Finger wrote:
>
>> Thanks. That took care of the WARN_ON message and the SLUB debug messages;
>
> Ok, good. Want to adopt that patch and formally submit it, or want me
> to?
I'll keep looking for the final bit, but I'll formalize the patch when I find
the other problem, or give up.
Thanks for the help. I'll never tell how much time I spent looking for that problem.
Larry
On Mon, 2009-01-05 at 16:04 -0600, Larry Finger wrote:
> Thanks. That took care of the WARN_ON message and the SLUB debug messages;
Ok, good. Want to adopt that patch and formally submit it, or want me
to?
> however, the device will not scan until it has been powered down. I'm still
> looking for something there.
That's a bit odd, but I'm not sure I know how to help you. I've seen
things like that with ar9170 too though, if I rmmod/modprobe then I need
to unplug it to make it work again.
> Are there any other mac80211 routines that should be fed other than error codes?
I don't think so, no.
johannesNone that I'm aware of, no.
Johannes Berg wrote:
>
> That's rather strange, I see no way for this path to attempt sending an
> SKB that has since been freed. Unless... yes, here's a problem:
> rtl8187_tx is not supposed to return error codes, it's supposed to
> return NETDEV_TX_{OK,BUSY}.
Thanks. That took care of the WARN_ON message and the SLUB debug messages;
however, the device will not scan until it has been powered down. I'm still
looking for something there.
Are there any other mac80211 routines that should be fed other than error codes?
Larry