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
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 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.
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. Please clarify.
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