change isAnyWirelessPoweredOn() accordingly to the removal of the old status kernel interface

[Nicolò Chieffo]

Binary package hint: acpi-support

affected file: /usr/share/acpi-support/state-funcs
affected function: isAnyWirelessPoweredOn()

the kernel interface /sys/class/net/*/device/power/state has been removed in linux-2.6.24, the version in hardy. Te current script fails because of this, and should be changed, accordingly to this problem.

[Nicolò Chieffo (yelo3)]

a solution to the problem

[Nicolò Chieffo (yelo3)]

adding a more performant solution to the problem

[Steve Langasek (vorlon)]

This patch looks wrong to me. The original behavior would only treat a wireless interface as enabled if the file existed under /sys and had a value of 0. The new behavior is to treat a wireless interface as enabled *unless* the file exists and does *not* have a value of 0. This results in different handling of the case where $DEVICE/wireless exists as a directory, and neither $DEVICE/device/power/state nor $DEVICE/device/rf_kill exists. Do you have a reason to believe that this behavior needs to be changed? If not, I would recommend restoring the previous default of assuming a device is disabled.

(BTW, the comments in the patch are wrong -- 0 means enabled in each case here, and 1 means disabled.)

[Nicolò Chieffo (yelo3)]

I made a mess with the comments, I'm sorry, I'm attaching the correct patch now.

Instead I think that the correct behavior is the one I attached, even if it is different from the one before.
Why would you assume a device off by default? Devices are always on by default, then they can be off only if someone changes their status.

BTW, do you know other methods to check if a device is on? for instance, how can we check for broadcom devices? and for laptops which have a hardware hotkey, such as HP and DELL?

[Steve Langasek (vorlon)]

The reason for assuming a device is off by default is that this function's purpose is to check whether there are wireless devices powered on *that can be turned off*. If the device can't be powered off because there's no interface for doing so, then reporting it as being "on" gives the wrong results and will prevent acpi-support from ever powering any /other/ wireless devices in the system back on.

This is a corner case; nevertheless it's one that the previous code handles correctly and the new code does not.

The code should also probably not try to check the status of hardware kill switches, since attempting to honor them would also break the "toggle" functionality here in acpi-support - after all, you can't toggle a hardware kill switch from software. :)

[Nicolò Chieffo (yelo3)]

But on the other hand if devices are thought off by default, in some
corner cases the LEDs are switched down.
I really think that this infrastructure should be re-implemented in a
smarter way, through HAL... In this way we have a common hook to check

[Nicolò Chieffo (yelo3)]

This bug has to be fixed, since it prevents some asus laptops to have wireless working, since it always returns failure, and for asus laptops a script that disables the led is always called with failure, so the led is always off. In some particular models this also means to switch off the wireless device

[Steve Langasek (vorlon)]

On Tue, Mar 04, 2008 at 09:39:18AM -0000, Nicolò Chieffo wrote:
> But on the other hand if devices are thought off by default, in some
> corner cases the LEDs are switched down.

I don't understand what you mean. Do you mean that the LED is shown as a
separate device under the /sys/class/net tree on these asus laptops?

I agree that the bug needs fixed - it affects other laptops besides asus,
including mine - but I don't agree with treating devices as "on" when they
don't have a control interface. That could be a regression on some systems,
so that's not a change I'm willing to make at this point in the release
cycle since we can't really test all the possible cases.

So I'm uploading a fix for this which retains the existing default handling
of network devices with no power interface. If you still have problems with
this version, please help me understand what that problem is; I'm happy to
help fix any remaining problems, I just don't believe that changing the
semantics of isAnyWirelessPoweredOn() is the right way to fix them.

[Launchpad Janitor (janitor)]

This bug was fixed in the package acpi-support - 0.108

---------------
acpi-support (0.108) hardy; urgency=low

  [ Daniel Hahler ]
  * /etc/modprobe.d/toshiba_acpi.modprobe, debian/rules, README.toshiba:
    Fix regression for toshiba, which should not have been removed
    (LP: #199888)
  * events/lenovo-eject, debian/preinst:
    Drop events/lenovo-eject again: it's a dock eject button and not a CD
    eject button (LP: #194609)

  [ Steve Langasek ]
  * lib/state-funcs: update isAnyWirelessPoweredOn() to recognize
    devices exporting only the new rf_kill status interface.
    LP: #180598.

 -- Steve Langasek <email address hidden> Fri, 21 Mar 2008 16:51:13 -0700

[Nicolò Chieffo (yelo3)]

What I meant was that for asus laptops, we have a led device in
/sys/devices/platform/asus-laptop/wlan that in some cases also switch
on/off the device. Since the asus wireless hook updates that file with
the value returned by isAnyWirelessPoweredOn, it always switched the
led off, and in up-mentioned cases also the device.

I will see what happens in my laptop which has a broadcom device, that
does not have any control interface.

Thank you for the fix, anyway I think that drivers must have a common
power interface. I hope this is not an utopia.
Bye!

[Linus Harling (linus-ussarna)]

Steve: Thank you for the fix, it helps kind of; please have a look at bug https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/204378 , it probably explains more about the problem with asus.

Nicolò: /sys/devices/platform/asus-laptop/wlan /is/ the controller for the wlan card, although it controls the LED too (at least on the U1F) which is why the LED stays on even when the WLAN is off. (asus-wireless.sh sets them both).

[Nicolò Chieffo (yelo3)]

Steve, I've had a look at the patch, ok it works in most cases, but it has a problem (especially if some new methods to check the wifi status are added):
it is not enought that _one_ method reports the card on, since there could be another that reports it off.
to report a device on _every_ methods must say "on"

(This is another motivation to think that the device is on by default.)

[Steve Langasek (vorlon)]

On Sat, Mar 22, 2008 at 12:43:04PM -0000, Nicolò Chieffo wrote:
> Steve, I've had a look at the patch, ok it works in most cases, but it has
> a problem (especially if some new methods to check the wifi status are
> added): it is not enought that _one_ method reports the card on, since
> there could be another that reports it off. to report a device on _every_
> methods must say "on"

Yes, one of the assumptions I've made in this patch is that, if multiple
interfaces are exposed by the driver for this information, each of these
interfaces is equally valid. If a driver exposes both rf_kill and
power/state, and they disagree, then this is a bug in the kernel driver.

Since I'm not aware of any kernel drivers with this bug, I currently don't
think it's worth the additional effort to guard against this possibility.
(Even in the ASUS case, it appears that the only other interface which
*might* provide conflicting information is one not currently supported by
isAnyWirelessPoweredOn().)

[Nicolò Chieffo (yelo3)]

This is not right. power/state is a hook to check if the device is
powered, not if it has a kill. so it is possible that rf_kill is 1 and
power/state is 0. anyway now there is no risk because power/state does
not exist anymore.

But this is a design problem, and we will occur on it when adding new
kill-check methods

[Jui-Hao Chiang (windtracekimo)]

Dear all:
First, I must say if my problem suites these discussion or not.
I am using Fujitsu S7110 laptop with intel 3945abg wifi card in it.
It works fine on 7.10 while I switch the hardware button to "on" after logging into X.
But after upgrading to 8.04 LTS, it comes out some problems.
After turning on the hardware switch, dmesg will sometimes say
 iwl3945: Radio Frequency Kill Switch is On:
 Kill switch must be turned off for wireless networking to work.
if I manually do "modprobe -r iwl3945; modprobe iwl3945" or "ifconfig eth1 up", then the network works.
Maybe it is not a big bug, but I just want to figure out why.
I have been searching for a lot of days for solutions (my lspci has successfully recognize the device, and the module of iwl3945, iwlwifi... are all update to date. I also have installed linux-backport-modules)

My current version of acpi-support is 0.109, while the above patch is for older version.
Is this a remaining bug of state-funcs or the driver problems (my iwl3945.ko shows a version of 1.2.25)??

Many thanks to all.