From: Satyam S. <sa...@in...> - 2007-08-31 14:42:45
|
[ Trimmed Cc: list, dropped sched folk, retained DRM. ] On Fri, 31 Aug 2007, Rene Herman wrote: > On 08/31/2007 08:46 AM, Tilman Sauerbeck wrote: > > > > On 08/29/2007 09:56 PM, Rene Herman wrote: > > > > > > With X server 1.3, I'm getting consistent crashes with two glxgear > > > > > instances running. So, if you're getting any output, it's better than > > > > > my > > > > > situation. > > > > Before people focuss on software rendering too much -- also with 1.3.0 > > > > (and a Matrox Millenium G550 AGP, 32M) glxgears also works decidedly > > > > crummy using hardware rendering. While I can move the glxgears window > > > > itself, the actual spinning wheels stay in the upper-left corner of the > > > > screen and the movement leaves a non-repainting trace on the screen. > > > > This sounds like you're running an older version of Mesa. > > The bugfix went into Mesa 6.3 and 7.0. > > I have Mesa 6.5.2 it seems (slackware-12.0 standard): > > OpenGL renderer string: Mesa DRI G400 20061030 AGP 2x x86/MMX+/3DNow!+/SSE > OpenGL version string: 1.2 Mesa 6.5.2 > > The bit of the problem sketched above -- the gears just sitting there in the > upper left corner of the screen and not moving alongside their window is fully > reproduceable. The bit below ... : > > > > > Running a second instance of glxgears in addition seems to make both > > > > instances unkillable -- and when I just now forcefully killed X in this > > > > situation (the spinning wheels were covering the upper left corner of > > > > all > > > > my desktops) I got the below. > > [ two kernel BUGs ] > > ... isn't. This seems to (again) have been a race of sorts that I hit by > accident since I haven't reproduced yet. Had the same type of "racyness" > trouble with keyboard behaviour in this version of X earlier. Dave (Airlie), this is an oops first reported at: http://lkml.org/lkml/2007/8/30/9 mga_freelist_get() is inlined at its only callsite mga_dma_get_buffers() that is in turn inlined at its only callsite in mga_dma_buffers(). This oops was hit ... static struct drm_buf *mga_freelist_get(struct drm_device * dev) { ... head = MGA_READ(MGA_PRIMADDRESS); <=== ... HERE. ... } MGA_READ() is DRM_READ32(), and dev_priv->mmio was found to be NULL when trying to access dev_priv->mmio->handle as shown above. > > Running two instances of glxgears and killing them works for me, too. > > > > I'm using xorg-server 1.3.0.0, Mesa 7.0.1 with the latest DRM bits from > > http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary > > For me, everything standard slackware-12.0 (X.org 1.3.0) and kernel 2.6.22 > DRM. > > > I'm not running CFS though, but I guess the oops wasn't related to that. > > I've noticed before the Matrox driver seems to get little attention/testing so > maybe that's just it. A G550 is ofcourse in graphics-time a Model T by now. > I'm rather decidedly not a graphics person so I don't care a lot but every > time I try to do something fashionable (run Google Earth for example) I notice > things are horribly, horribly broken. > > X bugs I do not find very interesting (there's just too many) and the kernel > bugs are requiring more time to reproduce than I have available. If the BUGs > as posted aren't enough for a diagnosis, please consider the report withdrawn. As you already know by now, this oops isn't a bug or anything in the scheduler at all, but more likely a race in the DRM itself (which possibly could have been exposed by some aspect of CFS). So it makes sense to "withdraw" this as a CFS-related bug report, but definitely not as a DRM- related bug report. Satyam |