Bug 42252 - rtl8192se BUG on load
Summary: rtl8192se BUG on load
Status: RESOLVED INSUFFICIENT_DATA
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks: 40982
  Show dependency tree
 
Reported: 2011-09-02 18:22 UTC by Stephane Travostino
Modified: 2012-08-30 09:49 UTC (History)
8 users (show)

See Also:
Kernel Version: 3.0.4
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
dmesg with stack trace (65.60 KB, text/plain)
2011-09-02 18:22 UTC, Stephane Travostino
Details
Proposed patch (986 bytes, patch)
2011-09-03 03:28 UTC, Larry Finger
Details | Diff

Description Stephane Travostino 2011-09-02 18:22:39 UTC
Created attachment 71392 [details]
dmesg with stack trace

The builtin rtl8192se module from linux 3.0.4 crashes upon load with the attached stacktrace.

Reverted back to 3.0.3 when it seemed to run but I've got the same error.

The only way to have it run is compile the official Realtek driver - used version 92ce_se_de_linux_mac80211_0003.0620.2011

Specs: Archlinux updated daily, latest linux-firmware snapshot (20110822).
lspci:

06:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvA Wireless LAN Controller (rev 10)
Comment 1 Stephane Travostino 2011-09-02 18:31:28 UTC
I confirm that the problem lies in the mainline tree.

I upgraded to 3.0.4, stock firmware and driver and still got the error.
The only way to run it is using the Realtek driver, version posted above.

More info about the card:

06:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvA Wireless LAN Controller (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RTL8191SEvA Wireless LAN Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 256 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: I/O ports at d800 [size=256]
        Region 1: Memory at fbdfc000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: rtl8192se
        Kernel modules: rtl8192se

06:00.0 0280: 10ec:8171 (rev 10)
Comment 2 Greg Kroah-Hartman 2011-09-02 22:24:40 UTC
Does 3.0.1 work for you?  3.0.2?  3.0.3?
Comment 3 Larry Finger 2011-09-03 00:03:49 UTC
I cannot duplicate this problem using the same card as yours. The one thing I notice is that you have 8 CPUs that may be a lot faster than my 2. Ihave a dual-core Trurion at 2.0 GHz.

Does the same problem occur if you boot with "maxcpus=1" or "maxcpus=2" on the GRUB boot options line?
Comment 4 Larry Finger 2011-09-03 03:28:47 UTC
Created attachment 71502 [details]
Proposed patch

The code that initializes interrupts was run under a mutex. If I understand the failure correctly, the first interrupt actually occurs before the initialization finishes.

To test that this is the reason, the patch places the section in question inside a spin_lock_irqsave() .. spin_unlock_irqrestore() sequence.

Please report if this helps.
Comment 5 Stephane Travostino 2011-09-05 09:39:11 UTC
I haven't been able to reproduce the bug in the last days, using the stock driver.

I'm dual booting with Windows 7 and I suspect in some cases it may leave the wireless card in a strange state which causes the panic on Linux.

I'll see if there is a way to reliably reproduce the bug.
Comment 6 Larry Finger 2011-09-05 14:46:21 UTC
If Windows 7 is involved, there is no way for me to reproduce it. Keep trying to find a way for you to reproduce the problem.
Comment 7 John W. Linville 2012-01-13 19:03:14 UTC
Does this problem persist with kernel 3.2 or later?

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