[Intrepid] Radio killswitch off-event isn't recognized on Thinkpad T61p

[Gert van Dijk]

On my laptop, a Lenovo T61p I have two radio killswitches. One at the front, to be considered as a hardware switch and a soft-key (Fn+F5). The one at the front will disable all radio devices (BT, WLAN and WWAN if available) and the soft-key will toggle between the different modes (BT+WLAN, only BT, only WLAN, all off). At least, this was how it was in Hardy.

Now in Intrepid the situation is as follows.
The hardware radio killswitch at the front will correctly disable all wireless devices present. When turning it back off (wireless enabled) only Bluetooth comes up. The event isn't even recognized. (see below)

From syslog (when turning killswitch on)
Oct 25 23:59:18 gert-laptop kernel: [ 4955.195594] iwl3945: Radio Frequency Kill Switch is On:
Oct 25 23:59:18 gert-laptop kernel: [ 4955.195599] Kill switch must be turned off for wireless networking to work.

From syslog (when turning killswitch off)
Oct 25 23:59:29 gert-laptop kernel: [ 4966.480126] usb 1-1: new full speed USB device using uhci_hcd and address 4
Oct 25 23:59:29 gert-laptop kernel: [ 4966.647428] usb 1-1: configuration #1 chosen from 1 choice
Oct 25 23:59:29 gert-laptop bluetoothd[6232]: HCI dev 0 registered
Oct 25 23:59:29 gert-laptop bluetoothd[6232]: HCI dev 0 up

Clearly, I miss a line like 'iwl3945: Radio Frequency Kill Switch is Off'. I need to do a modprobe -r iwl3945 && modprobe iwl3945 to make wireless work again.

Now, for the software killswitch: it doesn't even control the WLAN module, only toggling the bluetooth state. This is inconsistent with behaviour in Windows, Hardy and the Owner's Manual. It should toggle between the states as described earlier.

The model of the laptop is T61p 6457, a 15.4" WUXGA display with NVidia Quadro FX 570M and Intel PRO/Wireless 3945 WLAN.

[Gert van Dijk (gertvdijk)]

Apparantly this has been solved in hal 0.5.11-4ubuntu4, also for Thinkpads.

[Mario Limonciello (superm1)]

You sure it was? The fix for Dell's was *very* Dell specific.

On Mon, Oct 27, 2008 at 20:36, Gert van Dijk <email address hidden> wrote:

> *** This bug is a duplicate of bug 288294 ***
> https://bugs.launchpad.net/bugs/288294
>
> Apparantly this has been solved in hal 0.5.11-4ubuntu4, also for
> Thinkpads.
>
> ** Changed in: ubuntu
> Status: New => Fix Released
>
> ** This bug has been marked a duplicate of bug 288294
> Dell HAL Bluetooth kill switch doesn't operate properly on several
> platforms
>
> --
> [Intrepid] Radio killswitch off-event isn't recognized on Thinkpad T61p
> https://bugs.launchpad.net/bugs/289286
> You received this bug notification because you are a direct subscriber
> of the bug (via bug 288294).
>

--
Mario Limonciello
<email address hidden>

[Gert van Dijk (gertvdijk)]

You're right Mario. Here's the story:
I noticed the bug since the beta release and I couldn't think of where I had to look for resolving this issue, since there are many changes in HAL and the kernel since Hardy. Now, when I got the "hal 0.5.11-4ubuntu4" update yesterday I thought "gosh, only for Dells, why not mine!?", but I decided to reboot anyway and was pleasantly surprised with working radio killswitches!
Now, after a suspend (to RAM) and resume it's not working anymore. So it might be Suspend to RAM related. In a few hours I'll have the time to do some more tests.

This bug will give a very weird user experience when you're not be able to bring wireless up again after killing it (what works).

[Gert van Dijk (gertvdijk)]

I did some more extensive tests and here are the results:

Intrepid (updated) - after fresh reboot: soft-killswitch works flawlessly, hard-killswitch can only bring WLAN down, not up. After hard-killswitch-off the soft-killswitch wil only control Bluetooth.
Intrepid (updated) - after suspend-to-RAM: same as after reboot. So it is *not* a STR issue.
Intrepid (RC Live CD): same as updated. So it is also *not* an issue with the Dell patch.
Hardy (8.04.1 Live CD): Works as it should do. Soft-killswitch will toggle between four states, hard-killswitch will disable all and is able to get both WLAN and BT back up.

Workaround for now is to not use the hard-killswitch, but that isn't an option in environments where Radio signals are not allowed (airplanes, etc), because after a resume of Suspend to RAM WLAN and BT are both up again, no matter what state it was in when suspending.

I can provide more information, just tell me what to post.

Could someone change the status of this bug ('cause it's greyed out now) and *unmark* it as a duplicate of the Dell bug? I was wrong in my earlier statements and I wasn't aware of not being able to change this later. Sorry for that and thanks in advance.

[Gert van Dijk (gertvdijk)]

I think it might be a duplicate of bug #193970, of which is a known issue in the release notes of Intrepid.
Weird thing is that I haven't had any problems with it in Hardy.

[Alecz20 (alexguzu)]

Same bug affects my laptop, which has intel 3945 wireless card. The hard killswitch can only turn the wireless off, not on.

One workaround that works for me is to reload the driver with the killswitch off (light comes on):

sudo rmmod iwl3945
sudo modprobe iwl3945

[Tom Vetterlein (smbm)]

This seems to still be an issue on my Jaunty (upgraded from Intrepid) setup.

I'm on a Lenovo R61 with Intel 3945 wireless adapter.

Anyone got any clues?

[Daniel J Blueman (danielblueman)]

I've been experiencing this issue on a Thinkpad T400 (BIOS 2.07) running x86-64 Jaunty 9.04 beta with 5300AGN/iwlagn card.

Since network manager monitors the interface list, removing and inserting the iwlagn module gets the interface active, however, restarting the networkmanager service also does the trick.

It seems the notification of the RF kill switch state change isn't wired up, or networkmanager isn't listening to the right /sys entries etc.

[Adrian Wilkins (adrian-wilkins)]

I'm seeing this on an HP/Compaq 6910p running Jaunty

When you boot in the radio-off state, using the radio-on toggle lights the light and successfully activates bluetooth, but NetworkManager doesn't try to negotiate a connection.

It does recognise that wireless is now available though, because the checkbox for "Enable Wireless" shows up (absent before the radio is switched on). If you uncheck the box, then check it again, NetworkManager now negotiates a wireless connection.

Subsequent toggles of the radio button during that session produce the intended result - bluetooth and wifi are disabled, and when reenabled, the wifi connection last lost is reestablished.

[dino99 (9d9)]

http://www.freedesktop.org/wiki/Software/hal/