Messages in this thread |  | | | Date | Sat, 12 Jul 2008 19:11:10 -0400 | | From | Andy Lutomirski <> | | Subject | Re: [RFT] x86 acpi: normalize segment descriptor register on resume |
| |
Rafael J. Wysocki wrote: > On Saturday, 12 of July 2008, Andy Lutomirski wrote: >> Rafael J. Wysocki wrote: >>> On Saturday, 12 of July 2008, Andy Lutomirski wrote: >>>> My Lenovo X61s fails to resume if I suspend it from within X, on both >>>> 2.6.26-rc9 and recent wireless-testing. 2.6.26-rc8 is fine, as is >>>> wireless-testing with 4b4f7280 reverted. My in-progress bisect between >>>> -rc8 and -rc9 is also consistent with this being the problem. >>>> >>>> The symptom is that, when I push the power button to resume, the hard >>>> drive light turns on, the fan turns on, then the hard drive light turns >>>> off, the sleep light stays on, and the fan keeps running. Sometimes the >>>> battery light will blink off very briefly (1/4 sec, maybe) every few >>>> seconds. The system is locked hard at this point. >>>> >>>> I'm using Ubuntu Hardy userspace. >>> Well, that's bad. >>> >>> There is the bugzilla entry at http://bugzilla.kernel.org/show_bug.cgi?id=11064 >>> for this bug and you've just confirmed my suspicion that this particular >>> commit is to blame. >>> >>> Can you please see if the appended patch changes anything? >> More correctly: >> >> If I suspend by typing pm-suspend or echo mem >/sys/power/state, then it >> resumes just fine. If I log in to Gnome and push the suspend button, >> then it does not resume. This seems to be the case with or without your >> patch. > > 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.
--Andy
|  |