linux-kernel - Re: Resume from S2R fails after dpm

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] [day] [month] [year] [list]

Message-Id: <1172871139.18544.87.camel@nigel.suspend2.net>
Date:	Sat, 03 Mar 2007 08:32:19 +1100
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Tim Gardner <timg@....com>
Cc:	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
	Ben Collins <ben.collins@...ntu.com>
Subject: Re: Resume from S2R fails after dpm_resume()

Hi.

On Fri, 2007-03-02 at 07:25 -0700, 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?

Tim, it's possible that the problem you're seeing is completely
different to the one Pavel is looking for. Given that you're down to
looking in console write code, I wonder if it's related to the changes
to console suspending that were done around that time. I'd suggest
either looking in LKML or Linux-PM archives for a commit related to
suspending the console, or doing your git bisect.

Regards,

Nigel

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