On Fri, Apr 18, 2003 at 10:28:24AM -0500, Florin Iucha wrote:
>
> With 2.5.67-bk8, agpgart and sis-agp compiled as modules and loaded:
> - X starts (I am using wdm as display manager)
> - direct rendering is enabled, according to /var/log/XFree86.0.log
> - start glxgears
> - framerate 130!!! It should be around 1900-2000 on my hardware
> (moons ago on XFree 4.2.1 + DRI snapshot)
Very strange. Does glxinfo output look sane too? Especially the
OpenGL renderer string. It sounds like it isn't doing hw rendering
even if your X log says it is..
> - after 15-20 seconds, the X session is restarted - back to wdm
> screen
> - I login, I logout and the machine freeze
> - the last words on serial console:
> [drm] Loading R200 Microcode
> double fault, gdt at c039df00 [255 bytes]
> double fault, tss at c0418800
> eip = c0143a00, esp = ececbf0c
> eax = ee37dc60, ebx = ee37dc40, ecx = 0000007b, edx = 00000000
> esi = ee37dc60, edi = edc0e0c0
Not good at all. 'bad shit happened'.
> With 2.5.67-bk8, agpgart and sis-agp built in:
> - no lockups
It's essentially the same code though, which doesn't
make a lot of sense.
> - direct rendering is disabled
Again, puzzling. What reason is given for this in your
XFree86.log ?
> - X crashes sometimes with the following traces:
> agpgart: Found an AGP 2.0 compliant device.
> agpgart: Putting AGP V2 device at 00:00.0 into 4x mode
> agpgart: Putting AGP V2 device at 01:00.0 into 4x mode
> [drm] Loading R200 Microcode
> agpgart: Found an AGP 2.0 compliant device.
> agpgart: Putting AGP V2 device at 00:00.0 into 4x mode
> agpgart: Putting AGP V2 device at 01:00.0 into 4x mode
> [drm] Loading R200 Microcode
The fact that this lot appears twice is odd, or did you
restart the X server ?
> Unable to handle kernel paging request at virtual address fffffff0
> printing eip:
> c0146147
> *pde = 00001067
> *pte = 00000000
> Oops: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c0146147>] Not tainted
> EFLAGS: 00013286
> EIP is at page_remove_rmap+0xb7/0x130
> eax: ffffffff ebx: c14acc48 ecx: 0000000f edx: fffffff0
> esi: dcd5ffc0 edi: ffffffff ebp: fffffff0 esp: da333b60
> ds: 007b es: 007b ss: 0068
> Process XFree86 (pid: 657, threadinfo=da332000 task=de0ced00)
> Stack: dcb72cc0 dcd5ffc0 da403a18 da403a18 0006e000 00100000 c14acc48 c0140495
> c14acc48 da332000 da332000 00000000 1deb5045 dc8b5084 08618000 08318000
> c0465758 c014053b c0465758 dc8b5080 08218000 00100000 08218000 dc8b5084
> Call Trace:
> [<c0140495>] zap_pte_range+0x155/0x1b0
> [<c014053b>] zap_pmd_range+0x4b/0x70
> [<c01405a3>] unmap_page_range+0x43/0x70
> [<c0140694>] unmap_vmas+0xc4/0x220
> [<c01444cb>] exit_mmap+0x7b/0x190
> [<c011bc44>] mmput+0x54/0xb0
> [<c0159203>] exec_mmap+0xb3/0x130
> [<c0159309>] flush_old_exec+0x19/0x850
> [<c0159140>] kernel_read+0x50/0x60
> [<c0175525>] load_elf_binary+0x2d5/0xb50
> [<c01651e2>] dput+0x22/0x1e0
> [<c021a187>] linvfs_readv+0x47/0x50
> [<c0175250>] load_elf_binary+0x0/0xb50
> [<c0159e7a>] search_binary_handler+0x8a/0x1d0
> [<c015a1d1>] do_execve+0x211/0x260
> [<c01093e0>] sys_execve+0x50/0x80
> [<c010ab77>] syscall_call+0x7/0xb
So X tried to load a module (likely the DRI part), and in doing so
something went awry.
Could be that something else caused memory corruption beforehand,
but that's speculation. If this always happens the second time
the server starts, it could be a problem with reentrancy of the
r200 dri module maybe. *shrug*.
Frankly, from this backtrace, I've no idea.
There are a bunch of radeon fixes pending in the DRI tree,
so things could suddenly 'start working' again, so this could
be one to keep an eye on in bugzilla for now so we don't forget about it.
Dave
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:26 EST