Bug 548265

Summary: WiFi connection attempt on (most? all?) Asus EeePC models causes immediate kernel freeze
Product: [openSUSE] openSUSE 11.2 Reporter: Zsolt Sági <novell.admin>
Component: Mobile DevicesAssignee: E-mail List <mobile-bugs>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Critical    
Priority: P3 - Medium CC: forgotten_1-yzHWP3HO, jeffm
Version: RC 1Flags: coolo: SHIP_STOPPER-
Target Milestone: ---   
Hardware: Other   
OS: openSUSE 11.2   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: My asus eee pc 1000h hardware

Description Zsolt Sági 2009-10-19 22:31:16 UTC
Created attachment 323133 [details]
My asus eee pc 1000h hardware

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090909 SUSE/3.5.3-3.2 Firefox/3.5.3

I tested it on an 1000h model. Kill switch is Fn+F2. Scancode when pressing: 0xe0 0x73. Scancode when releasing: 0xe0 0xf3. When the WiFi card is associated with an AP and I press the kill switch, the kernel freezes immediately, so I was unable to find out why. If I disassociate my wireless card (e.g. by disabling (and the re-enabling but not connecting, if I want so) wireless from knetworkmanager) before activating the kill switch, the kernel won't hang.

Possibly the same bug at ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/420363

Reproducible: Always

Steps to Reproduce:
1. Boot 32bit 11.2 rc1 kde on an asus eeepc 1000h
2. enable wireless
3. connect to a wireless AP
4. disable wireless by the kill switch
Actual Results:  
The kernel hangs immediately.

Expected Results:  
Wireless should detach from the AP and go into down state without crashing.
Comment 1 Jeff Mahoney 2009-12-14 14:59:00 UTC
Are you still able to reproduce this with a recent KOTD? In response to another bug reported against rt2860, I backported the driver from 2.6.32 after I saw it had a bunch of fixes.

The problem here is that the driver is a "staging" driver. That means its quality is known to be pretty low and it's not yet ready to be incorporated into the "regular" kernel driver tree. We include the drivers because it's better to enable more hardware even if the driver isn't perfect.
Comment 2 Zsolt Sági 2010-01-05 12:24:18 UTC
(In reply to comment #1)
> Are you still able to reproduce this with a recent KOTD? In response to another
> bug reported against rt2860, I backported the driver from 2.6.32 after I saw it
> had a bunch of fixes.

No, I'm not able to reproduce this issue, because the kernel now crashes during AP association, making knetworkmanager's configuration corrupt on the ext4 filesystem. To sum it up my WiFi became absolutely unusable now. No connection is possible anymore.

I can type some kernel call trace from tty10:

[<c055e770>] skb_push+0x50/0x60
[<f87a3de8>] wlan_802_11_to_802_3_packet+0x48/0x70 [rt2760sta]
[<f8772c59>] Indicate_Legacy_Packet+0xf9/0x250 [rt2760sta]
[<f8798f99>] STAHandleRxDataFrame+0x1b9/0x530 [rt2760sta]
[<f8799452>] STARxDoneInterruptHandle+0x142/0x1c0 [rt2760sta]
[<f87b7340>] rx_done_tasklet+0x60/0xe0 [rt2760sta]
[<c0255af9>] tasklet_hi_action+0xf9/0x110
[<c0256bd4>] __do_softirq+0xb4/0x200
[<c0256db5>] do_softirq+0x95/0xb0
[<c0256f55>] irq_exit+0x85/0xa0
[<c020602c>] do_IRQ+0x5c/0xe0
[<c0204670>] common_interrupt+0x30/0x40
[<f7e6e6f4>] acpi_idle_enter_simple+0x13f/0x181 [processor]
[<c053da0e>] cpuidle_idle_call+0x8e/0x110
[<c0202a35>] cpu_idle+0xa5/0xf0
[<c05ee8c5>] rest_init+0x65/0x80
[<c08abcbb>] start_kernel+0x369/0x380
[<c08ab087>] i386_start_kernel+0x87/0x9f
Code: 00 00 89 4c 24 14 8b 88 b0 00 00 00 89 54 24 0c 89 4c 24 10 8b 40 50 89 5c 24 04 c7 04 24 cc ce 76 c0 89 44 24 08 e8 3b 1f 0a 00 <0f> 0b eb fe b9 51 99 73 c0 eb ae 66 90 55 89 e5 53 89 cb 83 ec
EIP: [<c055deb3>] skb_under_panic+0x63/0x70 SS:ESP 0068:c0877d1c
---[ end trace 783eb5ba732cbf69 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Comment 3 Zsolt Sági 2010-01-05 21:34:52 UTC
Sorry, I tried it with the update system's recently released 2.6.31.8-0.1.1. Should I retry it with ad even more recent KOTD?
Comment 4 Zsolt Sági 2010-01-12 09:53:53 UTC
Anybody there?
Comment 5 Forgotten User 1-yzHWP3HO 2010-01-19 09:05:05 UTC
hello all,

I experience also a freeze on my eeepc after updating. I narrowed it down to wireless, just as the previous poster.

with 2.6.31.5 it works fine; with 2.6.31.8 it dies. I've disabled wireless and all keeps working.

I noticed that ra0 now is changed to wlan0 in this version as well.
Comment 6 Zsolt Sági 2010-01-19 09:18:13 UTC
(In reply to comment #5)
> with 2.6.31.5 it works fine; with 2.6.31.8 it dies. I've disabled wireless and
> all keeps working.

I circumvented this problem by simply extacting rt2860sta.ko from the old kernel and copying in into /lib/modules/2.6.31.8-0.1-desktop/kernel/drivers/staging/rt2860.
Comment 7 Forgotten User 1-yzHWP3HO 2010-01-19 17:34:48 UTC
like Tamas said, I copied the rt2860sta.ko file over the 2.6.21.8 version and now it doesn't crash the kernel hard.

atom:/lib/modules/2.6.31.8-0.1-desktop/kernel/drivers/staging/rt2860 # md5sum *
7cb4f41b1d2311b640302fcebad0656d  rt2860sta.ko
6ebf76f824d9dde08b57b93247e5e416  rt2860sta.ko.fail
Comment 8 Jeff Mahoney 2010-01-19 17:37:24 UTC
This is a duplcate of bnc#540589

*** This bug has been marked as a duplicate of bug 540589 ***
Comment 9 Zsolt Sági 2010-01-19 17:41:41 UTC
(In reply to comment #7)
> like Tamas said, I copied the rt2860sta.ko file over the 2.6.21.8 version and
> now it doesn't crash the kernel hard.

Yes, this workaround makes openSUSE able to handle the WiFi, but this older kernel version still crashes if you press the killswitch during an active WiFi session (when the WiFi card is attached to an AP).
Comment 10 Jeff Mahoney 2010-01-19 17:46:31 UTC
Tamás, can you test the kernel in bug 540589? I had backported the rt2860 driver from 2.6.32 and mixed some things up while trying to clean up some badness in the driver. That's where the Oops from comment #2 came from and is fixed with the test kernel from bug 540589. I suspect your original issue may have been addressed by the driver backport.

The important thing is that this driver is a "staging" driver. They are typically not of very high quality, which is why they're not included in the "main" kernel tree. Unfortunately, there's no easy way to document this while the system is running other than your kernel being tainted "C" - for "crap."

We include them because we believe it's better to err on the side of hardware enablement. Otherwise your wireless wouldn't work at all.