On Wed, 2009-04-29 at 07:55 +0200, Richard Körber wrote: > Hi! > > > F11 Preview.i368 with all updates as of 30 minutes ago! Everytime I > > visit www.wthitv.com <http://www.wthitv.com> (with firefox) my computer > > hard locks with only mouse movement. > > This sounds like the infamous "EQ Overflowing" bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=465884 "EQ overflowing" is not a bug, dang it. It's a symptom. Input events are handled in two places in X. A signal handler reads the events from the kernel, updates the cursor position, and adds the event to the queue; and then the main loop drains the event queue, sending events to clients and possibly updating the cursor image (say, if it changes from an arrow to a text bar). Since you can't malloc from signal handlers, the event queue is some fixed (but large) size. If you run out of space in the event queue, it's because the server is stuck somewhere away from the main loop. But that's not any one specific place, that's the entire rest of the X server. You could be waiting for the hardware to go idle. You could be waiting to acquire the DRI lock (in DRI1). You could be trying to do some kernel request that the kernel is taking its sweet time to get around to. _Anything_. So "EQ overflowing" is not any one particular bug, it's a symptom of many different bugs. In this particular case, it's something much more lame: (gdb) bt #0 0x00de3f73 in pixmanBltsse2 (src_bits=0xa8587000, dst_bits=0xa0587000, src_stride=1408, dst_stride=1408, src_bpp=32, dst_bpp=32, src_x=0, src_y=0, dst_x=0, dst_y=0, width=1299, height=15000) at pixman-sse2.c:4530 #1 0x00dd95ba in pixman_blt (src_bits=0xa8587000, dst_bits=0xa0587000, src_stride=1408, dst_stride=1408, src_bpp=32, dst_bpp=32, src_x=0, src_y=0, dst_x=0, dst_y=0, width=1299, height=15000) at pixman-utils.c:51 #2 0x00ef440a in fbCopyNtoN (pSrcDrawable=0x136b7530, pDstDrawable=0x1351e660, pGC=0x13409748, pbox=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at fbcopy.c:64 #3 0x002f0cc6 in uxa_copy_n_to_n () from /usr/lib/xorg/modules/drivers//intel_drv.so #4 0x00ef344b in fbCopyRegion (pSrcDrawable=0x136b7530, pDstDrawable=0x1351e660, pGC=0x13409748, pDstRegion=0xbf983b04, dx=0, dy=0, copyProc=0x2f0570 <uxa_copy_n_to_n>, bitPlane=0, closure=0x0) at fbcopy.c:396 #5 0x00ef396d in fbDoCopy (pSrcDrawable=0x136b7530, pDstDrawable=0x1351e660, pGC=0x13409748, xIn=0, yIn=0, widthSrc=1299, heightSrc=15000, xOut=0, yOut=0, copyProc=0x2f0570 <uxa_copy_n_to_n>, bitPlane=0, closure=0x0) at fbcopy.c:596 #6 0x002f0518 in uxa_copy_area () from /usr/lib/xorg/modules/drivers//intel_drv.so #7 0x0817a753 in damageCopyArea (pSrc=0x136b7530, pDst=0x1351e660, pGC=0x13409748, srcx=0, srcy=0, width=1299, height=15000, dstx=0, dsty=0) at damage.c:949 #8 0x08084b45 in ProcCopyArea (client=0xf205018) at dispatch.c:1555 #9 0x08086807 in Dispatch () at dispatch.c:437 Check out frame 0 [1]. The server is being asked to do a blit that's 15000 pixels tall. Who knows why, it could easily be a bug in firefox, but it could also be something the web page really did ask for. At any rate, the server's been asked to do it, so we really have no choice but to do it. Problem is your GPU can't accelerate that blit; even really nice ones like R700 have a blit coordinate limit of like 8192 pixels. So we fall back to software, which is the pixman bits in the backtrace. Now the subtle bit is that, okay, yeah, it's a huge blit, but it's also only like 75M of data. You have giganoms [2] of memory bandwidth, this should take milliseconds, not minutes. So what's almost certainly gone wrong here is that the kernel is giving us a bad caching policy on the map of video memory, so all those reads have to go out to the bus every time. So you're not actually hardlocked. You're just doing something very slow, a few billion times. I've been chasing this bug all week. Hopefully it'll be fixed soon? [1] - Also check out frame #2. Yeah baby, X is so hardcore it breaks gdb's DWARF decoder. Bug #497425. [2] - One nom being one byte per second, of course. Om nom nom. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
