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)
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)
Does 3.0.1 work for you? 3.0.2? 3.0.3?
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?
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.
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.
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.
Does this problem persist with kernel 3.2 or later?