nV News Forums


nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   VIA Apollo P4X400 chipset (VT8754 +VT8235) (http://www.nvnews.net/vbulletin/showthread.php?t=2832)

JollyRogers 10-13-02 07:07 PM

VIA Apollo P4X400 chipset (VT8754 +VT8235)
I just bought a SOYO SY-P4x400 Dragon ultra. Put RH8.0 on it. Got everything to work, including the nvidia drivers. But there is one problem. No agp support. Not NvAgp nor AGPGART.

I know AGPGART is trying to load as a module. Cause I get the unsupported chipset warning. So I add to modules.conf:

alias char-major-10-175 agpgart
options agpgart agp_try_unsupported=1
alias char-major-195 NVdriver

And AGPGART appears to load ok. then when X starts (using Option "NvAGP" "2" in XF86Config), I get a little red square up at the top left of screen. I know it is a problem with AGPGART because if comment out the entry in modules.conf for agpgart, or set "NvAgp" "0", then X starts fine.

I guess I wait. I searched all change logs in kernel's 2.4 and 2.5 and found nothing for support on this chipset in regards to AGPGART.
What of NVagp? Any chance that these chipsets will be supported?
Any help? Any ideas. I am out of them. The only thing I got left is return the board, or by windows. And it would be cheaper to by different board!

JollyRogers 10-14-02 08:59 PM

Well as a follow up. I tried upgrading to a newer kernel. But it was 2.5.42 and the NVIDIA_kernel-XXXXX.src.rpm would not even build under it, because it is "not" meant for testing kernels. Oh well that aint cool. Guess I shoulda tried 2.4.20. I did manage to get X to load under 4XAGP w/ the stock RH8.0 2.4.18-14 kernel and Nvidia's driver using AGPGART. But it locked up right away.
I got a MB and Geforce4 without the capability of 4XAGP. My old computer w/ Geforce3 does better. Plus that means no Unreal2003! :(

The chipset is a VIA P4X400 Apollo. Research what you buy........

bwkaz 10-15-02 08:42 AM

There may be a way to add support for that chip, assuming it works the same way the other Via AGP chips work.

I was poking around in linux/drivers/char/agp/agpgart_be.c (the AGP backend source file), and found the "list of supported AGP chips" in it. Assuming you know the PCI ID of your northbridge, you can add it to linux/include/linux/pci_ids.h -- find the line that says #define PCI_DEVICE_ID_VIA, and somewhere in that block of Via device ID #defines, add a line:

#define PCI_DEVICE_ID_VIA_8754_0 0xzzzz, where zzzz is the PCI ID of your northbridge.

You can find the ID out, if you have Linux running, by doing a cat /proc/bus/pci/devices | grep 1106 | awk '{print $1; print $2;}' -- the grep 1106 filters out any non-Via hardware you may have (1106 is Via's vendor ID), and the awk statement discards all the flag bits associated with each device, to make things more readable.

The device ID you want is probably the first one printed -- the format is, 4 characters representing bus, device, and function number (basically, where this thing is plugged in on your PCI bus) on one line, then 4 characters for vendor ID, followed by 4 characters for device ID, on the next line. So my guess is that adding the last 4 characters from the second line to the pci_ids.h file will suffice. Although it's probably not a bad idea to take the last 4 characters of the fourth line printed (this is some sort of secondary AGP bridge, or something), and add another line to pci_ids.h:

#define PCI_DEVICE_ID_VIA_8754_1 0xzzzz, where zzzz is now those four characters.

Once you've changed that file, you have to change linux/drivers/char/agp/agpgart_be.c as well. Down near the bottom, near to (but above) the #endif /* CONFIG_AGP_VIA */ line, add a few lines like this:


        { PCI_DEVICE_ID_VIA_8754_0,
                "Apollo Pro KT400",
                via_generic_setup },

That's the PCI ID you just added to pci_ids.h, with a vendor ID of Via, a set of flags that says "this is compatible with the KT133" (at least, that's what it looks like... I'm not positive that's what it actually means), a string for vendor ("Via"), a string for the device name ("Apollo Pro KT400" -- you can change this if you want), and the address of an initialization routine (via_generic_setup). Almost all the Via AGP chips use this routine for their initialization, and I believe the KT400 shouldn't be any different.

Now recompile your kernel (make sure you enable AGPGART, even if you have it as a module, and make sure to enable "Via chipset support" or whatever it's called), and see if that at least works.

Actually, the more I think about this, the more I think it's a long shot, but it might be worth it to try.

JollyRogers 10-15-02 04:34 PM

Thanks for the reply. Actually I tried something similiar, but not as complete. I added the chipset ID to the kernel/include/pci_ids.h table (BTW I also added this to the list at sourceforge to get updated). However, I did not add anything to agpgart_be.c . I then recompiled my kernel with agpgart as a module. Then I loaded it from modules.conf w/:
alias char-major-10-175 agpgart
option agpgart agp_try_unsupported=1

When the module loads it says it is using the VIA generic routine for AGP. Loading at 0e000000. That is what dmesg says and the module appears to load OK.

However, when it actually gets "used" by NVdriver during the start of X, that is when it crashes...hard.

I thought of hacking the module like you suggest, but I am thinking that if AGP for VT8754 is the same as the other chipsets, then the VIA generic routine would have worked fine, but it didn't. I read somewhere that VIA claims the chipset is backwards compatible, hence there shouldn't be any change. But this chipset supports 8Xagp also. So maybe there is something different? I ended up putting win2000 on this box and am very unhappy. But I also realize it will take time before the chipset will be supported better in my OS of choice. I gotta have 4Xagp for gaming! Also to note, Is there anyone with 4Xagp/NVidia drivers working with the KT400 and a GF4?

Another idea. I have a geforce3 in my kid's box running Slackware. I could switch out the cards. Though my GF4 was working fine when it was on my abit board 6 days ago running under Slackware, and seems to work fine under windows now.

I will drop another drive in and reinstall linux just to hack the agpgart kernel module and see if I can get it with that "long shot" :) I also can ask VIA for the chipset specifications etc and see if maybe it is different that I can figure it out. Or maybe someone from Nvidia or VIA could help out on this one?


JollyRogers 10-15-02 05:34 PM

hey since I do have windows installed, it does give memory address ranges etc. Maybe these could be used for writing the hack?

bwkaz 10-15-02 09:01 PM

Yeah, maybe. PCI should have a way to probe for that kind of configuration information, regardless of the device, though.

The 8X AGP might indeed have something to do with it, but I don't know enough about it to suggest anything, unfortunately.

Yeah, I don't think the problem is the video card, it's probably the KT400. But you're welcome to try it, of course. ;)

You said that later 2.5 kernels do support that chipset? Or didn't you get that far? There are patches somewhere to get NVIDIA_kernel to compile against 2.5 Linux kernels, so maybe trying one of those would help?

If the KT400 is supported in recent 2.5's, then you might try looking back through the changelogs to see when it was added, then taking a diff of pci-ids.h and the drivers/char/agp directory (diff between the version right before support was added, and the version that it first worked with, obviously) to see what got changed. See if you can maybe hack those changes into 2.4.19, or something...

JollyRogers 10-15-02 10:37 PM

Check it out :) I followed the directions you gave and agpgart.o does recognize my chip now!

#/sbin/insmod agpgart

Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: Detected Via Apollo Pro P4X400 chipset
agpgart: AGP aperture is 64M @ 0xe0000000

And in fact if i load NVdriver and XF86Config has the option "NvAgp" "2" then 4Xagp is loading. BUT IT CRASHES RIGHT AWAY. I even got it to load 4X, by starting X then switching to another console and killing it. Then starting it again with "NvAgp" "0". I check cat /proc/drivers/nvidia/agp/status showed AGPGART 4X. Then I ran glxgears and locked. :)

Gotta use "NvAgp" "0" when starting X or it lockups.

So this definitely answers it. The KT400/P4X400 (which both are 4X/8Xagp or AGP2.0/3.0 capable) will not work with generic VIA agp.

So now I have to write a function that does work with it called via_P4X400_setup and then in:

"Apollo Pro P4X400",
via_P4X400_setup },

I have not found any "test" kernels that support the new chipsets from via. I have searched all changelogs from 2.4.18 to 2.5.42. All I found is were they split the code and cleaned it up. Also some additions for Intel chips. ARG :(

I sent an email to both nvidia and to VIA. No reply as of yet. I will lookover the code for via_generic_setup and see what it is doing. I bet it has to do with continuous memory or something, because I noticed different mem blocks from the "resource" tab under the NorthBridge in windows. Also, read in one of the change logs that they addressed continuos mem (not the use of).

I sure would love NVIDIA or VIA to help out.

BTW, thanks for the help. It was fun editing those files and recompiling my kernel to at least see it say P4X400 :)


bwkaz 10-16-02 06:53 AM

Yeah, it looks like another _setup function is in order. Make sure you keep any attributes the original via_generic_setup function has (you can just copy the definition and change the name).

But it is kind of hard to do this if you don't know tech specs. Hope you have some luck finding things out.

Edit: and if you get a function to work, I think linux-kernel would probably be interested (assuming someone else doesn't beat you to it). You should probably send off a patch against whatever the latest 2.5 kernel is, though. Maybe sending another one (against 2.4.20-prewhatever) to Marcelo to get into 2.4 would be good, too.

JollyRogers 10-16-02 07:49 PM


I switched in my geforce3 ti200 into my SOYO P4X400 MB.

nvidia: loading NVIDIA Linux x86 NVdriver Kernel Module 1.0-3123 Tue Aug 27 15:56:48 PDT 2002
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: Detected Via Apollo Pro P4X400 chipset
agpgart: AGP aperture is 64M @ 0xd0000000
NVRM: AGPGART: VIA Apollo KT133 chipset
NVRM: AGPGART: aperture: 64M @ 0xd0000000
NVRM: AGPGART: aperture mapped from 0xd0000000 to 0xe1ab5000
NVRM: AGPGART: mode 4x
NVRM: AGPGART: allocated 16 pages

From my prior dmesg with the GF4 in I can see: NVRM:AGPGART: aperture: 64M @ 0xe0000000

I don't know, but the memory allocation was different, Course it is a different card but same Northbridge.

[user@redbox agp]$ cat /proc/driver/nvidia/agp/status
Status: Enabled
AGP Rate: 4x
Fast Writes: Disabled
SBA: Disabled

[user@redbox agp]$ glxgears
16194 frames in 5.0 seconds = 3238.800 FPS
18146 frames in 5.0 seconds = 3629.200 FPS
18111 frames in 5.0 seconds = 3622.200 FPS

I thought these were unified drivers????
MY GEFORCE4 ti4200 does not work with via's P4X400 chipset, but my Geforce3 ti200 does???

Now I know the Geforce4 is ok. It worked great with my ABIT KG7-Raid MB, which also has a VIA chipset on it. The difference? My GF4 has to us the agpgart AGP module on the P4X400 chipset MB, but it was using NvAGP on the Via 133 (abit KG7-raid MB).

So GF4 on the P4X400 series mb (SOYO P4X400 Dragon ultra) = BAD (why I am uncertain, because my GF3 is forced to use agpgart on this MB also).

GF3 on on the SOYO = Good. still using agpgart.

GF4 on KT133 (abit kg7-raid) using NvAgp) = good.

I wonder if using agpgart w/ the GF4 on the KT133 chipset will result in lockups. Bet it does. Will know real soon.

Also to note. I mentioned I had been using windows :( (this is being done from RH8 btw :) )...

Well I decide to try some things. EVERY TIME I STARTED AN OPENGL SCREEN SAVER IT LOCKED UP WINDOWS ALSO!!!!!!!!!!!!!!!!!!!!!!!!!!

DEFINITE PROBLEM. w/ GF4 and the P4X400 chipset!!!

I am bald now after a week, but am releived. :)

Nvidia. You gotta do something about this!!!! Please!!!!! This same info is going to VIA tech. as I have been asking them for help also.

JollyRogers 10-16-02 08:10 PM

Damn. You wont believe this. I put the GF4 into my old computer. It does the same thing. It is bad.

:( time for an RAR.


bwkaz 10-16-02 09:07 PM

Hmm. Well, I guess that's always one possibility with things like that... Don't feel bad though; when I first got this GF4 (from FTI Computers), one of the capacitors was rolling around inside the anti-static bag. It appeared to have broken off either during shipment or while it was being stored at FTI's warehouses.

So I RMA'd it with FTI (as a DOA, finally, after talking to like 8 different people over 4 different phone calls), and got another one. The problem was, this second one also had a capacitor missing -- or at least, there were a couple of holes in the PCB with solder in them, and a screen-printed "a capacitor goes here"-type image over them. So I can only guess that another capacitor was there originally.

Of course, I don't know this for sure, because when I got the second card, the anti-static bag was open when I got it. :rolleyes: And no parts were rolling around free in the packaging.

Luckily, the card worked anyway (my guess is because these were just power rail coupling capacitors to dampen electrical noise, and there isn't enough noise on whichever power rail this one is connected to to make any difference), otherwise I would have had to call and tear FTI a new one. And I do never plan on buying from them again, or recommending them to anyone. I would have considered taking the whole thing up with MSI (actually, the first person at FTI claimed that I should do this very thing... :rolleyes: ), except they specifically do not do RMAs for end users. Only resellers.

Anyway, yeah, basically, some vendors really suck. And sometimes you just get a bad card...

JollyRogers 10-17-02 11:15 PM

New card is in... all is good :)

BTW Via tech actually responded as was very willing to help out. Glad to see they care....

All times are GMT -5. The time now is 02:45 PM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2015, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.