Bug#490071: xorg occupies all cpu time
The last two days, without GDB, again it worked with no issues, so the glitch, hardware or software, seems disappeared. I spoken too early. Well, this time I was able to get a backtrace, don't know if useful: Program received signal SIGINT, Interrupt. 0xb7f0b424 in __kernel_vsyscall () #0 0xb7f0b424 in __kernel_vsyscall () #1 0xb7d77ed9 in ioctl () from /lib/i686/cmov/libc.so.6 #2 0xb7aff23d in drmDMA () from /usr/lib/libdrm.so.2 #3 0xb7a87f79 in RADEONCPGetBuffer (pScrn=0x9dcd8a0) at ../../src/radeon_accel.c:611 #4 0xb7a88113 in RADEONCPFlushIndirect (pScrn=0x9dcd8a0, discard=1) at ../../src/radeon_accel.c:665 #5 0xb7a929e3 in RADEONCPScanlinePacket (pScrn=0x9dcd8a0, bufno=0) at ../../src/radeon_accelfuncs.c:686 #6 0xb7890878 in XAAWritePixmapScanline (pScrn=0x9dcd8a0, x=343, y=146, w=912, h=173, src=0xa5ded320 FF, srcwidth=3648, rop=3, planemask=4294967295, trans=-1, bpp=32, depth=24) at ../../../../hw/xfree86/xaa/xaaImage.c:370 #7 0xb7882448 in XAADoImageWrite (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, prgnDst=0xbfe26150, pptSrc=0xbfe260f0) at ../../../../hw/xfree86/xaa/xaaCpyArea.c:218 #8 0xb7881bf2 in XAABitBlt (pSrcDrawable=0xa5bcd008, pDstDrawable=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3, doBitBlt=0xb7882330 XAADoImageWrite, bitPlane=0) at ../../../../hw/xfree86/xaa/xaaBitBlt.c:203 #9 0xb7882a3f in XAACopyArea (pSrcDrawable=0xa5bcd008, pDstDrawable=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3) at ../../../../hw/xfree86/xaa/xaaCpyArea.c:66 #10 0xb78c449a in cwCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, w=912, h=785, dstx=7, dsty=3) at ../../../miext/cw/cw_ops.c:201 #11 0x08177a26 in damageCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3) at ../../../miext/damage/damage.c:834 #12 0x0808be86 in ProcCopyArea (client=0xa07bec0) at ../../dix/dispatch.c:1802 #13 0x08155004 in XaceCatchDispatchProc (client=0xa07bec0) at ../../Xext/xace.c:281 #14 0x0808de64 in Dispatch () at ../../dix/dispatch.c:502 #15 0x08074795 in main (argc=9, argv=0xbfe26844, envp= Cannot access memory at address 0xc0286431 ) at ../../dix/main.c:452 The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /usr/bin/Xorg, process 2890 -- Andrea -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490071: xorg occupies all cpu time
Andrea Vettorello wrote: The last two days, without GDB, again it worked with no issues, so the glitch, hardware or software, seems disappeared. I spoken too early. Well, this time I was able to get a backtrace, don't know if useful: Program received signal SIGINT, Interrupt. 0xb7f0b424 in __kernel_vsyscall () #0 0xb7f0b424 in __kernel_vsyscall () #1 0xb7d77ed9 in ioctl () from /lib/i686/cmov/libc.so.6 #2 0xb7aff23d in drmDMA () from /usr/lib/libdrm.so.2 #3 0xb7a87f79 in RADEONCPGetBuffer (pScrn=0x9dcd8a0) at ../../src/radeon_accel.c:611 #4 0xb7a88113 in RADEONCPFlushIndirect (pScrn=0x9dcd8a0, discard=1) at ../../src/radeon_accel.c:665 #5 0xb7a929e3 in RADEONCPScanlinePacket (pScrn=0x9dcd8a0, bufno=0) at ../../src/radeon_accelfuncs.c:686 #6 0xb7890878 in XAAWritePixmapScanline (pScrn=0x9dcd8a0, x=343, y=146, w=912, h=173, src=0xa5ded320 FF, srcwidth=3648, rop=3, planemask=4294967295, trans=-1, bpp=32, depth=24) at ../../../../hw/xfree86/xaa/xaaImage.c:370 #7 0xb7882448 in XAADoImageWrite (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, prgnDst=0xbfe26150, pptSrc=0xbfe260f0) at ../../../../hw/xfree86/xaa/xaaCpyArea.c:218 #8 0xb7881bf2 in XAABitBlt (pSrcDrawable=0xa5bcd008, pDstDrawable=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3, doBitBlt=0xb7882330 XAADoImageWrite, bitPlane=0) at ../../../../hw/xfree86/xaa/xaaBitBlt.c:203 #9 0xb7882a3f in XAACopyArea (pSrcDrawable=0xa5bcd008, pDstDrawable=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3) at ../../../../hw/xfree86/xaa/xaaCpyArea.c:66 #10 0xb78c449a in cwCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, w=912, h=785, dstx=7, dsty=3) at ../../../miext/cw/cw_ops.c:201 #11 0x08177a26 in damageCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3) at ../../../miext/damage/damage.c:834 #12 0x0808be86 in ProcCopyArea (client=0xa07bec0) at ../../dix/dispatch.c:1802 #13 0x08155004 in XaceCatchDispatchProc (client=0xa07bec0) at ../../Xext/xace.c:281 #14 0x0808de64 in Dispatch () at ../../dix/dispatch.c:502 #15 0x08074795 in main (argc=9, argv=0xbfe26844, envp= Cannot access memory at address 0xc0286431 ) at ../../dix/main.c:452 Did you check that Xorg was actually stuck in there ? You should interrupt the process and get the backtrace, then hit 'c' to make the process continue, interrupt again, ... several times and compare the backtraces. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490071: xorg occupies all cpu time
On Wed, 2008-08-06 at 12:53 +0200, Brice Goglin wrote: Andrea Vettorello wrote: The last two days, without GDB, again it worked with no issues, so the glitch, hardware or software, seems disappeared. I spoken too early. Well, this time I was able to get a backtrace, don't know if useful: Program received signal SIGINT, Interrupt. 0xb7f0b424 in __kernel_vsyscall () #0 0xb7f0b424 in __kernel_vsyscall () #1 0xb7d77ed9 in ioctl () from /lib/i686/cmov/libc.so.6 #2 0xb7aff23d in drmDMA () from /usr/lib/libdrm.so.2 #3 0xb7a87f79 in RADEONCPGetBuffer (pScrn=0x9dcd8a0) at ../../src/radeon_accel.c:611 #4 0xb7a88113 in RADEONCPFlushIndirect (pScrn=0x9dcd8a0, discard=1) at ../../src/radeon_accel.c:665 #5 0xb7a929e3 in RADEONCPScanlinePacket (pScrn=0x9dcd8a0, bufno=0) at ../../src/radeon_accelfuncs.c:686 #6 0xb7890878 in XAAWritePixmapScanline (pScrn=0x9dcd8a0, x=343, y=146, w=912, h=173, src=0xa5ded320 FF, srcwidth=3648, rop=3, planemask=4294967295, trans=-1, bpp=32, depth=24) at ../../../../hw/xfree86/xaa/xaaImage.c:370 #7 0xb7882448 in XAADoImageWrite (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, prgnDst=0xbfe26150, pptSrc=0xbfe260f0) at ../../../../hw/xfree86/xaa/xaaCpyArea.c:218 #8 0xb7881bf2 in XAABitBlt (pSrcDrawable=0xa5bcd008, pDstDrawable=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3, doBitBlt=0xb7882330 XAADoImageWrite, bitPlane=0) at ../../../../hw/xfree86/xaa/xaaBitBlt.c:203 #9 0xb7882a3f in XAACopyArea (pSrcDrawable=0xa5bcd008, pDstDrawable=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3) at ../../../../hw/xfree86/xaa/xaaCpyArea.c:66 #10 0xb78c449a in cwCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, w=912, h=785, dstx=7, dsty=3) at ../../../miext/cw/cw_ops.c:201 #11 0x08177a26 in damageCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3) at ../../../miext/damage/damage.c:834 #12 0x0808be86 in ProcCopyArea (client=0xa07bec0) at ../../dix/dispatch.c:1802 #13 0x08155004 in XaceCatchDispatchProc (client=0xa07bec0) at ../../Xext/xace.c:281 #14 0x0808de64 in Dispatch () at ../../dix/dispatch.c:502 #15 0x08074795 in main (argc=9, argv=0xbfe26844, envp= Cannot access memory at address 0xc0286431 ) at ../../dix/main.c:452 Did you check that Xorg was actually stuck in there ? It's a classic backtrace for a GPU lockup - allocating indirect buffers is one point where things can get stuck if the GPU isn't making progress. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490071: xorg occupies all cpu time
On Wed, Aug 6, 2008 at 12:53 PM, Brice Goglin [EMAIL PROTECTED] wrote: [...] Did you check that Xorg was actually stuck in there ? Well, not completely stuck but as reported earlier, 100% CPU usage by X process, mouse pointer responding to movements but not buttons press, keyboard not responding. You should interrupt the process and get the backtrace, then hit 'c' to make the process continue, interrupt again, ... several times and compare the backtraces. I've done that (well... two times instead of several) but only included one backtrace as they were identical. I will try to grab more next time and check for differences. On Wed, Aug 6, 2008 at 1:07 PM, Michel Dänzer [EMAIL PROTECTED] wrote: [...] It's a classic backtrace for a GPU lockup - allocating indirect buffers is one point where things can get stuck if the GPU isn't making progress. Does it exclude an hardware glitch? As I wrote above, it seems to happen in the first few minutes after boot, never happened after few hours of use. It wouldn't surprise me as the video card is a pretty old Radeon 9000 (RV250), four or five years, if not more. -- Andrea -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490071: xorg occupies all cpu time
All last week I've used X attached to GDB trying to get a useful backtrace, but I was not able to replicate the hangs with current Sid packages. The last two days, without GDB, again it worked with no issues, so the glitch, hardware or software, seems disappeared. -- Andrea -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490071: xorg occupies all cpu time
I can reproduce the original report relatively precisely. It appears to be related to 3D acceleration. I'm using the most recent packages in Lenny on AMD64, with a PCIE ATI Radeon X800XT. Using the default XAA acceleration, not EXA. Start an X session (without compiz, tested in Gnome and fluxbox) and start gnome-screensaver-preferences. Click preview and cycle back and forth through the screensavers.. it will pretty quickly hang on a GL screensaver, but the mouse pointer will still be active (usually the screensaver draws nothing). top will show the process for the GL screensaver hack to be taking 100% of the processor time. Kill that process, then Xorg will take 100% of the processor time, and cannot be killed. With EXA, the Xorg process itself will be at 100% utilization and cannot be killed straight away. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490071: xorg occupies all cpu time
Package: xorg Version: 1:7.3+12 Severity: important Hello, since a few days, xorg occassionally occupies the whole available CPU time, which makes the system unusable. It is even impossible to stop the xorg process with kill -9 ...! In /var/log/Xorg.0.log.old I see the following last messages: (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 1 (II) RADEON(0): EDID data from the display on output: VGA-0 -- (II) RADEON(0): Manufacturer: HWP Model: 261e Serial#: 16843009 (II) RADEON(0): Year: 2005 Week: 15 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) RADEON(0): Sync: Separate (II) RADEON(0): Max H-Image Size [cm]: horiz.: 38 vert.: 30 (II) RADEON(0): Gamma: 2.20 (II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display (II) RADEON(0): Default color space is primary color space (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.639 redY: 0.342 greenX: 0.297 greenY: 0.614 (II) RADEON(0): blueX: 0.146 blueY: 0.067 whiteX: 0.312 whiteY: 0.328 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): [EMAIL PROTECTED] (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 108.0 MHz Image Size: 340 x 270 mm (II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEON(0): Serial No: CNC5151V45 (II) RADEON(0): Ranges: V min: 50 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: hp L1902 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 000022f01e2601010101 (II) RADEON(0): 0f0f010368261e78eea150a3574c9d25 (II) RADEON(0): 115054adef8081800101010101010101 (II) RADEON(0): 010101010101302a009851002a403070 (II) RADEON(0): 1300540e111e00ff00434e43 (II) RADEON(0): 353135315634350a202000fd0032 (II) RADEON(0): 4c1e530e000a20202020202000fc (II) RADEON(0): 006870204c313930320a2020202000ac in RADEONProbeOutputModes (II) RADEON(0): EDID vendor HWP, prod id 9758 (II) RADEON(0): I2C device DVI-0:ddc2 registered at address 0xA0. (II) RADEON(0): I2C device DVI-0:ddc2 removed. (II) RADEON(0): I2C device DVI-0:ddc2 registered at address 0xA0. (II) RADEON(0): I2C device DVI-0:ddc2 removed. (II) RADEON(0): I2C device DVI-0:ddc2 registered at address 0xA0. (II) RADEON(0): I2C device DVI-0:ddc2 removed. (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Detected non-DDC Monitor Type: 0 (II) 3rd Button detected: disabling emulate3Button tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. tossed event which came in late
Bug#490071: xorg occupies all cpu time
On Wed, Jul 9, 2008 at 18:32:29 +0200, Juergen Kosel wrote: since a few days, xorg occassionally occupies the whole available CPU time, which makes the system unusable. It is even impossible to stop the xorg process with kill -9 ...! In /var/log/Xorg.0.log.old I see the following last messages: tossed event which came in late mieqEnequeue: out-of-order valuator event; dropping. I believe it is related to the update of xorg a few days ago: I believe it isn't, because the xorg package contains no actual code. Is there anything particular you're doing to reproduce this? Can you try downgrading xserver-xorg-video-ati? Please also send your full X log and config. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
