2.6.29-rc2 regression: hibernation hang on eeepc-701 (method "platform" only)

2.6.29-rc2 regression: hibernation hang on eeepc-701 (method "platform" only)

[Alan Jenkins]

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"').

Let me know if you'd like more information.

Thanks
Alan

Re: 2.6.29-rc2 regression: hibernation hang on eeepc-701 (method "platform" only)

[Alan Jenkins]

On 1/18/09, Alan Jenkins <alan-jenkins@tuffmail.co.uk> 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"').

As a wild guess I tried "acpi_sleep=s4_nonvs", but it didn't help.

In fact it didn't seem to work.  The kernel log says that NVS was
still saved and restored.

$ dmesg | grep -i nvs
[    0.000000]  BIOS-e820: 000000001f790000 - 000000001f7d0000 (ACPI NVS)
[    0.000000] Kernel command line: root=/dev/sda2 ro resume=/dev/sda2
resume_offset=144480 quiet acpi_sleep=s4_nonvs
[   91.105449] PM: Saving platform NVS memory
[   91.106707] PM: Restoring platform NVS memory

Thanks
Alan

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

[Alan Jenkins]

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.

Alan


commit 571ff7584bb9e05fca0eb79752ae55a46faf3a98
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Wed Jan 7 13:05:05 2009 +0100

    PCI PM: Power-manage devices without drivers during suspend-resume

    PCI devices without drivers can be put into low power states during
    suspend with the help of pci_prepare_to_sleep() and prevented from
    generating wake-up events during resume with the help of
    pci_enable_wake().  However, it's better not to put bridges into
    low power states during suspend, because that might result in entire
    bus segments being powered off.

    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Pavel Machek <pavel@suse.cz>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

:040000 040000 6b6fb7bfa561583f14bdf55b084473dcf9cd1765
d72fbda87eff26db8f2574e868a793b79deb9f92 M      drivers

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

[Rafael J. Wysocki]

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?

Please retest with the appended patch applied.

Thanks,
Rafael


---
 drivers/pci/pci-driver.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: linux-2.6/drivers/pci/pci-driver.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-driver.c
+++ linux-2.6/drivers/pci/pci-driver.c
@@ -660,7 +660,10 @@ static int pci_pm_poweroff(struct device
 	if (pci_has_legacy_pm_support(pci_dev))
 		return pci_legacy_suspend(dev, PMSG_HIBERNATE);
 
-	if (drv && drv->pm && drv->pm->poweroff) {
+	if (!drv || !drv->pm)
+		return 0;
+
+	if (drv->pm->poweroff) {
 		error = drv->pm->poweroff(dev);
 		suspend_report_result(drv->pm->poweroff, error);
 	}

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

[Alan Jenkins]

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.

Thanks!
Alan

> Thanks,
> Rafael
>
>
> ---
>  drivers/pci/pci-driver.c |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/drivers/pci/pci-driver.c
> ===================================================================
> --- linux-2.6.orig/drivers/pci/pci-driver.c
> +++ linux-2.6/drivers/pci/pci-driver.c
> @@ -660,7 +660,10 @@ static int pci_pm_poweroff(struct device
>  	if (pci_has_legacy_pm_support(pci_dev))
>  		return pci_legacy_suspend(dev, PMSG_HIBERNATE);
>  
> -	if (drv && drv->pm && drv->pm->poweroff) {
> +	if (!drv || !drv->pm)
> +		return 0;
> +
> +	if (drv->pm->poweroff) {
>  		error = drv->pm->poweroff(dev);
>  		suspend_report_result(drv->pm->poweroff, error);
>  	}
>
>   

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

[Rafael J. Wysocki]

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?

Rafael

---
 drivers/pci/pci-driver.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: linux-2.6/drivers/pci/pci-driver.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-driver.c
+++ linux-2.6/drivers/pci/pci-driver.c
@@ -660,7 +660,10 @@ static int pci_pm_poweroff(struct device
 	if (pci_has_legacy_pm_support(pci_dev))
 		return pci_legacy_suspend(dev, PMSG_HIBERNATE);
 
-	if (drv && drv->pm && drv->pm->poweroff) {
+	if (!drv || !drv->pm)
+		return pci_set_power_state(dev, PCI_D3hot);
+
+	if (drv->pm->poweroff) {
 		error = drv->pm->poweroff(dev);
 		suspend_report_result(drv->pm->poweroff, error);
 	}

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

[Alan Jenkins]

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

Thanks
Alan

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

[Rafael J. Wysocki]

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. ;-)

Thanks,
Rafael

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

[Alan Jenkins]

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?  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.  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.

Thanks
Alan

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

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

[Alan Jenkins]

Rafael J. Wysocki wrote:
> 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.
>   

If I have a kernel mode-setting driver, won't that bind to the graphics 
device?  Then the device would be power managed, so it would trigger the 
same problem.

I guess I can test this rather than speculating.  If my concern is 
valid, then using intelfb should have the same effect.

> 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.
>   

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

[Alan Jenkins]

Alan Jenkins wrote:
> Rafael J. Wysocki wrote:
>> 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.
>>   
>
> If I have a kernel mode-setting driver, won't that bind to the
> graphics device?  Then the device would be power managed, so it would
> trigger the same problem.
>
> I guess I can test this rather than speculating.  If my concern is
> valid, then using intelfb should have the same effect.
>

Ok, it doesn't hang with intelfb (and not power managing devices without
drivers), so I guess there's nothing to worry about.

Alan

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

[Jesse Barnes]

On Saturday, January 24, 2009 3:15 am 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?  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).

Sounds like the BIOS pokes at gfx during S3 (then hopefully puts it into D3) 
but doesn't bother when going into S4, that's kind of strange, but maybe it's 
spec'd somewhere.

> Also it sounds like it would break when the linux kernel mode setting
> driver is used.  I thought kernel mode setting was going to make suspend
> _more_ reliable :-).

In the kernel mode setting case (and also in the X case) the device should 
have an associated kernel driver.  If there are still problems when one is 
loaded, we might have to figure out what to do with the "dummy" video device 
(device 2:1).

> 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.

Yeah.

-- 
Jesse Barnes, Intel Open Source Technology Center

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

[Rafael J. Wysocki]

On Saturday 24 January 2009, Jesse Barnes wrote:
> On Saturday, January 24, 2009 3:15 am 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?  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).
> 
> Sounds like the BIOS pokes at gfx during S3 (then hopefully puts it into D3) 
> but doesn't bother when going into S4, that's kind of strange, but maybe it's 
> spec'd somewhere.

Well, I think the BIOS doesn't touch the graphics during suspend to RAM and
resume, because it wants to save time.  ISTR, there is a limit on the amount
of time the BIOS can spend initializing devices and it doesn't get Windows
certification if that limit is not satisfied.

There's no such limit for hibernation, though, and the BIOS probably tries to
do something with the graphics before entering S4, but it should first check if
it's already in D3.

Thanks,
Rafael