On Saturday 24 January 2009, Alan Jenkins wrote:
> Rafael J. Wysocki wrote:
> > On Friday 23 January 2009, Alan Jenkins wrote:
> >
> >> Rafael J. Wysocki wrote:
> >>
> >>> On Thursday 22 January 2009, Alan Jenkins wrote:
> >>>
> >>>
> >>>> Rafael J. Wysocki wrote:
> >>>>
> >>>>
> >>>>> On Thursday 22 January 2009, Alan Jenkins wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Alan Jenkins wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Hibernation hangs just after writing the image. With s2disk I can see
> >>>>>>> this from the console messages. The same hang happens with kernel
> >>>>>>> swsusp ('echo disk | sudo tee /sys/power/state'), and I can see that
> >>>>>>> the image has been written from the HDD led.
> >>>>>>>
> >>>>>>> In either case, I can still hard-power-off and resume from hibernation.
> >>>>>>>
> >>>>>>> It doesn't hang if I use the shutdown method (either 'echo shutdown |
> >>>>>>> sudo tee /sys/power/disk' or 's2disk -P "shutdown method=shutdown"').
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> I've bisected this to commit 571ff7584bb9e05fca0eb79752ae55a46faf3a98.
> >>>>>> It doesn't revert cleanly from RC2.
> >>>>>>
> >>>>>> I think it's distinct from the other two reported suspend regressions.
> >>>>>> I'm not using acpi-cpufreq, and the issue doesn't affect resume.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> It looks distinct.
> >>>>>
> >>>>> Do you suspend this box to RAM and does it work?
> >>>>>
> >>>>>
> >>>>>
> >>>> Yes, I do use STR on it occasionally, and it still works in RC2.
> >>>>
> >>>>
> >>>>
> >>>>> Please retest with the appended patch applied.
> >>>>>
> >>>>>
> >>>>>
> >>>> That fixes it.
> >>>>
> >>>>
> >>> OK, it won't hurt to apply it.
> >>>
> >>> Still, the hardware or the BIOS in your box seems to be broken, or both, so I'd
> >>> like to debug it a bit more if you don't mind.
> >>>
> >>> Can you please test the patch below instead of the previous one?
> >>>
> >>>
> >> It hangs at the same point as the unpatched RC2. As before, it doesn't
> >> hang if I use "shutdown" instead of "platform".
> >>
> >> Going by sysfs, I have 4 PCI devices without a kernel driver.
> >>
> >> 8086:2592 Mobile 915 Express Graphics Controller
> >> 8086:2792 Mobile 915 Express Graphics Controller (driven by X)
> >> 8086:2448 82801 Mobile PCI Bridge
> >> 8086:2641 82801FBM (ICH6M) LPC Interface Bridge
> >>
> >
> > The bridges shouldn't be affected, so I bet on the graphics.
> >
> > It seems that the BIOS doesn't expect it to be in D3 while entering S4,
> > although it apparently doesn't mind it to be in D3 while entering S3.
> >
> > I blame the Asus BIOS writers. ;-)
> >
>
> Wouldn't Windows normally put it into D3?
It need not put it into D3hot if it's going to remove power from it.
> There are many reports of successful hibernation under Windows on this
> hardware. The motivation being that S3 drains the battery in <24 hours.
> (Fewer people hibernate on linux because you only have a 4G SSD, so a swap
> partition wastes a lot of space, and most installers can't set up swap
> files).
>
> Also it sounds like it would break when the linux kernel mode setting
> driver is used.
Why would it break? This is the last phase of hibernation, right before
powering off things.
> I thought kernel mode setting was going to make suspend _more_ reliable :-).
>
> So in the long term I think we either need to find a more specific root
> cause, or implement a PCI quirk for this quirky machine.
Well, that would be preferable. However, since we didn't power manage devices
without drivers during hibernation before the patch that broke it for you, I
think we can safely go back to doing this.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
