Bug 11678

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