On Thu, Oct 10, 2002 at 12:33:59AM +0200, Michel Dänzer wrote:
>
> What date is the DRM source you're using from?
I updated my dri HEAD cvs tree two hours ago, and I rebuilt
the drm module too.
Oct 10 00:53:32 dhcp7 kernel: [drm] Debug messages ON
Oct 10 00:53:32 dhcp7 kernel: [drm] AGP 0.99 on AMD Irongate @ 0xe8000000 128MB
Oct 10 00:53:32 dhcp7 kernel: [drm] Initialized radeon 1.6.0 20020828 on minor 0
Oct 10 00:53:33 dhcp7 kernel: [drm] Loading R200 Microcode
> What's your IRQ setup?
[root@dhcp7 root]# more /proc/interrupts
CPU0 CPU1
0: 463862 0 XT-PIC timer
1: 412 0 XT-PIC keyboard
2: 0 0 XT-PIC cascade
3: 7274 0 XT-PIC eth0
5: 115148 0 XT-PIC aic7xxx, EMU10K1
8: 1 0 XT-PIC rtc
10: 44102 0 XT-PIC aic7xxx, radeon@PCI:1:5:0
11: 22 0 XT-PIC usb-ohci
12: 3431 0 XT-PIC PS/2 Mouse
14: 10141 0 XT-PIC ide0
NMI: 0 0
LOC: 463790 463789
ERR: 69
MIS: 0
Hmm, all the interrupts are routed to the same CPU ? the SCSI disk
is on the first scsi0 controller (irq 5 I assume).
> Does the interrupt count for the radeon increase
> in /proc/interrupts after this happens? Does a single client work
> afterwards?
The previous trace finished with a complete machine hang, after both clients
terminated with the drmRadeonIrqWait: -16 error.
>
> Does this work with R200_NO_IRQS?
Setting R200_NO_IRQS=1 didn't change the behaviour. The machine crashed
after both clients existed with r200WaitForFrameCompletion:
drmRadeonIrqWait: -16
***
But I see another problematic behaviour, if I change the way I launch these
processes : (The previous traces were obtained when X, fgfs and glxgears were
all started from a remote machine, under the control of gdb. I had no
window manager, and no other window on screen : just X, fgfs, and glxgears.)
Now, if I do a startx from the console, like a regular user, lauches
the gnome environment, and starts fgfs and glxgears from a gnome terminal,
with R200_DEBUG unset, the machine no longer crashes.
The X session becomes promptly unresponsive, once glxgears
is launched, (the 2nd GL app). Remotely, I still can log in on
the machine, and I notice that X is taking 100% CPU time.
the drm log in full of :
Oct 10 00:59:53 dhcp7 kernel: [drm:radeon_cp_idle]
Oct 10 00:59:53 dhcp7 kernel: [drm:radeon_do_cp_idle]
Oct 10 00:59:53 dhcp7 kernel: [drm:radeon_ioctl] pid=1564, cmd=0x6444, nr=0x44, dev
0xe200, auth=1
Oct 10 00:59:53 dhcp7 kernel: [drm:radeon_cp_idle]
Oct 10 00:59:53 dhcp7 kernel: [drm:radeon_do_cp_idle]
Oct 10 00:59:53 dhcp7 kernel: [drm:radeon_ioctl] pid=1564, cmd=0x6444, nr=0x44, dev
0xe200, auth=1
1564 is the X server process.
The backtrace of the X process is :
(gdb) bt
#0 0x420d3454 in ioctl () from /lib/i686/libc.so.6
#1 0xfffffc02 in ?? ()
#2 0x084593d8 in ?? ()
#3 0x0839a1c4 in ?? ()
#4 0x0864d450 in ?? ()
#5 0x08166e52 in miSpriteGlyphs (op=3 '\003', pSrc=0x87b1f50,
pDst=0x8848670,
maskFormat=0x84094d8, xSrc=0, ySrc=0, nlist=1, list=0xbffff2c0,
glyphs=0xbfffeec0) at misprite.c:2098
#6 0x0813a85f in CompositeGlyphs (op=3 '\003', pSrc=0x87b1f50,
pDst=0x8848670,
maskFormat=0x84094d8, xSrc=0, ySrc=0, nlist=1, lists=0xbffff2c0,
glyphs=0xbfffeec0) at picture.c:1062
#7 0x0813bbaa in ProcRenderCompositeGlyphs (client=0x87670f0) at
render.c:1027
#8 0x0813bd6e in ProcRenderDispatch (client=0x0) at render.c:1080
#9 0x080ad7eb in Dispatch () at dispatch.c:462
#10 0x080bd630 in main (argc=2, argv=0xbffffaa4, envp=0xbffffab0) at
main.c:454
#11 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
and it looks like fgfs is locked in drmGetLock :
(gdb) bt
#0 0x420d3454 in ioctl () from /lib/i686/libc.so.6
#1 0xbffff118 in ?? ()
#2 0x4055c8b1 in r200GetLock (rmesa=Cannot access memory at address
0x3f800008
) at r200_lock.c:86
#3 0x4055ae1b in r200FlushCmdBuf (rmesa=0x8a786a8,
caller=0x405804ec "r200AllocCmdBuf") at r200_ioctl.c:148
#4 0x4055a4d3 in r200EmitVbufPrim (rmesa=0x8a786a8, primitive=527,
vertex_nr=4) at r200_ioctl.h:175
#5 0x40560ac5 in EMIT_PRIM (ctx=0x87d75e0, prim=9, hwprim=15, start=0,
count=142439904) at r200_tcl.c:195
#6 0x4056183a in tcl_render_poly_verts (ctx=0x8a8e100, start=145196712,
count=0, flags=777)
at ../../../../../../extras/Mesa/src/tnl_dd/t_dd_dmatmp2.h:493
#7 0x40562581 in r200EmitPrimitive (ctx=0x8a8e100, first=0, last=4,
flags=142439904) at r200_tcl.c:237
#8 0x40566e06 in flush_prims (rmesa=0x8a786a8) at r200_vtxfmt.c:233
#9 0x4056960a in r200FlushVertices (ctx=0x8a8e100, flags=1)
at r200_vtxfmt.c:940
and glxgears is blocked in the same function :
(gdb) bt
#0 0x420d3454 in ioctl () from /lib/i686/libc.so.6
#1 0xbffff6f8 in ?? ()
#2 0x403188b1 in r200GetLock (rmesa=Cannot access memory at address 0x8
) at r200_lock.c:86
#3 0x40316e1b in r200FlushCmdBuf (rmesa=0x804f198,
caller=0x4033ca09 "r200Flush") at r200_ioctl.c:148
#4 0x40318326 in r200Flush (ctx=0x804d4b8) at r200_ioctl.c:704
#5 0x403175a2 in r200CopyBuffer (dPriv=0x804f198) at r200_ioctl.c:379
#6 0x40071722 in glXSwapBuffers (dpy=0x804bc00, drawable=33554434)
at glxcmds.c:578
#7 0x0804a519 in event_loop ()
#8 0x0804a6a5 in main ()
#9 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
The apps did not crash this time.
The radeon card is still generating interrupts :
[root@dhcp7 root]# more /proc/interrupts
CPU0 CPU1
0: 463862 0 XT-PIC timer
1: 412 0 XT-PIC keyboard
2: 0 0 XT-PIC cascade
3: 7274 0 XT-PIC eth0
5: 115148 0 XT-PIC aic7xxx, EMU10K1
8: 1 0 XT-PIC rtc
10: 44102 0 XT-PIC aic7xxx, radeon@PCI:1:5:0
11: 22 0 XT-PIC usb-ohci
12: 3431 0 XT-PIC PS/2 Mouse
14: 10141 0 XT-PIC ide0
NMI: 0 0
LOC: 463790 463789
ERR: 69
MIS: 0
--
fabrice
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
