Kernel Bug Tracker – Bug 11678
NETGEAR WG111v2 (USB RTL8187): freezes whole system when setup
Last modified: 2009-05-16 13:17:33 UTC
Latest working kernel version: never, AFAIK
Distribution: Ubuntu 8.04
P4 UHCI through an USB2.0 hub and directly
Pentium-MMX/233 OHCI(USB1.1) through an USB1.1 hub and directly
I have an USB wireless card: Netgear WG111v2. It is reported in
usb 4-2: Product: NETGEAR WG111v2
usb 4-2: Manufacturer: NETGEAR WG111v2
usb 4-2: SerialNumber: 000FB5D51ECA
phy1: Selected rate control algorithm 'pid'
phy1: hwaddr 00:0f:b5:d5:1e:ca, RTL8187vB (default) V1 + rtl8225
usbcore: registered new interface driver rtl8187
On ifconfig up, the card always locks up two very different systems: a
relatively modern P4 desktop and P-MMX laptop with UHCI (ancient Compaq
Armada 1592DT) which has an OHCI.
The connection is not stable and sometimes the card just stops
talking to anything outside: the connection is not dropped, but
nothing works (no ping replies). Up/down interface does not help.
Aside from that there were no ill effects noticed.
Steps to reproduce:
1. Insert the card
2. ifconfig wlan0 up and try typing something or move the mouse
Would it be possible for you provide an oops? One way of doing this is to press: CTRL ALT F1, log in and then plug your card in and type the commands you mentioned and crash it.
Take a picture of it or write down the oops.
Well, the dirver does not oops by itself. Never ever. It freezes the system, does not crash it.
If you just want a backtrace, I'll can try to provide it but, as the system is frozen, Alt-SysRq-T probably will come too late... I'll try, anyway.
Created attachment 18141 [details]
1/500ms samples of backtraces while ifconfig wlan0 up
Comment on attachment 18141 [details]
1/500ms samples of backtraces while ifconfig wlan0 up
Well, I tried (and _not_ the whole system is frozen, just network interface
term1$ sleep 0.5; ifconfig wlan0 up
term2$ while sleep 0.5; do echo t >/proc/sysrq-trigger; done
IOW, I tried sampling backtrace every 500ms. There're no timestamps, but it
is around 10 sec from first ifconfig in D-state to the last. There is a
considerable amount of USB activity and msleep, so this may be a hint...
I just don't know.
What does it mean for "just the network interface related parts" to be "frozen"? Do you mean that iwconfig or ifconfig is hanging? Or simply that you don't get a wireless connection? Or something else?
(In reply to comment #5)
> What does it mean for "just the network interface related parts" to be
> "frozen"? Do you mean that iwconfig or ifconfig is hanging?
These two - yes. I actually tried running them both (and ip(8) and it hangs, too)
> Or simply that you don't get a wireless connection? Or something else?
Well, I get the connection in the end. But it also looks like every non-local
connect(2) freezes its caller.
Hmm, the device/driver needs time to initialize, so ifconfig "waits" for as long as it will take (4-10 secs on typical current systems). That's not a hang. The driver/device can be improved to start up faster and takes less time to initialize, though.
The problem is not that just ifconfig hangs. If you read the bugreport, you'll
notice that it talks about WHOLE system (it's a bit exaggerated, yes. Only the
network related parts).
So clarification: NOT ONLY ifconfig hangs. Something else is blocked as well
and the system just feels frozen (like "mouse pointer can't be moved")
BTW, why must ifconfig be blocked? There is a lot of ways to get notified
asynchronously (netlink?), why can't the ioctl in question just return EBUSY
or something like this?
(and anyway, what to do about almost frozen system?)
I think you have mis-worded your report - you "have a period of general
unresponsiveness", which is not a hang. (and I do not have the same "unreponsiveness" experience as you, ever).
I just woke my laptop from suspend. Since the driver itself does not declare explicit suspend/resume support, the kernel removes the module on suspend
and re-insert on resume. These are the timing according to my syslog:
2 seconds for udev to notice the device
4 seconds for NetworkManager to notice the wireless device and to bring it up
11 seconds to bring it up
9 seconds to associate with the wireless access point
4 seconds to get an ip address via dhcp, and another second for NetworkManager to acknowledge it.
The whole process takes 2 + 4 + 11 +9 + 4 +1 = 31 seconds from the whole machine waking up from suspend to having full connectivity. It is not ideal (and is a known issue), but NetworkManager's applet is spinning all the time, so I know it is working on it; and the machine remains responsive throughout, and also when I choose to disconnect and reconnect to a different access point.
The wait usually doesn't matter, because (1) the machine is responsive otherwise and NetworkManager's applet has a spinning icon saying it is working on it, (2) if you are using a static configuration, it is a small number compare to the machine booting up. (and most of that 30 seconds is not noticeable between log-in and the whole desktop appearing, in usual NM usage).
Some other devices can take a few seconds to initialize - what a big part of booting time is about.
(In reply to comment #9)
> BTW, why must ifconfig be blocked? There is a lot of ways to get notified
> asynchronously (netlink?), why can't the ioctl in question just return EBUSY
> or something like this?
Well, I have no answer to that - but if you think you can do better, feel free to DIY...
In to your log, there are 20 entries of rtl8187_start and 1 entry of rtl8187_config; and out of that 20 entries, 14 of them you managed to catch the
driver doing msleep() - it is literally sleeping and waiting for the hardware to
stablize after the last command - this is a known characteristic of not-too-recent version of the driver. That's 10 seconds where 7 seconds (or 14 times) you have managed to catch the driver sleeping. So the driver is literally *not doing anything* 7 out of 10 times you look at it.
I think to solve your problem, we need the *full* backtrace - i.e. what *else*
is your system doing. e.g. you may have a buggy USB hub, etc.
Closing old stale bug