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 for Android: free password hash cracker in your pocket

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

Message-ID: <497B249B.6040104@tuffmail.co.uk>
Date:	Sat, 24 Jan 2009 14:24:27 +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

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