Hey,
> > when I switch to vt while there is much drawing on the X Server (like KDE
> > start) the X Server crashes after 1-2 seconds with SEGV.
> > My setup: Linux 2.4.17, debian testing
> > XFree86 Version 4.1.0.1 (no option to fbdev, the same resolution and
> > color depth as set with fbset)
> > The problem is the same, if I only use the first head.
> > Hardware: Matrox G450, Athlon SMP
> > I don't have the problem, if I use the mga X driver on top of matroxfb,
> > instead of using the fbdev on top of matroxfb. But then there is a
> > strange flickering when the X Server starts, so I prefer the fbdev
> > driver.
> >
> > You probably need more information, but I'm not sure what else I could
> > write about this problem. Please let me know what else you need.
>
> A stack trace from when the server crashes would be most interesting.
I tested the Version 4.2 and it's still the same problem. The stack trace is
made using Version 4.2. BTW there is one minor difference between running X
standalone and running it in gdb. If I run it in gdb it always segfaults not
only if there is much drawing going on.
Program received signal SIGSEGV, Segmentation fault.
0x0828efd3 in shadowUpdatePacked (pScreen=0x86b8460, pBuf=0x86b2da0)
at shpacked.c:101
101 *win++ = *sha++;
(gdb) bt
#0 0x0828efd3 in shadowUpdatePacked (pScreen=0x86b8460, pBuf=0x86b2da0)
at shpacked.c:101
#1 0x0828bb22 in shadowRedisplay (pScreen=0x86b8460) at shadow.c:71
#2 0x0828bb79 in shadowBlockHandler (data=0x86b8460, pTimeout=0xbffff740,
pRead=0x86971e0) at shadow.c:84
#3 0x0829bfc9 in BlockHandler (pTimeout=0xbffff740, pReadmask=0x86971e0)
at dixutils.c:432
#4 0x082b5c95 in WaitForSomething (pClientsReady=0xbffff964) at WaitFor.c:330
#5 0x08295e8c in Dispatch () at dispatch.c:391
#6 0x082a5cbb in main (argc=1, argv=0xbffffe14, envp=0xbffffe1c) at
main.c:454
#7 0x4007265f in __libc_start_main () from /lib/libc.so.6
> > I first wrote to Petr (the matroxfb mantainer) he wrote me the following:
> > > I have no idea why it should die, on Gxxx neither video memory start
> > > nor length changes on mode switch (it changes on MillenniumI/II), and
> > > matroxfb does not steal framebuffer mapping from any app on console
> > > switch (there are some plans to do that on 2.5.x, but as I disagree
> > > with these plans...), only X itself unmap framebuffer itself.
> > >
> > > So I think that it is fbdev problem - if you are getting kernel oops,
> > > it is for sure matroxfb's problem, but if you are not getting them, it
> > > looks to me like that fbdev driver tries to paint to screen even if
> > > it is not visible
>
> That's a good analysis, so have you determined if the segfault is in
> fact an oops?
If it were a oops, the kernel would log it, right? Than it's no oops.
regards,
Roland Schulz
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
