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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 24 Jan 2009 14:01:05 +0000
From:	Alan Jenkins <alan-jenkins@...fmail.co.uk>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	kernel-testers@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pm@...ts.linux-foundation.org, Pavel Machek <pavel@...e.cz>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: BISECTED: 2.6.29-rc2 regression: hibernation hang on eeepc-701

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/