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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Resume from S2R fails after dpm_resume()
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Resume from S2R fails after dpm_resume()
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Resume from S2R fails after dpm_resume()
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 [EMAIL PROTECTED] www.tpi.com OR 503-601-0234 x102 MT 406-443-5357 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Resume from S2R fails after dpm_resume()
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Resume from S2R fails after dpm_resume()
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Resume from S2R fails after dpm_resume()
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 [EMAIL PROTECTED] www.tpi.com OR 503-601-0234 x102 MT 406-443-5357 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Resume from S2R fails after dpm_resume()
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Resume from S2R fails after dpm_resume()
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Resume from S2R fails after dpm_resume()
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 [EMAIL PROTECTED] www.tpi.com OR 503-601-0234 x102 MT 406-443-5357 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Resume from S2R fails after dpm_resume()
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 [EMAIL PROTECTED] www.tpi.com OR 503-601-0234 x102 MT 406-443-5357 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
