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: <1172847345.5821.42.camel@gullible>
Date:	Fri, 02 Mar 2007 09:55:45 -0500
From:	Ben Collins <ben.collins@...ntu.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Tim Gardner <timg@....com>, nigel@...el.suspend2.net,
	linux-kernel@...r.kernel.org
Subject: Re: Resume from S2R fails after dpm_resume()

On Fri, 2007-03-02 at 15:39 +0100, Pavel Machek wrote:
> On Fri 2007-03-02 07:25:49, Tim Gardner wrote:
> > Pavel Machek wrote:
> > > Hi!
> > > 
> > >> I instrumented 2.6.21-rc1 base/power/resume.c device_resume() with
> > >> TRACE_RESUME(0) as the last statement in the function. Sure enough it
> > >> was the last hash value in the RTC after a hard reboot when resume failed:
> > >>
> > >> [   12.028820]   hash matches drivers/base/power/resume.c:104
> > >>
> > >> The machine appears to be absolutely wedged after initiating resume by
> > >> pressing the power button. The disk flashes for a half second or so,
> > >> then thats it.
> > >>
> > >> It is a Dell XPS, BIOS rev A04. I'm using 'echo 1 > /sys/power/pm_trace;
> > >> echo mem > /sys/power/state' to initiate the S2R sequence.
> > >>
> > >> Any suggestions on where to go from here?
> > > 
> > > Did it work ok in 2.6.20? Can you try to get video working/get serial
> > > console/something?
> > > 									Pavel
> > 
> > Pavel,
> > 
> > The last version that worked well was Ubuntu Edgy (2.6.17). It was
> > broken by 2.6.18. I have not started the 'git bisect' process, instead
> > I've been trying to figure out why it doesn't work in 2.6.21-rc2. Using
> > the TRACE_RESUME macro I've drilled down to
> > kernel/printk.c:__call_console_drivers. So far the last trace info that
> > I have is just before the call to con->write(). I'm trying to figure out
> > what driver has registered as the console (intel_agp or agpgart?).
> > 
> > Am I banging my head on a known problem?
> 
> 2.6.21-rc* is known broken (in more than 1 way). I'd suggest playing
> with 2.6.20.

It's broken for him in 2.6.20 too, which led him to test 2.6.21-rc, and
some vanilla kernels back to 2.6.18. Everything past 2.6.17 is broken
for him.

-- 
Ubuntu:    http://www.ubuntu.com/
Linux1394: http://www.linux1394.org/

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ