Description of problem: Machine suspends and resumes correctly exactly once after booting kernel 4.17. If a second suspend is attempted, the machine becomes unresponsive. In this state the screen is dark and the power and fan are running. It's not possible to do anything except turn it off with a long press of the power button. This machine and OS can suspend and resume successfully an arbitrary number of times with earlier F28 kernels. Version-Release number of selected component (if applicable): 4.17.2, 4.17.3 (x86-64) from the Fedora repo. How reproducible: 100% Steps to Reproduce: 1. Boot F28 with kernel 4.17 2. Suspend to RAM (close the laptop lid or use Fn-F1 (sleep button)) and resume by opening the lid or pressing the power button. 3. Close the laptop lid or use Fn-F1 (sleep button) to attempt to suspend again. Actual results: Black screen, power on, fan spinning, machine unresponsive. Cannot switch consoles. Power button light is on and steady. Expected results: Machine suspends to RAM, fan off, power button light pulsing slowly. Machine wakes when lid is opened or power button is pressed. Additional info: NOTE: The info below was collected with the last 4.16 kernel, which seems to work perfectly: $ inxi -Fxzc0 System: Host: nubium Kernel: 4.16.16-300.fc28.x86_64 x86_64 bits: 64 gcc: 8.1.1 Desktop: KDE Plasma 5.12.5 (Qt 5.10.1) Distro: Fedora release 28 (Twenty Eight) Machine: Device: laptop System: Dell product: Latitude E7240 v: 00 serial: N/A Mobo: Dell model: 0PRPKP v: A00 serial: N/A BIOS: Dell v: A25 date: 02/01/2018 Battery BAT0: charge: 51.4 Wh 99.2% condition: 51.8/52.6 Wh (99%) model: LGC-LGC6.9 DELL W57CV status: Charging CPU: Dual core Intel Core i7-4600U (-MT-MCP-) arch: Haswell rev.1 cache: 4096 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 10775 clock speeds: max: 3300 MHz 1: 2565 MHz 2: 2536 MHz 3: 2298 MHz 4: 2863 MHz Graphics: Card: Intel Haswell-ULT Integrated Graphics Controller bus-ID: 00:02.0 Display Server: x11 (X.org 119.6 ) drivers: modesetting (unloaded: fbdev,vesa) Resolution: 1366x768 OpenGL: renderer: Mesa DRI Intel Haswell Mobile version: 4.5 Mesa 18.0.5 Direct Render: Yes Audio: Card-1 Intel 8 Series HD Audio Controller driver: snd_hda_intel bus-ID: 00:1b.0 Card-2 Intel Haswell-ULT HD Audio Controller driver: snd_hda_intel bus-ID: 00:03.0 Sound: Advanced Linux Sound Architecture v: k4.16.16-300.fc28.x86_64 Network: Card-1: Intel Ethernet Connection I218-LM driver: e1000e v: 3.2.6-k port: f080 bus-ID: 00:19.0 IF: eth0 state: down mac: <filter> Card-2: Qualcomm Atheros AR9462 Wireless Network Adapter driver: ath9k bus-ID: 04:00.0 IF: wlan0 state: up mac: <filter> Card-3: Qualcomm Atheros usb-ID: 001-003 IF: null-if-id state: N/A speed: N/A duplex: N/A mac: N/A Drives: HDD Total Size: 256.1GB (88.2% used) ID-1: /dev/sda model: SAMSUNG_SSD_PM85 size: 256.1GB Partition: ID-1: / size: 15G used: 11G (70%) fs: btrfs dev: /dev/sda2 ID-2: /home size: 224G used: 199G (89%) fs: btrfs dev: /dev/dm-0 ID-3: swap-1 size: 2.15GB used: 0.00GB (0%) fs: swap dev: /dev/zram0 RAID: No RAID devices: /proc/mdstat, md_mod kernel module present Sensors: System Temperatures: cpu: 50.0C mobo: N/A Fan Speeds (in rpm): cpu: N/A Info: Processes: 324 Uptime: 15 min Memory: 2322.6/7881.7MB Init: systemd runlevel: 5 Gcc sys: 8.1.1 Client: Shell (bash 4.4.231) inxi: 2.3.56 $ lsmod Module Size Used by ccm 20480 6 rfcomm 86016 4 fuse 118784 5 devlink 61440 0 ebtable_filter 16384 0 ebtables 36864 1 ebtable_filter zram 28672 1 ip6t_REJECT 16384 1 nf_reject_ipv6 16384 1 ip6t_REJECT nf_log_ipv6 16384 5 xt_hl 16384 22 ip6t_rt 16384 3 cmac 16384 1 nf_conntrack_ipv6 16384 8 nf_defrag_ipv6 36864 1 nf_conntrack_ipv6 xt_comment 16384 1 nf_log_ipv4 16384 5 nf_log_common 16384 2 nf_log_ipv6,nf_log_ipv4 xt_LOG 16384 10 xt_limit 16384 13 xt_addrtype 16384 4 nf_conntrack_ipv4 16384 8 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 xt_conntrack 16384 16 ip6table_filter 16384 1 bnep 24576 2 ip6_tables 28672 1 ip6table_filter nf_conntrack_netbios_ns 16384 0 nf_conntrack_broadcast 16384 1 nf_conntrack_netbios_ns nf_nat_ftp 16384 0 nf_nat 36864 1 nf_nat_ftp nf_conntrack_ftp 20480 1 nf_nat_ftp nf_conntrack 147456 8 nf_conntrack_ipv6,nf_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_broadcast,nf_nat_ftp,nf_conntrack_netbios_ns,xt_conntrack,nf_nat libcrc32c 16384 2 nf_conntrack,nf_nat sunrpc 413696 1 dm_crypt 40960 1 dm_multipath 32768 0 scsi_dh_rdac 16384 0 scsi_dh_emc 16384 0 scsi_dh_alua 20480 0 arc4 16384 2 ath3k 20480 0 btusb 53248 0 btrtl 16384 1 btusb btbcm 16384 1 btusb btintel 24576 1 btusb pn544_mei 16384 0 ath9k 155648 0 intel_rapl 24576 0 x86_pkg_temp_thermal 16384 0 mei_phy 16384 1 pn544_mei intel_powerclamp 16384 0 bluetooth 598016 32 btrtl,btintel,bnep,btbcm,rfcomm,ath3k,btusb pn544 20480 1 pn544_mei coretemp 16384 0 ath9k_common 24576 1 ath9k hci 53248 2 mei_phy,pn544 kvm_intel 180224 0 ath9k_hw 503808 2 ath9k,ath9k_common nfc 135168 2 hci,pn544 kvm 708608 1 kvm_intel mei_wdt 16384 0 iTCO_wdt 16384 0 dell_wmi 16384 0 iTCO_vendor_support 16384 1 iTCO_wdt sparse_keymap 16384 1 dell_wmi wmi_bmof 16384 0 ppdev 20480 0 ecdh_generic 24576 2 bluetooth irqbypass 16384 1 kvm crct10dif_pclmul 16384 0 crc32_pclmul 16384 0 mac80211 888832 1 ath9k dell_laptop 24576 0 dell_smbios 28672 2 dell_wmi,dell_laptop dell_wmi_descriptor 16384 2 dell_wmi,dell_smbios dcdbas 16384 1 dell_smbios ghash_clmulni_intel 16384 0 intel_cstate 16384 0 snd_hda_codec_realtek 110592 1 dell_smm_hwmon 16384 0 snd_hda_codec_hdmi 57344 1 snd_hda_codec_generic 86016 1 snd_hda_codec_realtek snd_hda_intel 45056 10 intel_uncore 131072 0 ath 36864 3 ath9k_hw,ath9k,ath9k_common intel_rapl_perf 16384 0 snd_hda_codec 151552 4 snd_hda_intel,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek joydev 24576 0 snd_hda_core 94208 5 snd_hda_intel,snd_hda_codec,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek cfg80211 733184 4 mac80211,ath9k,ath,ath9k_common snd_hwdep 16384 1 snd_hda_codec snd_seq 81920 0 snd_seq_device 16384 1 snd_seq snd_pcm 118784 4 snd_hda_intel,snd_hda_codec,snd_hda_core,snd_hda_codec_hdmi i2c_i801 28672 0 snd_timer 36864 2 snd_seq,snd_pcm snd 94208 30 snd_hda_intel,snd_hwdep,snd_seq,snd_hda_codec,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_seq_device,snd_hda_codec_realtek,snd_pcm mei_me 45056 1 mei 106496 6 mei_phy,mei_me,pn544_mei,mei_wdt soundcore 16384 1 snd lpc_ich 28672 0 shpchp 40960 0 wmi 28672 4 dell_wmi,wmi_bmof,dell_wmi_descriptor,dell_smbios parport_pc 32768 0 parport 57344 2 parport_pc,ppdev dell_rbtn 16384 1 rfkill 28672 11 bluetooth,nfc,dell_laptop,dell_rbtn,cfg80211 binfmt_misc 20480 1 vboxpci 28672 0 vboxnetadp 28672 0 vboxnetflt 32768 0 vboxdrv 491520 3 vboxnetadp,vboxnetflt,vboxpci btrfs 1351680 2 xor 24576 1 btrfs zstd_decompress 81920 1 btrfs zstd_compress 180224 1 btrfs xxhash 16384 2 zstd_compress,zstd_decompress i915 1998848 41 raid6_pq 122880 1 btrfs i2c_algo_bit 16384 1 i915 drm_kms_helper 200704 1 i915 drm 454656 20 i915,drm_kms_helper e1000e 282624 0 sdhci_pci 40960 0 crc32c_intel 24576 2 cqhci 28672 1 sdhci_pci sdhci 57344 1 sdhci_pci mmc_core 172032 3 sdhci,sdhci_pci,cqhci serio_raw 16384 0 ptp 20480 1 e1000e pps_core 20480 1 ptp video 45056 3 dell_wmi,dell_laptop,i915
I have the exact same issue on Dell latitude 7240 with almost identical specs. I have been seeing this with all kernel 4.17.x versions up to 4.17.4. I have tried changing /sys/power/state - it was "freeze mem". I changed it to "mem" to no effect. For mem, $ cat /sys/power/mem_sleep s2idle [deep] Anything I can test to get suspend to work?
Identical issue on Dell Latitude E7440 here. inxi -Fxzc0 System: Host: skadi.central.xn Kernel: 4.17.6-200.fc28.x86_64 x86_64 bits: 64 compiler: gcc v: 8.1.1 Desktop: Gnome 3.28.2 Distro: Fedora release 28 (Twenty Eight) Machine: Type: Laptop System: Dell product: Latitude E7440 v: 00 serial: <filter> Mobo: Dell model: 06MFX3 v: A00 serial: <filter> UEFI: Dell v: A22 date: 10/18/2017 Battery: ID-1: BAT0 charge: 35.5 Wh condition: 38.0/48.2 Wh (79%) model: SMP DELL 909H538 status: Charging CPU: Topology: Dual Core model: Intel Core i5-4310U bits: 64 type: MT MCP arch: Haswell rev: 1 L2 cache: 3072 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 20750 Speed: 2394 MHz min/max: 800/2400 MHz Core speeds (MHz): 1: 2394 2: 2395 3: 2395 4: 2395 Graphics: Card-1: Intel Haswell-ULT Integrated Graphics driver: i915 v: kernel bus ID: 00:02.0 Display: wayland server: Fedora Project X.org 11.0 driver: i915 resolution: 1920x1080~60Hz OpenGL: renderer: Mesa DRI Intel Haswell Mobile v: 4.5 Mesa 18.0.5 direct render: Yes Audio: Card-1: Intel Haswell-ULT HD Audio driver: snd_hda_intel v: kernel bus ID: 00:03.0 Card-2: Intel 8 Series HD Audio driver: snd_hda_intel v: kernel bus ID: 00:1b.0 Sound Server: ALSA v: k4.17.6-200.fc28.x86_64 Network: Card-1: Intel Ethernet Connection I218-LM driver: e1000e v: 3.2.6-k port: f080 bus ID: 00:19.0 IF: eno1 state: down mac: <filter> Card-2: Intel Wireless 7260 driver: iwlwifi v: kernel bus ID: 02:00.0 IF: wlp2s0 state: up mac: <filter> Drives: HDD Total Size: 465.76 GiB used: 134.66 GiB (28.9%) ID-1: /dev/sda vendor: Samsung model: SSD 850 EVO 500GB size: 465.76 GiB Partition: ID-1: / size: 48.97 GiB used: 29.26 GiB (59.7%) fs: ext4 dev: /dev/dm-1 ID-2: /boot size: 975.9 MiB used: 200.6 MiB (20.6%) fs: ext4 dev: /dev/sda2 ID-3: /home size: 399.33 GiB used: 105.18 GiB (26.3%) fs: ext4 dev: /dev/dm-3 ID-4: swap-1 size: 7.85 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/dm-2 Sensors: System Temperatures: cpu: 52.0 C mobo: 38.0 C sodimm: 34.0 C Fan Speeds (RPM): cpu: 0 Info: Processes: 279 Uptime: 5m Memory: 7.70 GiB used: 1.67 GiB (21.7%) Init: systemd runlevel: 5 Compilers: gcc: 8.1.1 clang: 6.0.0 Shell: bash v: 4.4.23 inxi: 3.0.14 lsmod Module Size Used by rfcomm 86016 4 fuse 118784 3 ccm 20480 6 nf_conntrack_netbios_ns 16384 1 nf_conntrack_broadcast 16384 1 nf_conntrack_netbios_ns xt_CT 16384 1 ip6t_rpfilter 16384 1 ip6t_REJECT 16384 2 nf_reject_ipv6 16384 1 ip6t_REJECT xt_conntrack 16384 21 ip_set 45056 0 nfnetlink 16384 1 ip_set ebtable_nat 16384 1 ebtable_broute 16384 1 bridge 188416 1 ebtable_broute stp 16384 1 bridge llc 16384 2 bridge,stp ip6table_nat 16384 1 nf_conntrack_ipv6 16384 12 nf_defrag_ipv6 20480 1 nf_conntrack_ipv6 nf_nat_ipv6 16384 1 ip6table_nat ip6table_mangle 16384 1 ip6table_raw 16384 1 ip6table_security 16384 1 iptable_nat 16384 1 nf_conntrack_ipv4 16384 12 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 nf_nat_ipv4 16384 1 iptable_nat nf_nat 36864 2 nf_nat_ipv6,nf_nat_ipv4 nf_conntrack 147456 9 xt_conntrack,nf_conntrack_ipv6,nf_conntrack_ipv4,nf_nat,nf_nat_ipv6,nf_conntrack_netbios_ns,nf_nat_ipv4,nf_conntrack_broadcast,xt_CT libcrc32c 16384 2 nf_conntrack,nf_nat iptable_mangle 16384 1 iptable_raw 16384 1 iptable_security 16384 1 ebtable_filter 16384 1 ebtables 36864 3 ebtable_nat,ebtable_filter,ebtable_broute ip6table_filter 16384 1 ip6_tables 28672 5 ip6table_filter,ip6table_raw,ip6table_nat,ip6table_mangle,ip6table_security cmac 16384 1 bnep 24576 2 vfat 20480 1 fat 77824 1 vfat btusb 53248 0 btrtl 16384 1 btusb btbcm 16384 1 btusb btintel 24576 1 btusb bluetooth 598016 31 btrtl,btintel,btbcm,bnep,btusb,rfcomm ecdh_generic 24576 2 bluetooth arc4 16384 2 pn544_mei 16384 0 mei_phy 16384 1 pn544_mei pn544 20480 1 pn544_mei iwlmvm 425984 0 hci 53248 2 mei_phy,pn544 intel_rapl 24576 0 x86_pkg_temp_thermal 16384 0 intel_powerclamp 16384 0 nfc 135168 2 pn544,hci coretemp 16384 0 mac80211 909312 1 iwlmvm kvm_intel 229376 0 mei_wdt 16384 0 iTCO_wdt 16384 0 iTCO_vendor_support 16384 1 iTCO_wdt wmi_bmof 16384 0 kvm 724992 1 kvm_intel dell_wmi 16384 0 sparse_keymap 16384 1 dell_wmi ppdev 20480 0 iwlwifi 262144 1 iwlmvm dell_laptop 24576 0 dell_smbios 28672 2 dell_wmi,dell_laptop snd_hda_codec_hdmi 57344 1 snd_hda_codec_realtek 110592 1 irqbypass 16384 1 kvm snd_hda_codec_generic 86016 1 snd_hda_codec_realtek dell_wmi_descriptor 16384 2 dell_wmi,dell_smbios intel_cstate 16384 0 dcdbas 16384 1 dell_smbios cfg80211 770048 3 iwlmvm,iwlwifi,mac80211 snd_hda_intel 45056 10 intel_uncore 131072 0 dell_smm_hwmon 16384 0 snd_hda_codec 151552 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek intel_rapl_perf 16384 0 snd_hda_core 94208 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek snd_hwdep 16384 1 snd_hda_codec snd_seq 81920 0 snd_seq_device 16384 1 snd_seq snd_pcm 118784 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core joydev 24576 0 i2c_i801 28672 0 mei_me 45056 1 mei 110592 6 mei_wdt,mei_phy,mei_me,pn544_mei snd_timer 36864 2 snd_seq,snd_pcm lpc_ich 28672 0 snd 94208 30 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm wmi 32768 4 dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor soundcore 16384 1 snd shpchp 40960 0 parport_pc 32768 0 parport 57344 2 parport_pc,ppdev dell_smo8800 16384 0 dell_rbtn 16384 1 rfkill 28672 10 nfc,bluetooth,dell_laptop,dell_rbtn,cfg80211 auth_rpcgss 73728 0 sunrpc 434176 5 auth_rpcgss dm_crypt 40960 1 i915 2052096 23 i2c_algo_bit 16384 1 i915 drm_kms_helper 196608 1 i915 sdhci_pci 40960 0 crct10dif_pclmul 16384 0 crc32_pclmul 16384 0 crc32c_intel 24576 4 cqhci 28672 1 sdhci_pci ghash_clmulni_intel 16384 0 sdhci 57344 1 sdhci_pci drm 458752 23 drm_kms_helper,i915 e1000e 282624 0 mmc_core 172032 3 sdhci,cqhci,sdhci_pci serio_raw 16384 0 video 45056 3 dell_wmi,dell_laptop,i915
Same problem here with an E7240. I can confirm that switching to kernel 4.16.16-300 (the latest koji build of a 4.16 kernel for F28) solves the problem. This laptop has run all Fedora versions since the end of 2014, when it was produced, and suspend has always worked. Apart from the two already mentioned methods of suspending, directly running as root 'systemctl suspend' also triggers it, i.e. it doesn't matter how the first or the second suspend operation is started. Setting the kernel command line option ahci.mobile_lpm_policy to 0 or 1, which helps for (some) ThinkPads, does not help here. Initially the BIOS was on version A23, updating to the latest release A25 (which also the OP mentions) did not help. The issue happens independently of the state of the battery (fully loaded or almost empty) and also when connected to the power supply. I'd also be willing to test, if anyone has ideas...
I forgot to mention that trying to shut down (or restart) after one suspend/wake causes "general protection fault: 0000 [#1] SMP PTI", then a call trace, and finally the message "/shutdown: line 113: 4272 Segmentation fault $ACTION -f -d -n". I strongly believe these issues are related.
This is happening on my Dell Latitude E7440. 4.16 kernel works fine, but 4.17 consistently hangs on the second suspend. I'm running the latest released BIOS (A25) I will try to capture a console log of the suspend, along with dumps of everything.
There seem to be at least two similar reports against F27 in Bugzilla, but they are against F27 and the 4.16 kernel. See #1547399 and #1515583. (The former is another Dell model, the latter is an Acer)
Dumps from my system: [pizza@flapjack ~]$ inxi -Fxzc0 System: Host: flapjack.fl.shaftnet.org Kernel: 4.17.7-200.fc28.x86_64 x86_64 bits: 64 compiler: gcc v: 8.1.1 Desktop: Gnome 3.28.3 Distro: Fedora release 28 (Twenty Eight) Machine: Type: Laptop System: Dell product: Latitude E7440 v: 00 serial: <filter> Mobo: Dell model: 07F3F4 v: A00 serial: <filter> UEFI: Dell v: A25 date: 02/01/2018 Battery: ID-1: BAT0 charge: 1.3 Wh condition: 33.8/47.1 Wh (72%) model: LGC-LGC6.2 DELL 0D47W47 status: Charging CPU: Topology: Dual Core model: Intel Core i7-4600U bits: 64 type: MT MCP arch: Haswell rev: 1 L2 cache: 4096 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 21551 Speed: 1397 MHz min/max: 800/3300 MHz Core speeds (MHz): 1: 1397 2: 1397 3: 1398 4: 1397 Graphics: Card-1: Intel Haswell-ULT Integrated Graphics driver: i915 v: kernel bus ID: 00:02.0 Display: server: X.Org 1.19.5 driver: i915 resolution: 1920x1200~60Hz, 1920x1200~60Hz OpenGL: renderer: llvmpipe (LLVM 6.0 256 bits) v: 3.3 Mesa 18.0.5 direct render: Yes Audio: Card-1: Intel Haswell-ULT HD Audio driver: snd_hda_intel v: kernel bus ID: 00:03.0 Card-2: Intel 8 Series HD Audio driver: snd_hda_intel v: kernel bus ID: 00:1b.0 Sound Server: ALSA v: k4.17.7-200.fc28.x86_64 Network: Card-1: Intel Ethernet I218-LM driver: e1000e v: 3.2.6-k port: f080 bus ID: 00:19.0 IF: eno1 state: down mac: <filter> Card-2: Intel Wireless 7260 driver: iwlwifi v: kernel bus ID: 02:00.0 IF: wlp2s0 state: up mac: <filter> Drives: Local Storage: total: 465.76 GiB used: 108.49 GiB (23.3%) ID-1: /dev/sda vendor: Samsung model: SSD 850 EVO mSATA 500GB size: 465.76 GiB temp: 36 C Partition: ID-1: / size: 49.09 GiB used: 28.54 GiB (58.1%) fs: ext4 dev: /dev/dm-1 ID-2: /boot size: 476.2 MiB used: 187.9 MiB (39.5%) fs: ext4 dev: /dev/sda2 ID-3: /home size: 400.71 GiB used: 79.76 GiB (19.9%) fs: ext4 dev: /dev/dm-3 ID-4: swap-1 size: 7.75 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/dm-2 Sensors: System Temperatures: cpu: 51.0 C mobo: 39.0 C sodimm: 36.0 C Fan Speeds (RPM): cpu: 3706 Info: Processes: 195 Uptime: 3m Memory: 15.57 GiB used: 722.6 MiB (4.5%) Init: systemd runlevel: 5 Compilers: gcc: 8.1.1 clang: 6.0.1 Shell: bash v: 4.4.23 inxi: 3.0.17 After the first suspend cycle, I did a ctrl-alt-delete to reboot, and it logged a GPF. I took a photo of the crash, but here's the interesting bits: RIP: mei_cl_set_disconnected+0x5/0x260[mei] Call trace: mei_cl_all_disconnect+0x22/0x30 mei_reset+0x194/0x250 __synchronize_hardirq+0x43/0x50 _cond_resched+0x15/0x30 mei_me_intr_clear+0x20/0x100 mei_stop+0x76/0xb0 mei_me_shutdown+0x3f/0x80 pci_device_shutdown+0x34/0x60 kernel_restart+0x0e/0x30
Created attachment 1470798 [details] screenshot of the general protection fault in mei_me After removing the mei_me module, suspending always succeeds.
@Solomon Peachy: Good find! Adding blacklist mei_me to /etc/modprobe.d/blacklist.conf fixes the issue on my Latitude E7240 (now running kernel 4.17.9-200.fc28.x86_64).
I can also confirm that: - downgrading to 4.16 fixes the problem - blacklisting mei_me as in comment 9 fixes the problem, no mei module is then loaded
Same Issue here with a Dell Latitude e7440, with bios up-to-date (A25) and running on gnome 3.28.3 with kernel 4.17.14. The workaround proposed in comment 9 also worked for me, althougth I guess that installing the LTS linux kernel would have been a nice solution too.
In my case, blacklisting mei_me does not hang up the system. However, the system never goes to suspend either ... :(
I'm running into what appears to be the same issue, Dell Latitude E7440. Ran fine under F26, fails to suspend twice, or poweroff after one suspend, using F28 (4.7.12-200). Don't know about F27 which I skipped. Here's what I can observe: - At fresh boot, everything seems fine. No mei-related warnings in dmesg, mei module has 6 references and 4 direct consumers (mei_wdt, mei_phy, mei_me and pn544_mei) - After suspend, two likely related errors in dmesg: * mei_wdt: mei:GUID:01: get hw module failed * mei_wdt: mei:GUID:01: Could not enable cl device What's interesting at this stage, is that the 'in use' count of mei_me is *-1*, and the 'in use' count of mei is now 5, with the same 'Used by' list. - When trying to suspend again, the system basically freezes with black screen but doesn't actually suspend. Not much to go on, however - When not trying to suspend again, but poweroff, I get a GPF with the same calltrace as https://bugzilla.redhat.com/show_bug.cgi?id=1597481#c7 (and RIP: meii_cl_set_disconnected) I haven't been able to try any patches (yet), but given the negative module refcount I wonder whether this relates to the changes introduced in 257355a44b9929e55d6fd47bfff66971dc4de948 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=257355a44b9929e55d6fd47bfff66971dc4de948)
This happens for me (Dell Latitude E7240) with kernels 4.16.11-100.fc26 and 4.17.14-102.fc27. It seemed to have been introduced during a relatively recent kernel update in Fedora 26 (I upgraded to Fedora 27 hoping that would fix the problem...no luck there). The laptop suspends fine the first time after a reboot. The second time, it suspends, but then immediately comes back up to the GDM lock screen (even though the lid is still closed). Subsequent times, I may or may not get keyboard/mouse control back, in which case it's hard-reset time. If it would be helpful to post journal entries, dmesg, etc., please tell me what would be most helpful.
(In reply to Marc from comment #11) > Same Issue here with a Dell Latitude e7440, with bios up-to-date (A25) and > running on gnome 3.28.3 with kernel 4.17.14. > The workaround proposed in comment 9 also worked for me, althougth I guess > that installing the LTS linux kernel would have been a nice solution too. I forgot to mention I'm running Arch linux, not Fedora. So this is obviously not a Fedora related bug.
@Marc: Did blacklisting mei_me cure it on your machine?
(In reply to Chris Koresko from comment #17) > @Marc: Did blacklisting mei_me cure it on your machine? @Chris: Yes it did (see comment #11) !
(In reply to Nicolas Trangez from comment #13) > I haven't been able to try any patches (yet), but given the negative module > refcount I wonder whether this relates to the changes introduced in > 257355a44b9929e55d6fd47bfff66971dc4de948 > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=257355a44b9929e55d6fd47bfff66971dc4de948) Reverting 257355a44b9929e55d6fd47bfff66971dc4de948 solved it for me.
Already tracked here https://bugzilla.kernel.org/show_bug.cgi?id=200455
4.17.17-100.fc27.x86_64 made this BETTER, but it still fails to suspend (without immediately waking back up) after the first time it wakes up. That is, the first suspend works normally, and it wakes up properly when the laptop lid is opened again (which is an improvement to what the previous kernel did). Closing the lid again will suspend, but it wakes up immediately even though the lid is still closed. Subsequent lid closings result in similar behavior to the second time.
The patches referenced in the kernel bug in comment 20 are not yet upstream or in any stable release, but they were sent to LKML and stable. Could they be included in the next scheduled kernel build, if not already in upstream/stable until then? https://bugzilla.kernel.org/attachment.cgi?id=278055 https://bugzilla.kernel.org/attachment.cgi?id=278057
Running 4.18.5-200.fc28.x86_64 with mei_me blacklisted, suspend and resume works, multiple times in a row (no crash observed yet). I may try to un-blacklist mei_me later.
The patches are not yet in 4.18.5, not even in 4.18.8. But the patches are now upstream, so I hope they will be in 4.18.9. I will write a note here when they are in a stable release.
This seems to be fixed in 4.17.19-100.fc27.x86_64. I still have trouble the first time I suspend (probably unrelated to this bug), but the second and subsequent suspensions are fine.
Kernel 4.18.10 contains the necessary patches which solve the issue
I can confirm the problem is resolved on my E7440, using the 4.18.10-200.fc28 kernel.
Read this blog, Dell Laptop Not Charging, you'll get the solution of your issue.This is the very informative blog. Here is the link- https://www.delltechsupportnumbers.com/blog/simple-steps-fix-dell-laptop-not-charging/
Some earlier "fixed" versions actually corrupted terminals (gnome-terminal running on X11, not Wayland) on my E7240 upon waking up. However, the versions released in the last 3-4 weeks function well. Also the 4.19.5-300 kernel in F29 functions well. Is the problem still present for someone, using the current kernel versions? If not, I'd propose to close this bug.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.20.5-100.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.