View Single Post

   
  #7 (permalink)  
Old 02-15-2008, 10:46 AM
Roger Cornelius
 
Posts: n/a
Default Re: Xwindow hang on osr507

Bela Lubkin wrote:
>
> Jean-Pierre Radley wrote:
>
> > 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 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?
> >
> > 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.

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


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 racpop@tenzing.org
Reply With Quote