iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch

I confirm this bug as occuring on my machine, also using iwl3945. It also occurs when resuming from suspend, and a full reboot is still required to fix. I have not tested resume from disk. I will attach the system details in a moment.

$ uname -a
Linux gertrude 2.6.24-11-generic #1 SMP Fri Feb 29 22:08:31 UTC 2008 i686 GNU/Linux

In this log, all events after [ 30.333148] are where I turned the wireless switch to 'on', which did not give me a usable wireless interface, but which does seem to have caused something to happen.

Mary, could you try the network-manager 0.7, which is in the PPA of Alexander Sack?

deb http://ppa.launchpad.net/asac/ubuntu hardy main

Either it's because of this version of network-manager or because of the latest kernel update, but today switching on wireless worked without the need of an reboot.

I don't know what you mean by latest kernel update, probably best to specify versions for clarity. I have linux-image-2.6.24-11-generic package 2.6.24-11.17, which seems to be the latest and which still has this bug. I will test the new network manager now.

Christian I tried network-manager 0.7 and it doesn't work. It gave me this error:

wax@doralice:~$ nm-applet
nm-applet: symbol lookup error: nm-applet: undefined symbol: dbus_method_dispatcher_new

And it wont start.

> Mary, could you try the network-manager 0.7, which is in the PPA of Alexander Sack?
>
> deb http://ppa.launchpad.net/asac/ubuntu hardy main

Neither the latest kernel version (supplied in the last comment) nor using this version of network-manager 0.7~~svn20080121t191418+eni1-0ubuntu0~pre7 (and associated upgrades to wpasupplicant 0.6.1~git20071119-1ubuntu1~asac1 plus several libraries) made wireless work for me if it was turned off at boot. It still does not work until I do a second boot with wireless switched on.

If people want me to do more testing, please let me know whether I should test against the PPA network-manager or the Hardy version. I can only test about once every 24 hours, as tests involve rebooting my machine at least twice.

I did some further testing to find out why it worked for me yesterday.

I could find out that wireless will work if you just restart hal (sudo /etc/init.d/hal restart) after you've disabled the kill switch. You can enable/disable the kill switch then without restarting hal every time. I didn't check if it would be enough to restart hal right after booting (without disabling the kill switch first), but I will try this later.

If a restart of hal solves this problem, then I think hal is started to early - or hal is missing some initialisation for the wireless network. I will assign hal to this bug to clarify this issue.

I have to mention that I'm using the hal package provided by Martin Pitts PPA

   deb http://ppa.launchpad.net/pitti/ubuntu hardy main

because of this fix:

  * Add debian/patches/05_fix_dell_brightness.patch: Fix Dell brightness
    backend. (LP: #191725)

Don't know if this hal makes any difference.

Current version of hal:
0.5.10+git20080301-1ubuntu1

Current behaviour:
 - if starting system with killswitch on, no wireless networks are found until after /etc/init.d/hal restart

 - if I turn the killswitch off and immediately (say 2 to 4 seconds at most) turn it back on, everything is fine. "iwlist scan" shows no interfaces during the off period, but sees them again when switched back on

 - if I turn the killswitch off and wait until Network Manager notices that there's no network available (about 20 or 30 seconds), Network Manager stupidly tries to re-associate with the access point, eventually asks for its WPA key and continues showing wireless networks available in its drop-down list. This may be a separate bug in NM, I'll recheck that behaviour when this one is fixed. "iwlist scan" does not show any interfaces even when the switch is turned back on. "sudo /etc/init.d/hal restart" does not seem to help after the switch has been off this long either, I have no alternative but to reboot my machine.

 - if I turn the killswitch off, suspend to RAM, resume, "iwlist scan" shows no interfaces. Again, "sudo /etc/init.d/hal restart" does not help

Federico, you reported this problem as well - which wireless card do you have? Mary and I have the Intel Corporation PRO/Wireless 3945ABG (driver=iwl3945). Maybe this problem is related to the driver? It's still unclear to me whether the driver or hal or some other software is causing this problem.

I have a Intel Corporation PRO/Wireless 3945ABG like you :P. I think the problem is in the driver because with ipw3945 (the proprietary driver) I don't have this problem :P

The problem is definitely in the driver. It has to do with the way that initialization happens. It only polls for the device if it's turned on. Needs to be rewritten to allow proper detection. This bug will need to be dealt with upstream rather than in Ubuntu.

same here. `modprobe -r iwl3945 && modprobe iwl3945` is a workaround but sometimes modprobe -r hangs while cpu on 100%

I have both the latest kernel (2.6.24-12-generic) and an older one (2.6.24-5-generic) and also the Gutsy kernel (as I just loaded the Hardy kernel on Gutsy). This problem does not happen on the 2.6.24-5 kernel. That uses the 1.1.17 module. I updated the module on the 2.6.24-12 to 1.2.26k from http://www.linuxwireless.org/en/users/Download as 1.2.0 didn't work for me, and I have this problem with it. It would appear it's something that changed in the kernel. I have the same driver set up for the Gutsy kernel, I will try and see if it happens there too. If it doesn't, then it's not a driver issue. I did notice that when the wifi is turned off, my wavelan panel says the device is there, while if the problem isn't happening (that is, on the other kernel and driver) it says the interface is not available. When I turn the wifi on, the panel will see the wifi interface.

I will report back here with the findings in the Gutsy kernel.

I've done some testing. I rebooted every time with the switch turned on (wifi off, kill switch on). Every time the network was shown disabled. When I did a sudo ifup wlan, the interface came back on. As long as the switch was on, the network was on DISABLED state shown on lshw -C network. When I turned the switch off (wifi on), the status didn't change. As I brought the interface up, the status changed in lshw. This was the case in both the Gutsy kernel, as well in the Hardy kernel. If there haven't been any changes to hal from 2.6.24-5 to 2.6.24-12, then the problem lies with the driver. Module 1.1.17 doesn't have any problem and it also shows my wavelan panel with the proper info. Kill switch on, no such device, switch off, device is seen and starts functioning.

I hope this info helps with solving this bug.

I'm suffering this problem but just with kernel 2.6.24-14-generic. It worked fine until 2.6.24-12 (included).

My laptop is a x61s, with 3945ABG.

Answering to myself in https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/193970/comments/19.

Forget it, it's ridiculous, the hardware wifi switch was off and the driver does the right thing: disables the device.

I have install Linux backport modules to get the LED working on my laptop again. The problem now is the switch to turn the wireless on / off is borked, I can turn the wireless off and the LED turns off too, but the wireless does not turn back on again operating the switch.

Laptop:
Acer Aspire 5601AWLMi

Wireless / Driver:
Intel 3945ABG / iwl3945

uname -a
Linux quails-laptop 2.6.24-15-generic #1 SMP Fri Apr 4 03:48:31 UTC 2008 i686 GNU/Linux

I've tested the iwl3945 from both the linux-backports-modules package and the linux-ubuntu-modules package. I've discovered that turning the kill switch from on (wireless disabled) to off (wireless enabled) does not reactivate the driver when using iwl3945 version 1.2.25 from linux-backports-modules. This does work with iwl3945 driver version 1.2.20 from linux-ubuntu-modules. This happens whether the kill switch is enabled when booting or disabled when booting and then enabled later.

Other users having this bug report can verify the version of the driver they are using via 'modinfo iwl3945' or 'apt-cache policy linux-backports-modules-hardy-generic'.

It is possible to workaround this bug by reloading the driver via 'rmmod iwl3945' and 'modprobe iwl3945'.

I've got the same problem with iwl4965:

kern.log:
Wireless -----> OFF
Apr 21 14:42:52 doris kernel: [ 3333.128890] ACPI: PCI interrupt for device 0000:06:00.0 disabled
Apr 21 14:42:52 doris kernel: [ 3333.151940] ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 17 (level, low) -> IRQ 17
Apr 21 14:42:52 doris kernel: [ 3333.152039] PM: Writing back config space on device 0000:06:00.0 at offset 1 (was 100002, writing 100006)
Apr 21 14:42:52 doris kernel: [ 3333.155181] iwl4965: Radio disabled by HW RF Kill switch
Apr 21 14:42:52 doris kernel: [ 3333.155272] ACPI: PCI interrupt for device 0000:06:00.0 disabled

Wireless -----> ON
Apr 21 14:43:21 doris kernel: [ 3340.707235] usb 5-1: new full speed USB device using uhci_hcd and address 3
Apr 21 14:43:21 doris kernel: [ 3340.753428] usb 5-1: configuration #1 chosen from 1 choice
Apr 21 14:43:21 doris kernel: [ 3340.857370] Bluetooth: HCI USB driver ver 2.9
Apr 21 14:43:21 doris kernel: [ 3340.860066] usbcore: registered new interface driver hci_usb
(stops here)

:~$ sudo rmmod iwl4965; sudo modprobe iwl4965
Apr 21 14:43:57 doris kernel: [ 3349.009748] iwl4965: Intel(R) Wireless WiFi Link 4965AGN driver for Linux, 1.2.25
Apr 21 14:43:57 doris kernel: [ 3349.009753] iwl4965: Copyright(c) 2003-2007 Intel Corporation
Apr 21 14:43:57 doris kernel: [ 3349.009857] ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 17 (level, low) -> IRQ 17
Apr 21 14:43:57 doris kernel: [ 3349.009869] PCI: Setting latency timer of device 0000:06:00.0 to 64
Apr 21 14:43:57 doris kernel: [ 3349.010648] iwl4965: Detected Intel Wireless WiFi Link 4965AGN
Apr 21 14:43:57 doris kernel: [ 3349.050680] wmaster0: Selected rate control algorithm 'iwl-4965-rs'
Apr 21 14:43:57 doris kernel: [ 3349.066323] ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 17 (level, low) -> IRQ 17
Apr 21 14:43:57 doris kernel: [ 3349.206484] iwl4965: Tunable channels: 11 802.11bg, 13 802.11a channels

have a similar problem: my kill-switch is working, i see and can connect to my wireless-network, recieve an ip-address from the dcp server but haven't any connection to any other host... (everything was working with ipw3945) please turn that back on in hardy kernel!!

Same as Dale :
- LED working (no blinking)
- Can turn off once but cannot turn back on (Had to boot on Gutsy liveCd to put it back on!)

Laptop:
Acer Aspire 5601AWLMi

Wireless / Driver:
Intel 3945ABG / iwl3945, version 1.2.25 (package linux-backports-modules-hardy-generic)

uname -a
Linux mathieu-laptop 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

Same here. I once pushed the kill switch and cannot connect via wireless at all anymore, not even after a reboot. I would say that this bug deserves more than medium status, because it keeps on blocking wireless network connection.

output /var/log/messages when I switch the Radio Frequency Kill Switch on (i.e. radio connection and blue lamp go off)
May 1 12:07:25 laptop kernel: [ 431.665939] iwl3945: Radio Frequency Kill Switch is On:
May 1 12:07:25 laptop kernel: [ 431.665945] Kill switch must be turned off for wireless networking to work.
May 1 12:07:25 laptop kernel: [ 431.806569] usb 5-1.1: USB disconnect, address 3

... and off (blue lamp goes on)
May 1 12:07:31 laptop kernel: [ 438.218646] usb 5-1.1: new full speed USB device using ehci_hcd and address 5
May 1 12:07:31 laptop kernel: [ 438.336767] usb 5-1.1: configuration #1 chosen from 1 choice
May 1 12:07:35 laptop kernel: [ 441.618229] ADDRCONF(NETDEV_UP): eth1: link is not ready
May 1 12:07:37 laptop dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason

I noticed that /etc/modprobe.d/ipw3945 still existed after upgrade from gutsy to hardy, while now the driver should be iwl3945 (ipw3945 is obsolete). I renamed the file to /etc/modprobe.d/ipw3945_old and rebooted. After manually selecting the wireless AP, it connected after a minute or so.

So, one of the problems for gutsy->hardy upgraders may be that 2 drivers for 3945 are present. This may be a clue.
BTW, I still get the "dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason" error.

I guess that there must be a more elegant way to get it right, so I will keep an eye on this

*** Platform ***
Xubuntu Hardy
Dell Vostro 1500
Intel PRO/Wireless 3945ABG Network Connection

*** Reproduction ***
I'm not capable of reproducing this bug.

*** Testing I have done ***
1. Booted Xubuntu Hardy with kill switch on (so no wireless)
2. After logging in: kill switch off (so wireless)
3. Succesfully made wireless connection and surfed on the internet
4. During the same session turning the kill switch on (so no wireless)
5. Xubuntu tries to (re-)join wireless network, but failes (it should fail since the kill switch is on ;) )
6. Waited till Xubuntu says "No network connection", turning the kill switch off (so wireless)
7. Succesfully made wireless connection
8. Posting this comment :p

*** All packages that are installed and begin with "linux-" ***
See attached file.
I have no linux-backports-modules-2.6.24 installed.

If anyone requires more info, just ask, I'm subscribed ;)

>*** Platform ***
>Xubuntu Hardy
>Dell Vostro 1500

I believe the 3945 problems with Hardy are related to the network-manager applet in gnome, so it would make sense that things would work in Xubuntu.

@Ben:
Without nm-applet running, I have exactly the same behaviour.
With backport modules, I can disable once, but can't turn back on.

@Ben: I had been running nm-applet 0.6.6 (http://www.gnome.org/projects/NetworkManager/) during the tests. I presume that's the same as the "network-manager applet in gnome"?

Hi,

I have a Thinkpad R60 with the iwl3945 driver running Hardy Heron and when I disable the kill switch I don't get wireless back on, but I can get it back on if i run "ifconfig wlan0 up" manually.

But instead of manually running ifconfig each time, I used acpi events to switch it back on using the howto here:
http://www.thinkwiki.org/wiki/How_to_configure_acpid
I created a new file "/etc/acpi/events/thinkpad-iwl3945" and added the following event:
event=ibm/hotkey HKEY 00000080 00007000
action=/etc/acpi/thinkpad-iwl3945.sh
and the script "/etc/acpi/thinkpad-iwl3945.sh" has the following:
#!/bin/bash
/sbin/ifconfig wlan0 up

and that did it for me, hope that helps :)

I can confirm that it does not reenable device on vanilla 2.6.25 on hardy. All it needs is manual device activation of wlan0 device, just like Aram Yegenian wrote before me. Little problem is that my Sony Vaio reports wifi switch always same hotkey, when switched to off and also to on. But it does not break things for me to try it always, with rf_kill on it does refuse going up.

Sending my script, a bit more complex then ifconfig (not sure it is better). You need to map wifi switch to that event, like in previous post.

@Pihhan: So if I understand correctly: If you install hardy with the 2.6.24 kernel without adding anything (like mine), there is no problem. But if you install hardy with 2.6.25 you do have the problem? So we are speaking of regression from the 2.6.24 to the 2.6.25?

Yes, it seems newer driver does work different way. In 2.6.24-16-generic kernel i have iwl4965 driver 1.2.0, which work it seems same way as in gutsy. On wifi off, nm gets information and remove device. On activation it does not need acpi event to reactivate, and it goes up itself. Ifconfig still report it as UP, even when rf_kill switch is on (value 2 in /sys/class/net/wlan0/device/rf_kill).

In 2.6.25 it does deactivate device on kill switch on, and even disable interrupt for wifi card. Card is down even after wifi is enabled by kill switch, you need to wake it up again. I have iwlwifi driver 1.2.23kds there, i think it is new behaviour of that driver. So yes, that might be propably because of newer kernel.

Maybe important information is, i dont have installed linux-backports-modules-2.6.24-16-generic, so i have original hardy iwlwifi driver.

After reseting BIOS to defaults iwl3945 Wireless can be activated with switch.
I also tried to install linux-backports-modules-2.6.24-17-generic, but after uninstalling them Wireless switch still works without problem, so, I'm not sure if linux-backports-modules-2.6.24-17-generic fixed some things or not :-/

Also I've noticed http://rfswitch.sourceforge.net project (deb packages are available at http://www.mirrorservice.org/sites/sidux.com/sidux/debian/pool/main/r/rfswitch/ and http://www.parsix.org/packages/pool/main/r/rfswitch/ ), according to http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1454 rfswitch should help to turn off kill switch

I'm suffering the same fate :)

Technical Specs

Ubuntu Hardy Heron

Kernel Linux 2.6.24-18-generic

venus@venus:~$ dpkg --list | grep network-manager

ii network-manager 0.6.6-0ubuntu5 network management framework daemon
ii network-manager-gnome 0.6.6-0ubuntu3 network management framework

venus@venus:~$ dpkg --list | grep backport

ii linux-backports-modules-hardy 2.6.24.18.20 Generic Linux backported drivers.
ii linux-backports-modules-hardy-generic 2.6.24.18.20 Backported drivers for generic kernel image

Wifi Card

Intel 3945/a/b/g dmesg output

[ 32.549503] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.25
[ 32.549507] iwl3945: Copyright(c) 2003-2007 Intel Corporation
[ 32.549652] iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
[ 32.717829] wmaster0: Selected rate control algorithm 'iwl-3945-rs'
[ 48.165537] iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels

Loaded modules

iwl3945 93940 0
iwlwifi_mac80211 219108 1 iwl3945
cfg80211 15112 1 iwlwifi_mac80211
sky2 47492 0
serio_raw 7940 0
led_class 6020 2 acer_acpi,iwl3945

Reproducible -> anytime

Hi,

I have found same information that can be interesting to solve this problem:

http://ipw3945.sourceforge.net/INSTALL

In section 6 you can read that:

6. KERNEL REQUIREMENTS - 2.6.13+chance
-----------------------------------------------

The Intel PRO/Wireless 3945ABG Network Connection driver for Linux is
currently maintained only for 2.6.13+ versions of the Linux kernel,
but may work in older versions. We try (when possible) to provide
backward compatibility patches to the driver to keep it working for as
long as possible with legacy kernels.

So bad news for us...

There is the last chance for us in section 7, I have no time to try to reconfigure the kernel, if someone have time and want to try, he is more than welcome to share his experience!!

I hope this information can be useful!!

Hi!

Same thing happening to me:

>lshal

udi = '/org/freedesktop/Hal/devices/pci_8086_4222'
  info.linux.driver = 'iwl3945' (string)
  info.parent = '/org/freedesktop/Hal/devices/pci_8086_27d0' (string)
  info.product = 'PRO/Wireless 3945ABG Network Connection' (string)
  info.subsystem = 'pci' (string)
  info.udi = '/org/freedesktop/Hal/devices/pci_8086_4222' (string)
  info.vendor = 'Intel Corporation' (string)
  linux.hotplug_type = 2 (0x2) (int)
  linux.subsystem = 'pci' (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0' (string)
  pci.device_class = 2 (0x2) (int)
  pci.device_protocol = 0 (0x0) (int)
  pci.device_subclass = 128 (0x80) (int)
  pci.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0' (string)
  pci.product = 'PRO/Wireless 3945ABG Network Connection' (string)
  pci.product_id = 16930 (0x4222) (int)
  pci.subsys_product = 'PRO/Wireless 3945ABG Network Connection' (string)
  pci.subsys_product_id = 4096 (0x1000) (int)
  pci.subsys_vendor = 'Intel Corporation' (string)
  pci.subsys_vendor_id = 32902 (0x8086) (int)
  pci.vendor = 'Intel Corporation' (string)
  pci.vendor_id = 32902 (0x8086) (int)

>lspci

02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

> dmesg | grep iwl
[ 43.692435] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.0
[ 43.692443] iwl3945: Copyright(c) 2003-2007 Intel Corporation
[ 43.692684] iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
[ 47.498383] iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels
[ 47.499146] wmaster0: Selected rate control algorithm 'iwl-3945-rs'

> iwlist scan
lo Interface doesn't support scanning.

eth0 Interface doesn't support scanning.

wmaster0 Interface doesn't support scanning.

wlan0 No scan results

> modinfo iwl3945
filename: /lib/modules/2.6.24-19-generic/ubuntu/wireless/iwlwifi/iwlwifi/compatible/iwl3945.ko
license: GPL
author: Copyright(c) 2003-2007 Intel Corporation
version: 1.2.0
description: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux
srcversion: 8E95C617988943846696F97
alias: pci:v00008086d00004227sv*sd*bc*sc*i*
alias: pci:v00008086d00004222sv*sd*bc*sc*i*
depends: iwlwifi_mac80211
vermagic: 2.6.24-19-generic SMP mod_unload 586
parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
parm: disable:manually disable the radio (default 0 [radio on]) (int)
parm: hwcrypto:using hardware crypto engine (default 0 [software]) (int)
parm: debug:debug output mask (int)
parm: disable_hw_scan:disable hardware scanning (default 0) (int)
parm: queues_num:number of hw queues. (int)
parm: qos_enable:enable all QoS functionality (int)

The nm-applet does not show any AP, and there's 7 around here...

I'm newbee in Linux and read all things here. But I don't know how to fix this.

If I ask for connect to another wireless net (left click over nm-applet as it shows no option under wireless network), I can type...

Ok, so in case it is any help at all, I try to give information about my problem as well (which seems to resemble the ones you have). I am definitely a newbie which does not understand what happens at all, so I am sorry if information is misleading or whatnot. Please let me know if you want me to try anything else / give you more information.

I have kubuntu 7.10, linux 2.6.24-19 on my Thinkpad T61p (core 2 duo T9300) with the Intel(R) Wireless WiFi Link 4965AGN driver for Linux, 1.2.0. In the beginning everything seemed to be working just fine. Then after a while I had problems finding networks, more and more so. To my surprise it seemed that moving the lid sort of helped (the antenna is here), so I was worried if this was a hardware problem (still don't know). From what I understand now, it seems to me that it's more likely a driver issue. After I have get a connection, I have no problems losing the connection again or similar. Also, what I discovered recently, was that placing the laptop just next to the router while trying to connect helped a lot. I would also like to add that the problem seems random, sometimes it's hopeless, sometimes it's almost non-existing. And, at work I have no problems finding and connecting to network until now anyway. The difference between home and work is that at home there are about 10 different access points discoverable, and there's no encryption at work. A last comment is that one of the available access point is a N-network. For some reason I often find this without finding any other network. This is why I try to connect to this network in this example (I don't know if the driver/utilities support N network yet, but that's a different story anyway, that's not urgent in any way for my part). As a "conclusion" it seems that the "thingy" hangs after a failed attempt to connect to the a.p. (this is also true when it tried to connect to b/g network and failed). Using the kill switch stops the dmesg output.

I attach a dmesg output that hopefully could give you some kind of information. A short summary:

booting the machine
dmesg output

[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.24-19-generic (buildd@vernadsky) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Wed Jun 4 16:35:01 UTC 2008 (Ubuntu 2.6.24-19.33-generic)
...
[ 27.925629] Bluetooth: RFCOMM socket layer initialized
[ 27.925645] Bluetooth: RFCOMM TTY layer initialized
[ 27.925649] Bluetooth: RFCOMM ver 1.8

iwlist wlan0 scan --> nothing new in dmesg, does not find any network(!)
ifconfig wlan0 down
ifconfig wlan0 up

[ 178.228974] ADDRCONF(NETDEV_UP): wlan0: link is not ready

iwlist wlan0 scan --> find N-network, nothing new in dmesg, does not find any other network(!)
knetworkmanager to connect

[ 201.257703] NET: Registered protocol family 17
[ 202.005125] wlan0: Initial auth_alg=0
[ 202.005134] wlan0: authenticate with AP 00:00:00:00:00:00
...
[ 204.271979] iwl4965: Not a valid iwl_rxon_assoc_cmd field values
[ 204.271983] iwl4965: Invalid RXON configuration. Not committing.

dmesg -c
dmesg

[ 219.591122] wlan0: authenticate with AP 00:00:00:00:00...

*edit* I use Ubuntu 8.04 sorry I was a bit tired when writing the post yesterday. The non-problematic era was when I had 7.10 (dunno the driver version numbers at that time)

For the record, same problem in Toshiba Satellite U400 (same wireless hardware). Hardy 8.04, all update repositories used, kernel backports package installed. Now I will read through this bug report to see if there is a workaround.

Sorry. The Toshiba U400 reports iwl4965 as the loaded module.

A summary of the thread for new readers:

If you are using Hardy 8.04 and have the kernel backported modules installed (linux-backports-modules-hardy), you will find a bug in the iwl (intel wireless) drivers. It has nothing to do with network manager, and if you don't use this module, you won't see the problem. The backport modules brings newer versions of the Intel wireless drivers to the 2.6.24 kernel of Hardy 8.04. This bug will surely be fixed. Apart from not using the backports module, there is an easy workaround:

The workaround: after re-enabling the kill-switch, do this from a shell:

sudo rmmod iwl4965
sudo modprobe iwl4965

for interest:
On the Toshiba, the kill-switch also turns off Bluetooth.
Bluetooth is reactivated when the kill-switch is turned on again.

I've recreated this using 2.6.27-4-generic on Intrepid Ibex and iwl3945 driver version 1.2.26ks. The workaround mentioned does work for me though.

$ sudo rmmod iwl4965
ERROR: Module iwl4965 does not exist in /proc/modules
$ sudo modprobe iwl4965

shouldnt this be iwlagn ?

I confirm the bug (Thinkpad T61p with iwl4965 from linux-backports-modules-hardy) but not the workaround (only reset can bring wifi back on).

On software rfkill (Fn-F5 here) both bluetooth and wifi go off, but then wifi goes back on in 15–20 seconds. Pressing Fn-F5 again causes bluetooth to go on and wifi to go off, and after 15–20 seconds wifi is on again. Pressing Fn-F5 quickly a few times can cause wifi to go off forever (i.e. until reset).

Targeting for intrepid as this is a regression.

I filed a similar issue with iwlagn as bug 278008

Confirmed in Intrepid upgraded from 8.04.1 to beta, all updates as of this post. Right-clicking nmapplet and Disabling and then Enabling Wireless fixes it.

Sorry, 3945 here.

i think most recent claims of broken kill switch should be covered by bug 267875 - which is now fixed in intrepid.

Could you please test and let us know if there are still issues left for this bug?

This bug report unfortunately appears to have been co-opted for a couple different issues, spread across two releases. I'm going to focus here on the issues that apply to intrepid.

I've recently (post-beta) patched hal in intrepid to support the kernel's new generic rfkill interface, to address bug #267875 - I wasn't aware that this bug was also open at the time. Could the users who are seeing this problem please re-test with the latest hal package version to verify whether this problem is resolved for you? If there is really a bug in the kernel driver then of course it will not, but I haven't seen any bugs in the kernel driver here - the "bug" may simply be that the backported iwlwifi drivers were using the generic rfkill interface which wasn't supported yet in 2.6.24.

invalid for 2.6.24 in intrepid, which is at 2.6.27.

Using kernel version 2.6.27-7.11 on Intrepid and booting with the kill switch enabled I noticed the following in dmesg:

iwl3945: Radio disabled by HW RF Kill switch
iwl3945: 0000:02:00.0: PCI INT A disabled

Then after disabling the kill switch I seen no new messages regarding iwl3945 in dmesg and iwlist wlan0 scan returns no results.

Removing the module (sudo rmmod iwl3945) and reloading it (sudo modprobe iwl3945) allows wireless to work again.

Booting the system with the killswitch on /sys/class/rfkill/rfkill0/state is 2. After disabling the kill switch it is still 2.

Confirmed here, the value seems to always be '2' for me:

perseus:[...0000:03:00.0/rfkill/rfkill5] cat name
4965AGN
perseus:[...0000:03:00.0/rfkill/rfkill5] cat state
2

So there would appear to be a kernel problem here still.

I can also reproduce this now, which I wasn't able to before for whatever reason; any change of the hardware kill switch requires a module unload/reload to reset.

I'm marking the 'hal' task as invalid, since AFAIK we have only the driver issue remaining, the only hal issue I know of having been dealt with in bug #267875.

After a reboot into 2.6.27-7.12, I'm no longer able to reproduce a problem here:

perseus:[/sys/class/rfkill] cat */name
tpacpi_bluetooth_sw
tpacpi_wwan_sw
4965AGN
perseus:[/sys/class/rfkill] cat */state
1
1
1
perseus:[/sys/class/rfkill] # toggle kill switch
perseus:[/sys/class/rfkill] cat */state
2
2
2
perseus:[/sys/class/rfkill] # toggle kill switch
perseus:[/sys/class/rfkill] cat */state
1
1
1
perseus:[/sys/class/rfkill] # toggle kill switch
perseus:[/sys/class/rfkill] cat */state
2
2
2

Network Manager responds appropriately and brings the wifi interface up/down as well.

I have no more issues at the moment, but I have no idea what changed to fix it.

Usually, I boot the system with the kill switch enabled (because I use a wired network). This time, I booted with it disabled because I happened to be testing for bug 258804.

Can anyone else confirm whether booting with the switch disabled changes the symptoms?

I'm on latest intrepid kernel (-7.12)

I usually boot with kill switch enabled (i. e. wifi disabled), and /sys/class/rfkill/rfkill0/state is always "2". Flipping the switch doesn't change it, and thus N-M never sees the device.

If I boot with kill switch disabled (i. e. wifi enabled), /sys/class/rfkill/rfkill0/state is "1", and flipping the switch toggles between 1 and 2. So it seems to work correctly only if I boot with wifi enabled.

As another data point, if I boot with killswitch enabled (wifi disabled), dmesg does not show anything if I flip the switch. When booting with kill switch disabled, and wifi toggling works, dmesg has the usual

[ 578.255779] iwl3945: Radio Frequency Kill Switch is On:
[...]

and

[ 585.254188] Registered led device: iwl-phy0:radio
[...]

lines.

Confirmed:

perseus:[/sys/class/rfkill] # enable the kill switch
perseus:[/sys/class/rfkill] sudo rmmod iwlagn
perseus:[/sys/class/rfkill] cat */state
2
2
perseus:[/sys/class/rfkill] sudo modprobe iwlagn
perseus:[/sys/class/rfkill] cat */state
2
2
1
perseus:[/sys/class/rfkill] # wait a few seconds
perseus:[/sys/class/rfkill] cat */state
2
2
2
perseus:[/sys/class/rfkill] # disable the kill switch
perseus:[/sys/class/rfkill] cat */state
1
1
2
perseus:[/sys/class/rfkill] # enable the kill switch
perseus:[/sys/class/rfkill] cat */state
2
2
2
perseus:[/sys/class/rfkill] # disable the kill switch
perseus:[/sys/class/rfkill] cat */state
1
1
2
perseus:[/sys/class/rfkill] # enable the kill switch
perseus:[/sys/class/rfkill] cat */state
2
2
2

If the state is '2' when the module is loaded, it never changes. If the state is '1' when the module is loaded, it works properly.

Also confirmed

I have an HP dv2915nr with the 3945 card. I have a similar problem. If I disable the kill switch while I am online, flipping the switch back on does not reconnect wireless. I have to shutdown/restart with the switch on to re-enable it.

on up to date intrepid wireless is permanently disabled

/sys/class/rfkill$ uname -r
2.6.27-7-generic

/sys/class/rfkill$ sudo modprobe iwlagn
/sys/class/rfkill$ cat */state
2
2

press Fn-F5

/sys/class/rfkill$ cat */state
2
2

/sys/class/rfkill$ sudo rmmod iwlagn
/sys/class/rfkill$ cat */state
2
2

press Fn-F5

/sys/class/rfkill$ cat */state
2
2

/sys/class/rfkill$ sudo modprobe iwlagn
/sys/class/rfkill$ cat */state
2
2

press Fn-F5

/sys/class/rfkill$ cat */state
2
2

output from dmesg after reboots

[11047.651826] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
[11047.651842] iwlagn: Copyright(c) 2003-2008 Intel Corporation
[11114.467765] iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[11114.468273] iwl3945: Radio disabled by HW RF Kill switch

ian, it's likely that in your case the problem is not the driver or network manager, but that the keyboard shortcut (Fn+F5) is not recognized, so the rfkill switch never gets toggled

yes, this is true..i found the switch on the front of the laptop and turned wireless back on and it works fine now..sorry about the noise

This won't make 8.10 GA, we will fix in an update

Great!

I can confirm that as of 10/25 at 8:15pm ET 8.10 Release Candidate with all updates installed has not fixed the problem for Lenovo ThinkPad T60 3945abg

2.6.27-7-generic #1 SMP

Any idea when the patch will be released for general (or beta) consumption?

Added to the release notes at <https://wiki.ubuntu.com/IntrepidReleaseNotes#Cannot%20reactivate%20Intel%203945/4965%20wireless%20if%20booting%20with%20killswitch%20enabled>.

I can confirm the boot problem and the network manager problem; on Intrepid beta (updated until the day before the release candidate), AMILO Si 2636, with Integrated Wireless LAN (WLAN) solution 802.11a/b/g/n: Intel® PRO/Wireless 4965ABN.

Network Manager (desktop app) wont start and once gone it will never come back (even if I re-install all network-manager packages). However, connections reconfigured before a crash still works.

I think I have seen duplicate bugs describing only the nm-applet crash problem.. perhaps they are related. Many users have problem with missing network applet - and without the old graphical network configuration it is hard for them to get online.

hello i have a better workaround for this issue
if wifi isn't working, then first press the rfkillswitch, secondly reload the iwlagn driver
wich can be done by
sudo rmmod iwlagn
sudo modprobe iwlagn
wait a little bit then there the led light goes ;)
this is much easier then rebooting right?

I just upgraded my t61 from Hardy (which did not exhibit this issue) to Intrepid. I am wondering if perhaps, until a proper fix is released, reverting to the wireless driver used in Hardy would solve this issue?

There is a patch fix this bug in Intrepid about iwl4965.

---
This patch take care of coming out rfkill when the driver is up while
rfkill is on
Signed-off-by: mohamed abbas <email address hidden>
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 7183ac5..da5d18a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -1655,8 +1655,11 @@ static void iwl4965_irq_tasklet(struct iwl_priv *priv)
    * the driver as well won't allow loading if RFKILL is set
    * therefore no need to restart the driver from this handler
    */
- if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status))
+ if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status)) {
    clear_bit(STATUS_RF_KILL_HW, &priv->status);
+ if (priv->is_open && !iwl_is_rfkill(priv))
+ queue_work(priv->workqueue, &priv->up);
+ }

   handled |= CSR_INT_BIT_RF_KILL;
  }
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 8eb0203..8de684d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -1490,6 +1490,16 @@ int iwl_radio_kill_sw_enable_radio(struct iwl_priv *priv)
   return 0;
  }

+ /* when driver is up while rfkill is on, it wont receive
+ * any CARD_STATE_NOTIFICATION notifications so we have to
+ * restart it in here
+ */
+ if (priv->is_open && !test_bit(STATUS_ALIVE, &priv->status)) {
+ clear_bit(STATUS_RF_KILL_SW, &priv->status);
+ if (!iwl_is_rfkill(priv))
+ queue_work(priv->workqueue, &priv->up);
+ }
+
  /* If the driver is already loaded, it will receive
   * CARD_STATE_NOTIFICATION notifications and the handler will
   * call restart to reload the driver.

what also works for me is this:

if killswitch is enabled (wifi off) nm-applet will disable the "[] enable wireless" menu entry
turning killswitch off should enable wifi, but the status led is still off, and no access points are shown in network manager
right-clicking on nm-applet "[x] enable wireless" is now activated. disabling it and then enabling it again, should bring up the status led and after some seconds all available networks.
no need to modprobe/rmmod in a terminal

be careful though… i had some kernel panics when enabling/disabling wifi

Thanks Daniel, that workaround works for me and makes this bug nothing but a smaller annoyance. Added your workaround to the bug description as well.

I can confirm that this bug also exists on the 5xxx series wireless devices as reported in bug 278008. Applied the patch above to the latest Intrepid kernel and confirmed that this does indeed fix the issue. Will chase the submitter of the patch to acertain its status for application.

I am curious, will this Fix be released as a SRU, backport or be kept back until Jaunty?

@Matt Zimmerman

This bug only manifests itself if the driver is loaded when the switch is on. If the driver is loaded when the switch is off then further on/off operations are successful.

SRU Justification

Impact: iwl wifi doesn't work if you boot with the RF kill switch enabled, then switch it off.

Patch Description: Restart the work queue when RF is disabled.

Patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=cd4666e63577dbd1fe79ccde3ee5a93aea9b7c60

Test case: see bug description

On Fri, Nov 14, 2008 at 12:29:33AM -0000, Andy Whitcroft wrote:
> @Matt Zimmerman
>
> This bug only manifests itself if the driver is loaded when the switch
> is on. If the driver is loaded when the switch is off then further
> on/off operations are successful.

Correct.

--
 - mdz

Please note, that the "Fix Committed" is only true for iwlwifi. This issue isn't yet fixed for iwl3945.

Accepted linux into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Just tried the kernel in intrepid-proposed, kill switch appears to work properly, but NetworkManager looks confused: it shows full signal bars when the kill switch is on (it should show the crossed out screen icon), while pings are being dropped (as they should be on a killed WiFi adapter).

I just wanted to add a note here that for those testing intrepid-proposed please be sure you test the 2.6.27-10 kernel that will contain this patch - https://edge.launchpad.net/ubuntu/+source/linux/ . I believe the 2.6.27-10 kernel is just being a bit slow to hit the archive so we appreciate your patience. Thanks.

This fix is also queued up for the Jaunty a2 kernel. Moving the Jaunty task to Fix Committed.

I confirm that with 2.6.27-10, disabling killswitch now works properly even if I booted with the killswitch enabled.

Kill switch works here too on 2.6.27-10, though NetworkManager is horribly confused and attempts to associate using a disabled adapter, which is bug #267875 I think.

Seems to be, that it really was fixed only for iwlwifi module or something orter.

On my system: Acer 6292, iwl3945, ubuntu 8.10 with all updates
uname -a
Linux neobook 2.6.27-10-generic #1 SMP Fri Nov 21 19:19:18 UTC 2008 x86_64 GNU/Linux

_it still actually doesn't work._

if wlan is turned on, I can turn it off
but if it was turned on, there is no way to get it on again.

so?

I'm changing the status back to Confirmed, because, as i have already said, the fix commited is only for iwl4965 (iwlwifi) and not iwl3945 which this bug is also and was originally about.
If this is the wrong status or someone disagrees for any other reasons, feel free to change the status again.

I confirm, that bug wasn't fixed for iwl3945

On Fri, Nov 14, 2008 at 12:29:33AM -0000, Andy Whitcroft wrote:
>> @Matt Zimmerman
>>
>> This bug only manifests itself if the driver is loaded when the switch
>> is on. If the driver is loaded when the switch is off then further
>> on/off operations are successful.

>Correct.

Actually, even if i booted with switch disabled, and i have wlan in working mode, if i press killswitch key - wlan will be disabled, but i can't turn it on again.
Acer 6292 , 8.10 with all updates, iwl3945

I can also confirm that in 8.10 with 2.6.27-10, enabling the kill switch works, but if I boot with the killswitch on and then want to enable wifi, i need to do "sudo ifconfig wlan0 up", otherwise the interface is never seen.

I have tried to port the changes to the iwl4965 to the iwl3945 driver. I have built some kernels based on the Intrepid -proposed kernel. If someone who has the iwl3945 hardware could test them. Specifically the booting with the rf kill switch disabled and then see if turning it off then allows the driver to start automatically. These kernels can be found at the following URL:

    http://people.ubuntu.com/~apw/lp193970/

New to the thread, but I'm having similar issues and tried your kernel build. Didn't seem to help. My particular oddity is that once I enable the killswitch (turn off wireless), I can't turn it back on again. I'll admit that I'm having trouble nailing down exactly the steps to reenable it, but a reboot followed by a couple of kills and restarts of NetworkManager seems to do it.

Anything else I can try for you, just let me know.

Thanks,
Chaz

Hello. I can confirm this and reproduce it anytime.

Scenario:
1. Wireless is working
2. Disable via NetworkManager
3. Wireless is off
4. Enable via NetworkManager
5. Wireless is working
6. Press killswitch
7. NetworkManager takes a while to realize that wireless is supposed to be off
8. cat /sys/bus/ returns 2
9. Press killswitch (now it's 1)
10. Wireless does not come back on
11. Press killswitch again to make it 2.
12. Reboot or sudo modprobe -r iwlagn; sudo modprobe iwlagn
13. Wireless doesn't work
14. Press killswitch to make it 1.
15. Reboot or sudo modprobe -r iwlagn; sudo modprobe iwlagn
16. Wireless works.

So it seems that
1. The killswitch DOES toggle the state properly (1/2)
2. NetworkManager seems to work
3. modprobe iwlagn when killswitch state is 2 (WLAN Disabled) fails
4. modprobe iwlagn when killswitch state is 1 (WLAN Enabled) succeeds
5. after modprobe iwlagn when kilswitch state is 2 (WLAN Disabled), switching the killswitch back to WLAN Enabled does not allow WLAN to work again.

Hardware:
Laptop, Acer TravelMate 6292 (Intel 4965AGN)

Software:
Ubuntu 8.1.0

uname -a:
Linux hubert-laptop 2.6.27-10-generic #1 SMP Fri Nov 21 12:00:22 UTC 2008 i686 GNU/Linux

I'm willing to provide as much information as I can. Hope this gets fixed ASAP. At least now I have a workaround to make it work, but it's quite bothersome to keep having to do it.

Thanks,
Hubert

I'm suffering this bug too, here are some information about my case:

Hardware :
Laptop, Sony Vaio VGN-FE770G

Software :
Ubuntu 8.10, installed from scracth, updated to now

Uname -a:
Linux halley 2.6.27-10-generic #1 SMP Fri Nov 21 12:00:22 UTC 2008 i686 GNU/Linux

Since the arrival of the iwl3945 driver my wireless never worked.
Randomly when I boot ( twice, in fact ) it worked well, but if I turned on the killswitch during this grace period, tha magic is gone.

None of the workarounds found in the web worked for me.

Attached you have the dmesg output from the two moments, the working wireless boot and the non-working.

I hope this cuold help you to help me, I don't want to get back to XP just to see my wireless working.

best regards

Trevor

this but affects me to. (Toshiba Satelite P100)
$ uname -a
Linux me 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux

$ lspci | grep -i "wireless"
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

this worked for me to enable wireless again.
$ sudo rmmod iwl3945
$ sudo modprobe iwl3945

need more info?

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

I can confirm that this is fixed for me (iwl3945) in jaunty, but not in intrepid.

The error seems to lie in userspace, though. Installing the linux-image-2.6.28-3-generic and linux-firmware from jaunty under intrepid doesn't change anything.

I confirm this bug on 8.10 (Dell Latitude D830).

$ uname -r
2.6.27-9-generic

$ lspci | grep -i "wireless"
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

Both workarounds (1 and 2) works for me.

On Tue, Jan 6, 2009 at 18:05, Andreas Gnau <email address hidden> wrote:

> I can confirm that this is fixed for me (iwl3945) in jaunty, but not in
> intrepid.

So we have this bug since 8.10, thus october 2008. I'm quite suprised to see
it's not yet solved.

Because of this annoying bug I've switched my laptop back to 8.04 one month
ago. I guess I'll to wait for 9.04.

Sander

I have HP 6510b with Intel iwl3945 and this bug is really annoying. I, myself, can handle this bug with rmmod && modprobe workaround, but tell other people :(

What's worse, few friends switched back to Windows :(

Michal Pěnka, it would be better to suggest them to use Hardy :) This time LTS have been really stable if we talk about wifi support.

Anyway, this bug is still in Jaunty Alpha 3 Live CD. I will try to install it, but if it isn't fixed, milestone should be moved to alpha 3 or 4.

I don't know if it's the same bug, but I still have this problem, on 8.04

Thinkpad x60 tablet
2.6.24-23-generic
iwl3945

for me, however, when switched off then on, the iwl3945 module actually hangs in a 'disk sleep',
additionally, attempts to 'sudo modprobe -r iwl3945' get hung in 'disk sleep'

I also have the same problem on a Haier W62-N Notebook with Ubuntu 8.10 and kernel 2.6.27-9-generic.

This notebook always starts up with wireless disabled.

After i enable wireless with soft switch nothing happens. I have to type sudo rmmod iwl3945; sudo modprobe iwl3945 in the terminal and then it works fine.

If disable the switch i cannot turn it back on again and have unload and reload iwl3945 again.

We have been able to backport the fixes for the iwl4965 and later drivers. There are no fixes in later drivers for the iwl3945 as those have been subsumed into the common intel wireless driver, which brings this fix automatically for those cards, and they should therefore work correctly in Jaunty. This work however was major and is not appropriate for SRU to intrepid. As there are appropriate work arounds for intrepid we do not intend to attempt a fix there.

Marking this Fix Released in Jaunty, and Won't Fix in Intrepid.

I have just downloaded Jaunty (seems to be that it is Alpha-2) and installed all updates, but killswitch still doesn't work. If there any time estimates, when it will be working to test it? should we set state back to not fixed?

so, next, there is no workaround to make killswitch work properly. there is workaround to make WI-fi works properly. But there is difference between these statements, isn't it?

still using Vista instead of Ubuntu..

PS. I confirm now it is still not fixed in Jaunty. Could anyone explain, what is the problem???

This is not fixed for iwl3945 chipsets in jaunty, because the iwlagn driver does *not* handle these chipsets in 2.6.28 - the driver is still split out. So it would be nice to have a fix for the iwl3945 branch of the family.

Is this bug going to be fixed in iwl3945 for jaunty?

13 dupes and countless "affects me toos" and yet it is classified as "won't fix." I know this is a volunteer effort for the most part, but this is a pretty serious pain that affects a lot of people. If there is a way to fix it, I want to lend my voice to the message "Please fix this bug!!" It drives me nuts, and affects a lot of people.

Waiting for Jaunty Alpha 5. Now I have 9.04 with all updates, when it starts it enables WLAN, but if I disable it using WLAN button (killswitch, but on my laptop it is button with no positioning), it still can't be reactivated with WLAN button. So, next, I think, that it isn't correct behavior to always enable WLAN at startup, cause it costs battery power.

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=6748b0809789a4f617455672491839e05a066bf7

Thanks to Tim for the commit.

Will this be available as backport for Intrepid? As Telorn said this ist quite annoying!

Or for Hardy, which has Long Term Support until April 2011?

Can confirm this on Fujitsu Siemens Amilo Si1520 with iwl3945 running Intrepid. The workaround I have to do is:

1) rmmod iwl3945
2) Activate radio using kill switch button.
3) modprobe iwl3945

All other attempts, even rebooting, hasn't worked.

Please find a way to get this fixed for Jaunty for iwl3945 too! Almost a year old bug.. And it used to work fine in Hardy.

This bug was fixed in the package linux - 2.6.28-8.23

---------------
linux (2.6.28-8.23) jaunty; urgency=low

  [ Andy Whitcroft ]

  * include the kernel configuration in the sub-flavour images
    - LP: #328859

  [ Tim Gardner ]

  * Revert "SAUCE: (drop after 2.6.28) [eCryptfs] Regression in unencrypted
    filename symlinks" in favor of upstream commit.
  * Fix compile issues with qc-usb
  * SAUCE: (remove after 2.6.28) V4L/DVB (10216): saa7127: fix broken
    S-Video with saa7129
    - LP: #329267

  [ Upstream Kernel Changes ]

  * Subject:SAUCE: LP#193970 iwlagn: fix hw-rfkill while the interface is
    down
    - LP: #193970
  * x86, vmi: put a missing paravirt_release_pmd in pgd_dtor
  * nbd: fix I/O hang on disconnected nbds
  * mac80211: restrict to AP in outgoing interface heuristic
  * w1: w1 temp calculation overflow fix
  * zd1211rw: adding 0ace:0xa211 as a ZD1211 device
  * zd1211rw: treat MAXIM_NEW_RF(0x08) as UW2453_RF(0x09) for TP-Link
    WN322/422G
  * parport: parport_serial, don't bind netmos ibm 0299
  * syscall define: fix uml compile bug
  * kernel-doc: fix syscall wrapper processing
  * Fix page writeback thinko, causing Berkeley DB slowdown
  * write-back: fix nr_to_write counter
  * writeback: fix break condition
  * mm: rearrange exit_mmap() to unlock before arch_exit_mmap
  * powerpc/fsl-booke: Fix mapping functions to use phys_addr_t
  * lockd: fix regression in lockd's handling of blocked locks
  * sctp: Fix crc32c calculations on big-endian arhes.
  * sctp: Correctly start rtx timer on new packet transmissions.
  * sctp: Properly timestamp outgoing data chunks for rtx purposes
  * net: Fix frag_list handling in skb_seq_read
  * net: Fix OOPS in skb_seq_read().
  * drivers/net/skfp: if !capable(CAP_NET_ADMIN): inverted logic
  * ipv4: fix infinite retry loop in IP-Config
  * net: Fix userland breakage wrt. linux/if_tunnel.h
  * net: packet socket packet_lookup_frame fix
  * packet: Avoid lock_sock in mmap handler
  * sungem: Soft lockup in sungem on Netra AC200 when switching interface
    up
  * udp: Fix UDP short packet false positive
  * udp: increments sk_drops in __udp_queue_rcv_skb()
  * ipv6: Disallow rediculious flowlabel option sizes.
  * ipv6: Copy cork options in ip6_append_data
  * net: 4 bytes kernel memory disclosure in SO_BSDCOMPAT gsopt try #2
  * sky2: fix hard hang with netconsoling and iface going up
  * tun: Add some missing TUN compat ioctl translations.
  * tun: Fix unicast filter overflow
  * virtio_net: Fix MAX_PACKET_LEN to support 802.1Q VLANs
  * tcp: splice as many packets as possible at once
  * tcp: Fix length tcp_splice_data_recv passes to skb_splice_bits.
  * sparc: Enable syscall wrappers for 64-bit (CVE-2009-0029)
  * sparc64: Annotate sparc64 specific syscalls with SYSCALL_DEFINEx()
  * ALSA: hda - Add missing terminator in slave dig-out array
  * ALSA: mtpav - Fix initial value for input hwport
  * HID: adjust report descriptor fixup for MS 1028 receiver
  * ide/libata: fix ata_id_is_cfa() (take 4)
  * libata: fix EH device failure handling
  * netfilter: fix tuple inversion for Node information request
  * netfilter: xt_sctp: sctp chunk mapping doesn't work
  * x86: micr...

I guess theres one more "Me Too" with me.

Regardless of the kill switch settings I can't get any network as dhcpcd / dhclient won't get me an address regardless. Using the rmmod / modprobe steps above will make the option in network-manager highlighted instead of grayed out but touching and of the settings just puts it back to the way it was(disabled). Manually using ifconifg / iwconfig / (dhcpcd | dhclient) output is below any other info needed just let me know.

fusco@fusco-laptop:/$ sudo ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:1b:77:34:ac:9e
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

fusco@fusco-laptop:/$ sudo ifconfig wlan0 up
SIOCSIFFLAGS: No such device
fusco@fusco-laptop:/$ sudo iwconfig wlan0 essid ****** key **************************
fusco@fusco-laptop:/$ sudo dhclient wlan0
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

wmaster0: unknown hardware address type 801
SIOCSIFFLAGS: No such device
SIOCSIFFLAGS: No such device
wmaster0: unknown hardware address type 801
Listening on LPF/wlan0/00:1b:77:34:ac:9e
Sending on LPF/wlan0/00:1b:77:34:ac:9e
Sending on Socket/fallback
receive_packet failed on wlan0: Network is down
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3
send_packet: Network is down
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
send_packet: Network is down
^C
fusco@fusco-laptop:/$ sudo dhc
dhclient dhclient3 dhclient-script dhcpcd dhcpcd-bin
fusco@fusco-laptop:/$ sudo dhcpcd wlan0
err, wlan0: ioctl SIOCSIFFLAGS: No such device

I'm running a Compaq nc4400 laptop

#uname -a
Linux fusco-laptop 2.6.28-8-generic #24-Ubuntu SMP Wed Feb 18 20:36:18 UTC 2009 x86_64 GNU/Linux

fusco@fusco-laptop:~$ lspci

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d...

This still isn't fixed for me :(

I start the machine with wifi off, then try to put it on... and it doesn't work. Bluetooth comes on, however.

Currently running 2.6.28-8.26 in Jaunty.

This is not fixed for me in Jaunty either.

Tried 2.6.28 and the unsupported 2.6.29 too.

still does not work in jaunty with all updates

Please don't touch the ubuntu-release-notes task. This issue *is* documented in the release notes, which means the release is fixed.

I have reviewed Jaunty Alpha 5 release notes and have not found any information about this bug, that i have seen for example in 8.10 rel notes?

The ubuntu-release-notes project refers to the release notes published for a final release, not to the technical overviews prepared for alpha milestones. The issue is documented in the 8.10 release notes. For 9.04 there is still the hope that this bug will be resolved before release.

I tested the 2.6.29 kernel which has the same problem

I too can confirm this on latest jaunty.
As I said before, I resolve this every time by running:
sudo ifconfig wlan0 up;sleep 2;sudo iwlist wlan0 scan

Is there any chance this is not kernel, but something else? (dbus, network-manager)

No, the problem appears to be that the driver never sees that the killswitch has been re-enabled. Therefore, it never tells n-m to reconnect.

For those of you on Jaunty there is a new linux-backport-modules which includes updated drivers for this card. If those who can test this could do so and report back here that would be very helpful.

After installing that package, the iwlwifi module does no more load...

i also lost my intel wifi 4965 abgn driver
wont even show up on iwconfig
add to reboot into kernel -7, to have wifi.

please revert this ASAP.
thanks

@Nicolo, @BUGabundo -- seems there is an issue with the new linux-backports-modules package, whcih is being worked on right now. If you were not using linux-backports-modules before I requested you test it you should be able to remove it to restore your wifi.

I will let you know when the issue is resolved with this package.

fixed for me in linux-image 2.6.28-8.27 (no need to install the backport modules)

 Nicolò, could you please describe your configuration? you have iwl3945 or 4965?

and next, have you tested it by fast switching killswitch or wait sometime for WLANs to disappear from networkmanager menu before trying to reenable it?

For me dmesg look like:

1. System booted. WLAN led lights on. Network manager discovers WLANs.

2. I press WLAN button WLAN led lights off.
3. Then I immidiately press it again.

WLAN led lights on. Network manager continue to discover WLANs.
dmesg looks like:
[ 101.771416] iwl3945: Radio Frequency Kill Switch is On:
[ 101.771420] Kill switch must be turned off for wireless networking to work.
[ 102.582424] Registered led device: iwl-phy0:radio
[ 102.582507] Registered led device: iwl-phy0:assoc
[ 102.582544] Registered led device: iwl-phy0:RX
[ 102.582578] Registered led device: iwl-phy0:TX

5. I can repeat steps 2-3 many times and it will works well.

6. But, if I try to repeat steps 2-3 in other way, but i wait for some time (about 5 seconds) beetween step 2 and step 3, and when i press WLAN button WLAN led turns off, but when i press it again it does not
turns back on again.
dmesg looks like:
[ 133.961713] iwl3945: Radio Frequency Kill Switch is On:
[ 133.961717] Kill switch must be turned off for wireless networking to work.
[ 134.954314] iwl3945: MAC is in deep sleep!
[ 134.954451] iwl3945: MAC is in deep sleep!
[ 134.954545] iwl3945: MAC is in deep sleep!
[ 134.961569] iwl3945 0000:05:00.0: PCI INT A disabled
and I can't work with WLANs

Some information about this bug:

[PATCH 5/5] iwl3945: fix deep sleep when removing the driver.: msg#00098 linux-wireless
http://osdir.com/ml/linux-wireless/2009-01/msg00098.html

Current iwl3945 version in Jaunty with all updates:

sudo modinfo iwl3945

filename: /lib/modules/2.6.28-8-generic/kernel/drivers/net/wireless/iwlwifi/iwl3945.ko
firmware: iwlwifi-3945-1.ucode
license: GPL
author: Copyright(c) 2003-2008 Intel Corporation
version: 1.2.26ks
description: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux
srcversion: 8E7486EDB58B5AB7FC7DBE6
alias: pci:v00008086d00004227sv*sd*bc*sc*i*
alias: pci:v00008086d00004222sv*sd*bc*sc*i*
alias: pci:v00008086d00004227sv*sd00001014bc*sc*i*
alias: pci:v00008086d00004222sv*sd00001044bc*sc*i*
alias: pci:v00008086d00004222sv*sd00001034bc*sc*i*
alias: pci:v00008086d00004222sv*sd00001005bc*sc*i*
depends: mac80211,led-class,cfg80211
vermagic: 2.6.28-8-generic SMP mod_unload modversions
parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
parm: disable:manually disable the radio (default 0 [radio on]) (int)
parm: hwcrypto:using hardware crypto engine (default 0 [software])
 (int)
parm: debug:debug output mask (int)
parm: disable_hw_scan:disable hardware scanning (default 0) (int)
parm: queues_num:number of hw queues. (int)
parm: qos_enable:enable all QoS functionality (int)

my modules are iwlcore and iwlang. the card is intel 5100. Yes, I have
waited enough time. The fix might only be for my device and not yours?

I have iwl3945 with all updates too. Same problem. If the switch is done quickly, it works. If not, it won't come back on.

Also, if it is off during boot, it can't be enabled. The above only happens if it's switched on at boot time.

 Nicolò, yes this bug originally refers only to iwl3945 and iwl4965 drivers.

Yes, but I also had this issue with my 5100 (my bug was duplicated to
this), so I thought it could be fixed for you too

We have a potential patch for the iwl3945 side of this issue. I have built some test kernels for both Intrepid and Jaunty with that patch applied. If those of you who are affected could try those kernels and report back here that would be helpful. These kernels are at the URLs below:

    http://people.ubuntu.com/~apw/lp193970-intrepid/
    http://people.ubuntu.com/~apw/lp193970-jaunty/

Works perfectly now on my Fujitsu-Siemens Amilo Pi 1536 laptop. Thanks a lot!!!

Works here too, Lenovo R61. Cheers. Will this make it into Jaunty?

@Whoopie -- did you test intrepid or jaunty kernels there?

@Tom Vetterlein -- I believe you are on Jaunty? Correct?

Could anyone else who tests please report the version you tested against.

I am on Jaunty yes. Sorry for omitting that.

Thanks again.

Andy, it works for me on Acer 6292 with Jaunty with all updates!!! Thanks a lot!!!!

Based on the positive feedback for Jaunty I have commited this change there, and it should make the next kernel upload and the next Alpha.

Same Here, worked with Intrepid x86 on Thinkpad R60, thanks Andy

Yea, works for me too (Intrepid) on my Fujitsu Siemens Amilo Si1520 with iwl3945. Great work Andy.

@Andy: Sorry, I tested under Intrepid.

This bug was fixed in the package linux - 2.6.28-9.29

---------------
linux (2.6.28-9.29) jaunty; urgency=low

  [ Andy Whitcroft ]

  * link-headers -- only link directories which do not already exist
    - LP: #315252

  [ Daniel Marjamäki ]

  * SAUCE: (drop after 2.6.28) netxen: fix memory leak in
    drivers/net/netxen_nic_init.c
    - LP: #330813

  [ Dhananjay Phadke ]

  * SAUCE: (drop after 2.6.28) netxen: fix endianness in firmware commands
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: fix ipv6 offload and tx cleanup
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: fix link speed reporting for some
    boards
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: firmware init fix
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: cleanup mac list on driver unload
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: hold tx lock while sending firmware
    commands
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: handle dma mapping failures
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: avoid invalid iounmap
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: include ipv6.h (fixes build failure)
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: fix vlan tso/checksum offload
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: reduce memory footprint
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: revert jumbo ringsize
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: fix msi-x interrupt handling
    - LP: #330813
  * SAUCE: (drop after 2.6.28) netxen: remove pcie workaround
    - LP: #330813

  [ Hannes Eder ]

  * SAUCE: (drop after 2.6.28) drivers/net/netxen: fix sparse warnings: use
    NULL pointer instead of plain integer
    - LP: #330813

  [ Huaxu Wan ]

  * SAUCE: report rfkill changes event if interface is down
    - LP: #193970

  [ Tim Gardner ]

  * MV78XX0 must specify a target in the vars definition.

  [ Upstream Kernel Changes ]

  * Revert "ext4: wait on all pending commits in ext4_sync_fs()"
  * jbd2: Fix return value of jbd2_journal_start_commit()
  * jbd2: Avoid possible NULL dereference in
    jbd2_journal_begin_ordered_truncate()
  * ext4: Fix to read empty directory blocks correctly in 64k
  * ext4: Fix lockdep warning
  * ext4: Initialize preallocation list_head's properly
  * ext4: Implement range_cyclic in ext4_da_writepages instead of
    write_cache_pages
  * ext4: Fix NULL dereference in ext4_ext_migrate()'s error handling
  * ext4: Add fallback for find_group_flex
  * ext4: Fix deadlock in ext4_write_begin() and ext4_da_write_begin()

  [ Brad Figg ]

  * Added mv78xx0 flavor

 -- Tim Gardner <email address hidden> Fri, 06 Mar 2009 06:13:31 -0700

I can confirm that this is fixed in the latest Jaunty kernel.

Cheers devs.

Accepted intrepid into linux-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

For me the bug still exists, in Intrepid, like before. I can't enable wi-fi after switch it off, even if the switch is off when booting.
Asus W5F - Intel WM3945abg

I can give more information about my system if any one find it useful.

I've just enable proposed repository, updated and rebooted and the bug still persists for me in Intrepid. Running HP 6720s with intel 3945...

I have similar observations:
- Enabled proposed
- Upgraded with the latest kernel, and modules available there
- Rebooted with the newer kernel
- Disabled wifi by engaging the killswitch
- Waited 30 - 40 sec and disengaged killswitch
- Wireless connection *was not* restored
- Rebooted again with killswitch engaged at boot time
- When my desktop loaded, I disengaged killswitch
- Wireless connection *was not* brought up

I'm running Toshiba Satelite A110-195, featuring intel 3945.
Please advise if/what further info is necessary.

The kernel image is not yet in intrepid-proposed. Wait until it's built and you get an update, the needed package is linux-image-2.6.27-14-generic.

I've just installed the linux-image-2.6.27-14-generic and all the other kernel packages, and the switch is not working like I reported in https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/193970/comments/156

I have just upgraded linux-image, linux-headers, and linux-restricted-modules to 2.6.27-14. So far I have followed the scenario I described in my comment above and killswitch has been working as expected. I'll continue to play with it later today and if the improbable happens, and something goes wrong, I'll be back complaining.

Cheers :)

So far the workaround with disabling network and reenabling it via nm-applet worked but,
now I just updated to kernel 2.6.27-14-generic and when i do it now I always encounter a kernel panic :-((. Any suggestion what could have caused this regression?

Workaround for Acer Notebook user

to enable the wireless by configuring the file /etc/modprobe.d/options

Please follow this procedure:

Step 1: Open Terminal from "Applications->Accessories->
Terminal"

Step 2: Run the following command (copy-paste the line below to the
Terminal then hit <enter>)

Code:

sudo gedit /etc/modprobe.d/options

# add the following 2 lines to the end of the options file

Code:

options iwl3945 disable=0
options acer-wmi wireless=1

Step 3: Reboot pc and then retest the wireless

credit for this solution goes to Mark Rijckenberg , from this thread> https://answers.launchpad.net/ubuntu/+source/util-linux/+question/61864

On Tue, Apr 07, 2009 at 05:12:06AM -0000, TiloBunt wrote:
> Code:
>
> options iwl3945 disable=0
> options acer-wmi wireless=1

This sounds like bug 319825, which should be fixed (at least for some Acer
models) in current Jaunty.

--
 - mdz

I could be wrong, but I don't think this is working properly for me in jaunty beta.

I have a touch-button on my hp6710b that enables/disables both wifi and bluetooh. In windows I have disabled wifi in addition to this, meaning the physical button only enables bluetooth atm. In this state my jaunty sees the wifi as disabled, which is correct. Is there no way to control the separate "soft" bt/wifi killswitches from within jaunty? The version for my kernel is 2.6.28-11.41

There is still a small problem regarding this bug in jaunty beta.
If I disable the wifi before suspend, when I resume it doesn't activate anymore.
The only solution is to:
rmmod iwlagn
modprobe iwlagn

It's better to open a new bug?

This is not fixed in Jaunty final, at least not for XPS M1330. After having the killswitch enabled (wifi disabled) when waking up from resume, I need to right-click network manager, deactive wireless, then activate it again. Only then the wireless LED lights up again and wireless networks are found. At times when doing this, kernel panic occurs, so I am not to fond of the workaround...

This is the same behavior that existed in Intrepid before the SRU that fixed in in the .27 kernel. This is a regression in other words.

@Matteo: Try right clicking as I described, it should work and is more convenient than rmmod.

For me (HP Pavilion dv2352ea's iwl3945) the bug is fixed in jaunty final. Completely, even when hibernating.

Thank you very much, whoever hacked/released the patch!

This is also fixed for me (Dell Latitude D430).

Motin, can you please open a new bug with "ubuntu-bug linux"? I think this is fixed for most people, and this bug has many duplicates. Let's handle the remaining cases in a separate report, to avoid spamming so many people on this one. Thank you!

Sure thing. This may be a Dell XPS specific issue.

I found a typo in the hal killswitch scripts, affecting the dell-part of this script: Bug #368553

And have opened a new bug report for my specific case here: Bug #368556

This bug persists for me in Jaunty final release.

07:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02)
 Subsystem: Intel Corporation Device [8086:1001]
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 2301
 Region 0: Memory at fe7ff000 (32-bit, non-prefetchable) [size=4K]
 Capabilities: <access denied>
 Kernel driver in use: iwl3945
 Kernel modules: iwl3945

for me, the bug was fixed on jaunty until kernel 2.6.28-11. but since 2.6.28-12 the problem reappeared (but the package linux-restricted-modules-generic was not installed because the dependency to linux-restricted-modules-generic-2.6.28-12 can no be fulfilled).

the kill switch is not working as expected anymore: when booting with WIFI on, kill switch won't disable WIFI. only disabling network manager "enable wireless" will do that. ...

hardware:
- Acer TravelMate 3010
- Intel PRO/Wireless 3945ABG

cheers,
johannes raggam

This bug was fixed in the package linux - 2.6.27-14.33

---------------
linux (2.6.27-14.33) intrepid-proposed; urgency=low

  [Stefan Bader]

  * Fix FTBS due to a mysteriously missing ABI directory.

linux (2.6.27-14.32) intrepid-proposed; urgency=low

  [Stefan Bader]

  * Rebuild of 2.6.27-14.30 with 2.6.27-11.31 security patches applied

linux (2.6.27-14.30) intrepid-proposed; urgency=low

  [ Alexey Starikovskiy ]

  * SAUCE: ACPI: EC: Limit workaround for ASUS notebooks even more
    - LP: #288385

  [ Huaxu Wan ]

  * SAUCE: report rfkill changes event if interface is down
    - LP: #193970

  [ Scott James Remnant ]

  * SAUCE: floppy: Provide a PnP device table in the module.
    - LP: #255651

  [ Steve Beattie ]

  * fix apparmor memory leak on deleted file ops
    - LP: #329489

  [ Stefan Bader ]

  * Revert "ACPI: Fix compiler warnings introduced by 32 to 64 bit acpi
    conversions"
    - LP: #337019
  * Revert "ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit
    kernels"
    - LP: #337019

  [ Upstream Kernel Changes ]

  * KVM: MMU: Add locking around kvm_mmu_slot_remove_write_access()
    - LP: #335097, #333409
  * ricoh_mmc: Handle newer models of Ricoh controllers
    - LP: #311932

linux (2.6.27-13.29) intrepid-proposed; urgency=low

  [ Colin Ian King ]

  * SAUCE: Bluetooth USB: fix kernel panic during suspend while streaming
    audio to bluetooth headset
    - LP: #331106, #322082

  [ Stefan Bader ]

  * Revert "SAUCE: Work around ACPI corruption upon suspend on some Dell
    machines." (replaced by stable update)
    - LP: #330200
  * Revert "SAUCE: Add back in lost commit for Apple BT Wireless Keyboard"
    (replaced by stable update)
    - LP: #330902

  [ Upstream Kernel Changes ]

  * Revert "vt: fix background color on line feed"
    - LP: #330200
  * ti_usb_3410_5052: support alternate firmware
    - LP: #231276
  * fuse: destroy bdi on umount
    - LP: #324921
  * fuse: fix missing fput on error
    - LP: #324921
  * fuse: fix NULL deref in fuse_file_alloc()
    - LP: #324921
  * inotify: clean up inotify_read and fix locking problems
    - LP: #324921
  * mac80211: decrement ref count to netdev after launching mesh discovery
    - LP: #324921
  * sysfs: fix problems with binary files
    - LP: #324921
  * x86, mm: fix pte_free()
    - LP: #324921
  * alpha: nautilus - fix compile failure with gcc-4.3
    - LP: #324921
  * it821x: Add ultra_mask quirk for Vortex86SX
    - LP: #324921
  * libata: pata_via: support VX855, future chips whose IDE controller use
    0x0571
    - LP: #324921
  * rtl8187: Add termination packet to prevent stall
    - LP: #324921
  * serial_8250: support for Sealevel Systems Model 7803 COMM+8
    - LP: #324921
  * SUNRPC: Fix a memory leak in rpcb_getport_async
    - LP: #324921
  * SUNRPC: Fix autobind on cloned rpc clients
    - LP: #324921
  * USB: fix char-device disconnect handling
    - LP: #324921
  * USB: storage: add unusual devs entry
    - LP: #324921
  * USB: usbmon: Implement compat_ioctl
    - LP: #324921
  * ALSA: hda - add another MacBook Pro 4, 1 subsystem ID
    - LP: #324921
  * ALSA: hda - Add quirk for HP DV6700 laptop
    - LP: #324921
  * ALSA: ...

i see. since i got linux-restricted-modules-generic-2.6.28-12 via apt WIFI works fine again! :)

Adding to the data for this bug.

It still shows up on Hardy 8.04 kernel: 2.6.24-24-generic
fully patched.

on a Compaq 8710p laptop with iwl4965

I _don't_ have the backport package installed.

 " dpkg --list | grep backport" yields nothing.

Symptoms and description are as others have reported. The "hard" switch on this laptop is along a touch-bar above the function keys. In Windows XP, it lights up when on, and goes out when off, and correctly toggles the wifi/bluetooth. In Ubuntu, once wifi is turned off via the switch, nothing seems to wake the wifi back up. Even after a reboot, the wifi antenna remains offline.

/var/log/messages just shows:

Jun 28 18:02:47 laptop kernel: [ 136.685170] iwl4965: Radio Frequency Kill Switch is On:
Jun 28 18:02:47 laptop kernel: [ 136.685173] Kill switch must be turned off for wireless networking to work.

but pushing the touch bar switch doesn't help without the modprobe fix described.

I've been able to boot into XP (as a previous poster described) and use the "HP wireless assistant" pop-up to fix it, and after finding this thread, I have a work-around in ubuntu:

hit the wireless button, then do
 sudo modprobe -r iwl4965
 sudo modprobe iwl4965

But it would be nice to have this fix propagated to Hardy 8.04. I'd rather not have to upgrade distros just to get this fix. Any chance this can get into the next release for Hardy, or if someone could point me to a patch I could manually apply just for this? Reading through the comments above, I'm not entirely clear that I understand the root cause of the problem, or the nature of the fix in Jaunty. There is some mention of "hal" as well as a few other components. A clear pointer to the problem and the fix would be greatly appreciated.

Thanks, and please let me know if there is other information I can provide about my hardware that would be of use.

since upgrade to kernel 2.6.28-14 yesterday and 2.6.28-15 today (ubuntu 9.04), the wlan switch again does not work anymore - despite the linux-restricted-modules-xxx are installed. (it worked with 2.6.28-13)

from /var/log/messages:
XXX kernel: [ 752.989043] iwl3945: Radio Frequency Kill Switch is On:
XXX kernel: [ 752.989046] Kill switch must be turned off for wireless networking to work.

This bug is still present on Karmic alpha 6 on my Sony Vaio SZ650 (Intel 4965 / iwlagn). If I shut down (or suspend, I think) with an enabled killswitch, then boot (or resume), I cannot get my wifi to work until I reboot with the killswitch disabled. The killswitch works properly if I use it within a session. Since this is such an old bug, I am posting here, though can make a new bug if someone thinks each case has to be handled separately.

After upgrade from 9.04 (2.6.28-16) to 9.10 (2.6.31.14) I have same problem.
When wlan switch is off before booting I am able to activate wlan successfully inside a session. But if I boot with enabled wlan switch - wlan will not work and I can not disable/enable wlan settings
Dell Vostro 1520

The same problem is on SONY VAIO VGN-SZ7 after upgrade from 9.04 (2.6.28-16) to 9.10 (2.6.31.14).

2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks

I can reactivate the wlan with the following command
>sudo modprobe dell_laptop
>sudo rmmod dell_laptop

the problem still affects me on an Acer Travelmate 292,
9.10 (2.6.31-17)
02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)

Linux 2.6.32-13-generic #18-Ubuntu SMP Fri Feb 12 11:03:56 UTC 2010 x86_64 GNU/Linux, this bug affects me to, and the solution does not work.

This bug is similar https://bugs.launchpad.net/ubuntu/+source/linux/+bug/365321

06:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)

This bug affects me on a Dell Latitude D830 on karmic with a 4965 AGN card. Uname output:
Linux 2.6.32-22-generic #60-Ubuntu SMP Thu May 27 02:41:03 UTC 2010 x86_64 GNU/Linux.