After returning from suspend to disk, RF devices (wlan and bluetooth) are disabled. Running lspci indicates that no wireless network device is available, and no drivers are loaded. Furthermore, the LED on the front of the laptop remains off - this is always on when RF devices are available. There is an Fn-F1 function key to toggle wireless, but this does not function to either enable or disable.

Rebooting the system does not re-enable the RF devices, and there is no option in the BIOS. The only workaround I have at present is to boot into windows vista and use the Fn-F1 function key. This pops up a small hotkey utility with the option to disable/enable the wi-fi and bluetooth (independently). Upon confirming the dialog, the RF device light immediately illuminates. Rebooting into fedora and wireless devices are working once again.

I am running kernel 2.6.31.12-174.2.3.fc12.x86_64, with the latest compat-wireless drivers. I can provide much more debug information (dmidecode, acpidump, boot logs, lspci etc...), I am just unable to determine what is relevant

# rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no

There is no hardware RF switch on this laptop. Applying the software RF block (rfkill block all) does disable the wireless devices, however the LED remains lit and upon rebooting these are re enabled. There there appears to be some other RF kill mechanism that is being enabled during suspend to disk and that is causing my issue.

The hardware is a Novatech laptop, model X65- a rebranded FIC PMN70D - http://www.fic.com.tw/product/pmn70d.aspx

# lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev07)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation Device 0652 (rev a1)
04:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCIExpress) (rev 01)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

Suspend is triggered by a suspend script - events in /etc/acpi/events usually run scripts in /etc/acpi. If it heppens when you type run suspend manually, it's a bios thing. Try 'sync; echo -n mem > /sys/power/state'

In that case, why not hibernate? I have a lidbutton script which simply hibernates the box, and you can reboot later. One thing to watch for here is you may come up with the same ip as another box on the net. Configure your router to get around that.

Thanks for your reply.

Firstly my problem relates to hibernation (suspend to disk). Suspend (suspend to ram) works OK either through the gnome system>shutdown>suspend or using the command you suggested.

Secondly, if I run the command 'sync; echo -n disk > /sys/power/state' then the problem still occurs.


As I said, during the hibernation process something is disabling the the RF devices, there must be a specific command being called? How can I debug this and find out what it is.

I know it can be enabled in vista via a small application which is installed from the driver disk and pops up upon pressing Fn-F1 - so it should be possible to emulate this in linux

It's not in the linux bit, because, as I pointed out I can come up with the same IP as another box. So it's in the bios. I wish you well debugging that.You can try for an update, or check the settings and change anything that might even go close in the power menu.

Thanks again, but I think you misunderstand my problem.

On returning from hibernation the RF devices (WiFi and Bluetooth) are non-existent. Running lspci and the wireless card will no longer be there. Running lsusb and the bluetooth card will be missing.

The problem is not related to IP settings or configuration - it is at a much more fundamental level than that.

Read, young man. There's about 6 ways to turn them off, the bios and 'fast ethernet switching' being a principal one. This fast ethernet switching means if your nic is in use, bios will disable wifi.

OK, I'll try and narrow down the issue

Here is what I know

1) Issue persistent across reboots of fedora
2) Issue persistent across reboots of other OS's e.g. Vista, Ubuntu
3) Issues causes both bluetooth and wifi devices to be disabled
4) While I don't know the exact mechanism of how the RF devices are being disabled (kernel instructing the BIOS is my theory at present), I know the mechanism of how they are re-enabled - through a very small app in vista which pops up upon pressing Fn-F1
5) Same symptoms in fedora/vista - no RF devices show up in the device manager while the RF LED is off. Upon enabling they appear in vista
6) There is no hard rfkill switch, and the soft kill switch is n/a


So that would lead me to believe it is a feature of the BIOS.


On a related note, I have managed to trap the Fn-F1 keypress in linux - the button that should enable/disable RF devices, and assign it to XF86WLAN, using the command

# setkeycodes 63 238

Narrowed that down from the kernel messages

kernel: atkbd.c: Unknown key released (translated set 2, code 0x63 on isa0060/serio0).
kernel: atkbd.c: Use 'setkeycodes 63 <keycode>' to make it known.

If you have fedora, can network manager not do the business for you in gnome?

Network manager does not help with this issue. Compare the following lspci output (which is showing what devices are present after the hibernation) to the one I originally posted. The actual hardware (Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter) is not detected, therefore Network Manager is not applicable.

# lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation Device 0652 (rev a1)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

Same here for the internal usb bluetooth. First listing is during normal operation. Second shows after hiberation.

# lsusb
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

# lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Have you checked for a BIOS update? I can't finger anything except the BIOS.
My laptop has a switch for wifi/bluetooth, and I leave it permanently on, because madness starts if I don't. Afaik, the bios provides a dsdt file which is stored in /proc and implements the various calls on the particular hardware in that box. This dsdt file is unique to your box. Before you start messing, grab a copy of it, and your entire bios. Then, if you absolutely can't live with this, and are prepared to go it alone, follow this link and start reading
http://www.lesswatts.org/projects/ac...ridingDSDT.php