Using intel kms on a thinkpad r50e, the system freezes while trying to suspend to ram. Steps to reproduce : 1 - boot the system (even simply in console mode), intel kms gets enabled : 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 [drm] set up 7M of stolen space [drm] initialized overlay support ipw2200: Detected geography ZZR (14 802.11bg channels, 0 802.11a channels) Console: switching to colour frame buffer device 128x48 fb0: inteldrmfb frame buffer device registered panic notifier [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 2 - suspend to ram with pm-suspend and the machine freezes. The screen stays on, the sleep led blinks as if it was suspended, but the machine is still on. Only way out is hard reset / shutdown. kernel versions used : 2.6.32 and 2.6.33-rc7 The same problem was reported by another user on freedesktop, which contains more information, but few progress : http://bugs.freedesktop.org/show_bug.cgi?id=22126 He reported the same issue on 2.6.{30,31,32}-rc Quoting one of the last information provided by Ferec : "After hooking up some LEDs to the parallel port, I was able to determine that under 2.6.31 the freeze happens in drivers/acpi/acpica/hwsleep.c, function acpi_enter_sleep_state_prep, line 176, that is /* Run the _PTS method */ status = acpi_evaluate_object(NULL, METHOD_NAME__PTS, &arg_list, NULL); does not return if I load i915 with modeset=1. I compiled with CONFIG_ACPI_DEBUG=y, but the framebuffer console is already off by the time we get here, so I wasn't able to extract any info from that. Not that I understand ACPI the least." Rafael J. Wysocki said this could indicate a BIOS bug. But it's worth mentioning that the machine suspends and resumes perfectly in UMS mode. Sidenote : the machine freezes hard instantly when I try to unbind fbcon : echo 0 > /sys/class/vtconsole/vtcon1/bind
Are you sure it hangs when unbinding fbcon? Your console will be unusable at that point (we don't hand back off to the vga driver in any meaningful way), so your console will just stop at whatever point you left it at. Does suspend work if you use echo mem > /sys/power/state rather than pm-suspend?
I am pretty sure it hangs, sysrq does not work and the thinkpad leds are frozen. Also I do not just unbind fbcon, I do this for reloading the driver. It works well with nouveau, but I don't know if it does with intel. Shouldn't the console be restored after reloading i915 module with modeset? IIRC I checked with netconsole while unbinding & reloading, but I could not get any information/message. Maybe the network was down as well. I just tried now : echo 0 > /sys/class/vtconsole/vtcon1/bind ; echo '7 on' > /pric/acpi/ibm/led And the suspend led did not turn on. The wireless network does not answer ping and its led is frozen. I tried many times with pm-suspend, many times with echo mem > /sys/power/state , I always get the same result with both. Finally I confirm everything Ferenc reported, the two most important bits are probably the following : 1 - following Documentation/power/basic-pm-debugging.txt , freezer and devices test pass , but platform test fails. "If the "platform" test fails, there is a problem with the handling of the platform (eg. ACPI) firmware on your system. In that case the "platform" mode of hibernation is not likely to work. You can try the "shutdown" mode, but that is rather a poor man's workaround." (but again, it works perfectly without KMS) 2 - it seems to hang on the following call : /* Run the _PTS method */ status = acpi_evaluate_object(NULL, METHOD_NAME__PTS, &arg_list, NULL); (This was also tested using thinkpad leds : I added code to turn them on before the call and turn them down after. Result : they stay on. But no idea how reliable that test is :))
Yakui, any ideas? Hang at suspend is a bad failure mode...
Thanks to Matthew Garrett aka mjg59, there are some new information on this. By removing a single line / call in _PST (\VVPD (0x03)), everything seems to work perfectly. I will attach the simple dsdt diff as well as the irc conversation (hopefully Matthew is fine with that ;)).
Created attachment 25632 [details] irc conversation with matthew
Created attachment 25633 [details] DSDT patch that fixes / workarounds the problem.
Thanks Xavier, I'll try right now!
I just built a custom kernel applying Xavier's patch to my DSDT. It works! So, I have no clue how we can fix this /in/ the kernel, but I surely look forward for such fix :-). I repeat, the DSDT trick works.
Last comment from mjg59 : 02:02 <mjg59> Ok, so that's good to know 02:03 <mjg59> Unfortunate that it's an SMI call... 02:03 <mjg59> Maybe we can try to figure out from the name what it's doing I don't know if we can still hope it'll be figured out and fixed one day. But at least we have the custom DSDT now. So thanks to Matthew again ! :)
Well, since you are already on it why don't you bug matthew a bit more and get his help for some further debugging? ;)
dupe of https://bugs.freedesktop.org/show_bug.cgi?id=22126, closing this one
*** Bug 13805 has been marked as a duplicate of this bug. ***
Just a short info: This patch breaks external monitor support on certain notebooks (including mine, unfortunately). For more details please have a look at the following bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796030 At the bottom of this launchpad bug report is also a patch that fixes the external monitor issue. Thank you for patching the patch so that I can finally upgrade from kernel 2.6.32 to something more current.