Professional Web Applications Themes

Xwindow hang on osr507 - SCO

I have two dissimilar 5.0.7 systems which exhibit the same problem. 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 ...

  1. #1

    Default Xwindow hang on osr507

    I have two dissimilar 5.0.7 systems which exhibit the same problem.
    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 XpertPlay 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 org
    Roger Guest

  2. #2

    Default Re: Xwindow hang on osr507

    On Mon, Oct 06, 2003 at 07:58:12PM +0000, Roger Cornelius wrote: 

    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.
    com Hicksville, NY - USA
    http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
    Joe Guest

  3. #3

    Default Re: Xwindow hang on osr507

    Roger Cornelius typed (on Mon, Oct 06, 2003 at 07:58:12PM +0000):
    | I have two dissimilar 5.0.7 systems which exhibit the same problem.
    | 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 XpertPlay 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?

    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
    Jean-Pierre Guest

  4. #4

    Default Re: Xwindow hang on osr507

    Jean-Pierre Radley wrote:
     

    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 Guest

  5. #5

    Default Re: Xwindow hang on osr507

    On Mon, Oct 06, 2003 at 07:23:38PM -0400, Bela Lubkin wrote: 
    >
    > 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.[/ref]

    i tried and this does not fix the problem for me.

    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?

    --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
    -Joe Chasan- Magnatech Business Systems, Inc.
    com Hicksville, NY - USA
    http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
    --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
    -Joe Chasan- Magnatech Business Systems, Inc.
    com Hicksville, NY - USA
    http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
    Joe Guest

  6. #6

    Default Re: Xwindow hang on osr507


    "Roger Cornelius" <org> wrote in message
    news: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


    Bob Guest

  7. #7

    Default Re: Xwindow hang on osr507

    Bela Lubkin wrote: 
    >
    > 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.[/ref]

    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 org
    Roger Guest

  8. #8

    Default Re: Xwindow hang on osr507

    Bob Bailin wrote: 
    >
    > Have you tried using the generic VESA driver for your card?
    > Using it, you may be limited to only 800x600, but it may work.[/ref]

    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 org
    Roger Guest

  9. #9

    Default Re: Xwindow hang on osr507

    Joe Chasan wrote: 
    > >
    > > 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.[/ref]
    >
    > i tried and this does not fix the problem for me.
    >
    > 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?[/ref]

    I use mozilla only rarely. I personally don't think this is application
    induced.
    --
    Roger Cornelius org
    Roger Guest

  10. #10

    Default Re: Xwindow hang on osr507

    Roger Cornelius wrote:
     [/ref][/ref]

    I asked you to try editing each entry in the active grafinfo file to
    add:
     [/ref]

    after the existing "MEMORY" line(s) in each mode. You say:
     

    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".
     

    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:
     [/ref][/ref]

    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:
     

    ....
     

    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'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 Guest

  11. #11

    Default Re: Xwindow hang on osr507

    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.

    | 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
    Jean-Pierre Guest

  12. #12

    Default Re: Xwindow hang on osr507

    On Wed, Oct 08, 2003 at 08:39:21PM -0400, Jean-Pierre Radley wrote: 

    FWIW, i, too have a .startxrc, but alls i have in it is
    xterm &
    exec pmwm

    --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
    -Joe Chasan- Magnatech Business Systems, Inc.
    com Hicksville, NY - USA
    http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
    Joe Guest

  13. #13

    Default Re: Xwindow hang on osr507

    Joe Chasan typed (on Wed, Oct 08, 2003 at 08:52:29PM -0400):
    |
    | 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
    Jean-Pierre Guest

  14. #14

    Default Re: Xwindow hang on osr507

    Joe Chasan wrote:
     
    >
    > FWIW, i, too have a .startxrc, but alls i have in it is
    > xterm &
    > exec pmwm[/ref]

    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 Guest

  15. #15

    Default Re: Xwindow hang on osr507

    Jean-Pierre Radley wrote:
     

    Ok, so revert all of those...
     

    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 Guest

  16. #16

    Default Re: Xwindow hang on osr507

    On Thu, Oct 09, 2003 at 01:44:28AM +0000, Bela Lubkin wrote: 
    > >
    > > FWIW, i, too have a .startxrc, but alls i have in it is
    > > xterm &
    > > exec pmwm[/ref]
    >
    > 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.[/ref]

    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- Magnatech Business Systems, Inc.
    com Hicksville, NY - USA
    http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
    Joe Guest

  17. #17

    Default Re: Xwindow hang on osr507

    On Wed, Oct 08, 2003 at 09:34:39PM -0400, Jean-Pierre Radley wrote: 

    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- Magnatech Business Systems, Inc.
    com Hicksville, NY - USA
    http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
    Joe Guest

  18. #18

    Default Re: Xwindow hang on osr507

    On Thu, Oct 09, 2003 at 01:44:28AM +0000, Bela Lubkin wrote: 
    > >
    > > FWIW, i, too have a .startxrc, but alls i have in it is
    > > xterm &
    > > exec pmwm[/ref]
    >
    > 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.[/ref]

    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.

    --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
    -Joe Chasan- Magnatech Business Systems, Inc.
    com Hicksville, NY - USA
    http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
    Joe Guest

  19. #19

    Default Re: Xwindow hang on osr507

    Bela Lubkin typed (on Wed, Oct 08, 2003 at 10:19:47PM -0400):
    | 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
    Jean-Pierre Guest

  20. Moderated Post

    Default Re: Xwindow hang on osr507

    Removed by Administrator
    Bela Guest
    Moderated Post

Page 1 of 2 12 LastLast

Similar Threads

  1. SWF causes JSP to hang
    By _Rob in forum Macromedia Flash Player
    Replies: 2
    Last Post: April 19th, 02:23 PM
  2. Why does my application hang?
    By Mea in forum Macromedia Director Basics
    Replies: 3
    Last Post: October 22nd, 02:51 PM
  3. OS X hang
    By Eric in forum Adobe Photoshop Elements
    Replies: 14
    Last Post: October 4th, 09:30 PM
  4. irc hang
    By Frank in forum Sun Solaris
    Replies: 5
    Last Post: September 18th, 09:12 PM
  5. hdr hang
    By Jack in forum Informix
    Replies: 0
    Last Post: August 22nd, 11:21 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139