Bug 85851 - [ivb] i915 driver lid thinkpad X1 1st generation
Summary: [ivb] i915 driver lid thinkpad X1 1st generation
Status: RESOLVED UNREPRODUCIBLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: Intel Linux
: P3 normal
Assignee: intel-gfx-bugs@lists.freedesktop.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-08 08:42 UTC by Gijs Hillenius
Modified: 2015-01-28 15:40 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.16
Tree: Mainline
Regression: No


Attachments
the output of acpidump-acpica > acpidump.txt (365.63 KB, text/plain)
2014-10-08 08:42 UTC, Gijs Hillenius
Details
output of dmesg (twice) each time after lid close and re-open (181.12 KB, text/plain)
2014-10-08 08:44 UTC, Gijs Hillenius
Details
pm-suspend log (9.69 KB, text/x-log)
2014-10-08 08:45 UTC, Gijs Hillenius
Details

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.

Note You need to log in before you can comment on or make changes to this bug.