My laptop is basically an Acer Aspire rebranded to be a Gateway Something (T100, I think? The marketing people REALLY did not give a shit). For all intents and purposes, though, it's an Aspire. And it has a slight problem where the wifi gives out after extended periods of the machine running.
Now, this isn't easy to test, because it takes forever to manifest. My current uptime is about 50 days (rounding up from a very top-heavy 49), and I'm only running into it now. I think it might involve some variable in the driver overflowing after a certain amount of bandwidth passes through it. Even so, it has a habit of dying when I actually need it and don't want to close everything and restart. So I'm trying to solve it more permanently now, while it's convenient.
Hardware light on the right turns off. nm-applet keeps trying to access the network it was just on, prompting for the password. This does not succeed. wlan0 is still listed in ifconfig. Restarting /etc/init.d/networking has no effect.
So far, I've tried unloading and reloading the Atheros wireless kernel modules - ath9k, ath5k, and ath. I know from previous battles that these are in fact the correct drivers - in fact I've actually salvaged the situation before, which is why I know it can be done, but so far it's been dumb luck every time I've succeeded. I'm hoping to document it publicly this time around, for my own sake and for lurkers like myself.
The results of this are that I can't get wlan0 to show up in ifconfig or iwconfig anymore. Nor does "ifup wlan0" work. Reloading the KMs results in output like this in dmesg (timecodes omitted, as I'm having to retype the information manually):
ath9k 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
ath9k 0000:02:00.0: setting latency timer to 64
ath9k 0000:02:00.0: failed to initialize device
ath9k 0000:02:00.0: PC INT A disabled
ath9k: probe of 0000:02:00.0 failed with error -5
From my vague recollections of past battles, I'm fairly convinced that this whole thing traces back to power management gone awry. Also, there was a message via the kernel about disabling IRQ 17 which showed up on the terminal earlier, "Disabling IRQ #17", the same time the mess started. Another thing I see, that the uhci_hcd module is also getting its hands on IRQ 17 for some reason or another, and may be the cause of interference, although it's also messing with with the other IRQs 16-19