Resume from S2R fails after dpm_resume()

Resume from S2R fails after dpm_resume()

[Tim Gardner]

Gentlemen,

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?

rtg
-- 
Tim Gardner timg@tpi.com www.tpi.com
OR 503-601-0234 x102 MT 406-443-5357

Re: Resume from S2R fails after dpm_resume()

[Pavel Machek]

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Resume from S2R fails after dpm_resume()

[Tim Gardner]

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?

rtg

-- 
Tim Gardner timg@tpi.com www.tpi.com
OR 503-601-0234 x102 MT 406-443-5357

Re: Resume from S2R fails after dpm_resume()

[Pavel Machek]

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.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Resume from S2R fails after dpm_resume()

[Ben Collins]

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/

Re: Resume from S2R fails after dpm_resume()

[Pavel Machek]

On Fri 2007-03-02 09:55:45, Ben Collins wrote:
> 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.

Yep, I understood.

But 2.6.20 tends to work for people while 2.6.21-rc is broken for
people, and even broken for me (*). So I suggest to debug
2.6.20. Debugging three different problems at the same time is not
fun.

(*) timing is wrong after resume, disk spinup waits for timeout.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Resume from S2R fails after dpm_resume()

[Nigel Cunningham]

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