Xwindow hang on osr507
Roger Cornelius
When exiting from a console X session, X hangs approximately 75% of the
time. It appears to be exiting, but I end up with a blank root window
with the crosshatch pattern and an "x" as the mouse pointer. I can move
the pointer but nothing else. Alt-Fkey or ctrl-prtscreen will switch
away, but I just get a blank screen. Attempting to switch to another
tty again results in a beep.
The systems:
IBM x345
SCO odt window manager
On board video identified by mkdev graphics as:
ATI RAGE PRO/LT-PRO/XL/Mobility (P/M/M1)
Also tried an ATI Xpert@Play card with same results.
Dell Precision 330
fvwm2 window manager
Matrox Millenium G200 (configured for Matrox G100/G200/G400 series
adapters)
Both systems have osr507mp and osr507up installed.
I've tried various resolution configurations in mkdev graphics but no
change in the problem.
After the hang and from another login, I can kill the X process which
results in a black or sometimes garbled screen. I can log in again,
though I can't see what's happening on the screen. On the Dell box, I
can then log out and the screen returns to normal. On the IBM box,
logging out just gives me another blank screen.
Has anyone else experienced this very annoying behaviour?
--
Roger Cornelius rac...@tenzing.org
Joe Chasan
yes, exact same problem. dell poweredge 1600sc with osr507, mp1 and up1.
i'd guess 75% of the time as well, have not had time to debug it other
than switching resolution settings in mkdev graphics once in a while
to no avail.
embedded VGA adaptor, recognized as ATI RAGE PRO/LT-PRO/XL/Mobility
(P/M/M1)
--- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
-Joe Chasan- Magnatech Business Systems, Inc.
j...@magnatechonline.com Hicksville, NY - USA
http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
Jean-Pierre Radley
I've got this problem too, with the same software.
My video card is an ATI RAGE128 Pro GL AGP.
If I try to exit "normally", I usually end up with no usable character
screen at all. Everything is black, and Alt-Fxkey just beeps.
Sometimes I can telnet in and run /etc/clean_screen and reclaim the
console, but I've finally learned to exit X via the abrupt method of
hitting Alt-PrtScr.
--
JP
Bela Lubkin
Hmmm, three reports with all different X drivers (r128, mtx, r3ppci)...
I've recently been investigating an issue that _might_ be related.
Would each of you please try the following. Edit the active grafinfo
file (e.g. /usr/lib/grafinfo/ati/r128.xgi). [To find the active
grafinfo: `cat /usr/lib/grafinfo/grafdev`. Each entry looks something
like "/dev/tty01:matrox.mtx.mtx.1280x1024-16m-60". The first two
"words" after the colon tell you the directory and filename of the
active grafinfo; that is, "...:matrox.mtx..." points to the grafinfo
file /usr/lib/grafinfo/matrox/mtx.xgi]
For every resolution, you will see one or more "MEMORY" statements; e.g.
on my Matrox G450 I have:
MEMORY(0xF2000000, 0x4000); /* Base Address, Length */
MEMORY(FBM, 0xF0000000, 0x800000); /* Base Address, Length */
in each entry. The edit is, add the following line _after_ the existing
"MEMORY" lines in each mode:
MEMORY(VID, 0x000A0000,0x0020000); /* Standard VGA video memory window */
The change takes effect the next time you _start_ the X server (so if
you do this edit from within X, you still have a 75%-or-whatever chance
of failure on exiting that X server).
In my case this fixes a 100% failure on exiting X. I can't really
picture a scenario where the problem I'm chasing would cause an
_intermittent_ failure, but it's worth testing the theory.
Please tell me whether this has any effect.
>Bela<
Joe Chasan
i think i do have a lead - so far (after your fix), i tried checking what
apps i ran in X, and i think i have it narrowed down to mozilla (which
my scohelp pulls up by default) which seemed to run clean, but caused the
problem exiting X. can anyone else verify?
Bob Bailin
"Roger Cornelius" <rac...@tenzing.org> wrote in message
news:3F81C954...@tenzing.org...
Have you tried using the generic VESA driver for your card?
Using it, you may be limited to only 800x600, but it may work.
My system had an old Tseng Labs ET6000 adapter, and the
built-in ET4000 driver *should* have worked but never did,
so based on past experience I switched over to the VESA driver,
which has worked admirably ever since.
Bob
Roger Cornelius
This changed the behaviour on the IBM system and possibly fixed it on
the Dell. For the latter, the couple of opportunities I've had to exit
X worked correctly. For the former, I exited X three times today. The
first time, I was returned to the shell prompt as should be normal. The
second time, I got a blank, black screen, like JPR described, which I
used to log in blind, then ran clean_screen which got the video back.
The third time, I got a kernel panic and reboot. Here are [what I think
are] the important parts of the output of crash's panic command:
Unexpected trap in kernel mode:
cr0 0x8001003B cr2 0x0011001C cr3 0x00002000 tlb
0x00000000
ss 0x00000001 uesp 0x0080A2CC efl 0x00010286 ipl
0x00000000
cs 0x00000158 eip 0xF005919A err 0x00000002 trap
0x0000000E
eax 0x00002000 ecx 0x00000001 edx 0x00000014 ebx
0xE0000E1C
esp 0xE0000DE0 ebp 0xE0000E0C esi 0x00000001 edi
0x00000000
ds 0x00000160 es 0x00000160 fs 0x00000000 gs
0x00000000
cpu 0x00000001
PANIC: k_trap - Kernel mode trap type 0x0000000E
Trying to dump 262023 pages to dumpdev hd (1/41), 3276 pages per '.'
.
Panic String: k_trap - Kernel mode trap type 0x%x
Kernel Trap. Kernel Registers saved at 0xe0000db0
ERR=2, TRAPNO=14
cs:eip=0158:f005919a Flags=10286
ds = 0160 es = 0160 fs = 0000 gs = 0000
esi= 00000001 edi= 00000000 ebp= e0000e0c esp= e0000de0
eax= 00002000 ebx= e0000e1c ecx= 00000001 edx= 00000014
Kernel Stack before Trap:
STKADDR FRAMEPTR FUNCTION POSSIBLE ARGUMENTS
e0000de0 e0000e0c v86vint (u+0xe1c,0)
I'll post again as I have more details, but I won't have console access
to the IBM again until Thursday.
--
Roger Cornelius rac...@tenzing.org
Roger Cornelius
I use mozilla only rarely. I personally don't think this is application
induced.
--
Roger Cornelius rac...@tenzing.org
Roger Cornelius
My experience with it has been that it's unusably slow. I'm willing to
try it again as an experiment, but don't think it's an acceptable
solution to the problem.
--
Roger Cornelius rac...@tenzing.org
Bela Lubkin
I asked you to try editing each entry in the active grafinfo file to
add:
> > MEMORY(VID, 0x000A0000,0x0020000); /* Standard VGA video memory window */
after the existing "MEMORY" line(s) in each mode. You say:
> This changed the behaviour on the IBM system and possibly fixed it on
> the Dell. For the latter, the couple of opportunities I've had to exit
> X worked correctly.
Perhaps you could cycle it a few more times for confidence? If it's as
random as it seemed, just running the X server and exiting as quickly as
possible ought to be a decent "smoke test".
> For the former, I exited X three times today. The
> first time, I was returned to the shell prompt as should be normal. The
> second time, I got a blank, black screen, like JPR described, which I
> used to log in blind, then ran clean_screen which got the video back.
> The third time, I got a kernel panic and reboot.
So previously the X server was hanging on exit (not affecting the whole
machine) about 75% of the time. I assume that 75% is a very rough
estimate. Now, out of 3 samples, one exited cleanly and two more went
wrong (in different ways). So without further examination of the
failure modes, I would tend to conclude that whatever was causing the
problem is still happening. Only the failure modes have changed. That
is, if you were to run 100 cycles under the new setup, you would see
about 25 successful exits, about 75 failures -- same as before.
Since the new failure modes include worse options (panic vs. a mere
unusable screen), you should probably undo the patch on the IBM.
Repeating part of the original message:
> > > | After the hang and from another login, I can kill the X process which
> > > | results in a black or sometimes garbled screen. I can log in again,
> > > | though I can't see what's happening on the screen. On the Dell box, I
> > > | can then log out and the screen returns to normal. On the IBM box,
> > > | logging out just gives me another blank screen.
Let's go back to the original grafinfo file. After a "bad" exit, you
seem to be saying the X server is still running. You can see this from
a network login, so the rest of the system is fine.
I don't quite understand from this description what happens on the IBM
when you run a new X server. Are you saying that it too is blank, or
that it displays normally? In other words, has the console become
totally unusable at this point, or are you able to return to a usable X
server as often as you want, but not to text mode?
Anyway, next time the exit hang happens, examine that X server's process
tree. In particular, does it have a subprocess called `vbiosd`? What
happens if you kill _that_ rather than the X server -- does X then
finish exiting in a more normal manner?
I'm thinking that you may end up with a still blank or trashed screen,
but at least your ability to flip multiscreens should return. It might
be that you can flip, but still can't see what you're doing. But you
should be able to distinguish between e.g. a multiscreen that was
sitting at a shell prompt; `echo '\07'` will beep -- vs. one that was
sitting at a login prompt.
Once the X server has exited relatively gracefully, try to get to a
shell prompt and run /etc/clean_screen. If you can't get to a shell
prompt on the console, run it from the network login as `clean_screen
< /dev/tty02` (substituting the name of the tty on which X was running
-- or, if you've flipped multiscreens, the one you think is currently
"displayed").
I'm trying both to develop a viable workaround for temporary use; and to
better understand the problem so that we can solve it permanently
without a clumsy workaround. So please describe the results very
carefully.
Now, back to the panic:
> Here are [what I think
> are] the important parts of the output of crash's panic command:
>
> Unexpected trap in kernel mode:
> cr0 0x8001003B cr2 0x0011001C cr3 0x00002000 tlb 0x00000000
> ss 0x00000001 uesp 0x0080A2CC efl 0x00010286 ipl 0x00000000
> cs 0x00000158 eip 0xF005919A err 0x00000002 trap 0x0000000E
> eax 0x00002000 ecx 0x00000001 edx 0x00000014 ebx 0xE0000E1C
> esp 0xE0000DE0 ebp 0xE0000E0C esi 0x00000001 edi 0x00000000
> ds 0x00000160 es 0x00000160 fs 0x00000000 gs 0x00000000
> cpu 0x00000001
...
> Kernel Stack before Trap:
> STKADDR FRAMEPTR FUNCTION POSSIBLE ARGUMENTS
> e0000de0 e0000e0c v86vint (u+0xe1c,0)
Hmmm. Well, it panic'd while running code under an interrupt that was
being serviced in virtual 8086 mode. Presumably that would be an
interrupt that was provoked by something the adapter's BIOS did while
coming down from graphics mode; and should have been handled by code
within the BIOS. The panic was a trap E (an illegal memory reference);
the bad reference address was 0x11001C (CR2). That address isn't a
sensible address for BIOS code to be accessing. We have no basis to
determine whether this is a BIOS bug or a bug in the simulated 8086
environment under which the Unix kernel is running the BIOS.
This does remind me of another thing that you should try, though. In
fact something that all three of the original posters should try. Many
modern systems have a BIOS setup item that boils down to "Should an
interrupt vector be assigned to the video board?". In most cases this
should be set to "no" for Unix. To be precise, I do not know of any
case where it needs to be "yes", but I could easily believe that some
video BIOSes might require it and I simply haven't run into one. This
is another one of those things that you'll learn about right away: if
you turn it off and the board/BIOS really need it, getting _into_ X will
fail and you'll back out the change.
Yet a third thing that you could try is to disable the high-precision
timer interrupts that were first introduced in OSR506. To do this, boot
with "defbootstr clock.disable_short_timers=1". The BIOS code may be
getting an unexpectedly high speed stream of timer interrupts, which
could get it in trouble.
> I'll post again as I have more details, but I won't have console access
> to the IBM again until Thursday.
I've given you several conflicting ideas to try. When you have access,
you'll have to decide what to fiddle with. I don't think it would be
wise to try more than one of these ideas at the same time, because you
wouldn't be able to tell which behavior changes were caused by what.
I think my order of attack would be:
1. Revert to the original grafinfo -- the change didn't help in this
case, and made the failure mode worse at times
2. Disable VGA IRQ in BIOS setup; test
3. Unless that made X unusable, leave it off even if it didn't help,
because it leaves more IRQs free for other devices
4. Try "defbootstr clock.disable_short_timers=1"; test
5. If that doesn't fix the problem, reboot without it and forget about
that setting
6. If neither of those fix the problem, work towards a workaround
based on killing `vbiosd` and running `clean_screen`
7. Comment on all the steps you took so we learn what was really
relevant...
>Bela<
Jean-Pierre Radley
| 1. Revert to the original grafinfo -- the change didn't help in this
| case, and made the failure mode worse at times
Adding the MEMORY string for VGA did not help me.
| 2. Disable VGA IRQ in BIOS setup; test
My BIOS affords no such option.
| 4. Try "defbootstr clock.disable_short_timers=1"; test
Made no difference.
| 7. Comment on all the steps you took so we learn what was really
| relevant...
If I run 'startx' when logged in as root or any other user on the system
except 'jpr', exiting X presents no problem.
But I usually run 'startx' when logged in as 'jpr', and that's when I get
the hang-ups upon trying to exit X "normally" (meaning other than using
Alt-PrtScrn).
User 'jpr' has a .startxrc; if I put it aside, then a normal desktop
appears, and I do not have any problem exiting X. The .startxrc:
# following script zaps existing mozilla and its locks, relaunches mozilla
/u/jpr/bin/mz &
xclock -update 1 -hd magenta -hl magenta -geometry 110x110+0+1012 &
xeyes -geometry 120x80+510+1120 -center yellow -outline magenta &
scoterm -n JPR -title jpr -geometry 156x25+0+100 &
scoterm -fg cyan -bg black -n JPR -title jpr -geometry 80x47+1600+0 &
scoterm -fg magenta -bg white -n JPR -title jpr -geometry 80x47+1700+100 &
scoterm -fg yellow -bg blue -n JPR -title jpr -geometry 80x47+2364+224 &
scoterm -fg red -bg cyan -n NEWS -title news -geometry 80x47+7164+224 \
-e su - news &
# ... more scoterms with assorted '-e su other_users'
win &
exec pmwm
--
JP
Joe Chasan
FWIW, i, too have a .startxrc, but alls i have in it is
xterm &
exec pmwm
Jean-Pierre Radley
|
| FWIW, i, too have a .startxrc, but alls i have in it is
| xterm &
| exec pmwm
A bit off the topic of this thread, but why would you use xterm instead
of scoterm?
--
JP
Bela Lubkin
WIW would be more if you'd tested what JPR mentioned: that moving aside
his .startxrc -- or logging in as a different user who doesn't have one
-- corrects the problem for him.
So it looks like each of you three may have completely different
underlying problems. Roger Cornelius has a Dell which (so far) may have
been fixed by giving the video BIOS access to standard VGA video memory
ranges, and an IBM which has some serious BIOS conflict with how we
execute the BIOS. JPR has issues with processes shutting down properly
on the way out of X. We don't know too much about your situation yet.
>Bela<
Bela Lubkin
> Bela Lubkin typed (on Wed, Oct 08, 2003 at 08:39:36AM +0000):
> | 1. Revert to the original grafinfo -- the change didn't help in this
> | case, and made the failure mode worse at times
>
> Adding the MEMORY string for VGA did not help me.
>
> | 2. Disable VGA IRQ in BIOS setup; test
>
> My BIOS affords no such option.
>
> | 4. Try "defbootstr clock.disable_short_timers=1"; test
>
> Made no difference.
Ok, so revert all of those...
> | 7. Comment on all the steps you took so we learn what was really
> | relevant...
>
> If I run 'startx' when logged in as root or any other user on the system
> except 'jpr', exiting X presents no problem.
>
> But I usually run 'startx' when logged in as 'jpr', and that's when I get
> the hang-ups upon trying to exit X "normally" (meaning other than using
> Alt-PrtScrn).
>
> User 'jpr' has a .startxrc; if I put it aside, then a normal desktop
> appears, and I do not have any problem exiting X. The .startxrc:
>
> # following script zaps existing mozilla and its locks, relaunches mozilla
> /u/jpr/bin/mz &
>
> xclock -update 1 -hd magenta -hl magenta -geometry 110x110+0+1012 &
> xeyes -geometry 120x80+510+1120 -center yellow -outline magenta &
> scoterm -n JPR -title jpr -geometry 156x25+0+100 &
> scoterm -fg cyan -bg black -n JPR -title jpr -geometry 80x47+1600+0 &
> scoterm -fg magenta -bg white -n JPR -title jpr -geometry 80x47+1700+100 &
> scoterm -fg yellow -bg blue -n JPR -title jpr -geometry 80x47+2364+224 &
> scoterm -fg red -bg cyan -n NEWS -title news -geometry 80x47+7164+224 \
> -e su - news &
>
> # ... more scoterms with assorted '-e su other_users'
>
> win &
> exec pmwm
Well, clearly it must be due to something in your .startxrc. You could
conduct a series of experiments, commenting out various bits until you
know which bits cause it. I would start by commenting out all the
scoterms, xclock & xeyes, and observing that the problem still occurs,
because it's going to be an interaction between either Mozilla or Merge,
and pmwm.
Then comment out one or the other of those, test some more.
Once you've narrowed it down to Mozilla, you can try something like
manually killing Mozilla (be sure to get all of its associated
processes) before exiting X.
Then try your normal .startxrc, exit X, take a look at what processes
are still running (do this from a network login from a different
display). You'll probably see one of Mozilla's outrigger processes
still hanging around [or possibly Merge's]. If you kill that, X
shutdown will probably complete.
At which point you have to figure out how to convince Mozilla [or Merge]
to gracefully die all the way when the X server sends it an "I'm going
away now" message. Having narrowed it down that much, you'll be able to
do things like kill the main M* process and observe whether it carries
the message along to its various subprocesses, or in fact leaves itself
in exactly the same contorted state as when you abort the X server. The
details will suggest the next step.
>Bela<
Joe Chasan
this is true, maybe i should have waited to tell you of it existence
until i was in front of the machine and could test w/it moved aside.
will post back in the A.M.
Joe Chasan
i'm sure there must've been some compatibility issue with some application
or another at some point, or some other preference, but i've no idea
anymore why, date on the file is pretty old.
Joe Chasan
no, moving out the .startxrc had no effect. i am now 99% sure it is
tied in to mozilla (which i note JP had in his startuprc file).
removing the startxrc and not removing the startxrc, i can get in and
out ok - if i start mozilla (scohelp, using mozilla), i get stuck leaving
X with the 'dead screen', whether my startxrc was there or not.
Jean-Pierre Radley
| Well, clearly it must be due to something in your .startxrc. You could
| conduct a series of experiments, commenting out various bits until you
| know which bits cause it. I would start by commenting out all the
| scoterms, xclock & xeyes, and observing that the problem still occurs,
| because it's going to be an interaction between either Mozilla or Merge,
| and pmwm.
|
| Then comment out one or the other of those, test some more.
|
| Once you've narrowed it down to Mozilla, you can try something like
| manually killing Mozilla (be sure to get all of its associated
| processes) before exiting X.
|
| Then try your normal .startxrc, exit X, take a look at what processes
| are still running (do this from a network login from a different
| display). You'll probably see one of Mozilla's outrigger processes
| still hanging around [or possibly Merge's]. If you kill that, X
| shutdown will probably complete.
|
| At which point you have to figure out how to convince Mozilla [or Merge]
| to gracefully die all the way when the X server sends it an "I'm going
| away now" message. Having narrowed it down that much, you'll be able to
| do things like kill the main M* process and observe whether it carries
| the message along to its various subprocesses, or in fact leaves itself
| in exactly the same contorted state as when you abort the X server. The
| details will suggest the next step.
It's Mozilla.
Doesn't matter if Mozilla is started by a .startxrc, from a Desktop icon,
or from a command line in a scoterm.
Doesn't matter if I choose "Quit" from Mozilla's "File" menu, or if I
kill
/opt/mozilla/lib/mozilla-bins
which then kills its parent
/opt/mozilla/lib/run-mozilla.sh /opt/mozilla/lib/mozilla-bin,
I cannot then exit X with hanging up the console except via the
Alt-PrtScr route.
And I see no other processes that are the children of those two.
--
JP
Bela Lubkin
> It's Mozilla.
>
> Doesn't matter if Mozilla is started by a .startxrc, from a Desktop icon,
> or from a command line in a scoterm.
>
> Doesn't matter if I choose "Quit" from Mozilla's "File" menu, or if I
> kill
> /opt/mozilla/lib/mozilla-bins
> which then kills its parent
> /opt/mozilla/lib/run-mozilla.sh /opt/mozilla/lib/mozilla-bin,
> I cannot then exit X with hanging up the console except via the
> Alt-PrtScr route.
>
> And I see no other processes that are the children of those two.
Nevertheless. Run a `ps -ef > /tmp/before` before you start X; start X
(sans .startxrc, to keep things very simple); start Mozilla; `ps -ef >
/tmp/during`; then blow out of X, `ps -ef > /tmp/after`; send 'em all to
me. There must be something hanging out causing the trouble...
(direct email; I can post my findings, but no need to post hundreds of
lines of `ps` gibberish...)
>Bela<
Roger Cornelius
Apologies for taking so long to reply. I did some testing last
Thursday and then, Thursday night, read all the posts relating this as
a Mozilla problem so wanted to test some more, which I did over the
weekend. I found the problems on the two systems I have to be
different. Joe Chasan first suggested Mozilla as the culprit but this
didn't seem likely since I rarely use it. On the Dell system, I
typically start X and don't exit except when I need to reboot the
system, which could be weeks or months later. It's true I rarely use
Mozilla, but it apparently only takes once during an X session to
cause the hang on exit. I confirmed that mozilla is the cause of the
problem on the Dell. As was suggested in a later post, I compared
processes before and after executing Mozilla, and found that
/opt/mozilla/lib/run-mozilla.sh was left as a defunct process on one
execution, but not the next.
The IBM's problem is not related to Mozilla, though Mozilla does cause
X to hang on exit just like on the Dell. When I exit X on the IBM,
without having previously run mozilla, I get a black screen which I
can run clean_screen blind to get the video back. The suggestion to
"Disable VGA IRQ in BIOS setup" didn't work. I can change the IRQ
used but not disable it. The "defbootstr
clock.disable_short_timers=1" suggestion had no effect.
So the result of this thread is that I understand the problems better
and have workarounds for them, but not really a solution.