Description of problem: Each time I resume my laptop from suspend I have to 'Turn On' WiFi again. Version-Release number of selected component (if applicable): NetworkManager-1.0.6-0.2.20150813git7e2caa2.fc23.x86_64 How reproducible: Every time Steps to Reproduce: 1. Suspend laptop 2. Resume from suspend 3. WiFi failes to connect to a local (known) network. Actual results: The WiFi is still 'Off' and you need to click in the top-right corner of Gnome, select WiFi and then select Turn On. Expected results: WiFi should automatically be turned on and just connect to a known network if available. Additional info: This is a regression. $ lspci 00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b) 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) 00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b) 00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04) 00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04) 00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 1 (rev e4) 00:1c.2 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 3 (rev e4) 00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04) 02:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b)
Please check that you Wi-Fi connection profile is setup to connect automatically. Either in gnome-control-center or using nmcli. $ nmcli connection select you profile $ nmcli con show <your profile name> | grep autoconnect
$ nmcli con show "Somewhere Else" | grep autoconnect connection.autoconnect: yes connection.autoconnect-priority: 0 connection.autoconnect-slaves: -1 (default) $ nmcli con show "Somewhere There" | grep autoconnect connection.autoconnect: yes connection.autoconnect-priority: 0 connection.autoconnect-slaves: -1 (default) $ nmcli con show "MRSS School" | grep autoconnect connection.autoconnect: yes connection.autoconnect-priority: 0 connection.autoconnect-slaves: -1 (default)
The problem isn't autoconnecting. Once WiFi is turned on the connection works properly, but the WiFi is "Off" after resume. See the attached screenshots of the gnome properties Network dialog before and after a suspend/resume cycle.
Created attachment 1067697 [details] Before suspending and resuming
Created attachment 1067699 [details] After suspending and resuming
Well, would you then grab NetworkManager logs over suspend/resume cycle? (journalctl -u NetworkManger) Also take output of 'nmcli radio' and 'rfkill list' before and after suspend.
Before suspend: $ nmcli radio WIFI-HW WIFI WWAN-HW WWAN enabled enabled enabled enabled $ rfkill list 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no 4: hci0: Bluetooth Soft blocked: no Hard blocked: no After resume: $ nmcli radio WIFI-HW WIFI WWAN-HW WWAN enabled disabled enabled enabled $ rfkill list 1: phy0: Wireless LAN Soft blocked: yes Hard blocked: no 6: hci0: Bluetooth Soft blocked: no Hard blocked: no Log file for "journalctl -u NetworkManger" NOTE: It's not as consistent as it was. These log files contain a suspend/resume cycle where the WIFI started properly, and then one where it didn't. Sep 14 10:13:53 moose NetworkManager[962]: <info> sleep requested (sleeping: no enabled: yes) Sep 14 10:13:53 moose NetworkManager[962]: <info> sleeping... Sep 14 10:13:53 moose NetworkManager[962]: <info> (wlp2s0): device state change: activated -> unmanaged Sep 14 10:13:53 moose NetworkManager[962]: <info> (wlp2s0): canceled DHCP transaction, DHCP client pid Sep 14 10:13:53 moose NetworkManager[962]: <info> (wlp2s0): DHCPv4 state changed bound -> done Sep 14 10:13:53 moose NetworkManager[962]: <info> NetworkManager state is now ASLEEP Sep 14 10:13:53 moose NetworkManager[962]: <warn> Failed to GDBus.Error:fi.w1.wpa_supplicant1.NotConnec Sep 14 10:14:02 moose NetworkManager[962]: <info> wake requested (sleeping: yes enabled: yes) Sep 14 10:14:02 moose NetworkManager[962]: <info> waking up... Sep 14 10:14:02 moose NetworkManager[962]: <info> (wlp2s0): device state change: unmanaged -> unavailab Sep 14 10:14:02 moose NetworkManager[962]: <info> NetworkManager state is now CONNECTED_LOCAL Sep 14 10:14:02 moose NetworkManager[962]: <info> connectivity: check for uri 'http://fedoraproject.org Sep 14 10:14:02 moose NetworkManager[962]: <info> (wlp2s0) supports 1 scan SSIDs Sep 14 10:14:02 moose NetworkManager[962]: <info> (wlp2s0): supplicant interface state: starting -> rea Sep 14 10:14:02 moose NetworkManager[962]: <info> (wlp2s0): device state change: unavailable -> disconn Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): supplicant interface state: ready -> inacti Sep 14 10:14:05 moose NetworkManager[962]: <info> Auto-activating connection 'Somewhere There'. Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): Activation: starting connection 'Somewhere Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): device state change: disconnected -> prepar Sep 14 10:14:05 moose NetworkManager[962]: <info> NetworkManager state is now CONNECTING Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): device state change: prepare -> config (rea Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): Activation: (wifi) access point 'Somewhere Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): device state change: config -> need-auth (r Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): device state change: need-auth -> prepare ( Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): device state change: prepare -> config (rea Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): Activation: (wifi) connection 'Somewhere Th Sep 14 10:14:05 moose NetworkManager[962]: <info> Config: added 'ssid' value 'Somewhere There' Sep 14 10:14:05 moose NetworkManager[962]: <info> Config: added 'scan_ssid' value '1' Sep 14 10:14:05 moose NetworkManager[962]: <info> Config: added 'key_mgmt' value 'WPA-PSK' Sep 14 10:14:05 moose NetworkManager[962]: <info> Config: added 'psk' value '<omitted>' Sep 14 10:14:05 moose NetworkManager[962]: <info> Config: added 'proto' value 'WPA RSN' Sep 14 10:14:05 moose NetworkManager[962]: <info> Config: set interface ap_scan to 1 Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): supplicant interface state: inactive -> ass Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): supplicant interface state: associating -> Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): supplicant interface state: 4-way handshake Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): Activation: (wifi) Stage 2 of 5 (Device Con Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): device state change: config -> ip-config (r Sep 14 10:14:05 moose NetworkManager[962]: <info> Activation (wlp2s0) Beginning DHCPv4 transaction (tim Sep 14 10:14:05 moose NetworkManager[962]: <info> dhclient started with pid 10768 Sep 14 10:14:05 moose dhclient[10768]: DHCPREQUEST on wlp2s0 to 255.255.255.255 port 67 (xid=0x132df714) Sep 14 10:14:05 moose dhclient[10768]: DHCPACK from 192.168.100.254 (xid=0x132df714) Sep 14 10:14:05 moose NetworkManager[962]: <info> address 192.168.100.100 Sep 14 10:14:05 moose NetworkManager[962]: <info> plen 24 (255.255.255.0) Sep 14 10:14:05 moose NetworkManager[962]: <info> gateway 192.168.100.1 Sep 14 10:14:05 moose NetworkManager[962]: <info> server identifier 192.168.100.254 Sep 14 10:14:05 moose NetworkManager[962]: <info> lease time 600 Sep 14 10:14:05 moose NetworkManager[962]: <info> hostname 'moose.home.clarkson.id.au' Sep 14 10:14:05 moose NetworkManager[962]: <info> nameserver '192.168.100.254' Sep 14 10:14:05 moose NetworkManager[962]: <info> domain name 'home.clarkson.id.au' Sep 14 10:14:05 moose NetworkManager[962]: <info> domain search 'home.clarkson.id.au.' Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): DHCPv4 state changed unknown -> bound Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): device state change: ip-config -> ip-check Sep 14 10:14:05 moose dhclient[10768]: bound to 192.168.100.100 -- renewal in 283 seconds. Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): device state change: ip-check -> secondarie Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): device state change: secondaries -> activat Sep 14 10:14:05 moose NetworkManager[962]: <info> NetworkManager state is now CONNECTED_LOCAL Sep 14 10:14:05 moose NetworkManager[962]: <info> NetworkManager state is now CONNECTED_SITE Sep 14 10:14:05 moose NetworkManager[962]: <info> Policy set 'Somewhere There' (wlp2s0) as default for Sep 14 10:14:05 moose NetworkManager[962]: <info> (wlp2s0): Activation: successful, device activated. Sep 14 10:14:06 moose NetworkManager[962]: <info> NetworkManager state is now CONNECTED_GLOBAL Sep 14 10:14:34 moose NetworkManager[962]: <info> sleep requested (sleeping: no enabled: yes) Sep 14 10:14:34 moose NetworkManager[962]: <info> sleeping... Sep 14 10:14:34 moose NetworkManager[962]: <info> (wlp2s0): device state change: activated -> unmanaged Sep 14 10:14:34 moose NetworkManager[962]: <info> (wlp2s0): canceled DHCP transaction, DHCP client pid Sep 14 10:14:34 moose NetworkManager[962]: <info> (wlp2s0): DHCPv4 state changed bound -> done Sep 14 10:14:34 moose NetworkManager[962]: <info> NetworkManager state is now ASLEEP Sep 14 10:14:34 moose NetworkManager[962]: <warn> Failed to GDBus.Error:fi.w1.wpa_supplicant1.NotConnec Sep 14 10:14:43 moose NetworkManager[962]: <info> WiFi now disabled by radio killswitch Sep 14 10:14:43 moose NetworkManager[962]: <info> wake requested (sleeping: yes enabled: yes) Sep 14 10:14:43 moose NetworkManager[962]: <info> waking up... Sep 14 10:14:43 moose NetworkManager[962]: <info> (wlp2s0): device state change: unmanaged -> unavailab Sep 14 10:14:43 moose NetworkManager[962]: <info> NetworkManager state is now CONNECTED_LOCAL Sep 14 10:14:43 moose NetworkManager[962]: <info> connectivity: check for uri 'http://fedoraproject.org
Created attachment 1087602 [details] Output from "journalctl -u NetworkManager" Output from "journalctl -u NetworkManager" after a suspend/resume cycle. May contain old log data.
I'm experiencing this very same issue on fedora 23 (4.2.3-300.fc23.x86_64), using a dualband Intel Corporation Wireless 7265. These are the requested info: $ nmcli con show "droid 2.0" | grep autoconnect connection.autoconnect: yes connection.autoconnect-priority: 0 connection.autoconnect-slaves: -1 (default) $ nmcli radio #BEFORE RESUME HW-WIFI WIFI HW-WWAN WWAN habilitado habilitado habilitado habilitado $ rfkill list #BEFORE RESUME 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no $ nmcli radio #AFTER RESUME HW-WIFI WIFI HW-WWAN WWAN habilitado desabilitado habilitado habilitado $ rfkill list #AFTER RESUME 1: phy0: Wireless LAN Soft blocked: yes Hard blocked: no 2: hci0: Bluetooth Soft blocked: no Hard blocked: no $ lspci 00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09) 00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09) 00:04.0 Signal processing controller: Intel Corporation Broadwell-U Camarillo Device (rev 09) 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03) 00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03) 00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3) 00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03) 00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03) 00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03) 00:1f.6 Signal processing controller: Intel Corporation Wildcat Point-LP Thermal Management Controller (rev 03) 01:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59) $ journalctl -u NetworkManager << PLEASE SEE THE ATTACHED FILE (Output from "journalctl -u NetworkManager") >>
I've noticed after a "resume and turn manually wifi on", everything works fine if the computer suspend/resume an arbitrary number of times (I've tested it with 3 suspend/resume cycles). But if I reboot the system and suspend/resume again, wifi will not turn on automatically, as reported on this bug.
The rfkill outputs show that after resume the device is soft blocked. Let's see if it unblocks on resume again. 1. enable debug logging in NM $ sudo nmcli gen log level debug 2. in a second terminal run $ udevadm monitor 3. suspend/resume computer 4. restore original NM log level $ sudo nmcli gen log level info 5. attach NM logs and the output of the udevadm command There could be an issue with platform driver. What laptop is it again?
Hello, I've done those steps, the outputs are attached. These were the steps I've done: 1. Turn on computer; 2. enabled debug log level, as described above; 3. suspend/resume computer 4. attached the logs to this message. Do you want me to do an aditional step 3? (two suspend/resume cycles in a row). The exact model of my computer is Dell Inspiron 7348 (2-in-1 laptop). Thanks!
Created attachment 1087972 [details] journalctl -u NetworkManager (with debug level) A more verbose output for NetworkManager log.
Created attachment 1087973 [details] udevadm monitor output (for a suspend/resume cycle on lid close)
If NM changes the rfkill state, it will log the message "WiFi hardware radio set [dis]enabled". In the logs you attached, NM enables the rfkill switch a number of times, but never disables it. Instead, the logs show that something is changing the rfkill state while NetworkManager is asleep: <debug> [1446219870.901324] [nm-rfkill-manager.c:354] handle_uevent(): udev rfkill event: action 'change' device 'rfkill1' <debug> [1446219870.901960] [nm-rfkill-manager.c:210] recheck_killswitches(): WiFi rfkill switch rfkill1 state now 0/1 <debug> [1446219870.901983] [nm-rfkill-manager.c:237] recheck_killswitches(): WiFi rfkill state now 'soft-blocked' <debug> [1446219870.901997] [nm-manager.c:1355] manager_rfkill_update_one_type(): WiFi hw-enabled 1 sw-enabled 0 <info> WiFi now disabled by radio killswitch <debug> [1446219870.902111] [nm-rfkill-manager.c:354] handle_uevent(): udev rfkill event: action 'remove' device 'rfkill0' <debug> [1446219870.914974] [nm-rfkill-manager.c:210] recheck_killswitches(): WiFi rfkill switch rfkill1 state now 0/1 <debug> [1446219870.922485] [nm-sleep-monitor-systemd.c:139] signal_cb(): Received PrepareForSleep signal: 0 <debug> [1446219870.922515] [nm-sleep-monitor-systemd.c:109] take_inhibitor(): Taking systemd sleep inhibitor <debug> [1446219870.922590] [nm-manager.c:3817] resuming_cb(): Received resuming signal <info> wake requested (sleeping: yes enabled: yes) <info> waking up... <debug> [1446219870.923476] [nm-manager.c:1355] manager_rfkill_update_one_type(): WiFi hw-enabled 1 sw-enabled 0 <debug> [1446219870.927512] [nm-manager.c:1355] manager_rfkill_update_one_type(): WWAN hw-enabled 1 sw-enabled 1 <debug> [1446219870.932467] [nm-manager.c:1355] manager_rfkill_update_one_type(): WiMAX hw-enabled 1 sw-enabled 1 <debug> [1446219872.542940] [nm-manager.c:3677] do_sleep_wake(): disabling WiFi devices (hw_enabled 1, sw_enabled 0, user_enabled 1) <debug> [1446219872.562969] [nm-device-wifi.c:3112] set_enabled(): [0x5564e49a9bf0] (wlp1s0): device now disabled <debug> [1446219872.568755] [nm-device-wifi.c:3117] set_enabled(): [0x5564e49a9bf0] (wlp1s0): (disable): device blocked by UNMANAGED state <debug> [1446219872.568774] [nm-manager.c:3677] do_sleep_wake(): enabling WWAN devices (hw_enabled 1, sw_enabled 1, user_enabled 1) <debug> [1446219872.568782] [nm-manager.c:3677] do_sleep_wake(): enabling WiMAX devices (hw_enabled 1, sw_enabled 1, user_enabled 1) <debug> [1446219872.607485] [devices/nm-device.c:7547] nm_device_set_unmanaged(): [0x5564e49a9bf0] (wlp1s0): now managed <info> (wlp1s0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] I also notice that there's really only one rfkill driver on your system, and its name sometimes bounces around. Systemd has rfkill save/restore functionality, and there may well be stale value stored in /var/lib/systemd/rfkill/ for the name the kernel picks for the device on resume, so it gets disabled. Try this: 1) mv /usr/lib/systemd/systemd-rfkill / 2) try to reproduce the problem with a couple suspend/resume cycles 3) mv /systemd-rfkill /usr/lib/systemd/ if you don't have any problems after moving systemd-rfkill, then this bug should be moved to systemd.
Okay, I've followed those steps and wifi turned on only after the second suspend/resume cycle: 1. mv /usr/lib/systemd/systemd-rfkill / 2. suspend / resume (here, WIFI DID NOT BACK, as previously described); 3. suspend / resume (surprise, NOW WIFI ADAPTER WOKE UP! It just connected to default SSID as it should do); 4. mv /systemd-rfkill /usr/lib/systemd/ I've attached the log for NetworkManager for these steps in the hope it be useful. Also, I can't move this bug to systemd because I'm not the guy that filed it =)
Created attachment 1088121 [details] journalctl -u NetworkManager, for the steps on the comment #16 Logs for the steps on the comment #16: 1. mv /usr/lib/systemd/systemd-rfkill / 2. suspend / resume 3. suspend / resume 4. mv /systemd-rfkill /usr/lib/systemd/
*** Bug 1289631 has been marked as a duplicate of this bug. ***
The rfkill service was rewritten in systemd-227, i.e. the change is currently only in rawhide. Any chance one of the reporters could check how the system behaves with the new systemd from rawhide? I made a scratch build of the rawhide systemd in koji for F23: http://koji.fedoraproject.org/koji/taskinfo?taskID=12116636. This way it doesn't require newer versions of dependencies, and it should be relatively safe to upgrade just the packages from this build, but please don't do this on a production machine.
Hello, thanks for helping with this issue. Sure I can test it! but at the momment I can't download the x86_64 (my fedora cpu arch.) package because it's marked with a "build error". I'm not a experienced user, perhaps I'm missing some detail. I will try to download it again.
Yeah, that build failed. This one succeeded: http://koji.fedoraproject.org/koji/taskinfo?taskID=12116703.
I've tested these packages but it did not solve the problem. I had some SELinux warnings (iptables and systemd), so I've put it on permissive mode and rebooted the system. After reboot, I did a suspend/resume cycle, but wifi did not back from suspend. Please let me know if you need some extra information or system log.
I want to lob in and add that I am suffering from this issue also on my Dell Latitude E7450. The original "fresh" install of Fedora 23 did not exhibit this bug. Happy to provide any further information if required. $ lspci | grep -i wireless 02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59) $ rfkill list 0: dell-wifi: Wireless LAN Soft blocked: no Hard blocked: no 1: dell-bluetooth: Bluetooth Soft blocked: no Hard blocked: no 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no 9: hci0: Bluetooth Soft blocked: no Hard blocked: no suspend/resume $ rfkill list 0: dell-wifi: Wireless LAN Soft blocked: yes Hard blocked: no 1: dell-bluetooth: Bluetooth Soft blocked: yes Hard blocked: no 2: phy0: Wireless LAN Soft blocked: yes Hard blocked: yes 10: hci0: Bluetooth Soft blocked: no Hard blocked: no Key-press to toggle wifi: Dec 20 12:08:51 hawk.gns.cri.nz kernel: atkbd serio0: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0). Dec 20 12:08:51 hawk.gns.cri.nz kernel: atkbd serio0: Use 'setkeycodes e008 <keycode>' to make it known. Dec 20 12:08:51 hawk.gns.cri.nz kernel: iwlwifi 0000:02:00.0: RF_KILL bit toggled to enable radio. Dec 20 12:08:51 hawk.gns.cri.nz kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled Dec 20 12:08:51 hawk.gns.cri.nz kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled Dec 20 12:08:51 hawk.gns.cri.nz kernel: dell_wmi: Unknown key 153 pressed Dec 20 12:08:51 hawk.gns.cri.nz kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled Dec 20 12:08:51 hawk.gns.cri.nz kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled Dec 20 12:08:51 hawk.gns.cri.nz kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready $ rfkill list 0: dell-wifi: Wireless LAN Soft blocked: no Hard blocked: no 1: dell-bluetooth: Bluetooth Soft blocked: no Hard blocked: no 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no 10: hci0: Bluetooth Soft blocked: no Hard blocked: no
And FWIW, this is on systemd-228-6.gite35a787.fc24.x86_64
There's clearly something getting toggled here, when it shouldn't... If I suspend/resume everything's blocked, but then another suspend/resume cycle unblocks everything! $ rfkill list 0: dell-wifi: Wireless LAN Soft blocked: no Hard blocked: no 1: dell-bluetooth: Bluetooth Soft blocked: no Hard blocked: no 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no 9: hci0: Bluetooth Soft blocked: no Hard blocked: no $ systemctl suspend $ rfkill list 0: dell-wifi: Wireless LAN Soft blocked: yes Hard blocked: no 1: dell-bluetooth: Bluetooth Soft blocked: yes Hard blocked: no 2: phy0: Wireless LAN Soft blocked: yes Hard blocked: yes 10: hci0: Bluetooth Soft blocked: yes Hard blocked: no $ systemctl suspend $ rfkill list 0: dell-wifi: Wireless LAN Soft blocked: no Hard blocked: no 1: dell-bluetooth: Bluetooth Soft blocked: no Hard blocked: no 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no 11: hci0: Bluetooth Soft blocked: yes Hard blocked: no Dec 20 20:44:34 hawk kernel: wlp2s0: deauthenticating from 00:60:64:ec:1e:bb by local choice (Reason: 3=DEAUTH_LEAVING) Dec 20 20:44:36 hawk kernel: PM: Syncing filesystems ... done. Dec 20 20:44:36 hawk kernel: PM: Preparing system for sleep (mem) Dec 20 20:44:40 hawk kernel: Freezing user space processes ... (elapsed 0.002 seconds) done. Dec 20 20:44:40 hawk kernel: Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done. Dec 20 20:44:40 hawk kernel: PM: Suspending system (mem) Dec 20 20:44:40 hawk kernel: Suspending console(s) (use no_console_suspend to debug) Dec 20 20:44:40 hawk kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache Dec 20 20:44:40 hawk kernel: sd 1:0:0:0: [sda] Stopping disk Dec 20 20:44:40 hawk kernel: e1000e: EEE TX LPI TIMER: 00000011 Dec 20 20:44:40 hawk kernel: PM: suspend of devices complete after 180.756 msecs Dec 20 20:44:40 hawk kernel: PM: late suspend of devices complete after 17.023 msecs Dec 20 20:44:40 hawk kernel: ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI Dec 20 20:44:40 hawk kernel: e1000e 0000:00:19.0: System wakeup enabled by ACPI Dec 20 20:44:40 hawk kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI Dec 20 20:44:40 hawk kernel: PM: noirq suspend of devices complete after 87.925 msecs Dec 20 20:44:40 hawk kernel: ACPI: Preparing to enter system sleep state S3 Dec 20 20:44:40 hawk kernel: ACPI : EC: EC stopped Dec 20 20:44:40 hawk kernel: PM: Saving platform NVS memory Dec 20 20:44:40 hawk kernel: Disabling non-boot CPUs ... Dec 20 20:44:40 hawk kernel: smpboot: CPU 1 is now offline Dec 20 20:44:40 hawk kernel: smpboot: CPU 2 is now offline Dec 20 20:44:40 hawk kernel: smpboot: CPU 3 is now offline Dec 20 20:44:40 hawk kernel: ACPI: Low-level resume complete Dec 20 20:44:40 hawk kernel: ACPI : EC: EC started Dec 20 20:44:40 hawk kernel: PM: Restoring platform NVS memory Dec 20 20:44:40 hawk kernel: Enabling non-boot CPUs ... Dec 20 20:44:40 hawk kernel: x86: Booting SMP configuration: Dec 20 20:44:40 hawk kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2 Dec 20 20:44:40 hawk kernel: cache: parent cpu1 should not be sleeping Dec 20 20:44:40 hawk kernel: CPU1 is up Dec 20 20:44:40 hawk kernel: smpboot: Booting Node 0 Processor 2 APIC 0x1 Dec 20 20:44:40 hawk kernel: cache: parent cpu2 should not be sleeping Dec 20 20:44:40 hawk kernel: CPU2 is up Dec 20 20:44:40 hawk kernel: smpboot: Booting Node 0 Processor 3 APIC 0x3 Dec 20 20:44:40 hawk kernel: cache: parent cpu3 should not be sleeping Dec 20 20:44:40 hawk kernel: CPU3 is up Dec 20 20:44:40 hawk kernel: ACPI: Waking up from system sleep state S3 Dec 20 20:44:40 hawk kernel: xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI Dec 20 20:44:40 hawk kernel: ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI Dec 20 20:44:40 hawk kernel: PM: noirq resume of devices complete after 101.955 msecs Dec 20 20:44:40 hawk kernel: PM: early resume of devices complete after 6.154 msecs Dec 20 20:44:40 hawk kernel: sd 1:0:0:0: [sda] Starting disk Dec 20 20:44:40 hawk kernel: e1000e 0000:00:19.0: System wakeup disabled by ACPI Dec 20 20:44:40 hawk kernel: rtc_cmos 00:01: System wakeup disabled by ACPI Dec 20 20:44:40 hawk kernel: usb 3-1.3: reset full-speed USB device number 3 using ehci-pci Dec 20 20:44:40 hawk kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Dec 20 20:44:40 hawk kernel: ata1: SATA link down (SStatus 0 SControl 300) Dec 20 20:44:40 hawk kernel: Bluetooth: hci0: turning off Intel device LED failed (-19) Dec 20 20:44:40 hawk kernel: ata2.00: configured for UDMA/133 Dec 20 20:44:40 hawk kernel: usb 3-1.6: reset high-speed USB device number 4 using ehci-pci Dec 20 20:44:40 hawk kernel: PM: resume of devices complete after 507.997 msecs Dec 20 20:44:40 hawk kernel: PM: Finishing wakeup. Dec 20 20:44:40 hawk kernel: Restarting tasks ... done. Dec 20 20:44:40 hawk kernel: pci_bus 0000:01: Allocating resources Dec 20 20:44:40 hawk kernel: pci_bus 0000:02: Allocating resources Dec 20 20:44:40 hawk kernel: pci_bus 0000:03: Allocating resources Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: Bluetooth: hci0: read Intel version: 370810011003110e00 Dec 20 20:44:40 hawk kernel: Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq Dec 20 20:44:40 hawk kernel: pci_bus 0000:01: Allocating resources Dec 20 20:44:40 hawk kernel: pci_bus 0000:02: Allocating resources Dec 20 20:44:40 hawk kernel: pci_bus 0000:03: Allocating resources Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: pci_bus 0000:01: Allocating resources Dec 20 20:44:40 hawk kernel: pci_bus 0000:02: Allocating resources Dec 20 20:44:40 hawk kernel: pci_bus 0000:03: Allocating resources Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:40 hawk kernel: acpi PNP0401:00: Already enumerated Dec 20 20:44:40 hawk kernel: acpi PNP0501:00: Still not present Dec 20 20:44:41 hawk kernel: e1000e: eno1 NIC Link is Down Dec 20 20:44:41 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready Dec 20 20:44:41 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready Dec 20 20:44:41 hawk kernel: Bluetooth: hci0: Intel Bluetooth firmware patch completed and activated Dec 20 20:44:41 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready Dec 20 20:44:55 hawk kernel: PM: Syncing filesystems ... done. Dec 20 20:44:55 hawk kernel: PM: Preparing system for sleep (mem) Dec 20 20:44:55 hawk kernel: Freezing user space processes ... (elapsed 0.002 seconds) done. Dec 20 20:44:55 hawk kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Dec 20 20:44:55 hawk kernel: PM: Suspending system (mem) Dec 20 20:44:55 hawk kernel: Suspending console(s) (use no_console_suspend to debug) Dec 20 20:44:55 hawk kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache Dec 20 20:44:55 hawk kernel: sd 1:0:0:0: [sda] Stopping disk Dec 20 20:44:55 hawk kernel: e1000e: EEE TX LPI TIMER: 00000011 Dec 20 20:44:55 hawk kernel: PM: suspend of devices complete after 75.960 msecs Dec 20 20:44:55 hawk kernel: PM: late suspend of devices complete after 16.685 msecs Dec 20 20:44:55 hawk kernel: ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI Dec 20 20:44:55 hawk kernel: e1000e 0000:00:19.0: System wakeup enabled by ACPI Dec 20 20:44:55 hawk kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI Dec 20 20:44:55 hawk kernel: PM: noirq suspend of devices complete after 80.935 msecs Dec 20 20:44:55 hawk kernel: ACPI: Preparing to enter system sleep state S3 Dec 20 20:44:55 hawk kernel: ACPI : EC: EC stopped Dec 20 20:44:55 hawk kernel: PM: Saving platform NVS memory Dec 20 20:44:55 hawk kernel: Disabling non-boot CPUs ... Dec 20 20:44:55 hawk kernel: smpboot: CPU 1 is now offline Dec 20 20:44:55 hawk kernel: smpboot: CPU 2 is now offline Dec 20 20:44:55 hawk kernel: smpboot: CPU 3 is now offline Dec 20 20:44:55 hawk kernel: ACPI: Low-level resume complete Dec 20 20:44:55 hawk kernel: ACPI : EC: EC started Dec 20 20:44:55 hawk kernel: PM: Restoring platform NVS memory Dec 20 20:44:55 hawk kernel: Enabling non-boot CPUs ... Dec 20 20:44:55 hawk kernel: x86: Booting SMP configuration: Dec 20 20:44:55 hawk kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2 Dec 20 20:44:55 hawk kernel: cache: parent cpu1 should not be sleeping Dec 20 20:44:55 hawk kernel: CPU1 is up Dec 20 20:44:55 hawk kernel: smpboot: Booting Node 0 Processor 2 APIC 0x1 Dec 20 20:44:55 hawk kernel: cache: parent cpu2 should not be sleeping Dec 20 20:44:55 hawk kernel: CPU2 is up Dec 20 20:44:55 hawk kernel: smpboot: Booting Node 0 Processor 3 APIC 0x3 Dec 20 20:44:55 hawk kernel: cache: parent cpu3 should not be sleeping Dec 20 20:44:55 hawk kernel: CPU3 is up Dec 20 20:44:55 hawk kernel: ACPI: Waking up from system sleep state S3 Dec 20 20:44:55 hawk kernel: xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI Dec 20 20:44:55 hawk kernel: ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI Dec 20 20:44:55 hawk kernel: PM: noirq resume of devices complete after 105.065 msecs Dec 20 20:44:55 hawk kernel: PM: early resume of devices complete after 7.489 msecs Dec 20 20:44:55 hawk kernel: sd 1:0:0:0: [sda] Starting disk Dec 20 20:44:55 hawk kernel: iwlwifi 0000:02:00.0: RF_KILL bit toggled to enable radio. Dec 20 20:44:55 hawk kernel: e1000e 0000:00:19.0: System wakeup disabled by ACPI Dec 20 20:44:55 hawk kernel: rtc_cmos 00:01: System wakeup disabled by ACPI Dec 20 20:44:55 hawk kernel: usb 3-1.6: reset high-speed USB device number 4 using ehci-pci Dec 20 20:44:55 hawk kernel: ata1: SATA link down (SStatus 0 SControl 300) Dec 20 20:44:55 hawk kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Dec 20 20:44:55 hawk kernel: ata2.00: configured for UDMA/133 Dec 20 20:44:55 hawk kernel: usb 3-1.3: reset full-speed USB device number 3 using ehci-pci Dec 20 20:44:55 hawk kernel: PM: resume of devices complete after 527.055 msecs Dec 20 20:44:55 hawk kernel: PM: Finishing wakeup. Dec 20 20:44:55 hawk kernel: Restarting tasks ... done. Dec 20 20:44:55 hawk kernel: Bluetooth: hci0: read Intel version: 370810011003110e00 Dec 20 20:44:55 hawk kernel: Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq Dec 20 20:44:55 hawk kernel: pci_bus 0000:01: Allocating resources Dec 20 20:44:55 hawk kernel: pci_bus 0000:02: Allocating resources Dec 20 20:44:55 hawk kernel: pci_bus 0000:03: Allocating resources Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: pci_bus 0000:01: Allocating resources Dec 20 20:44:55 hawk kernel: pci_bus 0000:02: Allocating resources Dec 20 20:44:55 hawk kernel: pci_bus 0000:03: Allocating resources Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: pci_bus 0000:01: Allocating resources Dec 20 20:44:55 hawk kernel: pci_bus 0000:02: Allocating resources Dec 20 20:44:55 hawk kernel: pci_bus 0000:03: Allocating resources Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Dec 20 20:44:55 hawk kernel: acpi PNP0401:00: Already enumerated Dec 20 20:44:55 hawk kernel: acpi PNP0501:00: Still not present Dec 20 20:44:55 hawk kernel: e1000e: eno1 NIC Link is Down Dec 20 20:44:55 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready Dec 20 20:44:55 hawk kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled Dec 20 20:44:55 hawk kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled Dec 20 20:44:56 hawk kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled Dec 20 20:44:56 hawk kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled Dec 20 20:44:56 hawk kernel: Bluetooth: hci0: Intel Bluetooth firmware patch completed and activated Dec 20 20:44:56 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready Dec 20 20:44:56 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready Dec 20 20:44:56 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready Dec 20 20:44:56 hawk kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready Dec 20 20:44:59 hawk kernel: wlp2s0: authenticate with 00:60:64:ec:1e:bb Dec 20 20:44:59 hawk kernel: wlp2s0: send auth to 00:60:64:ec:1e:bb (try 1/3) Dec 20 20:44:59 hawk kernel: wlp2s0: authenticated Dec 20 20:44:59 hawk kernel: wlp2s0: associate with 00:60:64:ec:1e:bb (try 1/3) Dec 20 20:44:59 hawk kernel: wlp2s0: RX AssocResp from 00:60:64:ec:1e:bb (capab=0x431 status=0 aid=9) Dec 20 20:44:59 hawk kernel: wlp2s0: associated Dec 20 20:44:59 hawk kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
Also affects Dell XPS13 9333 with same network card as original poster. Can provide additional details if useful.
I'm experiencing that problem with Fedora 23 (all up to date with updates-testing) and LXQt desktop. After resuming from suspend, right-clicking on NetworkManager shows that "Enable Wi-Fi" is unchecked. I tried adding a USB Wi-Fi device in addition to the internal card, and both are shows as "Soft blocked: yes". Bluetooth is not soft blocked. The problem also existed on the same system with Fedora 22 and LXDE.
Workaround this bug: $ cat /etc/systemd/system/rfkill.service [Unit] Description=Unlock my wifi After=suspend.target [Service] ExecStart=/usr/sbin/rfkill unblock 1 [Install] WantedBy=suspend.target # systemctl enable rfkill
I am experiencing the same issues on a Dell XPS 15 (9530) with an Intel Wireless-AC 7260 wireless card on Fedora 23 with the latest available NetworkManager (1.0.10-3.fc23) and systemd (222-14.fc23). I can confirm the findings already reported by other users: Before resume: $ rfkill list 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no 15: nfc0: NFC Soft blocked: no Hard blocked: no 16: hci0: Bluetooth Soft blocked: no Hard blocked: no After resume: $ rfkill list 2: phy0: Wireless LAN Soft blocked: yes Hard blocked: no 15: nfc0: NFC Soft blocked: no Hard blocked: no 16: hci0: Bluetooth Soft blocked: no Hard blocked: no These is my journalctl --unit Networkmanager output: 13:08:23 NetworkManager[14269]: <info> sleep requested (sleeping: no enabled: yes) 13:08:23 NetworkManager[14269]: <info> sleeping... 13:08:23 NetworkManager[14269]: <info> (wlp6s0): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37] 13:08:23 NetworkManager[14269]: <info> (wlp6s0): canceled DHCP transaction, DHCP client pid 19803 13:08:23 NetworkManager[14269]: <info> (wlp6s0): DHCPv4 state changed bound -> done 13:08:23 NetworkManager[14269]: <info> (wlp6s0): canceled DHCP transaction, DHCP client pid 19893 13:08:23 NetworkManager[14269]: <info> (wlp6s0): DHCPv6 state changed unknown -> done 13:08:23 NetworkManager[14269]: <info> NetworkManager state is now ASLEEP 13:08:23 NetworkManager[14269]: <warn> Failed to GDBus.Error:fi.w1.wpa_supplicant1.NotConnected: This interface is not connected: disconnect. 13:08:35 NetworkManager[14269]: <info> WiFi now disabled by radio killswitch 13:08:35 NetworkManager[14269]: <info> wake requested (sleeping: yes enabled: yes) 13:08:35 NetworkManager[14269]: <info> waking up... 13:08:35 NetworkManager[14269]: <info> (wlp6s0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] 13:08:35 NetworkManager[14269]: <info> NetworkManager state is now CONNECTED_LOCAL Regarding the workaround by Cedric Bellegarde: My `phy0: Wireless LAN` has another id number (2 instead of 1), so I would suggest using `/usr/sbin/rfkill unblock wlan`, as suggested by the rfkill help: --- list [IDENTIFIER] block IDENTIFIER unblock IDENTIFIER where IDENTIFIER is the index no. of an rfkill switch or one of: <idx> all wifi wlan bluetooth uwb ultrawideband wimax wwan gps fm nfc ---
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Hi Running FC23 (4.4.6-301.fc23.x86_64) here - dell latitude e5550 02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59) after suspend this still happens: [andreas@anakin ~]$ rfkill list 0: dell-wifi: Wireless LAN Soft blocked: yes Hard blocked: no 1: dell-bluetooth: Bluetooth Soft blocked: yes Hard blocked: no 3: phy0: Wireless LAN Soft blocked: yes Hard blocked: yes 8: hci0: Bluetooth Soft blocked: no Hard blocked: no [andreas@anakin ~]$ so I have to manually unblock to make it work again: (either rfkill or network manager > "turn on") Apr 13 09:15:30 anakin kernel: iwlwifi 0000:02:00.0: RF_KILL bit toggled to enable radio. Apr 13 09:15:38 anakin NetworkManager[1404]: <info> WiFi now enabled by radio killswitch Apr 13 09:15:38 anakin kernel: iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled BUT: browsing journalcrt I came across this: Apr 12 07:01:16 anakin systemd[1]: Started Unlock my wifi. Apr 12 07:01:16 anakin systemd[1]: Starting Unlock my wifi... Apr 12 07:01:16 anakin systemd[1]: Started Unlock my wifi. Apr 12 07:01:16 anakin systemd[1]: Starting Unlock my wifi... Apr 12 07:01:16 anakin systemd[1]: Started Unlock my wifi. Apr 12 07:01:16 anakin systemd[1]: Starting Unlock my wifi... is someone busy with this? Can I help?
It's a kernel issue. Just happened on ArchLinux while switching from linux-lts-4.1.21 to linux-lts-4.4.7
The bug is still present in Fedora 24. systemd-229-7.fc24.x86_64 kernel-4.5.2-300.fc24.x86_64 Dell Latitude E5450 iwlwifi 0000:02:00.0: loaded firmware version 16.242414.0 op_mode iwlmvm iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 7265, REV=0x210 Why is this bug in POST? Was it fixed somewhere? Is the bug tracked upstream?
This happens for me as well Dell Precision 7510, Fedora 24
I'm seeing this behavior on a Dell e7450 as well.
Same thing on Dell XPS 13 (9333) with AC7260 Intel wireless chip. I think I see a pattern here: except for the first two reporters who didn't mention their laptop manufacturers, only dell laptops with AC726x chips seem to have this issue. It's likely that it's a bug in the platform driver for this hardware rather than in systemd.
I did not mention the model of my laptop in my comment, but it's indeed Dell P57G. I tried suspend and resume with up-to-date packages from update-testing. The problem still exists. dmesg shows some ACPI problems, but no problems with the wireless driver. That's what would be expected if the problem is manufacturer related.
Created attachment 1157794 [details] kernel log on Dell P57G
Created attachment 1157795 [details] lspci on Dell P57G
I happens to me as well. It is fresh installation of Fedora 24, kernel 4.6.4. HW is Lenovo C440. There was no problem on earlier F23 installation (although I do not know which kernel I was using). Problem description: when I resume computer, wifi won't reconnect, I have to restart NetworkManager to connect.
One more note to this: It does not happen only when computer suspends. It happens also when you leave your computer running, but you let option "Suspend wifi to save power" in Power section of Gnome settings enabled.
Sorry on last comment / I was just trying to subscribe to updates-- Having this same issue on Fedora 24 fresh install - 1+ year after this bug was reported. If this helps, i have an Intel Wifi (Wirelesss AC) chip.. I would love to contribute, but I'm starting from scratch knowledgewise.
I'm looking at the Network Manager logs Pardon me if i'm stating the obvious, but the relevant part seems to be that when it *wakes* it gets a "WiFi Disabled By Network KillSwitch" message. On way to sleep.. Nov 14 19:13:19 localhost.localdomain NetworkManager[864]: <info> [1479168799.3317] manager: NetworkManager state is now ASLEEP --8 seconds later i wake it up-- Nov 14 19:13:27 localhost.localdomain NetworkManager[864]: <info> [1479168807.1745] manager: WiFi now disabled by radio killswitch Nov 14 19:13:27 localhost.localdomain NetworkManager[864]: <info> [1479168807.1950] manager: wake requested (sleeping: yes enabled: yes) Nov 14 19:13:27 localhost.localdomain NetworkManager[864]: <info> [1479168807.1951] manager: waking up... So the question would be why is the network killswitch being trigerred when it wakes? Someone mentioned the AC 7260 chip was an issue, but mine only has an AC 3160 chip, which i believe is half the speed but basically the same chip. Yes, this is a dell laptop. -Rob
This seems to be fixed. I did an update using dandefied yum ("dnf update"), rebooted, and now i've suspended and resumed at least 6 times and every time wifi came back on.
The issue is not occurring for me on the same system that was having trouble. I'm on the current Fedora 25 now, kernel 4.8.6-300.fc25.x86_64.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Equipment ********* New install of Fedora 25 & KDE Spin with USB wifi card and 1 dormant/unused hard-wire connection: Actions: ******** Suspended PC Restarted PC NetworkManager icon is RED. No wifi or wired connections shown/listed at task bar display. System did not attempt to re-connect. Clicked on connections icon (top right): Both potential connections displayed but "Connect" button is grayed-out on both (nothing operational). Downloaded & installed rfkill (FC24): No good -- displayed/changed nothing. Good News: ********** Rebooted PC and wlan connection restored. PLEASE NOTE -- I had a similar problem immediately after installing FC25 (though I am not clear that "suspend" was involved). I lost the wlan connection and nothing I found on the net helped restore it. I reinstalled the OS from the ground up. accck!
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
At least a couple of people said it affected F24 as well.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.