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 :p

[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.

[cogumbreiro]

You can alway try Alan Cox's branch of 2.4.20 kernel which is called 2.4.20-c2 check it on http://www.kernel.org and that guy is from Red Hat so maybe Red Hat has an rpm version of this kernel. Btw to compile a kernel is quite easy and nothing to be afraid to do, first try to find the "config" file related to your actual kernel or do a "make oldconfig && make dep" then do the following (all these commands are made in the /usr/src/linux and *after* you symlinked linux-2.4.20-ac2 to /usr/src/linux):
--actual code--
make xconfig (or "make menuconfig" if you don't have tcl/tk libs)
--end of actual code--
You might want to check if all the options are correct.
--actual code--
make dep
make bzImage
make modules
make modules_install
cp System.map /boot/System.map-2.4.20-c2
cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.20-c2
vi /etc/lilo.conf
--actual code ends--
Edit /etc/lilo.conf file and add the following entry in the end of the file:
--/etc/lilo.conf--
image = /boot/vmlinuz-2.4.20-ac2
root = /dev/hda1 #Check your root if it's the same
label = Linux-2.4.20-ac2
read-only
--end of /etc/lilo.conf--
And that's it, not difficult at all, just try it:)
And one thing *don't* try to use NVAGP it *doesn't* and it will *never* work with via kt400 because via doesn't supports nvagp (at least with this chipset).
:afro: Cool Guy :P :afro:

[Omnifarious]

I've done it many times. I used to put LVM into my kernel before it was there by default. It's just annoying and time consuming. I have better things to do with my time.

Now, since agpgart is a loadable module, I may consider pulling the agpgart code from some other kernel, compiling it against the current kernel sources, and replacing the standard agpgart module with my own. That's a little less painful than compiling a whole kernel by hand. I've been doing that with cipe, since RedHat has been reluctant to ship cipe 1.5.4 instead of 1.4.5.

And, as I said, I looked at the kernel sources from RedHat's beta Phoebe release, and they appear to have support for the KT400, so I'll wait for RedHat 8.1 (or maybe it will be 9.0).

[cogumbreiro]

I tried to that and it didn't work, the agart from kernel 2.4.21-pre2 doesn't work with 2.4.19, Redhat 8.0 is still using 2.4.18 right?
But i must warn you that the kt400 support isn't fully correct because i tried kernel 2.4.21-pre3 (released today) and still doesn't recognizes apperture size of my GF4 MX440...
And i don't think kernel compiling takes that much of a time you let it compile you don't need to stare at it, you can do things in the meanwhile :p :D

[Omnifarious]

It isn't the time spent compiling it. It's the time spent carefully going over all the options to make sure they're right, and the time spent to maintain on configuration and version management when RPM is no longer doing it for me.

The new RH will be using 2.4.20. Currently, it uses 2.4.18 plus lots of patches.