Bug 10985
|
Description
Jon Dowland
2008-06-26 02:09:20 UTC
Created attachment 16633 [details]
output of intel_reg_dumper
On Matthew Garrett's advice, I booted to single user mode, and ran intel_reg_dumper (from the x86-video-intel git repo) before loading i915, afterwards, and after resuming from a suspend. This is the output from before loading i915. After is identical.
Created attachment 16634 [details]
output of intel_reg_dumper
This is the output of the reg dumper after resuming from suspend, when my backlight had not resumed.
One could argue whether it's technically a kernel regression, but it should be resolved either in the kernel or in userspace before 2.6.26. Jon, could you please try suspending by # echo mem > /sys/power/state (obviously as root) and see what happens? I've just attempted * echo mem > /sys/power/state * pm-suspend * pm-suspend --quirk-s3-bios --quirk-s3-mode with 2.6.25 and 2.6.26-rc8, both in X and without X. In all cases, echo mem > /sys/power/state worked (with 2.6.25 and 2.6.26) In the case of pm-suspend, only explicit quirks with 2.6.25 worked. Does this absolve the kernel? I'm a bit puzzled. I am now trying to figure out what pm-suspend does on top of echo mem > /sys/power/state and after resuming in my case. Hi folks, after some more digging it seems pm-suspend on my machine is back-ending to s2ram, from the uswsusp package. I haven't tried to dig into s2ram to establish why it prevents the backlight coming back up, but this suggests the kernel is fine: echo mem > ... worked fine, and pm-suspend in the absenceof s2ram works fine. I'm sorry for wasting your time. I'm a little miffed myself (back-ending to s2ram by default if present is a debian-specific alteration to the pm-utils package, so I will have to write a similar apology to the bug there.) Actually, the problem is not only yours, because many laptops required a userland workaround quirk before 2.6.26-rc which they don't require any more and which breaks things now. That's why the quirk was hardcoded into the s2ram whitelist and is still used by distributions. So, as far as the kernel is concerned, this is a "will not fix" thing rather than "invalid". BTW, please just add "-f" to the s2ram's command line and things should work again. Actually, it's adding "-f" that breaks it. Invoking "s2ram" on 2.6.26 means it uses it's built-in whitelist and passes the s3 quirks. This still works for me (although the quirks are superfluous). Invoking "s2ram -f" means it doesn't check the whitelist at all. pm-utils (as patched by debian) was invoking s2ram -f, but suffixing explicitly the s3 quirks on the command line for 2.6.25, which worked, and ommitting them with 2.6.26, which (strangely) doesn't. Hi folks- back again :) Sorry about this. When I was performing my tests before, I was not doing them from a clean boot on each occasion. That means the values in /proc/sys/kernel/acpi_video_flags had been set by one method and not reset prior to trying another. I have just performed, using 2.6.26-rc8, clean boots into single user mode, no X, the echo mem > /sys/power/state test. The backlight did not come on after resume :( I have repeated this three times. /proc/sys/kernel/acpi_video_flags was set to 0 before and after resuming. I shall attach the diff of the output of intel_reg_dumper before and after suspend. It appears to be larger than last time. Created attachment 16731 [details]
diff of intel_reg_dumper output before/after a suspend
Note that I had a VGA monitor plugged into the machine for the duration of all of the three tests, from boot. At no point did anything appear on it, though (I didn't start X and I don't appear to have the BIOS configured to echo to it).
Is there any difference with X? The backlight still doesn't come on. The intel regs are slightly different, because X has enabled my external display. I'm going to attach the output of the reg dumper before and after (files also include contents of acpi_video_flags and uname -a output) Created attachment 16733 [details]
intel_reg_dumper output (and other bits) prior to suspend, in X
Created attachment 16734 [details]
intel_reg_dumper output (and other bits) after suspend, in X
Jon, when you booted into single user you remembered to load i915 right? The register diffs make it look like the suspend/resume capable i915 driver wasn't loaded... Not on that last run, sorry. I've just redone them. I'll attach but here's the before/after diff for convenience: --- regs_before.txt 2008-07-05 11:17:55.000000000 +0100 +++ regs_after.txt 2008-07-05 11:17:58.000000000 +0100 @@ -24,7 +24,7 @@ (II): DVOB_SRCDIM: 0x00000000 (II): DVOC_SRCDIM: 0x00000000 (II): PP_CONTROL: 0x00000001 (power target: on) -(II): PP_STATUS: 0xc0000008 (on, ready, sequencing idle) +(II): PP_STATUS: 0x4800000b (off, ready, sequencing idle) (II): PFIT_CONTROL: 0x80000668 (II): PFIT_PGM_RATIOS: 0x00000000 (II): PORT_HOTPLUG_EN: 0x00000000 @@ -68,7 +68,7 @@ (II): DSPBTILEOFF: 0x00000000 (II): PIPEBCONF: 0x80000000 (enabled, single-wide) (II): PIPEBSRC: 0x027f018f (640, 400) -(II): PIPEBSTAT: 0x80000202 (status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS) +(II): PIPEBSTAT: 0x80000242 (status: FIFO_UNDERRUN VSYNC_INT_STATUS LBLC_EVENT_STATUS VBLANK_INT_STATUS) (II): FPB0: 0x0003120c (n = 3, m1 = 18, m2 = 12) (II): FPB1: 0x00021207 (n = 2, m1 = 18, m2 = 7) (II): DPLL_B: 0x90026000 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 2, p2 = 14) Created attachment 16744 [details]
single user; no x; i915 loaded; before suspend
Created attachment 16745 [details]
single user; no x; i915 loaded; after resume
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org> Where abouts are the hw quirks in the code? I've skimmed over most of the i915* files in drivers/char/drm but nothing is jumping out of me. I doubt I'd spot a bug (nor be able to provide a fix) but I am curious :) (In reply to comment #5) > I've just attempted > > * echo mem > /sys/power/state > * pm-suspend > * pm-suspend --quirk-s3-bios --quirk-s3-mode > > with 2.6.25 and 2.6.26-rc8, both in X and without X. > > In all cases, echo mem > /sys/power/state worked (with 2.6.25 and 2.6.26) > > In the case of pm-suspend, only explicit quirks with 2.6.25 worked. > > Does this absolve the kernel? I'm a bit puzzled. > > I am now trying to figure out what pm-suspend does on top of echo mem > > /sys/power/state and after resuming in my case. > Noting, pm-suspend could do something more and echo mem >/sys/power/state, (has far I know). If you say that "echo mem > /sys/power/state" works, where is the bug ? and if you say that pm-suspend fail in something, so it is a pm-utils bug. isn't it ? IMHO I am trying marking this bug related or depend on bug 6001 and bug 9642. Report please consider this patch http://bugzilla.kernel.org/attachment.cgi?id=14745 It is a very close problem, backlight problem with i915 drm . So in my H opinion I'd not consider one regression. (In reply to comment #22) > If you say that "echo mem > /sys/power/state" works, where is the bug I realised by comment #10 that my tests had been flawed and in fact echo mem > /sys/power/state does not work. (In reply to comment #23) > Report please consider this patch > http://bugzilla.kernel.org/attachment.cgi?id=14745 I've just tried that patch and I'm afraid my backlight still did not come on. > So in my H opinion I'd not consider one regression. I'd agree with Adrian in #3 that it is not a regression since this doesn't work for 2.6.25 or earlier either. (In reply to comment #23) > I am trying marking this bug related or depend on bug 6001 and bug 9642. > Report please consider this patch > http://bugzilla.kernel.org/attachment.cgi?id=14745 That patch adds a printk to acpi_video_device_query which does not appear in my dmesg so acpi_video_device_query is not called as part of my suspend sequence. I do not know if acpi_video_bus_start_devices is called or not (I shall try adding a printk to that, too). (In reply to comment #21) > Where abouts are the hw quirks in the code? I've skimmed over most of the > i915* > files in drivers/char/drm but nothing is jumping out of me. Should I be looking at drivers/acpi/video too, then? No, all of this should be handled entirely by the drm. The X40 doesn't have ACPI backlight control. I've dropped this bug from the list of recent regressions on the basis of Comment #24. Created attachment 16852 [details]
Restore LVDS state before PLL state
Can you give something like this a try (it may not apply directly depending on what version you use, but it should be easy to fix). LVDS state is supposed to be restored before the PLLs are enabled or the panel might not come up. I hope that's the problem here... Please let me know if this works for you.
Hi - I just tried that against 2.6.26 (hunks applied against i915_drv.c). Unfortunately it didn't fix the problem. I'll attach the intel_reg_dumper output before/after as usual. This is the script I use to test: #!/bin/sh set -u set -e modprobe i915 /root/intel_reg_dumper > /root/x_regs_before.txt uname -a > /root/BEFORE echo acpi_video_flags: >> /root/BEFORE cat /proc/sys/kernel/acpi_video_flags >> /root/BEFORE echo mem > /sys/power/state /root/intel_reg_dumper > /root/x_regs_after.txt uname -a > /root/AFTER echo acpi_video_flags: >> /root/AFTER cat /proc/sys/kernel/acpi_video_flags >> /root/AFTER dmesg >> /root/AFTER sync Created attachment 16860 [details] intel_reg_dumper output before suspend; 2.6.26 + jesse's patch from comment #28 Created attachment 16861 [details] intel_reg_dumper output after suspend; 2.6.26 + jesse's patch from comment #28 Here's the diff: --- x_regs_before.txt 2008-07-17 12:12:37.000000000 +0100 +++ x_regs_after.txt 2008-07-17 12:12:37.000000000 +0100 @@ -24,7 +24,7 @@ (II): DVOB_SRCDIM: 0x00000000 (II): DVOC_SRCDIM: 0x00000000 (II): PP_CONTROL: 0x00000001 (power target: on) -(II): PP_STATUS: 0xc0000008 (on, ready, sequencing idle) +(II): PP_STATUS: 0x4800000b (off, ready, sequencing idle) (II): PFIT_CONTROL: 0x80000668 (II): PFIT_PGM_RATIOS: 0x00000000 (II): PORT_HOTPLUG_EN: 0x00000000 @@ -68,7 +68,7 @@ (II): DSPBTILEOFF: 0x00000000 (II): PIPEBCONF: 0x80000000 (enabled, single-wide) (II): PIPEBSRC: 0x027f018f (640, 400) -(II): PIPEBSTAT: 0x80000202 (status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS) +(II): PIPEBSTAT: 0x80000242 (status: FIFO_UNDERRUN VSYNC_INT_STATUS LBLC_EVENT_STATUS VBLANK_INT_STATUS) (II): FPB0: 0x0003120c (n = 3, m1 = 18, m2 = 12) (II): FPB1: 0x00021207 (n = 2, m1 = 18, m2 = 7) (II): DPLL_B: 0x90026000 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 2, p2 = 14) Jon, can you try the drm tree? It's working well on my 855 test machine and is easier for me to test/generate diffs against. $ git clone git://git.freedesktop.org/git/mesa/drm $ cd linux-core $ make DRM_MODULES=i915 $ rmmod i915; rmmod drm; insmod ./drm.ko; insmod i915.ko # suspend/resume That should work as long as your kernel development headers are installed... Thanks, Jesse I tried the git tree today on my ThinkPad R61, but the backlight did not come on. However I also noticed that the suspend LED (the crescent moon) was still lit as well, so I'm not sure if the system is waking up or not. (In reply to comment #32) > Jon, can you try the drm tree? It's working well on my 855 test machine and > is > easier for me to test/generate diffs against. Sure. Actually this is easier for me too. I've tried that tree (HEAD 7cfdba2b30), the backlight does not come on. Would the register dumps be useful? Created attachment 16927 [details]
disable panel & restore all panel state first
this one tries to disable the panel first thing, since that should unlock some of the regs that we may be failing to restore.
Hello; tried that patch against refs/heads/master = b5cddbcc1536 ; I'm afraid it did not fix it. And I don't suppose the register diff changes either? I'm afraid not. Would it be helpful if I could find other people experiencing this? I know of a few X40 owners I might convince to test this too. Yeah it would be good to get some confirmation, but istr seeing another, similar report for another thinkpad but I don't remember the details. I wonder if there's some ACPI call we're missing here? The PP_STATUS regs definitely change in your config, but they're also undocumented in my 855 manual, so I wonder if there are some other bits we don't know about on this machine that are required to bring the panel back up... Heh, now I see it was comment #33 that had the other thinkpad report. It sounds like that's a different suspend/resume problem though, since the sleep light was still on... I've just had an email from someone who has reproduced this on a thinkpad x30. My understanding is that Jesse has confirmed this and has access to x40 hardware now. Right I just need to find some time to work on bugs... I have a few more theories to test now at least, and hw. Hi, I have a Thinkpad X40 (855 chipset) running Debian that used to parse two quirks passed to it from the GRUB command line in order for the panel to turn back on when the machine resumed from suspend (S3). Is there any chance we could go back to the old behaviour because I've been unable to use suspend for around 6 months now :( Does this still exist now? Unfortunately I loaned out my X40. I should have it back within the next four weeks so I will try bleeding-edge drm/i915 when I get it back. Created attachment 23409 [details]
fix suspend/resume on x40
Turns out we weren't saving & restoring a register that's important on this model. I'm not sure how many other machines it affects...
I think this one is fixed. |