Re: [RFT] x86 acpi: normalize segment descriptor register on resume

Ingo Molnar
2008-07-13T09:16:19Z

* Rafael J. Wysocki <rjw@sisk.pl> wrote:

> > 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.
>
> The first possibility is that the quirks actually didn't work on your
> system with 2.6.26-rc before commit 4b4f7280 at all for some obscure
> reason and that commit made them work again which in turn resulted in
> the breakage.
>
> The second possibility is that commit 4b4f7280 actually broke those
> quirks.
>
> I'm not sure if it's worth the effort to check which of the above
> really happened. After all, you can suspend and resume the box
> without any quirks now. ;-)

which is the ideal situation :-)

we still need to find the HAL quirk and disable it, right?

Ingo