|Summary:||dell_laptop rfkill incorrectly reports state '2' (Vostro 1320)|
|Product:||Other||Reporter:||Sam Morris (sam)|
|Severity:||normal||CC:||alan, benjury, blessedbyvirtuosity, debfx-kernel, felash, kernel-bugzilla, raphoun, squan|
Description Sam Morris 2009-08-31 12:15:57 UTC
The rfkill device provided by the dell_laptop module incorrectly reports state '2' on a Dell Vostro 1320. This breaks NetworkManager which uses this information to disable parts of its UI that allow the user to scan for and connect to networks.
Comment 1 Felix Geyer 2009-09-10 16:42:24 UTC
An update of the BIOS to A03 solves the issue.
Comment 2 Sam Morris 2009-09-10 22:46:58 UTC
Is it possible to upgrade the BIOS without Windows? I had a go with the libsmbios tools but couldn't get them to recognise the new firmware image.
Comment 3 Felix Geyer 2009-09-10 22:59:19 UTC
I spent (too) much time trying to update it without installing Windows. Afaik the Vostro series doesn't support updating the BIOS though libsmbios. However they provide a DOS executable, which I tried to run on freedos but didn't work because it hung while analyzing the system. So in the end I backed up my Linux partition, installed Windows to update the BIOS and restored the Linux partition.
Comment 4 Sam Morris 2009-09-10 23:06:04 UTC
Ugh. Unfortunately I don't want to spend £70 for a Windows license just to update the BIOs... :(
Comment 5 Felix Geyer 2009-09-16 07:55:34 UTC
Initally I thought the bios update fixed the issue for me, but whenever I boot my laptop while the hardware killswitch (phy0) is set to blocked, wireless lan is disabled. The only way to fix this is to un-block the hardware killswitch and reload the kernel module. After that everything works fine. So if the killswitch phy0 is set to hard blocked while the kernel module dell_laptop is loaded, the killswitch dell-wifi is permanently set to hard and soft blocked and thus disabling wireless network in NetworkManager.
Comment 6 Raphaël GERMON 2009-09-25 09:28:33 UTC
This bug occurs with a dell XPS M1530 too. Is there a workaround to fix it?
Comment 7 Felix Geyer 2009-09-25 10:04:27 UTC
Add "blacklist dell_laptop" to your modprobe config (e.g. on Ubuntu /etc/modprobe.d/blacklist.conf).
Comment 8 Julien Wajsberg 2009-12-24 15:15:27 UTC
I confirm that either blacklisting dell_laptop (what brings this module anyway ?) or updating the BIOS (got it without Windows) to the last version (and enabling back dell_laptop) made network-manager work again.
Comment 9 Mike Williamson 2010-01-11 03:54:45 UTC
Just ran into this with an update to Ubuntu Karmic. Also a Dell XPS m1530. I am already running BIOS A12 which according to Dell is the highest available for the m1530. Felix's instructions (comment #7) to blacklist dell_laptop worked for me.
Comment 10 Ben Jury 2010-01-17 12:47:30 UTC
Had the same problem with my Dell XPS M1330. Blacklisting dell_laptop also worked.
Comment 11 Ryan Hayle 2010-01-20 06:38:19 UTC
I am getting this on my M1530 also, but I wonder if it isn't a slightly different issue. It seems to detect the switch reliably, it's just that the values are reversed. When I switch it off, rfkill list shows it as unblocked, and when I switch it back on, it shows it as blocked. So I wonder if this isn't actually a simple problem with this particular model in the dell_laptop driver?
Comment 12 Stefan 2010-07-31 04:34:25 UTC
Same problem with dell latitude X300 with "PRO/Wireless LAN 2100 3B Mini PCI Adapter" running 2.6.34 (openSUSE-11.3, module drivers/platform/x86/dell-laptop.ko not loaded (don't know why). After boot rfkill (from package 'rfkill') command reports 0: phy0: Wireless LAN Soft blocked: no Hard blocked: yes and after activating the adapter with FN F2 it reverses: 0: phy0: Wireless LAN Soft blocked: yes Hard blocked: no and that's wrong. After doing rfkill 0 unblock radio state confusion is fixed and interface is able to associate and connect. rfkill (and connection) state also persist on suspend/resume (to RAM) cycles. It looks like rfkill gets its information from /dev/rfkill and /sys/class/rfkill/rfkill0/name In contrast states in /sys/bus/pci/drivers/ipw2100/0000\:02\:04.0/rf_kill seem always be ok.