r818x driver freezes randomly

I suppose this driver is broken. I've been using ndiswrapper with breezy before. I currently made a clean install with dapper and it had this wifi driver of it's own, but it seemd to be poor.

When I tried to log in my WEP protected network the the whole system did freeze. I tried changing security options but it just couldn't make it. When I logged in to text terminal and activated the wifi-connection I saw that these drives causes kernel panic. I got my wlan working by disabling WEP but even though the signal strength jumped between 0% to 100% on the same room in which my natbox is. With ndiswrapper the signal strength did'nt jump like that. So I blacklisted those wifi-card modules which are r818x and ieee80211_rtl. And now the signal strength and WEP-protection is handled with ndiswrapper and it works well.

The current kernel I'm using is 2.6.15-18-386. I hope you guys get this fixed soont. :)

I can confirm that using ndiswrapper works like a charm. I have the same modules blacklisted.

Also I should add that doing NFS transmissions (sending, not receiving) freezes the system. SMB seems to have the same problems but very few times.

I can confirm this bug also occurs on an AMD3500+ chip and a Pentium IV 2.4ghz chip, using x86 version of Dapper Beta. Jumping signal strength, random freezes and all. Same card in two different PCs had exactly the same symptoms.

Card was an otherwise unnamed Excel 11mb/s PCI card using the rtl8180l chipset.

So looking like it's a driver thing, as opposed to a driver and certain obscure hardware issue?

Same problem with my 8180L-based PC-Card.

The signal strenght is jumping around and sometimes the card looses its connection to the access-point or router for some seconds.

Seems to my a driver problem, because ndiswrapper is working perfectly.

Concerning the signal strenght it's in fact not correct, that's what Andrea Merello said some time ago:

"...about the signal reported by the various ndiswrapper, windows, and this driver, please don't trust them!
Each driver uses its own criteria to show quality and furthermore in my driver the signal strenght report is still quite broken (this is why I couldn't implement rate adaption and signal drop-down handling). The way to discover if the problem is the signal strenght is just to move nearer to the AP."

Despite of it I still think this driver is working better than the binary one.
AFAIR after lowering sensibility (try adding wireless-sens 70 to /etc/network/interfaces) it doesn't disconnect anymore (i've an external antenna and the distance to another antenna is around 50m with a huge tree in between :))

And about the freezes, i've filled another bug report:

https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/38884

As i said it happens only on k7 kernel, which is SMP with "the SMP alternatives patch". If i compile it as an UP kernel, no freezes. Now i use i386 kernel and it works flawlessly.

I'm using the kernel driver again, and it apparently works ok in the lastest dapper kernel, however as Wiktor says it would be a good idea to wait a little and see if it reappears.

I see that this problem has dissapeared in kernel 2.6.15-22, BUT it appears again in -23. I read the changelog and it says that this driver was updated, so I'm guessing there's a problem with the latest driver.

I don't see any updates here:

http://kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=log;h=67f58057b76a7acf82a2baa2aa2a9ef7d6d576d2

are you sure anything was updated?

I must correct myself, this looks related to HIGH net use. I used bittorrent yesterday and i got a freeze, today same thing.

Looks related to high net use instead of randomness

I can confirm this bug on:
2.6.15-26-amd64-k8 #1 SMP PREEMPT Mon Jul 17 19:55:58 UTC 2006

Often happens when I'm receiving lots of data too, eg doing an apt-get upgrade.

I can confirm this very critic bug with a Edgy.

Linux Haruhi 2.6.17-7-server #2 SMP Wed Sep 6 17:58:27 UTC 2006 i686 GNU/Linux

I can confirm this bug under both Edgy and Feisty (stock kernels).

I am using a wireless card with a Realtek 8225 front-end chip. I have found that the system freezes ONLY when I am SENDING lots of data, NEVER when receiving. For example, if I throttle a file upload to 10 kB/s, it will continue to work indefinitely, but if I allow it to run at full speed the system will normally crash in a few seconds.

Who is maintaining this driver? I emailed the maintainer listed in the log files several months ago, but never received a response... I would like to try to fix this problem myself, but haven't made much headway. There's no indication in the system logs of anything going wrong before it crashes.

Okay, I have tracked down a bit more info on this bug: it is evidently a soft lockup resulting from a spinlock. I can reproduce it by trying to upload a 1gb file to a remote server without limiting the upload rate... my system will freeze within a few seconds or minutes of starting this. The system freezes, and then a few seconds later it spews out debug info onto the console.

uname -a: Linux localhost 2.6.19-7-generic #2 SMP Mon Dec 4 12:39:22 UTC 2006 x86_64 GNU/Linux

Unfortunately I haven't got a serial console set up, but here are the top few levels of the call trace, which are always the same:

Call trace:
    :ieee80211_rtl:rtl_ieee80211_stop_queue+0x20/0x60
    :ieee80211_rtl:rtl_ieee80211_softmac_xmit+0x74/0xc0
    :ieee80211_rtl:rtl_ieee80211_xmit+0x886/0x960
    __qdisc_run+0x11c/0x200
    dev_queue_xmit+0x125/0x270
    ip_output+0x217/0x270
    ip_queue_xmit+0x446/0x4a0
    tcp_transmit_skb+0x666/0x700
    tcp_push_one+0xfc/0x150
    tcp_sendmsg+0x88f/0xb10

Code: 83 3f 00 7e fa eb f2 c3 0f 1f 80
      00 00 00 00 0f 1f 80 00 00

Here is the code of the offending function (in the file /usr/src/linux-source-2.6.19/ubuntu/wireless/rtl_ieee80211/rtl_ieee80211_softmac.c from the Ubuntu package linux-source-2.6.19):

void rtl_ieee80211_stop_queue(struct rtl_ieee80211_device *ieee)
{
        unsigned long flags;
        spin_lock_irqsave(&ieee->lock,flags);

        if (! netif_queue_stopped(ieee->dev)){
                netif_stop_queue(ieee->dev);
                ieee->softmac_stats.swtxstop++;
        }
        ieee->queue_stop = 1;
        spin_unlock_irqrestore(&ieee->lock,flags);

}

Okay, will this help get the ball rolling for finding a fix to this problem? Any hints on how to fix it? I haven't done much kernel hacking...

The same problem occurs with the kernel 2.6.17-11-generic.

I am experiencing this lock up too in Feisty. I agree with Dan Lenski that it happens when sending data. An easy way to reproduce is to ssh to the machine containing the card and then cat /var/log/messages.

I am willing to ship my card to a developer that is willing to fix this bug.

Confirmed. System locks up hard when sending large amounts of data. Bittorrent, http server and sending pictures via MSN all lockup the system. Has anyone tried an updated kernel.org+ubuntu patched kernel? I really need my http server back up and running.

Found a temporary solution. System uploads totally fine when using the 2.6.20-15-386 kernel. All others cause hard lockups. Should be pretty easy to fix?

None of the drivers with the essid bug (you have to add a letter to the name) cause lockups here.

I have switched to the 2.6.20-15-386 kernel and I am no longer experiencing lock ups.

STILL Completely busted in Gutsy. Renders the system completely un-useable due to the fact that its not blacklisted anymore.

As someone already said, the driver hangs on high network usage when using a kernel other than -386. Of course the problem is that -386 kernel has no optimizations and not even NO_HZ :).

Can someone with the proper skills take a look at why would this be happening?

Also, the -386 kernel isnt on the disk, so theres no reasonable work
around as of yet. Ill look for another work around in a few hours.
Also, filing a new bug report.
Looks like Ill have to re-install just to get to a command line tho :|

Still happening. Problem appears on kernels other than -386 variant. Ndiswrapper is not a solution because uploading files is broken there.

I can confirm that this is still busted in 7.10, as well. Why was it removed from the blacklist?

...but I put the old blacklisted lines in:

blacklist r818x
blacklist ieee80211_rtl
blacklist r8187

...and it still doesn't work. It still freezes on startup. However, if I take out the realtek wireless card from the laptop physically, the system starts up fine!

Any ideas?

The offending module is actually r8180
So,

blacklist r8180

should cover it.

I had to remove the card from the machine too. I read somewhere (not sure of the link anymore). That is because of WEP and this card. I haven't had a chance to see if what happens if I turn off WEP, and I'm not sure of what would happen if I used WPA. Has anyone tried this?

When I rmmod the module, I get this on dmesg:

[145624.216000] pccard: CardBus card inserted into slot 0
[145624.420000] rtl_ieee80211_crypt: registered algorithm 'NULL'
[145624.420000] rtl_ieee80211_crypt: registered algorithm 'TKIP'
[145624.420000] rtl_ieee80211_crypt: registered algorithm 'WEP'
[145624.420000] rtl_ieee80211_crypt: registered algorithm 'CCMP'
[145624.488000]
[145624.488000] Linux kernel driver for RTL8180 / RTL8185 based WLAN cards
[145624.488000] Copyright (c) 2004-2005, Andrea Merello
[145624.488000] rtl8180: Initializing module
[145624.488000] rtl8180: Wireless extensions version 22
[145624.488000] rtl8180: Initializing proc filesystem
[145624.492000] rtl8180: Configuring chip resources
[145624.492000] PCI: Enabling device 0000:03:00.0 (0000 -> 0003)
[145624.492000] ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[145624.492000] PCI: Setting latency timer of device 0000:03:00.0 to 64
[145624.492000] rtl8180: Memory mapped space @ 0xd4000000
[145624.492000] rtl8180: MAC controller is a RTL8180
[145624.492000] rtl8180: This is a CARDBUS NIC
[145624.492000] rtl8180: Reported EEPROM chip is a 93c56 (2Kbit)
[145624.500000] rtl8180: Card MAC address is 00:09:5b:22:02:c4
[145624.508000] rtl8180: EEPROM version 102
[145624.508000] rtl8180: RfParam: 5
[145624.512000] rtl8180: Card reports RF frontend by Philips.
[145624.512000] rtl8180: OK! Philips SA2400 radio chipset is supported.
[145624.512000] rtl8180: Analog PHY found
[145624.512000] rtl8180: Energy threshold: b
[145624.512000] rtl8180: PAPE from CONFIG2: 6
[145624.512000] rtl8180: Antenna A is default antenna
[145624.512000] rtl8180: Antenna diversity is enabled
[145624.512000] rtl8180: Carrier sense 1
[145624.512000] rtl8180: 40-bit WEP is NOT supported in hardware
[145624.512000] rtl8180: 104-bit WEP is NOT supported in hardware
[145624.516000] rtl8180: IRQ 11
[145624.516000] rtl8180: Driver probe completed
[145624.516000]
[145633.492000] rtl8180: Card successfully reset
[145633.712000] rtl8180: Freeing irq 11
[145633.716000] ACPI: PCI interrupt for device 0000:03:00.0 disabled
[145633.716000] rtl8180: wlan driver removed
[145633.716000]
[145633.716000] WARNING: at /build/buildd/linux-source-2.6.22-2.6.22/fs/proc/generic.c:741 remove_proc_entry()
[145633.716000] [<c01b8585>] remove_proc_entry+0x1a5/0x1b0
[145633.716000] [<f8b70362>] rtl8180_pci_module_exit+0x12/0x22 [r8180]
[145633.716000] [<c014c1da>] sys_delete_module+0x12a/0x190
[145633.716000] [<c02f0030>] clip_constructor+0x20/0xa0
[145633.716000] [<c016f9d6>] do_munmap+0x186/0x1e0
[145633.716000] [<c01041d2>] sysenter_past_esp+0x6b/0xa9
[145633.716000] [<c02f0000>] clip_ioctl+0x500/0x510
[145633.716000] =======================
[145633.716000] rtl8180: Exiting

To summarise:

Using r818x driver:
- Getting data works as long as the load is low, high network load produces a system freeze.
- Sending data (uploading) freezes the system
- WEP key is useless, setting it freezes the system (this worked fine before)
- -386 variant kernels allow safe uploading and downloading of data, however WEP still freezes the system and a kernel without NO_HZ is pretty useless on a laptop.

Using ndiswrapper net8180:
- Getting data works fine, no matter the load.
- Sending data doesn't work, transfers above some few Kbs get stalled forever.
- WEP key is useless, it causes a partial freeze on the system that becomes a full freeze after some seconds
- WPA state is unknown, but probably the same as WEP

Doing a summary of both lists:
- Getting data always work (ndis, r8180-386) as long as you don't put the card to high load (like torrents), a high load can take you to a freeze (r8180).
- Sending data either freezes (r8180) the system or doesn't work (ndis).
- WEP is always useless.
- Using a -386 kernel allows you to safely send and receive data (r8180), without freezes. However you are not able to use WEP anyway. ndiswrapper always stalles.

I add myself to the begging to get this fixed somehow.

I have freeze problem as described in bug #74418, I am using a wireless PCI card using rtl818x driver, I am using Gutsy.

Please contact me if I can provide some debug info, or help test.

@dieguito, my experience with a rlt 8180 based NIC, has been exactly the same so far.

Unfortunately, I have not been able to find any suitable modules in Gutsy (kernel 2.6.22-14-386)

Not much luck with Ndiswrapper either. Seems like that module is gone as well. Weird.

Hi, I'm having the same problem (I think). I don't have access to a non-WEP'd network to check the card without it, but upon attempting to connect to the network with WEP, the whole system completely freezes, requiring a hard reset.

I can confirm that my card (a generic RTL8180 based PCMCIA card) worked perfectly using the ubuntu driver with 2.6.20, but with 2.6.22 it gives me this behaviour.

Attached tar contains a r818x version that is patched to be built with 2.6.24, the source code is from rtl-wifi.sf.net and adapted by a guy in their forum (search it if you wanna credit it, probably he's already credited in the source files).
I repeat that the svn version does not work, this patched version works, I didn't really care on producing a patch after I got this thing working. All I know is that I'll not upgrade my kernel if there's no good reason to have to do it and hence rebuild the driver...

It needs some love though, I couldn't get it to install but insmoding it works fine.

This driver works perfectly, I have been stress testing it and so far it has no problems with uploading or WEP keys, I haven't tested WPA.

If someone creates a package from this source, I (and I am sure others) would be happy to test.

This driver doesnt work well to me. Using Hardy-8.04 w/ 2.6.24-15 kernel and "0bda:8187" card.
I still need to be very very close to the AP to be able to use the wifi conn.

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Doesn't seem to happen, but the included driver kernel has a mysterious disconnection problem. But that's not this bug.

This bug seems to be resolved according to the last comment. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks.