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.
>
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
