Bug 11678 - NETGEAR WG111v2 (USB RTL8187): freezes whole system when setup
NETGEAR WG111v2 (USB RTL8187): freezes whole system when setup
Status: RESOLVED INSUFFICIENT_DATA
Product: Networking
Classification: Unclassified
Component: Wireless
All Linux
: P1 normal
Assigned To: networking_wireless@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-30 15:26 UTC by Alex Riesen
Modified: 2009-05-16 13:17 UTC (History)
4 users (show)

See Also:
Kernel Version: v2.6.27-rc8, -rc7
Tree: Mainline
Regression: No


Attachments
1/500ms samples of backtraces while ifconfig wlan0 up (25.83 KB, text/plain)
2008-10-02 14:01 UTC, Alex Riesen
Details

Description Alex Riesen 2008-09-30 15:26:51 UTC
Latest working kernel version: never, AFAIK
Distribution: Ubuntu 8.04
Hardware Environment:
 P4 UHCI through an USB2.0 hub and directly
 Pentium-MMX/233 OHCI(USB1.1) through an USB1.1 hub and directly
Software Environment:
 ifconfig/ifup
Problem Description:
I have an USB wireless card: Netgear WG111v2. It is reported in
syslog as:

    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
Comment 1 Luis R. Rodriguez 2008-09-30 15:46:44 UTC
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.
Comment 2 Alex Riesen 2008-10-02 10:54:48 UTC
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.
Comment 3 Alex Riesen 2008-10-02 14:01:04 UTC
Created attachment 18141 [details]
1/500ms samples of backtraces while ifconfig wlan0 up
Comment 4 Alex Riesen 2008-10-02 14:02:08 UTC
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
related parts):
  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.
Comment 5 John W. Linville 2008-10-07 08:51:20 UTC
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?
Comment 6 Alex Riesen 2008-10-07 23:19:17 UTC
(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.

Comment 7 Hin-Tak Leung 2008-10-21 22:31:18 UTC
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.

Please clarify.
Comment 8 Alex Riesen 2008-10-22 10:38:28 UTC
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")
Comment 9 Alex Riesen 2008-10-22 10:47:45 UTC
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?)
Comment 10 Hin-Tak Leung 2008-10-22 12:29:54 UTC
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...
Comment 11 Hin-Tak Leung 2008-10-22 12:45:56 UTC
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.
Comment 12 Alan 2009-04-27 14:08:36 UTC
Closing old stale bug

Note You need to log in before you can comment on or make changes to this bug.