Bug 85851

Summary: [ivb] i915 driver lid thinkpad X1 1st generation
Product: Drivers Reporter: Gijs Hillenius (gijs)
Component: Video(DRI - Intel)Assignee: intel-gfx-bugs (intel-gfx-bugs)
Status: RESOLVED UNREPRODUCIBLE    
Severity: normal CC: intel-gfx-bugs
Priority: P3    
Hardware: Intel   
OS: Linux   
Kernel Version: 3.16 Subsystem:
Regression: No Bisected commit-id:
Attachments: the output of acpidump-acpica > acpidump.txt
output of dmesg (twice) each time after lid close and re-open
pm-suspend log

Description Gijs Hillenius 2014-10-08 08:42:55 UTC
Created attachment 152881 [details]
the output of acpidump-acpica > acpidump.txt

Since two weeks I use a Thinkpad X1 Carbon (1st Gen), which is using
i915 kernel driver.



I'm trying to figure out what happens when I close the lid of this
laptop. It is not behaving as I would expect. I notice this because
i3lock does *not* switch on after the laptop's lid is re-opened. I'm
using Debian Linux, and a package called acpi-support that configure's
the screen to be lock by a one of a list of screensavers, when the lid
is closed & re-open.

I'm going to supply you a lot of info, and my apologies if that is *not*
what you want.


cat /sys/power/state
freeze mem disk

If I close the lid, the machine goes or seems to go into
suspend. However, it seems like LID/state never changes

cat /proc/acpi/button/lid/LID/state 
state:      open

and when I do what you recommend here https://bugzilla.kernel.org/show_bug.cgi?id=13263

while true; do cat /proc/acpi/button/lid/LID/state; sleep 1; done
state:      open
state:      open
state:      open
^C

this list continous, it merely hickup's for a wee short while..



lspci  -vv -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Lenovo Device 21f9
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 44
        Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
        Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at 4000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
                Address: fee0f00c  Data: 41d1
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a4] PCI Advanced Features
                AFCap: TP+ FLR+
                AFCtrl: FLR-
                AFStatus: TP-
        Kernel driver in use: i915
Comment 1 Gijs Hillenius 2014-10-08 08:44:58 UTC
Created attachment 152891 [details]
output of dmesg (twice) each time after lid close and re-open
Comment 2 Gijs Hillenius 2014-10-08 08:45:23 UTC
Created attachment 152901 [details]
pm-suspend log
Comment 3 Jani Nikula 2015-01-28 14:37:22 UTC
We seem to have neglected this bug, apologies.

Is this still an issue with recent kernels? Please reproduce with drm.debug=0xe module parameter set, and provide dmesg, all the way from boot.
Comment 4 Gijs Hillenius 2015-01-28 15:13:59 UTC
The problem seems to be in the systemd implementation in Debian at that time. I've reverted to sysvinit, and everything is ok. Extensively debugged this with the maintainer of acpi-support in Debian, is how we narrowed it down to Systemd. It is possible the bug is fixed in systemd now, I just have not tried it.
Comment 5 Jani Nikula 2015-01-28 15:40:11 UTC
(In reply to Gijs Hillenius from comment #4)
> The problem seems to be in the systemd implementation in Debian at that
> time. I've reverted to sysvinit, and everything is ok. Extensively debugged
> this with the maintainer of acpi-support in Debian, is how we narrowed it
> down to Systemd. It is possible the bug is fixed in systemd now, I just have
> not tried it.

Thanks for reporting back. I'll close this now, please reopen if the problem comes back. Thanks.