On Sat, Aug 23, 2003 at 04:28:25PM -0500, Branden Robinson wrote:
> On Sat, Aug 23, 2003 at 07:53:17PM +0200, David N. Welton wrote:
> > While running xscreensaver, X appears to hang, somewhat randomly. I
> > downloaded the debug server, and attached to it when the problem
> > occurred:
> [...]
> > (gdb) bt
> > #0 0x080826e7 in Permedia2Sync (pScrn=0x8942ec0) at pm2_accel.c:404
> [...]
> > Let's try doing stepi:
> >
> > 404 in pm2_accel.c
> > (gdb)
> > 0x080826d3 404 in pm2_accel.c
> > (gdb)
> > 0x080826d6 404 in pm2_accel.c
> > (gdb)
...
> Let's have a look at our first contestant, shall we?
>
> 392 void
> 393 Permedia2Sync(ScrnInfoPtr pScrn)
> 394 {
> 395 GLINTPtr pGlint = GLINTPTR(pScrn);
> 396
> 397 CHECKCLIPPING;
> 398
> 399 while (GLINT_READ_REG(DMACount) != 0);
> 400 GLINT_WAIT(2);
> 401 GLINT_WRITE_REG(0x400, FilterMode);
> 402 GLINT_WRITE_REG(0, GlintSync);
> 403 do {
> 404 while(GLINT_READ_REG(OutFIFOWords) == 0);
> 405 } while (GLINT_READ_REG(OutputFIFO) != Sync_tag);
> 406 }
>
> Well, that certainly looks like a good way to fuck yourself. Whoever
> wrote this code has a lot of confidence in the underlying hardware.
>
> Since I happen to know that Sven Luther does a lot of glint driver work,
> I'm CCing him on this message.
Yep, i did write part of this code, altough i mostly worked for the
permedia3, but it is the same code. Could you try building the glint
module with the DEBUG #define at the start of pm2_accel.c set to 1, in
order to see the call trace in the /var/log/XFree86.0.log.
What is happening is that the Permedia2Sync function is sending the sync
command to the chip, to synchronize the pipeline, probably between accel
drawing and software drawing, since the permedia2 cannot accel some of
the function (notably lines). The sync tag should be read back once the
sync command has reached the bottom of the graphic pipeline, and every
accel drawing has been commited to the framebuffer. Since no sync tag is
read back, this can be for various reasons :
o the sync command never reached the chip, because of of bus hogging
or somethign such.
o the graphic pipe did fail to synchronize, or dies for whatever
reason. This means the problem is not in the sync call, but with
whatever was done previously.
o naturally, the random crashing could hint at hardware problem or bus
problems, a more complete of your exact card (with lspci -v output
maybe and/or lspci -vn too) would be welcome, as well as on what arch
it is, and what kind of bus it is connected. Information on the
motherboard would be welcome too, altough i doubt it is relevant here.
My first guess would either be a previous call did make the graphic
pipeline die, or maybe even hog the bus. Does the machine stay
accessible under ssh or something, i guess yes since you were able to to
gdb work on it. What happens if you kill and restart the X server, which
should reinitialize the pipeline.
> Sven, any ideas?
I hope this gives some ideas, altough the randomness of this happening
might well be the input fifo overflowing and thus loosing the sync
command or something such. Tricky thing to hunt down if this is the
case.
Friendly,
Sven Luther
