Bug 830833 - Atheros wireless not working on Asus EEEPC after fresh Fedora 17 install
Atheros wireless not working on Asus EEEPC after fresh Fedora 17 install
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
i686 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-11 09:41 EDT by Frank
Modified: 2013-01-21 05:33 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-02 08:17:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frank 2012-06-11 09:41:40 EDT
Description of problem:
I did a fresh install of F17 on an Asus EEEPC, and wireless is gone. Wireless is not showing up in NetworkManager, no ath9k module present in lsmod.


Version-Release number of selected component (if applicable):
kernel 3.4.0-1.fc17.i686 

lspci:
03:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)


How reproducible:
always

Steps to Reproduce:
1. turn on computer
2.
3.
  
Actual results: no wireless

Expected results:
wireless card and available networks should show up in NetworkManager 


Additional info:
Comment 1 John W. Linville 2012-06-11 10:53:09 EDT
FWIW, that 03:00.0 PCI device is an ethernet device, not a wireless one.

Can we see the entire output of 'lspci -n' please?
Comment 2 Frank 2012-06-11 11:04:15 EDT
lspci -n

00:00.0 0600: 8086:27ac (rev 03)
00:02.0 0300: 8086:27ae (rev 03)
00:02.1 0380: 8086:27a6 (rev 03)
00:1b.0 0403: 8086:27d8 (rev 02)
00:1c.0 0604: 8086:27d0 (rev 02)
00:1c.1 0604: 8086:27d2 (rev 02)
00:1c.3 0604: 8086:27d6 (rev 02)
00:1d.0 0c03: 8086:27c8 (rev 02)
00:1d.1 0c03: 8086:27c9 (rev 02)
00:1d.2 0c03: 8086:27ca (rev 02)
00:1d.3 0c03: 8086:27cb (rev 02)
00:1d.7 0c03: 8086:27cc (rev 02)
00:1e.0 0604: 8086:2448 (rev e2)
00:1f.0 0601: 8086:27b9 (rev 02)
00:1f.2 0101: 8086:27c4 (rev 02)
03:00.0 0200: 1969:1026 (rev b0)
Comment 3 John W. Linville 2012-06-11 11:13:28 EDT
Well, I can see why there was some confusion -- there is no wireless device listed there at all!  Please check your BIOS settings -- it is possible/likely that your wireless device has somehow been disabled there.  Also, some implementations of "rfkill" buttons physically unplug a device from the bus, so please also ensure that you have the rfkill switch set to enable wireless.
Comment 4 Frank 2012-06-12 02:38:49 EDT
Ok, my bad. Wirlesse was turned off in BIOS, and so was bluetooth. However, I don't know how this happened. It was definitely working when F16 was running. After the boot from USB and installation of F17, it was turned off in BIOS. I wonder if the change of boot device order and/or USB-boot does affect these settings.

Anyway, thanks for pointing me into the right direction
Comment 5 Frank 2012-06-12 09:32:38 EDT
Obviously, on my EEE PC, when turning wireless off by clicking the off-switch in the wireless symbol on the desktop, wireless becomes permanently disabled in BIOS. This explains why I can't switch it back on - there is no wireless option any more. The only solution I found is to reboot and turn it back on manually in the BIOS. Same goes for Bluetooth.
It seems I'm not the only one with an eee pc to observe this:
http://forums.fedoraforum.org/showthread.php?t=279000

So maybe after all, this is a bug?
Comment 6 John W. Linville 2012-06-12 09:57:19 EDT
Does sound problematic...just to narrow things down, let's try to replicate this with the rfkill tool.

Use 'rfkill list' to get a list of rfkill devices.  What is that output?

If you then do 'rfkill block all', do you still get the "disabled in BIOS" issue?
Comment 7 Frank 2012-06-12 12:36:08 EDT
I can switch it on and off with rfkill block/unblock without problems.

rfkill list:
0: eeepc-wlan: Wireless LAN
	Soft blocked: no
	Hard blocked: no
1: eeepc-bluetooth: Bluetooth
	Soft blocked: no
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
3: eeepc-wwan3g: Wireless WAN
	Soft blocked: no
	Hard blocked: no
4: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

rfkill block all
0: eeepc-wlan: Wireless LAN
	Soft blocked: yes
	Hard blocked: no
1: eeepc-bluetooth: Bluetooth
	Soft blocked: yes
	Hard blocked: no
3: eeepc-wwan3g: Wireless WAN
	Soft blocked: yes
	Hard blocked: no

and a 'rfkill unblock all' restores the first output.

However, after 'rfkill block all' and a reboot into bios, both wireless and bluetooth *are* disabled (which, I assume, means 'hard blocked')
Comment 8 John W. Linville 2012-06-12 13:21:16 EDT
Well, not so much 'hard blocked' as 'unplugged', since lspci doesn't even show the devices.  I'm not sure where to go with this -- whatever the eeepc-wlan implementation is doing causes the BIOS to simply disable the device on a reboot, leaving no indication to the system that it should even load a wireless driver.

After you 'rfkill block all' and reboot (recreating the original conditions of this report), then does 'rfkill unblock all' bring the devices back to life?
Comment 9 Frank 2012-06-12 13:50:31 EDT
Yes, after reboot, 'rfkill list' gives the same output as after 'rfkill block all', and 'rfkill unblock all' brings wireless and bluetooth back to normal.
Comment 10 Justin M. Forbes 2012-12-07 10:06:12 EST
Is this still an issue with 3.6.9?
Comment 11 Frank 2013-01-21 05:33:07 EST
Still the same with 3.7.2-201.fc18.i686. But: bluetooth can be switched back on with a mouseclick.

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