Bug 13805 - [855GM KMS S3] With i915 modeset=1 TP R50e locks up during suspend (not powering off)
Summary: [855GM KMS S3] With i915 modeset=1 TP R50e locks up during suspend (not power...
Status: CLOSED DUPLICATE of bug 15322
Alias: None
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: ykzhao
URL:
Keywords:
Depends on:
Blocks: 7216
  Show dependency tree
 
Reported: 2009-07-20 20:56 UTC by Andre Muller
Modified: 2011-07-30 06:36 UTC (History)
5 users (show)

See Also:
Kernel Version: Git 78af08d (2.6.31-rc3)
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg of pseudo-suspend to "device" with i915 modeset=1 (14.83 KB, text/plain)
2009-07-20 20:56 UTC, Andre Muller
Details
dmesg of real suspend to ram w/ i915 w/o KMS (14.82 KB, text/plain)
2009-07-20 20:59 UTC, Andre Muller
Details
Kernel config (49.23 KB, text/plain)
2009-07-20 21:01 UTC, Andre Muller
Details
lspci -vxxx (19.05 KB, text/plain)
2009-07-21 09:06 UTC, Andre Muller
Details
acpidump (143.84 KB, text/plain)
2009-07-21 09:07 UTC, Andre Muller
Details
Acpidump after bios upgrade (143.84 KB, text/plain)
2009-12-18 03:33 UTC, Andre Muller
Details

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 2 Andre Muller 2009-07-20 21:01:23 UTC
Created attachment 22420 [details]
Kernel config
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 5 Andre Muller 2009-07-21 09:06:54 UTC
Created attachment 22428 [details]
lspci -vxxx
Comment 6 Andre Muller 2009-07-21 09:07:44 UTC
Created attachment 22429 [details]
acpidump
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...
Comment 12 Len Brown 2011-07-30 06:36:22 UTC

*** This bug has been marked as a duplicate of bug 15322 ***

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