http://people.redhat.com/davej/kernels/Fedora/devel/
If you are running rawhide FC5 on any architecture, please update to the latest kernel here often, reboot and test. We need your feedback very quickly if a new kernel here causes regressions, because we are rapidly approaching what will become the FC5 final kernel.
If your box is SMP or dual-core, please test booting the uniprocessor and multi-processor kernels if your architecture has both kernel builds. In cases where we have separate uniprocessor and SMP kernels (x86 and ppc), we need both tested because the installer uses uniprocessor while your yum updated system might not by default.
Please keep in mind that we are only interested in regressions in things that would break installation and booting at this point. If issue has always existed in past Fedora, then it would not be useful to push it again now. PLEASE REPORT ONLY REGRESSIONS
Thank you, Warren Togami wtogami@redhat.com
Hello Warren,
I do not have much time to test but please try to test your kernel with the parameter init 3 in the grub.conf My kernel (xen) use to hang there. I'm sorry but I'm too busy to provide more details at the moment.
I'm not sure if init 3 is official kernel parameter or just a test parameter.
Cheers,
Jan
On 3/8/06, Warren Togami wtogami@redhat.com wrote:
http://people.redhat.com/davej/kernels/Fedora/devel/
If you are running rawhide FC5 on any architecture, please update to the latest kernel here often, reboot and test. We need your feedback very quickly if a new kernel here causes regressions, because we are rapidly approaching what will become the FC5 final kernel.
If your box is SMP or dual-core, please test booting the uniprocessor and multi-processor kernels if your architecture has both kernel builds. In cases where we have separate uniprocessor and SMP kernels (x86 and ppc), we need both tested because the installer uses uniprocessor while your yum updated system might not by default.
Please keep in mind that we are only interested in regressions in things that would break installation and booting at this point. If issue has always existed in past Fedora, then it would not be useful to push it again now. PLEASE REPORT ONLY REGRESSIONS
Thank you, Warren Togami wtogami@redhat.com
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Not sure if it's the kernel or pm-utils or something, but hibernation used to work perfectly on my Gateway 4540GZ, when kernel revision was 1928, 1955, 1966. Now (with latest rawhide kernel) it boots OK after hibernation, but then it can't start the X server (video card state not restored properly?)
-- alain.
On 3/8/06, Warren Togami wtogami@redhat.com wrote:
http://people.redhat.com/davej/kernels/Fedora/devel/
If you are running rawhide FC5 on any architecture, please update to the latest kernel here often, reboot and test. We need your feedback very quickly if a new kernel here causes regressions, because we are rapidly approaching what will become the FC5 final kernel.
If your box is SMP or dual-core, please test booting the uniprocessor and multi-processor kernels if your architecture has both kernel builds. In cases where we have separate uniprocessor and SMP kernels (x86 and ppc), we need both tested because the installer uses uniprocessor while your yum updated system might not by default.
Please keep in mind that we are only interested in regressions in things that would break installation and booting at this point. If issue has always existed in past Fedora, then it would not be useful to push it again now. PLEASE REPORT ONLY REGRESSIONS
Thank you, Warren Togami wtogami@redhat.com
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
On Wed, 2006-03-08 at 08:51 -0800, Alain Mellan wrote:
Not sure if it's the kernel or pm-utils or something, but hibernation used to work perfectly on my Gateway 4540GZ, when kernel revision was 1928, 1955, 1966. Now (with latest rawhide kernel) it boots OK after hibernation, but then it can't start the X server (video card state not restored properly?)
That's really weird -- video state on resume from hibernate should be *exactly* the same as if you'd just rebooted. We're not fiddling with it, and the machine _is_ doing a cold boot.
That's really weird -- video state on resume from hibernate should be *exactly* the same as if you'd just rebooted. We're not fiddling with it, and the machine _is_ doing a cold boot.
Yes. In some cases, the server starts, but the video is not initialized properly. Window redrawingis not done properly. I added chvt/fgconsole in /etc/pm/functions-intel, it does a bit better, but still sometimes the video is not initialized properly.
Also, suspend/resume doesn't work. The video doesn't come back.
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
-- alain.
On Fri, 2006-03-10 at 10:12 -0800, Alain Mellan wrote:
That's really weird -- video state on resume from hibernate should be *exactly* the same as if you'd just rebooted. We're not fiddling with it, and the machine _is_ doing a cold boot.
Yes. In some cases, the server starts, but the video is not initialized properly. Window redrawingis not done properly.
"the server starts" meaning what? The X server? Or are you saying sometimes video is messed up when you power on the machine, regardless of hibernate?
I added chvt/fgconsole in /etc/pm/functions-intel, it does a bit better,
I wouldn't expect this to make any difference at all -- we're already switching VTs to an unalocated one before suspend (or hibernate), and switching back after resume.
So when it does "a bit better", what exactly are you seeing that happens differently?
Are you using intelfb, or just the normal text mode?
"the server starts" meaning what? The X server? Or are you saying sometimes video is messed up when you power on the machine, regardless of hibernate?
No, no, the video gets messed up after hibernate only. I get two behaviors: either the X server starts and it can't redraw windows properly (i.e. xterm background is all black, windows are not redrawn when moved), or after 6 tries the X server stops and tell me gdm is disabled. Sometimes even in text mode the display is garbled.
I added chvt/fgconsole in /etc/pm/functions-intel, it does a bit better,
I wouldn't expect this to make any difference at all -- we're already switching VTs to an unalocated one before suspend (or hibernate), and switching back after resume.
OK. You are right, I thought it was working yesterday, and today I got the same problem again.
So when it does "a bit better", what exactly are you seeing that happens differently?
I meant, I thought I could do more than one hibernate cycle in a row without crashing the video. I think I did 4 cycles before it crashed this morning.
Are you using intelfb, or just the normal text mode?
Just normal text. How to use intelfb?
What other information do you think would help?
-- alain.
Peter Jones skrev:
On Fri, 2006-03-10 at 10:12 -0800, Alain Mellan wrote:
That's really weird -- video state on resume from hibernate should be *exactly* the same as if you'd just rebooted. We're not fiddling with it, and the machine _is_ doing a cold boot.
Yes. In some cases, the server starts, but the video is not initialized properly. Window redrawingis not done properly.
"the server starts" meaning what? The X server? Or are you saying sometimes video is messed up when you power on the machine, regardless of hibernate?
I added chvt/fgconsole in /etc/pm/functions-intel, it does a bit better,
I wouldn't expect this to make any difference at all -- we're already switching VTs to an unalocated one before suspend (or hibernate), and switching back after resume.
So when it does "a bit better", what exactly are you seeing that happens differently?
Are you using intelfb, or just the normal text mode?
How do I tell, and how do I switch between them? Anyhow, what's happening in whatever mode I am using is that /usr/sbin/vbetool post never terminates.
Regards Uno Engborg
On Fri, 2006-03-10 at 22:09 +0100, Uno Engborg wrote:
Peter Jones skrev:
Are you using intelfb, or just the normal text mode?
How do I tell, and how do I switch between them?
If you don't know, you're not using intelfb. And that's probably good, at least for now.
Anyhow, what's happening in whatever mode I am using is that /usr/sbin/vbetool post never terminates.
Er, we shouldn't be _running_ vbetool post on resume-from-hibernate currently. What version of pm-utils is installed, and what's in /etc/sysconfig/pm ?
On 3/10/06, Peter Jones pjones@redhat.com wrote:
On Fri, 2006-03-10 at 22:09 +0100, Uno Engborg wrote:
Peter Jones skrev:
Are you using intelfb, or just the normal text mode?
How do I tell, and how do I switch between them?
If you don't know, you're not using intelfb. And that's probably good, at least for now.
Anyhow, what's happening in whatever mode I am using is that /usr/sbin/vbetool post never terminates.
Er, we shouldn't be _running_ vbetool post on resume-from-hibernate currently. What version of pm-utils is installed, and what's in /etc/sysconfig/pm ?
-- Peter
Make sure HIBERNATE_RESUME_POST_VIDEO="no" in /etc/sysconfig/pm
tom -- Tom London
As for me, I'm running pm-utils-0.13.1
/etc/sysconfig/pm says SUSPEND_MODULES="button" HIBERNATE_RESUME_POST_VIDEO="no"
in /etc/pm/functions-intel, I have now:
resume_video() { ( /usr/sbin/vbetool post /usr/sbin/vbetool vbestate restore < /var/run/vbestate /usr/sbin/vbetool dpms on ) > /dev/null 2&1 }
I guess I'll try again without the vbetool post and see how it works?
On Fri, 2006-03-10 at 14:12 -0800, Alain Mellan wrote:
As for me, I'm running pm-utils-0.13.1
/etc/sysconfig/pm says SUSPEND_MODULES="button" HIBERNATE_RESUME_POST_VIDEO="no"
in /etc/pm/functions-intel, I have now:
resume_video() { ( /usr/sbin/vbetool post /usr/sbin/vbetool vbestate restore < /var/run/vbestate /usr/sbin/vbetool dpms on ) > /dev/null 2&1 }
I guess I'll try again without the vbetool post and see how it works?
But /etc/pm/hooks/20video shouldn't run that function on hibernate's resume path.
There, it's done it again. I removed vbetool post, and coming out of hibernation I see the busy cursor on and off a couple of time, and then pooof! I lost control of the laptop, even though I can see some disk activity. I remember I never had the problem with earlier versions of rawhide; I think before updating pm-utils it went well (many hibernations cycles without a hitch). Anybody happen to have the old rpm? It may be worth a try.
Added vbetool post again, and now the video doesn't work correctly (windows not redrawn correctly), although I can Alt-Ctrl-1 to get a console.
Any idea?
On Fri, 2006-03-10 at 14:12 -0800, Alain Mellan wrote:
As for me, I'm running pm-utils-0.13.1
/etc/sysconfig/pm says SUSPEND_MODULES="button" HIBERNATE_RESUME_POST_VIDEO="no"
in /etc/pm/functions-intel, I have now:
resume_video() { ( /usr/sbin/vbetool post /usr/sbin/vbetool vbestate restore < /var/run/vbestate /usr/sbin/vbetool dpms on ) > /dev/null 2&1 }
I guess I'll try again without the vbetool post and see how it works?
Neeeever mind, Try this patch:
Index: 20video =================================================================== RCS file: /cvs/devel/pm-utils/pm/hooks/20video,v retrieving revision 1.2 retrieving revision 1.3 diff -u -p -r1.2 -r1.3 --- /etc/pm/hooks/20video 28 Feb 2006 17:04:20 -0000 1.2 +++ /etc/pm/hooks/20video 10 Mar 2006 22:34:06 -0000 1.3 @@ -19,7 +19,7 @@ case "$1" in suspend_video ;; resume) - if [ "x$PM_MODE" != "hibernate" -o \ + if [ "x$PM_MODE" != "xhibernate" -a \ "x$HIBERNATE_RESUME_POST_VIDEO" == "xyes" ]; then resume_video fi
(this will be pm-utils-0.14-1)
Patched 20video. 4 hibernation cycles in a row, so far so good ...
Thanks.
-- alain.
On 3/10/06, Peter Jones pjones@redhat.com wrote:
On Fri, 2006-03-10 at 14:12 -0800, Alain Mellan wrote:
As for me, I'm running pm-utils-0.13.1
/etc/sysconfig/pm says SUSPEND_MODULES="button" HIBERNATE_RESUME_POST_VIDEO="no"
in /etc/pm/functions-intel, I have now:
resume_video() { ( /usr/sbin/vbetool post /usr/sbin/vbetool vbestate restore < /var/run/vbestate /usr/sbin/vbetool dpms on ) > /dev/null 2&1 }
I guess I'll try again without the vbetool post and see how it works?
Neeeever mind, Try this patch:
Index: 20video
RCS file: /cvs/devel/pm-utils/pm/hooks/20video,v retrieving revision 1.2 retrieving revision 1.3 diff -u -p -r1.2 -r1.3 --- /etc/pm/hooks/20video 28 Feb 2006 17:04:20 -0000 1.2 +++ /etc/pm/hooks/20video 10 Mar 2006 22:34:06 -0000 1.3 @@ -19,7 +19,7 @@ case "$1" in suspend_video ;; resume)
if [ "x$PM_MODE" != "hibernate" -o \
if [ "x$PM_MODE" != "xhibernate" -a \ "x$HIBERNATE_RESUME_POST_VIDEO" == "xyes" ]; then resume_video fi
(this will be pm-utils-0.14-1)
-- Peter, amazed at the number of people who read this code and didn't catch that.
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Peter Jones skrev:
On Fri, 2006-03-10 at 22:09 +0100, Uno Engborg wrote:
Peter Jones skrev:
Are you using intelfb, or just the normal text mode?
How do I tell, and how do I switch between them?
If you don't know, you're not using intelfb. And that's probably good, at least for now.
Anyhow, what's happening in whatever mode I am using is that /usr/sbin/vbetool post never terminates.
Er, we shouldn't be _running_ vbetool post on resume-from-hibernate currently. What version of pm-utils is installed, and what's in /etc/sysconfig/pm ?
pm-utils-0.13-1
/etc/sysconfig/pm: SUSPEND_MODULES="button"
HIBERNATE_RESUME_POST_VIDEO="no"
Regards Uno Engborg
Peter Jones skrev:
On Sat, 2006-03-11 at 00:42 +0100, Uno Engborg wrote:
pm-utils-0.13-1
/etc/sysconfig/pm: SUSPEND_MODULES="button"
HIBERNATE_RESUME_POST_VIDEO="no"
You want the patch I posted to this list.
I did apply the patch but still a black screen on resume.
To debug, I added some echo statements to the patched 20video so that it looks like this:
#!/bin/bash
. /etc/pm/functions
case "$(get_video_type)" in ATI) . /etc/pm/functions-ati ;; nVidia) . /etc/pm/functions-nvidia ;; Intel) . /etc/pm/functions-intel ;; esac echo $1>/tmp/20video case "$1" in suspend) suspend_video ;; resume) if [ "x$PM_MODE" != "xhibernate" -a \ "x$HIBERNATE_RESUME_POST_VIDEO" == "xyes" ]; then resume_video echo "In if">>/tmp/20video echo $PM_MODE>>/tmp/20video echo $HIBERNATE_RESUME_POST_VIDEO>>/tmp/20video echo "---------------">>/tmp/20video fi echo "After if">>/tmp/20video ;; *) ;; esac
exit $?
In /tmp/20video I get the following:
resume After if
Is this really what's supposed to happen?
Regards Uno Engborg