Re: VIA KT400A and AGP/DRI?

From: Doug White <dwhite_at_gumbysoft.com>
Date: Tue, 24 Feb 2004 09:58:40 -0800 (PST)
On Tue, 24 Feb 2004, Stefan Walter wrote:

> Stefan Walter, 13.01.04, 16:20h CET:
>
> > I just replaced an old mainboard with a new one with a VIA KT400A
> > chipset. Is it possible to get DRI working with that? It used to work
> > with the old board (different chipset), but I had to turn off DRI in my
> > X configuration for the new one, as it made X/the system freeze/hang
> > immediately.


What happens if you force it to AGP4x? I get crashes o my system if its
run at AGP8x, at least under windows.

>
> The problem still persists in a -CURRENT as of February 14th (due to the
> recent threading related changes, all ports have been recompiled as
> well). It doesn't freeze but panics when I start X with DRI enabled. The
> monitor is in standby right after switching from the console, so I don't
> see anything while it's writing the core.
> A 'gdb -k /boot/kernel/kernel ./vmcore.0' outputs the following:
>
> ***
> GNU gdb 5.2.1 (FreeBSD)
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-undermydesk-freebsd"...(no debugging symbols found)...
> panic: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address	= 0x1
> fault code		= supervisor write, page not present
> instruction pointer	= 0x8:0xc0500004
> stack pointer	        = 0x10:0xe1959b8b
> frame pointer	        = 0x10:0xe1959b90
> code segment		= base 0x0, limit 0xfffff, type 0x1b
> 			= DPL 0, pres 1, def32 1, gran 1
> processor eflags	= interrupt enabled, resume, IOPL = 3
> current process		= 49093 (XFree86)
> trap number		= 12
> panic: page fault
> at line 819 in file /usr/src/sys/i386/i386/trap.c
>
> syncing disks, buffers remaining... 3842 3842 3841 3841 3841 3839 3839 3838 3838 3838 3837 3838 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837
> giving up on 1099 buffers
> Uptime: 6h41m50s
> Dumping 511 MB
>  16 32[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]  48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496
> ---
> Reading symbols from /boot/kernel/acpi.ko...(no debugging symbols found)...done.
> Loaded symbols for /boot/kernel/acpi.ko
> Reading symbols from /boot/kernel/blank_saver.ko...(no debugging symbols found)...done.
> Loaded symbols for /boot/kernel/blank_saver.ko
> #0  0xc05438b0 in doadump ()
> (kgdb) quit
> ***
>
> I am not too familiar with kernel hacking, so suggestions/hints are
> welcome. My XF86Config and the output of dmesg and pciconf are still
> available at [1].
>
> Stefan
>
> [1]: http://www.gegenunendlich.de/stuff/kyuzo/
>

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite_at_gumbysoft.com          |  www.FreeBSD.org
Received on Tue Feb 24 2004 - 08:58:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:44 UTC