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: <200901240827.05557.jbarnes@virtuousgeek.org>
Date:	Sat, 24 Jan 2009 08:27:05 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Alan Jenkins <alan-jenkins@...fmail.co.uk>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, kernel-testers@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	Pavel Machek <pavel@...e.cz>
Subject: Re: BISECTED: 2.6.29-rc2 regression: hibernation hang on eeepc-701

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