From: Pavel Machek <pavel@ucw.cz>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: linux-pm@osdl.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Adrian Bunk <bunk@stusta.de>
Subject: Re: Funky "Blue screen" issue while rebooting from X with 2.6.18-git21
Date: Sun, 8 Oct 2006 23:51:10 +0200 [thread overview]
Message-ID: <20061008215110.GF4152@elf.ucw.cz> (raw)
In-Reply-To: <9a8748490610081446y6103a9b1o491ce87250beabfb@mail.gmail.com>
Hi!
> >> > I have a strange "problem" with 2.6.18-git21 that I've never had with
> >> > any previous kernel. If I open up an xterm in X, su to root and
> >> > 'reboot' (or 'shutdown -r now') I instantly get a blue screen that
> >> > persists until the box actually reboots.
> >>
> >> Pavel, is this a known issue or should Jesper bisect?
> >
> >Jesper should show it is kernel problem and not userland race.
> >
>
> Jesper will try to do that ;-)
>
>
> >If userspace does kill -15 -1; kill -9 -1, and X fails to shut down in
> >time, it is userland problem ('should wait for X to shut down').
> >
>
> Well, I just checked my initscript that is run when going into
> runlevels 0 & 6, and it does this :
>
> (...)
>
> # Kill all processes.
> # INIT is supposed to handle this entirely now, but this didn't always
> # work correctly without this second pass at killing off the processes.
> # Since INIT already notified the user that processes were being killed,
> # we'll avoid echoing this info this time around.
> if [ ! "$1" = "fast" ]; then # shutdown did not already kill all processes
> /sbin/killall5 -15
> /bin/sleep 5
> /sbin/killall5 -9
> fi
...so, if X takes more than five seconds to shut down, you kill it
with -9, resulting in blue screen. Too bad, and not an kernel problem.
Try inserting something like
while ps -aux | grep myXserver;
sleep 1;
done
alternatively, remove/shorten the sleep and you should experience blue
screen in 2.6.17.
> kernels, but since somewhere in the 2.6.18-rc series I've experienced
> this "blue screen" problem once in a while and I've also had a problem
> with the screen going all white when switching from X to a plain tty
> and back (once it goes white it stays that way permanently until I
> reboot) - I *never* see those issues when running 2.6.17.x and
> earlier.
Maybe something got slower in 2.6.18?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: Adrian Bunk <bunk@stusta.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-pm@osdl.org
Subject: Re: Funky "Blue screen" issue while rebooting from X with 2.6.18-git21
Date: Sun, 8 Oct 2006 23:51:10 +0200 [thread overview]
Message-ID: <20061008215110.GF4152@elf.ucw.cz> (raw)
In-Reply-To: <9a8748490610081446y6103a9b1o491ce87250beabfb@mail.gmail.com>
Hi!
> >> > I have a strange "problem" with 2.6.18-git21 that I've never had with
> >> > any previous kernel. If I open up an xterm in X, su to root and
> >> > 'reboot' (or 'shutdown -r now') I instantly get a blue screen that
> >> > persists until the box actually reboots.
> >>
> >> Pavel, is this a known issue or should Jesper bisect?
> >
> >Jesper should show it is kernel problem and not userland race.
> >
>
> Jesper will try to do that ;-)
>
>
> >If userspace does kill -15 -1; kill -9 -1, and X fails to shut down in
> >time, it is userland problem ('should wait for X to shut down').
> >
>
> Well, I just checked my initscript that is run when going into
> runlevels 0 & 6, and it does this :
>
> (...)
>
> # Kill all processes.
> # INIT is supposed to handle this entirely now, but this didn't always
> # work correctly without this second pass at killing off the processes.
> # Since INIT already notified the user that processes were being killed,
> # we'll avoid echoing this info this time around.
> if [ ! "$1" = "fast" ]; then # shutdown did not already kill all processes
> /sbin/killall5 -15
> /bin/sleep 5
> /sbin/killall5 -9
> fi
...so, if X takes more than five seconds to shut down, you kill it
with -9, resulting in blue screen. Too bad, and not an kernel problem.
Try inserting something like
while ps -aux | grep myXserver;
sleep 1;
done
alternatively, remove/shorten the sleep and you should experience blue
screen in 2.6.17.
> kernels, but since somewhere in the 2.6.18-rc series I've experienced
> this "blue screen" problem once in a while and I've also had a problem
> with the screen going all white when switching from X to a plain tty
> and back (once it goes white it stays that way permanently until I
> reboot) - I *never* see those issues when running 2.6.17.x and
> earlier.
Maybe something got slower in 2.6.18?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2006-10-08 21:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-04 20:16 Funky "Blue screen" issue while rebooting from X with 2.6.18-git21 Jesper Juhl
2006-10-08 17:47 ` Adrian Bunk
2006-10-08 17:47 ` Adrian Bunk
2006-10-08 18:34 ` Pavel Machek
2006-10-08 21:46 ` Jesper Juhl
2006-10-08 21:46 ` Jesper Juhl
2006-10-08 21:51 ` Pavel Machek [this message]
2006-10-08 21:51 ` Pavel Machek
2006-10-08 22:49 ` Jesper Juhl
2006-10-08 22:49 ` Jesper Juhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061008215110.GF4152@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=bunk@stusta.de \
--cc=jesper.juhl@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.