Re: BISECTED: 2.6.29-rc2 regression: hibernation hang on eeepc-701

[Rafael J. Wysocki]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/