Messages in this thread | | | Date | Sun, 13 Jul 2008 10:56:03 +0200 | From | Pavel Machek <> | Subject | Re: [RFT] x86 acpi: normalize segment descriptor register on resume |
| |
Hi!
> > > Is there an Intel graphics in your box? > > > > Yes. > > > > > > > >> -rc8 and -rc9 with the original patch 4b4f7280 resume fine no matter how > > >> I suspend. > > > > > > That's _really_ strange. > > > > > > In fact I have only one explanation, which is that the Gnome suspend button > > > causes some user-space quirks to be applied, which are harmful and break the > > > resume. Also, without commit 4b4f7280 those quirks might have not been really > > > executed. Peter, does it sound reasonable? > > > > Bingo. It's a HAL quirk. > > > > Testing from the console (not X): > > > > With 4b4f7280: > > # echo mem >/sys/power/state -- works fine > > > > # echo 3 >/proc/sys/kernel/acpi_video_flags > > # echo mem >/sys/power state -- fails to resume > > > > Without 4b4f7280: > > # echo mem >/sys/power/state -- works fine > > > > # echo 3 >/proc/sys/kernel/acpi_video_flags > > # echo mem >/sys/power state -- works fine > > > > So HAL contains an apparently unnecessary quirk for my laptop, and > > 4b4f7280 breaks that quirk. Of course, it's entirely possible that > > 4b4f7280 is 100% correct, but that the quirk only worked by accident and > > 4b4f7280 broke the call into video BIOS. > > We've had reports from users of Intel graphics and the i915 driver that > previously working quirks started to break their systems with 2.6.26-rc, but > instead the plain "echo mem > /sys/power/state" started to work for them. > Your system may be one of these, but I wonder what the effect of commit > 4b4f7280 is.
In such case, you could verify by disabling intel framebuffer and just using plain VGA driver (or vesafb).
Breaking video bios calls would be bad. Pavel
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |