|Summary:||[855GM KMS S3] With i915 modeset=1 TP R50e locks up during suspend (not powering off)|
|Product:||Power Management||Reporter:||Andre Muller (andremuellerster)|
|Severity:||normal||CC:||diegoe, lenb, rjw, va, yakui.zhao|
|Kernel Version:||Git 78af08d (2.6.31-rc3)||Subsystem:|
|Bug Depends on:|
dmesg of pseudo-suspend to "device" with i915 modeset=1
dmesg of real suspend to ram w/ i915 w/o KMS
Acpidump after bios upgrade
Description Andre Muller 2009-07-20 20:56:45 UTC
Created attachment 22418 [details] dmesg of pseudo-suspend to "device" with i915 modeset=1 My Thinkpad R50e 855GM fails on its way to suspend with echo mem > /sys/power/state when KMS is enabled. The machine locks up and keeps sitting there, still powered on. This goes both for i915 compiled in and i915 as a module. Using /sys/power/pm_test, I can get as far down as "devices" to recover from. The deeper states lock up the system. With the modular kernel, I can suspend fine when i915 is not loaded, loading i915 without modeset=1 is also fine. I do attach dmesg of - i915 loaded with modesetting enabled, suspend to devices with pm_test - i915 loaded with modesetting disabled, full suspend to ram Suspend to disk works fine in any scenario. As far as I can tell, this is not a regression on KMS. In earlier days of KMS, the rules were like "you shutdown or do any VT switch, I drop dead". Tested against current git 78af08d (2009-07-17) (.config attached) and confirmed the failure to suspend on drm-intel-next dff33cf (2009-07-14). Linux leisereiter 2.6.31-rc3 #54 Thu Jul 16 21:08:24 CEST 2009 i686 Intel(R) Celeron(R) M processor 1300MHz GenuineIntel GNU/Linux Gnu C 4.3.2 Gnu make 3.81 binutils 2.18 util-linux 2.14.2 mount support module-init-tools 3.5 e2fsprogs 1.41.3 reiserfsprogs 3.6.19 pcmciautils 014 PPP 2.4.4 Linux C Library 2.9 Dynamic linker (ldd) 2.9 Procps 3.2.7 Net-tools 1.60 Kbd 1.13 Sh-utils 7.1 wireless-tools 29 Modules Loaded pppoe pppox ppp_generic slhc reiserfs snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd ide_cd_mod rtc psmouse cdrom snd_page_alloc I also tried without network and sound modules loaded. For info on the machine, I do attach an lspci -vv -nn I will happily drown this bug with regdumps, dmidecode and anything useful on request.
Comment 1 Andre Muller 2009-07-20 20:59:08 UTC
Created attachment 22419 [details] dmesg of real suspend to ram w/ i915 w/o KMS
Comment 3 ykzhao 2009-07-21 05:35:44 UTC
Hi, Andre Do you mean that the suspend/resume can work well if the KMS is disabled or i915 driver is not loaded? Right? But when the KMS is enabled, the suspend/resume can't work well. Even when echoing "cores/platform/cpu> /sys/power/pm_test", the suspend/resume can't work. Right? Will you please double check it again? Will you please also attach the output of acpidump, lspci -vxxx? Thanks.
Comment 4 Andre Muller 2009-07-21 09:05:28 UTC
(In reply to comment #3) > Hi, Andre > Do you mean that the suspend/resume can work well if the KMS is disabled > or > i915 driver is not loaded? Right? Yes. > But when the KMS is enabled, the suspend/resume can't work well. Even when > echoing "cores/platform/cpu> /sys/power/pm_test", the suspend/resume can't > work. Right? Yes again. > Will you please double check it again? I gave it another verification round, this one on init=/bin/bash. With i915 modeset=1 - real suspend fails - suspend to core, processors, platform fails - suspend to devices, freezer works With i915 / no modeset: suspend works without i915: suspend works. > > Will you please also attach the output of acpidump, lspci -vxxx? > Thanks. Both are attached. I do get a render error / pagetable error on every load of i915 modeset=1. I do not know at all wether this has anything to do with anything, googling did not help me out. So I thought I better mention it. Below is a snippet out of dmesg. Thanks. Linux agpgart interface v0.103 agpgart-intel 0000:00:00.0: Intel 855GM Chipset agpgart-intel 0000:00:00.0: detected 8060K stolen memory agpgart-intel 0000:00:00.0: AGP aperture is 128M @ 0xe0000000 [drm] Initialized drm 1.1.0 20060810 i915 0000:00:02.0: power state changed by ACPI to D0 i915 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11 i915 0000:00:02.0: setting latency timer to 64 i2c-adapter i2c-1: unable to read EDID block. i915 0000:00:02.0: LVDS-1: no EDID data [drm] DAC-6: set mode 640x480 0 ACPI: EC: missing confirmations, switch off interrupt mode. i2c-adapter i2c-1: unable to read EDID block. i915 0000:00:02.0: LVDS-1: no EDID data render error detected, EIR: 0x00000010 page table error PGTBL_ER: 0x00000049 [drm:i915_driver_irq_handler] *ERROR* EIR stuck: 0x00000010, masking render error detected, EIR: 0x00000010 page table error PGTBL_ER: 0x00000049 [drm] LVDS-8: set mode 1024x768 d Console: switching to colour frame buffer device 128x48 [drm] fb0: inteldrmfb frame buffer device [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Comment 7 Rafael J. Wysocki 2009-07-21 13:11:28 UTC
Suspend-resume is not supported by the i915 driver with KMS yet, AFAICS. Please don't use KMS if you want to use suspend (to RAM).
Comment 8 Andre Muller 2009-12-18 03:33:41 UTC
Created attachment 24218 [details] Acpidump after bios upgrade May I ping on this one? The suspend issues with KMS on i915 seem to get adressed by now... Suspend with KMS still fails in exactly the same way. "Devices" is the deepest sleep state the system will recover from. I tested on 2.6.32 and 2.6.33-rc1. I did upgrade my bios in the meantime to no avail. Nevertheless, I do replace the acpidump with the current version.
Comment 9 Andre Muller 2010-01-14 18:47:09 UTC
The problem persists with 2.6.33-rc4. Reopening in good faith...
Comment 10 Diego Escalante Urrelo 2010-03-20 17:54:07 UTC
Hi. This indeeds happens in 855 GM. Exactly the same experience as described by reporter. What can we do to help? I guess logs are a bit redundant by now.
Comment 11 Andre Muller 2010-08-11 22:42:25 UTC
Good news here, this bug is solved, this was a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=22126 https://bugzilla.kernel.org/show_bug.cgi?id=15322 This fixes things for me as well -- actually I found the dup through bisecting the kernel :-) Thanks all! Now, if this thing would even resume, I would be a happy camper...