Bug 501109 - kernel hangs when using wifi module rtl8180
Summary: kernel hangs when using wifi module rtl8180
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 11
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-05-16 14:11 UTC by Olivier Fourdan
Modified: 2010-06-22 23:10 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-06-09 17:46:23 UTC

Attachments (Terms of Use)
sosreport of the system (499.46 KB, application/x-bzip)
2009-05-16 14:11 UTC, Olivier Fourdan
no flags Details
rtl8180: fix tx status reporting (1.06 KB, patch)
2010-04-30 17:39 UTC, John W. Linville
no flags Details | Diff

System ID Priority Status Summary Last Updated
Launchpad 368679 None None None Never
Debian BTS 563668 None None None Never

Description Olivier Fourdan 2009-05-16 14:11:17 UTC
Created attachment 344269 [details]
sosreport of the system

Description of problem:

Ther system experiences hard hang when using WIFI with the rtl8180 kernel module. The system ends in such a state that sysrq is inefficient (sysrq-t, sysrq-m, sysrq-c do nothing) and quite often require a complete electrical unplug for several seconds to be able to reboot.

Console logs or /var/log/message show no oops or kernel backtrace.

Blacklisting the module rtl8180 or removing the Belkin WIFI G PCI card cures the problem but does not help with WIFI connectivity ^_~

Version-Release number of selected component (if applicable):

kernel-PAE- (But occurs on older kernel as well, including F10)

How reproducible:

100% reproducible

Steps to Reproduce:

1. Install the Belkin Wireless G dektop PCI card Based on the Realtek 818x
2. Boot the system
Actual results:

System will hang either at login or at logout

Expected results:

System remains stable and functional

Additional info:

The WIFI connection uses hidden ESSID and WPA/WPA2 security. The problem occurs either when NetworkManager connects to the network or when it terminates (logging out from the user session leads to a 100% hang).

Same happens if NetworkManager exits or needs to reconnect. The same hardware works perfectly under Windows with Belkin's provided driver though.

I am attaching the sosreport of the system, unfortunately I am unable to debug this issue much further and I could not come up with a usable workaround for the issue.

Comment 1 Bug Zapper 2009-06-09 15:55:39 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:

Comment 2 Skippy 2009-12-29 21:50:55 UTC
I can confirm this bug for Fedora 12 with the following wifi card : Zyxel G-302 v3.

For some other reason I cannot achieve a proper install right now so I can confirm only with the live CD, but symptoms are exactly the same as above : boot ok, user session ok, if I click on the NetworkManager icon I can select the network, then connect to it, enter my WEP key, and then the system will freeze (while asking for the keyring password, secondarily). If I don't try to connect, everything works fine but the system won't shutdown (didn't try to logout).

Similar issues happen with Ubuntu, cf https://bugs.launchpad.net/ubuntu/+source/linux/+bug/368679

Comment 3 Sylvain Arth 2010-03-16 18:14:38 UTC
I too confirm this kernel hang with a TRENDdet TEW-423PI (C1.0R) on a up to date Fedora 12 the only message when manually activating the connection was some "invalid parameter" message when using the GUI 
Otherwise when on startup or command line nothing is showing but only the endless hang

BTW this is a blocker on the rescue mode if the interface is checked on as managed by the NetworkManager
My workaround has been to let this card disabled :( 
obviously that was not my goal

Comment 4 Bug Zapper 2010-04-27 14:21:20 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 5 John W. Linville 2010-04-30 17:39:56 UTC
Created attachment 410552 [details]
rtl8180: fix tx status reporting

Comment 6 John W. Linville 2010-04-30 17:42:19 UTC

I don't get any such hang on F-12 w/ my cardbus rtl8185 device.  However, I did get rather poor performance.

Are you still seeing this hang with the test kernels above?

Comment 7 Steven Rostedt 2010-05-24 02:39:21 UTC
I just installed f12 on my wife's computer (she finally got frustrated enough with Windows to let me do it), and it hit this bug.

I have the following card:


From lspci -vv

02:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller (rev 20)
	Subsystem: ZyXEL Communication Corporation Device 340d
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at 2000 [size=256]
	Region 1: Memory at e8100000 (32-bit, non-prefetchable) [size=512]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: rtl8180
	Kernel modules: rtl8180

Seems to be a race condition. It gets past setting up the wlan0 every other boot or so. Once it is up and running, everything is fine. I tried suspend and resume once, and that locked up on resume too (even though this is a desktop, it should still support s2r).

I'm currently doing a "yum update", I'll report again with the results of the latest kernel.

Comment 8 Steven Rostedt 2010-05-24 13:07:37 UTC
After doing a "yum update" and updating all packages since the fresh f12 install (which included the kernel package), I have yet to hit this bug.

I've rebooted 4 times and suspend and resumed twice. So far, so good.

Comment 9 Steven Rostedt 2010-05-24 13:59:08 UTC
Spoke too soon. Seems the race condition is smaller. While showing my wife how to use her box, it locked up on suspend and resume while (I think) initializing the network.

Comment 10 John W. Linville 2010-05-24 16:57:45 UTC
Steven, and logs available?  Perhaps you could capture a trace using netconsole (over a wired port)?

Comment 11 Steven Rostedt 2010-05-26 00:41:39 UTC
John, investigating this further, the lockup seemed to have nothing to do with the network card. It looks like a drm/i915 bug. But it takes out the network too, although I don't know why.

It looks like I'm hitting this bug:

As far as I can tell from the logs when it locks up now. It does not seem to be related to the wifi nic, but to the video. I don't understand why I lose my wireless on the X lockup. I'm fine on serial. I'll try again with a wired connection, but as far as I'm concerned, it looks like this BZ is done.

I would like a working system before I conclude that though ;-)

Comment 12 Steven Rostedt 2010-05-27 19:05:20 UTC
Interesting, after pulling the pci wireless card, I can not make X lockup. I wonder if it is related.

Comment 13 Steven Rostedt 2010-05-27 20:59:55 UTC
Nevermind, I was able to finally reproduce the hang without the wireless card.

Comment 14 John W. Linville 2010-06-09 17:46:23 UTC
I can't recreate any problems -- this driver works reasonably well for me.

Comment 15 Sylvain Arth 2010-06-22 23:10:32 UTC
(In reply to comment #14)
> I can't recreate any problems -- this driver works reasonably well for me.    
It just means the card you own works fine with it....
Btw do you own a realtek branded one ?
Thanks in advance

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