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]

Message-Id: <200901241443.14930.rjw@sisk.pl>
Date:	Sat, 24 Jan 2009 14:43:14 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Jenkins <alan-jenkins@...fmail.co.uk>
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

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/