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.
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
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
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-
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:  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+
Kernel driver in use: i915
Created attachment 152891 [details]
output of dmesg (twice) each time after lid close and re-open
Created attachment 152901 [details]
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.
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.
(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.