We had this long-time problem with the Netgear WPN311 wireless cards which seemed to go and come back intermittently with each kernel revision: if we used intensively the wireless, the computer would freeze. As in totally frozen (you couldn’t even go back to a console and restart the X or something from there).
With Ubuntu 9.10 and the 2.6.31 kernel, the problem seemed semi-stable and only appeared if we used packet-crazy software such as bittorrent at high speeds, but at least we could connect to internet. Mr doob, a brave soul, updated his computer to Ubuntu 10.4 pretty much as soon as it was released, and got all the worse for that: the wireless card would freeze the computer almost every 20 minutes, and even worse, without any pattern such as “using a lot the internet” or “using bittorrent”. He ended up using another computer which a different wireless chipset, but that’s an expensive fix!
After I upgraded my computer hardware-wise I felt it was the time to risk it and upgrade it software-wise too. Mr doob warned me that I would be regretting this move later on, but I couldn’t stand the envy each time I went to his computer and saw the nicer shiny interface he had in 10.4, while I was still using 9.10 and a lot of outdated applications. Yes, one can use PPA’s for that, but it’s a bit tedious to install a PPA for every single program you want to update :D
So after carefully considering all the bug reports about the ath5k driver, I dared to update the system.
And as expected, a mere 15-20 minutes after the system had been updated and restarted, it froze.
None of the solutions out there seemed to make much sense, except for one which suggested a patch to the ath5k driver. This is how I applied the solution to the latest version of Ubuntu:
Download the source for the latest kernel:
sudo apt-get install linux-source-2.6.32It ends up downloading a .bz2 file into /usr/src. To uncompress it:
cd /usr/src
sudo tar -xvjf linux-source-2.6.32.tar
cd linux-source-2.6.32The patch expects the files to be in drivers/net/wireless/ but it seems they have been moved around since then. Now they are in drivers/net/wireless/ath/ath5k (note the extra /ath/).
I took a look at the files, and noticed that the patch hadn’t been applied to the kernel, even if the patch was almost two years old already.
So I manually applied the patch to the files (it was easy, just around 10 lines of code). Here’s how it should be done, green lines are new lines (additions), red lines are deleted things:
base.c
diff --git a/home/sole/Desktop/linux-source-2.6.32/drivers/net/wireless/ath/ath5k/base.c b/driver
index 6313788..db2c785 100644
--- a/home/sole/Desktop/linux-source-2.6.32/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -551,6 +551,7 @@ ath5k_pci_probe(struct pci_dev *pdev,
sc->opmode = NL80211_IFTYPE_STATION;
sc->bintval = 1000;
mutex_init(&sc->lock);
+ spin_lock_init(&sc->restlock);
spin_lock_init(&sc->rxbuflock);
spin_lock_init(&sc->txbuflock);
spin_lock_init(&sc->block);
@@ -2727,6 +2728,7 @@ ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
{
struct ath5k_hw *ah = sc->ah;
int ret;
+ unsigned long flags;
ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "resetting\n");
@@ -2738,7 +2740,10 @@ ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
sc->curchan = chan;
sc->curband = &sc->sbands[chan->band];
}
+ spin_lock_irqsave(&sc->restlock, flags);
ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, chan != NULL);
+ spin_unlock_irqrestore(&sc->restlock, flags);
+
if (ret) {
ATH5K_ERR(sc, "can't reset hardware (%d)\n", ret);
goto err;base.h
diff --git a/home/sole/Desktop/linux-source-2.6.32/drivers/net/wireless/ath/ath5k/base.h b/drivers/net
index a28c42f..a0cbf61 100644
--- a/home/sole/Desktop/linux-source-2.6.32/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -162,6 +162,7 @@ struct ath5k_softc {
led_on; /* pin setting for LED on */
struct tasklet_struct restq; /* reset tasklet */
+ spinlock_t restlock; /* protects reset state */
unsigned int rxbufsize; /* rx size based on mtu */
struct list_head rxbuf; /* receive buffer */And phy.c
diff --git a/home/sole/Desktop/linux-source-2.6.32/drivers/net/wireless/ath/ath5k/phy.c b/drivers/net/
index 9d67647..112e8e2 100644
--- a/home/sole/Desktop/linux-source-2.6.32/drivers/net/wireless/ath/ath5k/phy.c
+++ b/drivers/net/wireless/ath/ath5k/phy.c
@@ -578,8 +578,9 @@ int ath5k_hw_rfregs_init(struct ath5k_hw *ah, struct ieee80211_channel *channel,
* ah->ah_rf_banks based on ah->ah_rf_banks_size
* we set above */
if (ah->ah_rf_banks == NULL) {
- ah->ah_rf_banks = kmalloc(sizeof(u32) * ah->ah_rf_banks_size,
- GFP_KERNEL);
+ //ah->ah_rf_banks = kmalloc(sizeof(u32) * ah->ah_rf_banks_size,
+ // GFP_KERNEL);
+ ah->ah_rf_banks = kmalloc(sizeof(u32) * ah->ah_rf_banks_size, GFP_ATOMIC);
if (ah->ah_rf_banks == NULL) {
ATH5K_ERR(ah->ah_sc, "out of memory\n");
return -ENOMEM;Then this:
sudo make oldconfig
sudo makeand I let the computer compiling the kernel while I went to sleep, but I forgot to deactivate the wireless and it got frozen again, without completing the compilation.
Next morning, after cursing myself for having forgotten to deactivate the wireless, I rebooted again, but using the previous kernel (selected it from GRUB), just to be safe, and once the wireless had been deactivated, I tried to recompile again. This time it stopped in the middle because there’s an error in one Makefile (I seriously wonder how the Ubuntu guys manage to compile the kernel if it fails like this for them!)
Anyway, I manually applied this patch as well, and restarted the compilation again.
Once it finished, I got the desired new driver module (drivers/net/wireless/ath/ath5k/ath5k.ko) which I wanted to use instead of the existing module. So I backed it up and copied the new one over the old one:
cp /lib/modules/2.6.32-23-generic/kernel/drivers/net/wireless/ath/ath5k/ath5k.ko ~/Desktop
sudo cp /usr/src/linux-source-2.6.32/drivers/net/wireless/ath/ath5k/ath5k.ko /lib/modules/2.6.32-23-generic/kernel/drivers/net/wireless/ath/ath5k/ath5k.koand restarted the computer to use the latest kernel (and the new updated module)
I have tested it using bittorrent, amule, youtube, downloading packages from synaptic, all at the same time. So far I haven’t experienced any freeze, and the net speed is normal (if there’s a slowdown, I can’t appreciate it), so I would say the patch fixes this annoying bug.
I wonder why the fix has not been applied to the kernel (after two years!!) but I presume that maybe these cards are not as popular as maybe other wireless chipsets and as such they get less coverage/reports than other bugs. In any case, Bob Copeland (the author of the patch) is my personal hero for at least this month.
Bob, THANKS A LOT FOR THE PATCH!!!
Tomislav Nakic-Alfirevic
Hi Soledad, thank you for the very nice howto on WPN311 and ubuntu…unfortunately, I seem to be still stuck with an unstable system.
I installed the kernel source (2.6.32-24.39), unpacked it and manually patched the three files: I rechecked the patches and they seem to be correct. I built the kernel using “make oldconfig” and “make” and, among other things, got a new ath5k.ko file. I backed up the original ath5k.ko and put the new one in it’s place and rebooted.
Two things worry me. First, why is the new .ko file 2393308 bytes big and the old one just 153792 (i.e., 2.4MB vs. 154kB)? Debug symbols? Something else?
Second, I didn’t encounter the Makefile problem. You think it might have anything to do with you using 2.6.32-23 and me using 2.6.32-24.39?
In general, I seem to be using the right kernel:
$ uname -a
Linux neva 2.6.32-24-generic-pae
I’m using the “2.6.32-24-generic-pae” kernel because I need access to more than 3.2GB RAM.
Do you see a problem with what I did? Could it have anything to do with the pae kernel? Do you think you could send me your ath5k.ko to see if the system works with that? Is there anything else I need to do to make the kernel use the new driver other than copying it in /lib/modules…?
Cheers,
Tomislav
sole
Hi!
Mine after recompiling was also super big. 3.7MB, now that you point that out. Not sure why, maybe there are some optimiser flags not set in the makefile or whatever. I have no idea, and haven’t actually looked into that.
You not finding the makefile problem is a good sign: means they’ve fixed that :D
And the other thing I did after replacing the kernel .ko file with mine was just restarting the system.
I am now running another fresh and updated version of the kernel (I think I installed it five or six days ago, right from the System Updater). I thought I would need to apply this patch as soon as possible, since when I had a look at the list of kernel changes in this update I couldn’t find any reference to ath5k that looked like fixing our system freezes, but I haven’t done so and I have only had one system freeze since. I didn’t even bother having a look at /var/log/syslog to find out if it had been due to the usual ath5k madness, but if it happens again I’ll have a look into that.
In general it seems this new kernel is a tad more stable… before it was a freeze pretty much right after starting the system, and using bittorrent or downloading large files was something next to impossible, whereas now I can do that without the computer freezing.
My uname -a report, just in case it helps you:
Linux courgette 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 05:14:15 UTC 2010 x86_64 GNU/Linux
PD I am unsure about the pae thing, maybe you’re using a 32 bit Linux? Maybe the fix I suggest only works effectively with 64 bit Linux? Or maybe my 64 bit kernel is more stable than the 32 bit kernel? Ahh questions…
Tomislav Nakic-Alfirevic
Thanks for the detailed and precise answer. I’ll take a look at /var/log/syslog, but if I’m unable to prevent the freezing, I’ll simply go out and (as ugly and old-school as it may be) buy a UTP cable and be done with it. I’m used to seeing my machines run for months without problems (I use suspend/resume: they’re not always on): anything less than that is a problem.
32bit + PAE seemed a safer choice and a better fit for what I needed than 64-bit, so I guess I can’t use your ath5k.ko. :\
Again, thanks for the help!
sole
No I’m afraid my ath5k.ko is not only 64bit but for an older version of the kernel!
You know you can boot using an older version of the kernel, do you? at boot time. Selecting it with GRUB. Just to make sure it’s just the kernel which fails 8-)
Tomislav Nakic-Alfirevic
I’m on a UTP cable (sooo 20th century!) now and will see how the machine behaves: I expect it to be completely stable and to confirm that the network card was the only source of instability.