Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Sorry submitted by accident here the description: When running 4.1.2-200.fc22.x86_64 on my Lifebook u904 I cannot suspend the laptop by closing the lid: Jul 18 21:26:53 u904 kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Jul 18 21:26:53 u904 kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Jul 18 21:26:53 u904 kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Jul 18 21:26:53 u904 kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Jul 18 21:26:53 u904 kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Jul 18 21:26:53 u904 kernel: pci_bus 0000:01: Allocating resources Jul 18 21:26:53 u904 kernel: pci_bus 0000:02: Allocating resources Jul 18 21:26:53 u904 kernel: pci_bus 0000:03: Allocating resources Jul 18 21:26:53 u904 kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Jul 18 21:26:53 u904 kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment Jul 18 21:26:53 u904 kernel: acpi device:56: Cannot transition to power state D3cold for parent in (unknown) --- lspci 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:16.3 Serial controller: Intel Corporation 8 Series HECI KT (rev 04) 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-LM (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.1 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 2 (rev e4) 00:1c.3 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 4 (rev e4) 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 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01) 03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73) Suspending without using the lid however works fine ...
Does not seem specific to that kernel also happens with 4.0.6 and 4.0.8.
I'm seeing inconsistent comments here. Is this only limited to the 4.1.2 upgrade or does this happen with 4.0.6 as well?
(In reply to Laura Abbott from comment #3) > I'm seeing inconsistent comments here. Is this only limited to the 4.1.2 > upgrade or does this happen with 4.0.6 as well? Initially I saw it while testing 4.1.2 but reverting the the older kernels I had (4.0.6 and 4.0.8) did not fix it. So yes it happens with 4.0.6 as well.
I first noticed this issue with the 4.1.2 kernel after re-testing suspend via lid closing. I hadn't encountered it with the older 4.0.x series. (Or so I thought, anyway.) However, after seeing this report, I re-tested 4.0.8 and found I can duplicate the problem with that kernel as well. With both 4.1.2 and 4.0.8, in my case this problem doesn't occur consistently. E.g. I just did three lid closes with 4.0.8 and it failed one time and worked correctly twice. I also tested to see if there was some sort of relationship with periodicity to boot, as when I initially tested 4.1.2, suspend via lid closing did work fine. I found there was no pattern with either 4.1.2 or 4.0.8. One time 4.1.2 suspended fine right after boot, then it wouldn't suspend after that. Then I tried 4.0.8, which failed to suspend right after boot, and then successfully suspended the next few tries after that. So at least for me, there seems to be a specific state/interaction that's required to cause it to fail to suspend. I haven't figured out what that is yet.
In the last two days, I haven't managed to get 4.1.2 to fail to suspend on lid close. It's now doing it correctly every time. So I'm at a loss to identify what the cause (at least in my case) was before. I'm going to test 4.1.3 now.
It happens frequently with 4.1.3 so far. (I can of course still suspend by pressing the power button, just the lid close on its own doesn't work.) Enabling more verbose kernel output didn't reveal anything further, all I see is still this: [38428.909161] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment [38428.915687] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [38431.940200] usb 3-1.4: reset full-speed USB device number 4 using ehci-pci [38483.274097] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment [38483.282059] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 (Two lid closes in a row.)
Although, when suspend via lid close does work, I now get an error on resume, as follows: [ 715.926355] ------------[ cut here ]------------ [ 715.926400] WARNING: CPU: 0 PID: 1940 at drivers/gpu/drm/i915/intel_display.c:10098 intel_check_page_flip+0xdb/0xf0 [i915]() [ 715.926403] Kicking stuck page flip: queued at 42520, now 42528 [ 715.926404] Modules linked in: cmac rfcomm fuse ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw bnep arc4 iwldvm mac80211 uvcvideo videobuf2_vmalloc videobuf2_core videobuf2_memops intel_rapl v4l2_common videodev iosf_mbi media x86_pkg_temp_thermal coretemp snd_hda_codec_hdmi kvm snd_hda_codec_conexant snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec iwlwifi snd_hda_core iTCO_wdt iTCO_vendor_support snd_hwdep btusb snd_seq snd_seq_device snd_pcm btbcm btintel cfg80211 [ 715.926442] bluetooth thinkpad_acpi rfkill joydev rtsx_pci_ms memstick wmi tpm_tis snd_timer snd lpc_ich mei_me shpchp tpm mei soundcore i2c_i801 dm_crypt i915 rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel i2c_algo_bit drm_kms_helper ghash_clmulni_intel 8021q garp serio_raw stp drm llc mrp r8169 rtsx_pci mfd_core mii video [ 715.926466] CPU: 0 PID: 1940 Comm: gnome-shell Not tainted 4.1.3-200.fc22.x86_64 #1 [ 715.926468] Hardware name: LENOVO 68852BU/68852BU, BIOS HEET36WW (1.17 ) 10/14/2013 [ 715.926470] 0000000000000000 000000005a21c857 ffff88011e203d08 ffffffff8179b4cd [ 715.926473] 0000000000000000 ffff88011e203d60 ffff88011e203d48 ffffffff810a163a [ 715.926476] ffff88011e203d78 ffff880036b04800 ffff88011925e000 0000000000000000 [ 715.926478] Call Trace: [ 715.926480] <IRQ> [<ffffffff8179b4cd>] dump_stack+0x45/0x57 [ 715.926490] [<ffffffff810a163a>] warn_slowpath_common+0x8a/0xc0 [ 715.926493] [<ffffffff810a16c5>] warn_slowpath_fmt+0x55/0x70 [ 715.926520] [<ffffffffa01c129b>] intel_check_page_flip+0xdb/0xf0 [i915] [ 715.926537] [<ffffffffa018af3c>] ironlake_irq_handler+0x2ac/0xff0 [i915] [ 715.926541] [<ffffffff81630c50>] ? intel_pstate_stop_cpu+0x60/0x60 [ 715.926544] [<ffffffff81109079>] ? call_timer_fn+0x39/0x110 [ 715.926549] [<ffffffff810fa457>] handle_irq_event_percpu+0x77/0x1a0 [ 715.926551] [<ffffffff810fa5bb>] handle_irq_event+0x3b/0x60 [ 715.926553] [<ffffffff810fd98e>] handle_edge_irq+0x6e/0x120 [ 715.926556] [<ffffffff810173b4>] handle_irq+0x74/0x140 [ 715.926560] [<ffffffff817a478f>] do_IRQ+0x4f/0xf0 [ 715.926562] [<ffffffff817a25ae>] common_interrupt+0x6e/0x6e [ 715.926563] <EOI> [<ffffffff81346525>] ? avtab_search_node+0xc5/0x110 [ 715.926568] [<ffffffff81346515>] ? avtab_search_node+0xb5/0x110 [ 715.926571] [<ffffffff8135280c>] cond_compute_av+0x2c/0xc0 [ 715.926574] [<ffffffff8134df93>] context_struct_compute_av+0x213/0x440 [ 715.926577] [<ffffffff8134ee5e>] security_compute_av+0xfe/0x2d0 [ 715.926579] [<ffffffff81337231>] avc_compute_av+0x31/0x1a0 [ 715.926581] [<ffffffff81337797>] avc_has_perm_noaudit+0xd7/0x100 [ 715.926585] [<ffffffff8133b880>] selinux_inode_permission+0xb0/0x190 [ 715.926587] [<ffffffff81334f5c>] security_inode_permission+0x1c/0x30 [ 715.926590] [<ffffffff81235aea>] __inode_permission+0x4a/0xc0 [ 715.926591] [<ffffffff81235b74>] inode_permission+0x14/0x50 [ 715.926593] [<ffffffff81237cbe>] link_path_walk+0x3ee/0xdb0 [ 715.926595] [<ffffffff8123873c>] path_init+0xbc/0x440 [ 715.926597] [<ffffffff8123ba32>] path_openat+0x72/0x680 [ 715.926602] [<ffffffff81277547>] ? eventfd_ctx_read+0x67/0x1c0 [ 715.926605] [<ffffffff810ce6f0>] ? wake_up_state+0x20/0x20 [ 715.926608] [<ffffffff8123d699>] do_filp_open+0x49/0xd0 [ 715.926612] [<ffffffff813c266a>] ? find_next_zero_bit+0x1a/0x30 [ 715.926615] [<ffffffff8124a4ce>] ? __alloc_fd+0x7e/0x120 [ 715.926619] [<ffffffff81229ffa>] do_sys_open+0x13a/0x250 [ 715.926622] [<ffffffff81147366>] ? __audit_syscall_exit+0x1f6/0x290 [ 715.926625] [<ffffffff8122a12e>] SyS_open+0x1e/0x20 [ 715.926627] [<ffffffff817a1a6e>] system_call_fastpath+0x12/0x71 [ 715.926629] ---[ end trace 8581c06cb61f5ef9 ]---
I've noted comment 8 under existing bug 1195870, as it seems to be the same. (I've no idea if there's a relation between the page flip issue and failure to suspend.)
I'm seeing the exact same behavior like David and OP. After kernel upgrade to 4.1.2-200 from the updates-stable repo, lid closing does most often not cause the expected suspend. Rebooting with kernel 4.0.8, it does not work either anymore, but I never had any problems before the upgrade to 4.1.2. My laptop is a ThinkPad X1 Carbon 3rd Gen.
I too have a ThinkPad X1 Carbon 3rd Gen. I do not believe this is a kernel issue as noted in what appears to be a dup bug 1249363 Logs show the system is capturing the lid close/open events which makes me thing it is not the kernel. I believed this may be related to logind's logic to determine if the system is docked (which the default is to ignore lid close), so I set HandleLidSwitchDocked=suspend in /etc/systemd/logind.conf but didn't solve the problem. I was able to have consistent suspend/resumes on one boot, but after rebooting, I was unable to suspend/resume with the lid. I can always suspend with the power button. Aug 05 12:31:03 localhost.localdomain systemd-logind[925]: Lid closed. Aug 05 12:31:06 localhost.localdomain systemd-logind[925]: Lid opened.
I have this problem with a Fujitsu Lifebook AH532 with Linux 4.1.3-201 and systemd 219. I've just had a successful suspend/wake followed by an error; journal at http://pastebin.com/7gvp879e.
Seeing same issues on a T430s running 4.1.4-200.fc22.x86_64. Every lid close event I see the following message: kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
This may be related to bug 1249822, which is a systemd issue. There is an updated version of systemd in testing which is supposed to address it. (https://bodhi.fedoraproject.org/updates/systemd-219-23.fc22)
(In reply to David H. Gutteridge from comment #14) > This may be related to bug 1249822, which is a systemd issue. There is an > updated version of systemd in testing which is supposed to address it. > (https://bodhi.fedoraproject.org/updates/systemd-219-23.fc22) Doesn't seem to fix it here. Even setting "HandleLidSwitchDocked=suspend" in logind.conf does not make a difference.
Sep 05 08:29:16 u904 systemd-logind[615]: Lid closed. Sep 05 08:29:16 u904 systemd-logind[615]: Ignoring lid switch request, system startup or resume too close. Sep 05 08:29:16 u904 systemd-logind[615]: Ignoring lid switch request, system startup or resume too close.
In my case, I haven't encountered the issue again of late, irrespective of changes to systemd, but it was always intermittent for me. (But I'd suspected it was caused by something other than just kernel updates, some sort of interaction issue between components.) We'll see if it pops up again at some point now I've applied this systemd update.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is 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 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. 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 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
Still doesn't work with that kernel. However after upgrading to F23 it seems to work fine. So might be fixed by the newer logind not sure ...
I have exactly this problem on my Samsung laptop. Just reinstalled from fedora 20 to 23. Cloding lid was done in power management on f20, and it worked. Now its not visable in power management, changed the /etc/systemd/logind.conf and nothing works at all. Nothing with cloding the lid. Made the power button suspend the laptop now, but its not doing anything when closing the lid even if the settings tell the computer to suspend. Just had a the clean install the other day and i cant get this to work, running latest updates as im writing this.