ipw2200 doesn't retain sleep status after sleep/hibernate/reboot

[Nicolò Chieffo]

at every boot, or when I'm resuming from hibernate (and I think also sleep, but wireless is not working after a sleep) my ipw2200 card state is set to on, even if I had disabled it in the previous boot. I think a state has to be added somewhere, to avoid having to disable it manually every time!

[Vincent Untz (vuntz)]

IMHO, it should also try to reuse the same wireless settings (AP, key, etc.)

[Paul Sladen (sladen)]

Currently we put all the network devices into power-saving mode on sleep and then bring them all back out again from suspend afterwards.

This has the effect of forcibly waking up any network devices that were asleep.

In related news... After an unsuspend, the ThinkPad bluetooth module is always off...

[Nicolò Chieffo (yelo3)]

a quite simple solution is to store a file in /var/run/ipw2200 with the current status value {ON|OFF} or {0|1}.
then with a simple script executed after loading ipw2200 module (using /etc/modprobe.d/ipw2200) it should be easy to restore the status for ipw2200 interface!
the only difficolut thing is locating which interface belongs to ipw2200.. I tried to query sysfs but I couldn't find it in the ipw2200 module directory.

[Nicolò Chieffo (yelo3)]

of course in the status file everything Vincent proposed (AP,...) can be added easily too!

[Nicolò Chieffo (yelo3)]

duplicate removed. When I reported the bug I was not talking about interface status, but wireless card status! (radio status!)

[Nicolò Chieffo (yelo3)]

Radio status means the one in /sys/class/net/eth1/device/power/state or the software pci kill in /sys/class/net/eth1/device/rf_kill

[Nicolò Chieffo (yelo3)]

I've written a script which can preserve card sleep status. see bug

https://launchpad.net/malone/43061 and tell me what do you think of it

[Nicolò Chieffo (yelo3)]

Hello. Now that we have network manager, should it possible to use it to store the preferences to enable or disable wireless, so that at every boot we (who don't use wireless) don't have to hit the hotkey?

[Nicolò Chieffo (yelo3)]

How are you going to implement that?

[Paul Sladen (sladen)]

acpi-support (0.94) feisty; urgency=low

  * Save and restore values that the kernel does not preserve across
    suspend/resume and hibernate/resume:
    - /sys/class/net/eth*/device/rf_kill
    (Closes: LP #37010)
    - /proc/acpi/ibm/bluetooth
    (Closes: LP #37175)
    - /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    (Closes: LP #68191)
  * White list Lenovo ThinkPad Z60m as working suspend.
    (Closes: LP #57144)

 -- Paul Sladen <email address hidden> Thu, 22 Mar 2007 03:57:36 +0000

[Nicolò Chieffo (yelo3)]

Is the fix present for reboot also? or only for suspend and hibernate?

[Nicolò Chieffo (yelo3)]

I have reopened it because it does not support yet reboot. But I think that it is simple to do!
1) copy /etc/acpi/resume.d/58-proc-sysfs-restore-state.sh to /etc/acpi/start.d/
2) copy /etc/acpi/suspend.d/30-proc-sysfs-save-state.sh to /etc/acpi/stop.d
3) patch /etc/init.d/acpi-support to execute scripts in /etc/acpi/stop.d during the stop action

[Paul Sladen (sladen)]

Saving this state over a cold-boot is probably the responsibility of a higher-level process (eg. Network Manager, ifupdown).

I think about the only thing that the init-scripts save over a reboot is the ALSA (sound mixer/volume) state:

  /etc/rc.d/K50alsa-utils

I'd prefer to keep this bug to one-issue-one-bug (and have the satisfaction of having closed it!).

If it's still an issue, please could you open a new bug-report, though we probably need to pass it onto a separate package.

One large advantage of always using the defaults on a cold boot is that if the user/machine have managed to get things into a "strange state", then a reboot will fix things "back to normal".

If we save the wireless as being off, then on every boot we will continue to get the wireless being off. If the user then moves their laptop hard-drive to a new machine without a wifi-toggle key combination (eg. Fn-F5), then it's going to be awfully hard for them to work out what is going on, or turn the wireless back on.

Across a suspend/resume or hibernate/resume it's obvious that the we should return things to the identical state the user left them in---if the user had not wanted that, they would have done a shutdown.

[Nicolò Chieffo (yelo3)]

You're definitely right, let's close this bug.

[Peter Meiser (meiser79)]

Hi,

if someone used /etc/iftab to rename the WLAN device to e.g. wlan0, the state wouldn't be saved.

I think, "/sys/class/net/eth*/device/rf_kill" should be changed to "/sys/class/net/*/device/rf_kill".