os373pyg/XO-1. Wifi is always ON. Kernel misses the RFKILL

[mavrothal]

Clean os373pyg on XO-1 (G1G1).
WiFi stays powered-up regardless of the Power CP settings in both Sugar and Gnome, and BTW the extreme power management check box, although clickable does not stick.
I do not know if this is the expected/desired behavior, but should be some way for full suspend.
The attached Power-logs, have messages and powerd.trace (with tracing turned on) from 4 settings of the Power control panel. default, PmanagON (power management box checked and reboot), PextrON (power management and extreme boxes checked and reboot) and Gdefault (default settings in Gnome). In all cases after reboot the XO was left to go through a cycle of inactivity and wakeup by user input followed by a cycle of power button suspend and wakeup.

[mavrothal]

Looks like the server does not allow me to attach the (.tar.gz) logs (?)
Mailed to Bernie instead.

[bernie]

Replying to mavrothal:

Looks like the server does not allow me to attach the (.tar.gz) logs (?)
Mailed to Bernie instead.

Worked for me, but I'm a trac admin.

[pgf]

please try the command "sudo rfkill block wifi" in place of clicking the "extreme" power management box. (use "sudo rfkill unblock wifi" to undo.) the OLPC version of sugar 0.84 does the rfkill in response to the Network control panel's "Radio" checkbox. the "Extreme" checkbox is gone in that version.

[mavrothal]

Replying to pgf:

please try the command "sudo rfkill block wifi" in place of clicking the "extreme" power management box. (use "sudo rfkill unblock wifi" to undo.) the OLPC version of sugar 0.84 does the rfkill in response to the Network control panel's "Radio" checkbox. the "Extreme" checkbox is gone in that version.

I guess this explains the behaviour in Sugar and has to do with the Control panel coding. However, in Gnome we have the same behaviour. Eg the XO-1 goes through suspend and the wifi stays on.
BTW the original logs were missing somehow the power.trace log from the Gdefaul folder. The new gnome.logs.tar.gz attachment is from the same test. eg one cycle of inactivity and wakeup by user input followed by one power button cycle

[mavrothal]

Replying to pgf:

please try the command "sudo rfkill block wifi"

Hm... In GNOME:

[olpc@xo-11-ea-51 ~]$ sudo rfkill block wifi
Can't open RFKILL control device: No such file or directory

The kernel does have RFKILL=y but something else must be missing

[pgf]

Replying to mavrothal:

I guess this explains the behaviour in Sugar and has to do with the Control panel coding. However, in Gnome we have the same behaviour. Eg the XO-1 goes through suspend and the wifi stays on.

i don't understand what you mean. wifi operation as regards suspend/resume isn't dependent on what window manager is running.

independent of that observation, gnome has no applet to directly control rfkill, that i know of, so one must use the commandline.

[mavrothal]

Replying to pgf:

i don't understand what you mean. wifi operation as regards suspend/resume isn't dependent on what window manager is running.

OK, excuse my ignorance, assumptions and misconceptions, I thought that the control panel is part of Sugar and when in Gnome Sugar is not running, network "should be killed" by something independent of the radio or power management Sugar control panel and the related infrastructure.
I also thought that the RFKILL module was present in os373pyg
But all this this is "philosophical"...

The bottom line is that the os373pyg kernel is actually MISSING the rfkill module

[olpc@xo-11-ea-51 ~]$ cat /boot/config-2.6.31_xo1-20100701.1605.1.olpc.a8f1b26 | grep RFKILL
# CONFIG_RFKILL is not set
CONFIG_RT2X00_LIB_RFKILL=y
#

Edited the title of the bug accordingly

[bernie]

Replying to mavrothal:

The bottom line is that the os373pyg kernel is actually MISSING the rfkill module

I don't have an XO-1 handy now, but this is the kernel used in os373py for the XO-1:

kernel-2.6.31_xo1-20100701.1605.1.olpc.a8f1b26.i586

From the git logs I can see that RFKILL was enabled in a commit dated 20100709, just a few days later.

This bug should be fixed by a more recent Dextrose snapshot:

​http://download.sugarlabs.org/dextrose/testing/dxo2/xo1/intl/

Please reopen if it's not really fixed.