No AGP support for Quadro4 900 XGL on Dell 650?

[Jarrod]

We just bought a loaded Dell Precision 650 with a Quadro4 900 XGL. It is running kernel 2.4.20 (Debian).

Everything works (even stereo) except for AGP.

We see this:

1 kraken:/home/jsmith% dmesg | grep gart
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: Unsupported Intel chipset (device id: 2550), you might want to try agp_try_unsupported=1.
agpgart: no supported devices found.

and

2 kraken:/home/jsmith% dmesg | grep AGP
0: NVRM: AGPGART: unable to retrieve symbol table

and

5 kraken:/home/jsmith% cat /proc/driver/nvidia/agp/status
Status: Disabled

We've gone through the usual dance of trying all the NvAgp options - we even tried the agp_try_unsupported=1 kernel commandline suggested by the agpgart error message - it doesn't help.

The motherboard in this machine has an Intel E7505 chipset. So are we out of luck? It's very bad news if so - we bought this machine specifically to be a Linux graphics workstation...please help!

Thanks

Jarrod Smith

[Andy Mecham]

I responded to you in the other thread, but it's best to move it here.

I don't believe AGPGART supports the E7505 as of yet, but NVAGP should.

What's in /proc/driver/nvidia/agp/* with

Option   "NvAgp" "1"

in your XF86Config file?

--andy

[Jarrod]

Your verification that the E7505 should work with NVAGP encouraged us to try some addtional things. The problem was solved in the following way:

1. Recompiled the kernel without AGPGART support (it was previously compiled in monolithically - not as a module). I think this was the cause of the problem in the first place.

2. Set Option "NvAgp" "1" in XF86Config-4

We rebooted after this and it still didn't work. Then we decided to:

3. Reinstall the 4349 driver

I'm not certain why step 3 was required, but it was...

Anyhow, now it works and I am very happy - thanks.

[Andy Mecham]

1. Recompiled the kernel without AGPGART support (it was previously compiled in monolithically - not as a module). I think this was the cause of the problem in the first place.

Yep, that would make sense. If AGPGART is loaded (or compiled in), NVAGP won't work.

--andy

[jsolomon]

Hi,

I have a Dell Precision Workstation 450 with a Quadro 4 900 XGL and Redhat 8.0, and I have also seen the E7505 problem.

Initially, I saw the error messages in dmesg and just ignored it. My system did work and even claimed to use NVAGP.

But every few days my machine would freeze and without any other knowledge, I'm blaming the problem on AGP. So I added the following line to /etc/modules.conf:

options agpgart agp_try_unsupported=1

and the error messages in dmesg went away. I only made this change this morning, so I'm not sure how this change will effect stability.

I would have used the NVAGP right off of the bat except for two things.

First, the README.txt says nothing about the E7505 chipset being supported. (Although Andy says that NVAGP "should" support this chipset earlier in this thread.)

Second, while I think that AGPGART is a module, and not statically compiled in my kernel, I don't know how to prevent it from being loaded at boot-time.

Questions:

Is the E7505 officially supported by NVAGP?

If so, shouldn't the README.txt be updated?

How do I prevent AGPGART from being loaded at boot-time?

Once I prevent AGPGART from being loaded at boot-time, will the NvAGP option in the XF86Config file handle the loading of AGPGART (if I set NvAGP=2)? If not, what should I do?

If I just want to use NVAGP (and set NvAGP = 1), do I have to do anything to make sure the NVAGP module gets loaded?

In answering questions, if possible, please provide explicit instructions on which commands to run and/or files to edit.

Thanks,

Jeff

[Andy Mecham]

and the error messages in dmesg went away. I only made this change this morning, so I'm not sure how this change will effect stability.

I'd be interested in your results.

Is the E7505 officially supported by NVAGP?

Yes.

If so, shouldn't the README.txt be updated?

The README's list of supported chipsets is quite stale. It should get a full update sometime soon.

How do I prevent AGPGART from being loaded at boot-time?

AGPGART won't load until it's needed. If it's a module, you won't need to worry about it.

Once I prevent AGPGART from being loaded at boot-time, will the NvAGP option in the XF86Config file handle the loading of AGPGART (if I set NvAGP=2)?

Yes.

If I just want to use NVAGP (and set NvAGP = 1), do I have to do anything to make sure the NVAGP module gets loaded?

No.

--andy

[jsolomon]

Andy - thanks for the quick reply!

So by specifying NvAGP=1, I avoid the error messages from AGPGART (since AGPGART is never loaded) about the E7505 chipset (this is before I added the agp_try_unsupported), but I'm probably right back where I started - using NVAGP and possibly having system instability.

I'm using a 2.4.18smp kernel with a DFP which had prevented me from upgrading to 4349, so I'm using 4191.

Andy - do you have any recommendations? Specifically:

Are there differences between 4363 and 4191 that address AGP stability with NVAGP?

I assume in all cases you'd recommend 4363 over 4191?

If my machine locks up again, I'm not sure whether I should go back to AGPGART with agp_try_unsupported or whether I should upgrade to 4363 and try again with NVAGP.

Anyone have any thoughts?

Jeff

[Andy Mecham]

I'm using a 2.4.18smp kernel with a DFP which had prevented me from upgrading to 4349, so I'm using 4191.

This was fixed in 1.0-4363.

Are there differences between 4363 and 4191 that address AGP stability with NVAGP?

Yes, but I don't have any examples to give you.

I assume in all cases you'd recommend 4363 over 4191?

Yep.

If my machine locks up again, I'm not sure whether I should go back to AGPGART with agp_try_unsupported or whether I should upgrade to 4363 and try again with NVAGP.

I'd voice support for 1.0-4363.

--andy