I recently discussed this with Larry Finger and Chaomin Li, but every
once in a while, after having resumed from suspending to RAM, my NIC
(10ec:8172) doesn't work anymore, even after reloading the module. Even
worse, after reloading the module, my NIC's name gets changed (because
of udev rules) as a result of the MAC address changing, which means I
have to temporarily reconfigure whatever I'm using to make a connection
(wicd in my case).
Now, as a byproduct of the other discussion I had (RTL8192SE and 802.11n
problems), I've patched the driver to dump the EFUSE when appropriate
hardware is detected, and this time, I got the following:
rtl8192se 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
rtl8192se 0000:06:00.0: setting latency timer to 64
rtl8192se: In process "modprobe" (pid 17913):MAP
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
rtl8192se: Driver for Realtek RTL8192SE/RTL8191SE
Loading firmware rtlwifi/rtl8192sefw.bin
ieee80211 phy1: Selected rate control algorithm 'rtl_rc'
udevd[17907]: renamed network interface wlan0 to wlan26
As you can see, the EFUSE is completely messed up. To fix this problem,
I have to reboot my laptop. I'm not quite sure what could be causing
this, and I was hoping someone here might.
Greetings,
Stefan Zwanenburg
On Tue, Oct 04, 2011 at 02:27:55PM +0200, Stefan Zwanenburg wrote:
> I recently discussed this with Larry Finger and Chaomin Li, but every
> once in a while, after having resumed from suspending to RAM, my NIC
> (10ec:8172) doesn't work anymore, even after reloading the module. Even
> worse, after reloading the module, my NIC's name gets changed (because
> of udev rules) as a result of the MAC address changing, which means I
> have to temporarily reconfigure whatever I'm using to make a connection
> (wicd in my case).
You might try configure pm-utils to unload module before suspend, by
something like this:
echo 'SUSPEND_MODULES="rtl8192se rtlwifi"' >> /etc/pm/config.d/modules.conf
Other than that, would be good to try if converting to new PM framework
helps. It can be done quite simply, similar way like in this ath9k commit:
commit f0e94b479c987abef17eb18e5c8e0ed178d00cd4
Author: Rafael J. Wysocki <[email protected]>
Date: Sat Oct 16 00:36:17 2010 +0200
ath9k: Convert to new PCI PM framework
Stanislaw
On 10/04/2011 08:57 AM, Stanislaw Gruszka wrote:
> On Tue, Oct 04, 2011 at 02:27:55PM +0200, Stefan Zwanenburg wrote:
>> I recently discussed this with Larry Finger and Chaomin Li, but every
>> once in a while, after having resumed from suspending to RAM, my NIC
>> (10ec:8172) doesn't work anymore, even after reloading the module. Even
>> worse, after reloading the module, my NIC's name gets changed (because
>> of udev rules) as a result of the MAC address changing, which means I
>> have to temporarily reconfigure whatever I'm using to make a connection
>> (wicd in my case).
>
> You might try configure pm-utils to unload module before suspend, by
> something like this:
>
> echo 'SUSPEND_MODULES="rtl8192se rtlwifi"'>> /etc/pm/config.d/modules.conf
>
> Other than that, would be good to try if converting to new PM framework
> helps. It can be done quite simply, similar way like in this ath9k commit:
>
> commit f0e94b479c987abef17eb18e5c8e0ed178d00cd4
> Author: Rafael J. Wysocki<[email protected]>
> Date: Sat Oct 16 00:36:17 2010 +0200
>
> ath9k: Convert to new PCI PM framework
Stefan,
Following Stanislaw's suggestion, I have reworked the PM routines to use the new
framework. Attached is a patch. My system does not sleep and I cannot test it,
but it does hibernate. Let me know what happens.
Larry