rtl8187se locks up when switching network

rtl8187se locks up when switching network

[Stefan Monnier]

I've been using the rtl8187se driver in the vanilla liunx kernel since
2.6.29 for my MSI Wind and in general it seems to work just fine for my
use (connecting as a client to different access points, some of which
use WPA and others public, all under the control of wicd).

The only problem is that while connecting/disconnecting from networks
appears to work, the system often (almost always) hangs when connecting
to a different network than the last one.

I've just dine a few more tests, and switching network works just fine
if I "modprobe -r rtl8187se" and then "modprobe rth8187se" between the
disconnect and the reconnect, but otherwise the system almost always
hangs during the connection to the other network.  The way it hangs is
always the same: everything just freezes and 2 of the status
leds blink.  The exact moment at which the freeze takes place seems to
vary: sometimes it's while getting the IP address, other times its
earlier.

I've seen it with the 2.6.29 and 2.6.30 Debian kernels and have just
tried it with a freshly cloned wireless-testing kernel (2.6.32-rc6-wl).

IIUC this driver is not under active development, but maybe someone
knows it enough to try and fix it, or maybe there's some alternative
driver for this card that I should try?


        Stefan


PS: I see nothing in the system logs around the time of the system hang.
Here's the dmesg output when inserting the module, in case it's helpful.

[ 1398.353690] Linux kernel driver for RTL8180 / RTL8185 based WLAN cards
[ 1398.353706] Copyright (c) 2004-2005, Andrea Merello
[ 1398.353716] r8180: Initializing module
[ 1398.353728] r8180: Wireless extensions version 22
[ 1398.353739] r8180: Initializing proc filesystem
[ 1398.353834] r8180: Configuring chip resources
[ 1398.353885] r8180 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 1398.353911] r8180 0000:02:00.0: setting latency timer to 64
[ 1398.356863] r8180: Channel plan is 2
[ 1398.356869] 
[ 1398.356881] Dot11d_Init()
[ 1398.356895] r8180: MAC controller is a RTL8187SE b/g
[ 1398.356903] r8180: This is a PCI NIC
[ 1398.359377] r8180: usValue is 0x100
[ 1398.359385] 
[ 1398.414271] r8180: EEPROM version 104
[ 1398.419068] r8180: WW:**PLEASE** REPORT SUCCESSFUL/UNSUCCESSFUL TO Realtek!
[ 1398.420127] r8180: IRQ 17
[ 1398.424538] r8180: Driver probe completed

Re: rtl8187se locks up when switching network

[Larry Finger]

On 11/10/2009 07:25 PM, Stefan Monnier wrote:
> I've just dine a few more tests, and switching network works just fine
> if I "modprobe -r rtl8187se" and then "modprobe rth8187se" between the
> disconnect and the reconnect, but otherwise the system almost always
> hangs during the connection to the other network.  The way it hangs is
> always the same: everything just freezes and 2 of the status
> leds blink.  The exact moment at which the freeze takes place seems to
> vary: sometimes it's while getting the IP address, other times its
> earlier.

Do you mean that the "Caps Lock" and "num lock" LEDs are blinking? If so, that
is a kernel panic. You will be able to capture some information about that crash
by switching to the logging console (CTRL-ALT-F10) just after you initiate the
process that causes the crash.

> IIUC this driver is not under active development, but maybe someone
> knows it enough to try and fix it, or maybe there's some alternative
> driver for this card that I should try?

The vendor driver in staging is not really under active development. We are
currently writing a mainline driver that uses mac80211 from the vendor code. Of
course, it is not possible to predict when this driver will be ready.

Larry

Re: rtl8187se locks up when switching network

[Stefan Monnier]

>> I've just dine a few more tests, and switching network works just fine
>> if I "modprobe -r rtl8187se" and then "modprobe rth8187se" between the
>> disconnect and the reconnect, but otherwise the system almost always
>> hangs during the connection to the other network.  The way it hangs is
>> always the same: everything just freezes and 2 of the status
>> leds blink.  The exact moment at which the freeze takes place seems to
>> vary: sometimes it's while getting the IP address, other times its
>> earlier.

> Do you mean that the "Caps Lock" and "num lock" LEDs are blinking?

Could be (the label got washed away fairly quickly, but since those
leds are normally always off and I never use num-lock nor caps-lock,
that sounds right).

> If so, that is a kernel panic. You will be able to capture some
> information about that crash by switching to the logging console
> (CTRL-ALT-F10) just after you initiate the process that causes
> the crash.

It wasn't easy to do it quickly enough, but I just got a backtrace
there.  The 1024x600 display doesn't let me see the whole backtrace and
I don't seem to be able to scroll, so here's the part I can see:

   do_invalid_op+0x6c/0x75
   skb_put+0x5d/0x67
   vt_console_print+0x0/0x247
   up+0x9/0x2a
   release_console_sem+0x174/0x1a2
   error_code+0x66/0x6c
   do_invalid_op+0x0/0x75
   skb_put+0x5d/0x67
   ieee80211_association_req+0x189/0x1f8 [rtl8187se]
   ieee80211_association_req+0x189/0x1f8 [rtl8187se]
   ieee80211_associate_step+0x24/0x5b [rtl8187se]
   ieee80211_rx_frame_softmac+0x358/0x498 [rtl8187se]
   cpumask_next_and+0x23/0x33
   ieee80211_rx+0x542/0xc9c [rtl8187se]
   __alloc_skb+0x46/0x111
   rtl8180_rx+0x728/0x828 [rtl8187se]
   hrtimer_get_next_event+0x8c/0xa0
   tasklet_action+0x67/0xad
   rtl8180_interrupt+0x35d/0x368 [rtl8187se]
   __do_softirq+0xaa/0x151
   do_softirq+0x31/0x3c
   irq_exit+0x26/0x58
   do_IRQ+0x78/0x89
   common_interrup+0x29/0x30
   acpi_idle_enter_bm+0x246/0x281 [processor]
   cpuidle_idle_call+0x68/0xbb
   cpu_idle+0x46/0x5f
   start_kernel+0x2c7/0x2ca

>> IIUC this driver is not under active development, but maybe someone
>> knows it enough to try and fix it, or maybe there's some alternative
>> driver for this card that I should try?
> The vendor driver in staging is not really under active development.
> We are currently writing a mainline driver that uses mac80211 from the
> vendor code.  Of course, it is not possible to predict when this
> driver will be ready.

If/when there's something I can do to help test it, please let me know,


        Stefan