From: Rene H. <ren...@gm...> - 2007-08-30 07:11:41
|
On 08/29/2007 09:56 PM, Rene Herman wrote: Realised the BUGs may mean the kernel DRM people could want to be in CC... > On 08/29/2007 05:57 PM, Keith Packard 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. > 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. > > Kernel is 2.6.22.5-cfs-v20.5, schedule() is in the traces (but that may be > expected anyway). > > BUG: unable to handle kernel NULL pointer dereference at virtual address > 00000010 > printing eip: > c10ff416 > *pde = 00000000 > Oops: 0000 [#1] > PREEMPT > Modules linked in: nfsd exportfs lockd nfs_acl sunrpc nls_iso8859_1 > nls_cp437 vfat fat nls_base > CPU: 0 > EIP: 0060:[<c10ff416>] Not tainted VLI > EFLAGS: 00210246 (2.6.22.5-cfs-v20.5-local #5) > EIP is at mga_dma_buffers+0x189/0x2e3 > eax: 00000000 ebx: efd07200 ecx: 00000001 edx: efc32c00 > esi: 00000000 edi: c12756cc ebp: dfea44c0 esp: dddaaec0 > ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068 > Process glxgears (pid: 1775, ti=dddaa000 task=e9daca60 task.ti=dddaa000) > Stack: efc32c00 00000000 00000004 e4c3bd20 c10fa54b e4c3bd20 efc32c00 > 00000000 > 00000004 00000000 00000000 00000000 00000000 00000001 00010000 > bfbdb8bc > bfbdb8b8 00000000 c10ff28d 00000029 c12756cc dfea44c0 c10f87fc > bfbdb844 > Call Trace: > [<c10fa54b>] drm_lock+0x255/0x2de > [<c10ff28d>] mga_dma_buffers+0x0/0x2e3 > [<c10f87fc>] drm_ioctl+0x142/0x18a > [<c1005973>] do_IRQ+0x97/0xb0 > [<c10f86ba>] drm_ioctl+0x0/0x18a > [<c10f86ba>] drm_ioctl+0x0/0x18a > [<c105b0d7>] do_ioctl+0x87/0x9f > [<c105b32c>] vfs_ioctl+0x23d/0x250 > [<c11b533e>] schedule+0x2d0/0x2e6 > [<c105b372>] sys_ioctl+0x33/0x4d > [<c1003d1e>] syscall_call+0x7/0xb > ======================= > Code: 9a 08 03 00 00 8b 73 30 74 14 c7 44 24 04 28 76 1c c1 c7 04 24 49 > 51 23 c1 e8 b0 74 f1 ff 8b 83 d8 00 00 00 83 3d 1c 47 30 c1 00 <8b> 40 > 10 8b a8 58 1e 00 00 8b 43 28 8b b8 64 01 00 00 74 32 8b > EIP: [<c10ff416>] mga_dma_buffers+0x189/0x2e3 SS:ESP 0068:dddaaec0 > BUG: unable to handle kernel NULL pointer dereference at virtual address > 00000010 > printing eip: > c10ff416 > *pde = 00000000 > Oops: 0000 [#2] > PREEMPT > Modules linked in: nfsd exportfs lockd nfs_acl sunrpc nls_iso8859_1 > nls_cp437 vfat fat nls_base > CPU: 0 > EIP: 0060:[<c10ff416>] Not tainted VLI > EFLAGS: 00210246 (2.6.22.5-cfs-v20.5-local #5) > EIP is at mga_dma_buffers+0x189/0x2e3 > eax: 00000000 ebx: efd07200 ecx: 00000001 edx: efc32c00 > esi: 00000000 edi: c12756cc ebp: dfea4780 esp: e0552ec0 > ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068 > Process glxgears (pid: 1776, ti=e0552000 task=c19ec000 task.ti=e0552000) > Stack: efc32c00 00000000 00000003 efc64b40 c10fa54b efc64b40 efc32c00 > 00000000 > 00000003 00000000 00000000 00000000 00000000 00000001 00010000 > bf8dbdcc > bf8dbdc8 00000000 c10ff28d 00000029 c12756cc dfea4780 c10f87fc > bf8dbd54 > Call Trace: > [<c10fa54b>] drm_lock+0x255/0x2de > [<c10ff28d>] mga_dma_buffers+0x0/0x2e3 > [<c10f87fc>] drm_ioctl+0x142/0x18a > [<c11b53f6>] preempt_schedule+0x4e/0x5a > [<c10f86ba>] drm_ioctl+0x0/0x18a > [<c10f86ba>] drm_ioctl+0x0/0x18a > [<c105b0d7>] do_ioctl+0x87/0x9f > [<c105b32c>] vfs_ioctl+0x23d/0x250 > [<c11b52a9>] schedule+0x23b/0x2e6 > [<c11b533e>] schedule+0x2d0/0x2e6 > [<c105b372>] sys_ioctl+0x33/0x4d > [<c1003d1e>] syscall_call+0x7/0xb > ======================= > Code: 9a 08 03 00 00 8b 73 30 74 14 c7 44 24 04 28 76 1c c1 c7 04 24 49 > 51 23 c1 e8 b0 74 f1 ff 8b 83 d8 00 00 00 83 3d 1c 47 30 c1 00 <8b> 40 > 10 8b a8 58 1e 00 00 8b 43 28 8b b8 64 01 00 00 74 32 8b > EIP: [<c10ff416>] mga_dma_buffers+0x189/0x2e3 SS:ESP 0068:e0552ec0 > [drm:drm_release] *ERROR* Device busy: 2 0 Rene. |
From: Tilman S. <ti...@co...> - 2007-08-31 06:46:59
|
Rene Herman [2007-08-30 09:05]: > On 08/29/2007 09:56 PM, Rene Herman wrote: >=20 > Realised the BUGs may mean the kernel DRM people could want to be in CC... >=20 > > On 08/29/2007 05:57 PM, Keith Packard wrote: > >=20 > >> 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. > >=20 > > 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. > > 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 a= ll > > my desktops) I got the below. 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=3Dmesa/drm.git;a=3Dsummary I'm not running CFS though, but I guess the oops wasn't related to that. Regards, Tilman --=20 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? |
From: Rene H. <ren...@gm...> - 2007-08-31 11:20:25
|
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. > 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. Rene. |
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 |
From: Ingo M. <mi...@el...> - 2007-08-30 07:20:39
|
* Rene Herman <ren...@gm...> wrote: > Realised the BUGs may mean the kernel DRM people could want to be in CC... and note that the schedule() call in there is not part of the crash backtrace: > >Call Trace: > > [<c10fa54b>] drm_lock+0x255/0x2de > > [<c10ff28d>] mga_dma_buffers+0x0/0x2e3 > > [<c10f87fc>] drm_ioctl+0x142/0x18a > > [<c1005973>] do_IRQ+0x97/0xb0 > > [<c10f86ba>] drm_ioctl+0x0/0x18a > > [<c10f86ba>] drm_ioctl+0x0/0x18a > > [<c105b0d7>] do_ioctl+0x87/0x9f > > [<c105b32c>] vfs_ioctl+0x23d/0x250 > > [<c11b533e>] schedule+0x2d0/0x2e6 > > [<c105b372>] sys_ioctl+0x33/0x4d > > [<c1003d1e>] syscall_call+0x7/0xb it just happened to be on the kernel stack. Nor is the do_IRQ() entry real. Both are frequent functions (and were executed recently) that's why they were still in the stackframe. Ingo |