Good Day All,
There are numerous results when searching google on this issue, however, none seem to have a solution.
I have read until my eyes bleed and banged my head on the table more than once!
I am hoping to resolve this issue -- or at least have a decent workaround.
It is a real pain not to be able to put my laptop in standby knowing that if I do, I will have to reboot to regain my wireless connectivity.
I have copied snippets from **lshw** which first shows what type of system we are dealing with and then the state that the
wireless adapter is left in after going into sleep mode.
Unloading and reloading the drivers, obviously, has no effect. The card stays disabled.
My question:
Is there a way (via scripting or creating a small piece of executable code) to access the hardware, turn the wireless adapter back on,
and reload the drivers to regain connectivity without rebooting?
I am using Fedora 21 with the most recent kernel updates...
I can provide whatever other information that might be needed for this project very expeditiously.
Many people will be benefited by a workaround for this issue.
Code snippets...
root@redbrick /home/redbrick: uname -a
Linux redbrick 3.19.5-200.fc21.x86_64 #1 SMP Mon Apr 20 19:51:56 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Previously, I had only unsed modprobe for removing and reloading the drivers.
I will try rmmod to see if that uses a different (maybe more thorough) method.
Using modprobe didn't work because the card itself somehow became "disabled" in the suspend process.
I started to wonder if there wasn't something like an internal "wake up" signal that I could send to the adapter, from a terminal,
that would allow the driver reload to be effective.
That is what prompted my post.
This has been on the RedHat bug list for a long time.
I am hoping to find some kind of a workaround until they get it fixed.
It appears that it is not the driver stack that is causing the card to become disabled...
Maybe it the ACPI??
I did notice that the system log shows a notice that the generic ACPI should be replaced by a proprietary driver if available...
May 25 15:29:10 redbrick kernel: ACPI Warning: SystemIO range 0x0000000000006040-0x000000000000605f conflicts with OpRegion 0x0000000000006040-0x000000000000604f (\_SB_.PCI0.SBUS.SMBI) (20141107/utaddress-258)
May 25 15:29:10 redbrick kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
I do believe that I saw something while going through the journal errors about the bios... I need to go back and look at it again.
Thank you very much for the reply!
---------- Post updated at 12:09 PM ---------- Previous update was at 09:12 AM ----------
After a reboot I could get the the wifi interface to go up and down and it was able to reconnect as required in spite of the following errors...
So, it definitely looks like a standby process specifically turning off the wifi card and the resume process either cant or doesn't turn it back on...
---------- Post updated at 12:21 PM ---------- Previous update was at 12:09 PM ----------
BTW I did try to change the parameters on the modules and switch the power control to software controlled on; but I could not get the hardware control to turn off...
I now have a file in /etc/modprobe.d that contains those entries so that they are effective every boot.
root@redbrick /home/redbrick: modprobe rtl8188ee ips=0 swlps=1 hwlps=0
root@redbrick /home/redbrick: modinfo rtl8188ee | grep parm
parm: swenc:Set to 1 for software crypto (default 0)
parm: ips:Set to 0 to not use link power save (default 1)
parm: swlps:Set to 1 to use SW control power save (default 0)
parm: fwlps:Set to 1 to use FW control power save (default 1)
parm: msi:Set to 1 to use MSI interrupts mode (default 1)
parm: debug:Set debug level (0-5) (default 0) (int)
parm: disable_watchdog:Set to 1 to disable the watchdog (default 0)
I think I will try setting debug to 5 and the MSI parameter to 0 and trying again....
It may not be possible to fix a buggy driver by fiddling with a buggy driver. The problem may be the driver itself. A kernel upgrade might help or might not, but would be rather drastic.
It's quite possible the problem is specific to your model of laptop, as well. Manufacturers have a choice of how they attach the wiring to the wireless adaptor, and put whatever workarounds they need into the Windows driver, and Linux has to find out the difference the hard way. (This is why laptop hardware so often has its own particular drivers instead of using the manufacturer's generic ones.) Search for discussions on your exact laptop model.
lol yep. I think you are right!
Well, it looks like my options are to:
Wait it out -- maybe they will get this eventually straightened out,
Replace the wifi card in the laptop to a known good one
Get a different laptop
Live with it
I couldn't change some of the parameters using modprobe -- they wouldn't take.
---------- Post updated at 12:51 PM ---------- Previous update was at 12:47 PM ----------
@Corona688
Thanks for your help. I like working things out and having someone there to bounce ideas off of as I work toward a resolution.
By the way, I did get my disaster recovery script almost finished -- turns out I do not have to create all of the partitions from scratch using sgdisk...
Replacing the wifi card in your laptop probably isn't an option. Most laptops are programmed to freak out and refuse to boot if you do so, due to FCC regulations. Weird workarounds like disconnecting the detect pin until it boots have been done, but won't work with modern PCIE cards as far as I know.
Using a USB or other kind of external card is okay of course.
Yeah, after some research I'm finding out that there is a whitelist in the BIOS that only allows certain types of cards to be plugged in. typically this involves buying one of their way more expensive cards to replace it.
