No AGP with KT400 chipsets

[Omnifarious]

I had a Soyo DRAGON KT266 based motherboard die on me recently, and I'm now using their KT400 based motherboard.

Sadly, the Linux kernel's agpgart doesn't support this chipset, and neither does the nVidia driver. Any plans for this to change soon?

[bwkaz]

You can hack in support for the agpgart driver, by finding your northbridge's PCI ID, then editing include/linux/pci_ids.h and drivers/char/agp/agpgart_be.c in your Linux kernel source, and recompiling the kernel (actually, all you'd be recompiling should be the agpgart module), but you may not have to.

If you add a line to /etc/modules.conf reading options agpgart agp_try_unsupported=1, your KT400 may be detected, initialized, and used, but only when you use the agpgart driver.

[Omnifarious]

options agpgart agp_try_unsupported=1 doesn't work. It causes my computer to crash. That tells me that simply going into the agpgart.c source code and added a new PCI ID for the AGP bridge won't work either.

Anyway, it works without AGP for now, but I would like to see some support in the future. Perhaps nVidia could *gasp* contribute to an Open Source project and add the correct code to agpgart.c as well.

[bwkaz]

Originally posted by Omnifarious
Perhaps nVidia could *gasp* contribute to an Open Source project and add the correct code to agpgart.c as well.

Why should they? Seeing as the KT400 is not an nVidia chipset (it's a Via one), and seeing as nVidia did not write any of the agpgart code in the first place (and they therefore aren't a maintainer of it), I really don't see any reason why they should write a driver. Seeing as they're completely unfamiliar with the chipset...

I remember someone else having a KT400 chipset, and one of these two working for them.

If I remember correctly, they had issues too with it originally, but then they tried a different video card, and everything worked wonderfully. Although that might have been the SiS 651 chipset, I don't think it was.

[Omnifarious]

As soon as there's an option using Open Source drivers that comes within 75% of the performance of an nVidia card, I'm dropping nVidia as fast as I can.

I think their closed source drivers are untrustworthy, and I hate loading them into my kernel. It's high ickiness. The only reason I do it is because I think buying and running games under Linux is more important than avoiding nVidia for their stupid policy.

I don't suppose they're responsible for making the KT400 chipset work. But their drivers really annoy me and tend to cloud my thinking in their regard. Whenever anything crashes on my computer, those drivers are the first suspects, since I know they've undergone no peer review outside their own company.

Anyway, their drivers have a whole range of non-nVidia chipsets they support. So, I thought maybe they'd want to support another.

[bwkaz]

They support those non-nVidia chipsets through the facilities of the kernel, though, not through anything nVidia has done...

Well, that is assuming you use agpgart. Option "NvAgp" "1" (using NvAgp instead) would require that nVidia's driver work with it. But NvAgp will only be changed with a new driver release, and I wouldn't be surprised if it was quite a while before that happened.

You could always see if 2.5.45 works on your machine, then patch the NVIDIA_kernel tarball with one of the posted patches that has been tested against 2.5.45, reinstall the NVdriver kernel module, and try that. I'm fairly sure that 2.5.45 supports the KT400, though I'm not positive.

Edit: Never mind, it apparently isn't. Just checked drivers/char/agp/agp.c (the file layout has been changed), and the KT400 isn't listed in the initializer list there. What does /proc/pci say the PCI ID is for your northbridge (normally the first device in there)?

[Omnifarious]

I was talking about if you set "NvAGP" "1" when I asked for nVidia to support the KT400. I already have a bug report stuck in bugzilla.redhat.com about agpgart not supporting it.

I believe these are the vendor and device IDs for the VIA KT400 north bridge:

00:00.0 Class 0600: 1106:3189
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 3189

Might also be one of these two, but I don't think so:

00:01.0 Class 0604: 1106:b168
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device b168

00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge
00:11.0 Class 0601: 1106:3177

[bwkaz]

You'd need both of those IDs, actually.

In include/pci_ids.h (from the base directory of the 2.4.19 kernel; other recent 2.4 kernels would hopefully be the same), in the section where it has DEVICE_ID_VIA_xxxxx, add a couple of lines (preferably at the end of that section):

#define DEVICE_ID_VIA_8235_0 0x3189
#define DEVICE_ID_VIA_8235_1 0xb168

Save and exit your editor, and then open up drivers/char/agp/agpgart_be.c and add a device descriptor near the end. Do a search for CONFIG_AGP_VIA, and look around the third hit.

Down a bit further, there should be a set of lines looking like:

	{ PCI_DEVICE_ID_VIA_8367_0,
		PCI_VENDOR_ID_VIA,
		VIA_APOLLO_KT133,
		"Via",
		"Apollo Pro KT266",
		via_generic_setup },

Right after that, insert another section that looks almost the same:

	{ PCI_DEVICE_ID_VIA_8235_0,
		PCI_VENDOR_ID_VIA,
		VIA_APOLLO_KT133,
		"Via",
		"Apollo Pro KT266",
		via_generic_setup },

Then recompile the kernel and see that first, the AGP devices are detected properly in /proc/pci, and second, whether you can initialize AGP when you load the NVdriver and agpgart modules. You can just modprobe NVdriver, then modprobe agpgart, then check /proc/driver/nvidia/agp/status for whether or not it's initialized. Then try to startx (using agpgart), and see if you still get lockups. Also, you'll want to make sure you have your AGP stuff set to 4x everywhere -- which means that you'll probably want to set up options NVdriver NVreg_EnableVia4x=1 in your modules.conf as well. The KT400 chipset doesn't support the higher voltage ofthe older AGP 1x/2x cards, so it could be that when the nVidia driver requests 2x mode, the motherboard says "I can't do that", so it gets disabled.

Actually, now that I think about it, you might want to try that options line first...

[Omnifarious]

I may not get to this for a few days now that the work week has started, but I'll report back when I do.

I am curious about one thing... You suggest that I add:

#define DEVICE_ID_VIA_8235_1 0xb168

But, you don't use the DEVICE_ID_VIA_8235_1 symbol in any of the other code you suggest I add. You do use the DEVICE_ID_VIA_8235_0 symbol in the addition to the array you suggest, but not the other one. Why should that define be there? Is there a place I should be using it?

[bwkaz]

Right, I don't use it anywhere else. You could probably add a string description of it somewhere into the PCI driver (for /proc/pci's use), but you don't need that to get it to work. The reason it's there is just for symmetry more than anything else -- most of the other chipset device ID's have a _0 and _1 variant (usually for the north bridge itself and the AGP bridge sub-device-thingy), so I thought it might be good for this one to have it as well. If you don't want it, you can probably leave it out, although /proc/pci will complain that it's unrecognized then. Although it may complain anyway, I don't know.

There's a superficial reason for putting it there, though -- to keep the device IDs that the kernel knows about in sync with what you know about. But other than that, it's not needed.

[cogumbreiro]

Maybe you can try with the new kernel 2.4.21-pre2
To install it:
1- untar linux-2.4.20.tar.gz to /urs/src
3- gunzip patch-2.4.21-pre2.gz
4- cd /usr/src/linux-2.4.20
5- patch -p1 < /path/to/your/patch-2.4.21-pre2
6- compile it with agp support
7- you're done

[Omnifarious]

RedHat appears to have support in the Phoebe beta 2.4.20 kernel. I may install that kernel, or I may wait until the final version shows up and try that. Compiling my own custom kernel is a pain. It's bad enough I have to custom compile cipe. :-(

The 4191 drivers seems to have support via NvAGP, but I'm getting some weird halting when I move windows or windows need to be redrawn. The halting appears to be in the kernel as xmms momentarily (less than a second) stops playing.

When I move windows, it gets very jerky if I move them quickly.

When I flip desktops, there is sometimes a noticeable pause until everything suddenly redraws, and during this pause, xmms sometimes stops playing.

All other UI operations are very snappy, including scrolling in Mozilla. Also, I sometimes get normal behavior for a short time after I stop playing Quake 3, or other heavy GL game.