Bug 14098 - dell_laptop rfkill incorrectly reports state '2' (Vostro 1320)
Summary: dell_laptop rfkill incorrectly reports state '2' (Vostro 1320)
Alias: None
Product: Other
Classification: Unclassified
Component: Modules (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: other_modules
Depends on:
Reported: 2009-08-31 12:15 UTC by Sam Morris
Modified: 2013-12-10 16:48 UTC (History)
8 users (show)

See Also:
Kernel Version:
Regression: No
Bisected commit-id:


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
In contrast states in
seem always be ok.

Note You need to log in before you can comment on or make changes to this bug.