From: Fabrice B. <Fab...@cr...> - 2002-10-09 23:43:03
|
On Thu, Oct 10, 2002 at 12:33:59AM +0200, Michel D=E4nzer wrote: >=20 > 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.=20 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?=20 [root@dhcp7 root]# more /proc/interrupts=20 CPU0 CPU1 =20 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=20 LOC: 463790 463789=20 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 clie= nts terminated with the drmRadeonIrqWait: -16 error. >=20 > Does this work with R200_NO_IRQS? Setting R200_NO_IRQS=3D1 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 the= se=20 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=20 window manager, and no other window on screen : just X, fgfs, and glxgear= s.) 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.=20 The X session becomes promptly unresponsive, once glxgears is launched, (the 2nd GL app). Remotely, I still can log in on=20 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]=20 Oct 10 00:59:53 dhcp7 kernel: [drm:radeon_do_cp_idle]=20 Oct 10 00:59:53 dhcp7 kernel: [drm:radeon_ioctl] pid=3D1564, cmd=3D0x6444= , nr=3D0x44, dev 0xe200, auth=3D1 Oct 10 00:59:53 dhcp7 kernel: [drm:radeon_cp_idle]=20 Oct 10 00:59:53 dhcp7 kernel: [drm:radeon_do_cp_idle]=20 Oct 10 00:59:53 dhcp7 kernel: [drm:radeon_ioctl] pid=3D1564, cmd=3D0x6444= , nr=3D0x44, dev 0xe200, auth=3D1 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=3D3 '\003', pSrc=3D0x87b1f50, pDst=3D0x8848670,=20 maskFormat=3D0x84094d8, xSrc=3D0, ySrc=3D0, nlist=3D1, list=3D0xbffff= 2c0,=20 glyphs=3D0xbfffeec0) at misprite.c:2098 #6 0x0813a85f in CompositeGlyphs (op=3D3 '\003', pSrc=3D0x87b1f50, pDst=3D0x8848670,=20 maskFormat=3D0x84094d8, xSrc=3D0, ySrc=3D0, nlist=3D1, lists=3D0xbfff= f2c0,=20 glyphs=3D0xbfffeec0) at picture.c:1062 #7 0x0813bbaa in ProcRenderCompositeGlyphs (client=3D0x87670f0) at render.c:1027 #8 0x0813bd6e in ProcRenderDispatch (client=3D0x0) at render.c:1080 #9 0x080ad7eb in Dispatch () at dispatch.c:462 #10 0x080bd630 in main (argc=3D2, argv=3D0xbffffaa4, envp=3D0xbffffab0) a= t 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=3DCannot access memory at address 0x3f800008 ) at r200_lock.c:86 #3 0x4055ae1b in r200FlushCmdBuf (rmesa=3D0x8a786a8,=20 caller=3D0x405804ec "r200AllocCmdBuf") at r200_ioctl.c:148 #4 0x4055a4d3 in r200EmitVbufPrim (rmesa=3D0x8a786a8, primitive=3D527,=20 vertex_nr=3D4) at r200_ioctl.h:175 #5 0x40560ac5 in EMIT_PRIM (ctx=3D0x87d75e0, prim=3D9, hwprim=3D15, star= t=3D0,=20 count=3D142439904) at r200_tcl.c:195 #6 0x4056183a in tcl_render_poly_verts (ctx=3D0x8a8e100, start=3D1451967= 12,=20 count=3D0, flags=3D777) at ../../../../../../extras/Mesa/src/tnl_dd/t_dd_dmatmp2.h:493 #7 0x40562581 in r200EmitPrimitive (ctx=3D0x8a8e100, first=3D0, last=3D4= ,=20 flags=3D142439904) at r200_tcl.c:237 #8 0x40566e06 in flush_prims (rmesa=3D0x8a786a8) at r200_vtxfmt.c:233 #9 0x4056960a in r200FlushVertices (ctx=3D0x8a8e100, flags=3D1) 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=3DCannot access memory at address 0x= 8 ) at r200_lock.c:86 #3 0x40316e1b in r200FlushCmdBuf (rmesa=3D0x804f198,=20 caller=3D0x4033ca09 "r200Flush") at r200_ioctl.c:148 #4 0x40318326 in r200Flush (ctx=3D0x804d4b8) at r200_ioctl.c:704 #5 0x403175a2 in r200CopyBuffer (dPriv=3D0x804f198) at r200_ioctl.c:379 #6 0x40071722 in glXSwapBuffers (dpy=3D0x804bc00, drawable=3D33554434) 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=20 CPU0 CPU1 =20 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=20 LOC: 463790 463789=20 ERR: 69 MIS: 0 --=20 fabrice |