nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   5328 + Athlon -> OOPS (http://www.nvnews.net/vbulletin/showthread.php?t=22643)

gdh 12-23-03 06:27 AM

5328 + Athlon -> OOPS
 
Based on all the threads I've read sofar, the issues people have with the new 5328 driver:
-> real slow performance (4 -5 fps on gears)
-> kernel oops
(which causes the slow performance)

are only appearing on athlon based boards.
from what limited testing i could do (half a dozen machines, of which 1 athlon, together a dozen linux flavors) only the athon has issues, it works fine (albeit maybe a bit slower) on all other boxes.

Has anyone managed to get this working on an athlon board ?

Anyone from NVidia able to confirm that they see the problem on athlon boards as well ?

zander 12-23-03 06:45 AM

You can use the 1.0-5328 Linux 2.6 patch/installer from http://www.minion.de/nvidia.html, it works around this problem. Yes, it does work with Linux 2.4 (up to and including 2.4.23).

Papol 12-23-03 06:54 AM

There are working really well for me on an abit nf7 (athlon xp but with nforce2 chipset). Has someone run their 'oops' through ksymoops here? If so, can you post it? Don't worry. I don't belong to that 'WFM' club that thinks it must be your fault just because it happens to work well for me. It sounds like there's a pretty bad problem and I'm the oddball for not having it.

As fas as speed goes, it's only important if you're saying you're one of those who're getting something crazy like 4fps on glxgears. Otherwise most of this crap is margin of error amounts.

I've got an older board I'll try them on too, (a kt7a which is an old via board). Maybe that one will fail and I can try getting some debugging info.

Also: Anyone with problems, can you please list the contents of 2 directories (if you have them):

"ls -al /usr/lib/tls"
"ls -al /usr/X11R6/lib/tls"

Also list any 2d symptoms if you get that far, as well as any /var/log/XF*.log errors you see. No need to write a novel here, but anything might help, so try to diff out some errors instead of listing entire logs.

And also, 90% or so of those pci badness messages are from a kernel bug in conjunction with an nvidia bug, which is produced because of the frequency of interrupt and lenght of time to service it. The ISR sometimes loses track of the device id and manu id, but this can be patched (I came up with a patch for it), but it's not a big deal of an error and the interrupt winds up serviced on the next pass anyway. The worst thing about this one is that it winds up doing too much i/o to the /var/system/log file. There's another pci badness error that is much worse and will kill performance but I'm still trying to figure that one out.


Thanks.

zander 12-23-03 06:59 AM

The misconception here is that the problem is specific to Athlon processors/chipsets, which doesn't seem to be the case. Rather, the problem appears to be specific to some Via chipsets.

Papol 12-23-03 06:59 AM

Quote:

Originally posted by zander
You can use the 1.0-5328 Linux 2.6 patch/installer from http://www.minion.de/nvidia.html, it works around this problem. Yes, it does work with Linux 2.4 (up to and including 2.4.23).
Zander, the minion site is great. Thanks. I've noticed only one thing that could cause some of the problems people are having. If for some reason, you unpack your drivers, then decide not to user nvidia-installer or repack into a new *nv.run file, but rather use a 'make' from usr/src/nv, then the GLX drivers remain at the last version. I looked over the makefile and don't see why this is, but at first I found in /usr/lib/tls the GL drivers of the previous version.

However: If you recreate an *nv.run package and run it, it first creates the /usr/lib/tls GL drivers and all seems well.

Thanks.

btw: I'm on fc1 (like 2 beta from development) , have a basic 4200 nv card. 2.6.0 kernel and am up to gcc 3.3.2-3, glibc-2.3.3x for what it's worth.

zander 12-23-03 07:04 AM

The Badness in pci_find_subsys at drivers/pci/search.c warning messages are harmless by themselves (they wouldn't be if the card was hot-pluggable), but typically indicate data corruption of some kind. If you see these messages in your log files, and your system seems to be stuttering at times (i.e. stopping for a few seconds), it may make sense to check the AGP configuration (i.e. disable AGP FW/SBA, throttle the speed) and/or go through the list of other common sources of stability problems (disable ACPI, frame buffer devices, UP I/O APIC support, ...).

zander 12-23-03 07:07 AM

Quote:

Originally posted by Papol
Zander, the minion site is great. Thanks. I've noticed only one thing that could cause some of the problems people are having. If for some reason, you unpack your drivers, then decide not to user nvidia-installer or repack into a new *nv.run file, but rather use a 'make' from usr/src/nv, then the GLX drivers remain at the last version. I looked over the makefile and don't see why this is, but at first I found in /usr/lib/tls the GL drivers of the previous version.

However: If you recreate an *nv.run package and run it, it first creates the /usr/lib/tls GL drivers and all seems well.

This is expected behavior, the Makefile in usr/src/nv installs the kernel module, only. The top-level Makefile may be used to install the user-space driver components, but its use is highly discouraged. Instead, use a Linux 2.6 compatible variant of the .run installer, which will install/update all driver components as necessary. Prebuilt packages are now available as well.

Papol 12-23-03 07:31 AM

I meant that making your own 2.6 installer package and repackaging it, running it at least once in order to get the GL components made is needed. After that, running make works fine until something major changes in your setup.

zander 12-23-03 08:17 AM

Sure, if you don't use the installer to copy the new files in place or don't do so manually, the Makefile in usr/src/nv won't magically fix that. ;) This is documented, though.

gdh 12-23-03 08:24 AM

Quote:

Originally posted by zander
The misconception here is that the problem is specific to Athlon processors/chipsets, which doesn't seem to be the case. Rather, the problem appears to be specific to some Via chipsets.
OK, in that case,
The athlon has a
Apollo KT266/A/333 AGP
chipset.

bwkaz 12-23-03 08:39 AM

Quote:

Originally posted by zander
You can use the 1.0-5328 Linux 2.6 patch/installer from http://www.minion.de/nvidia.html, it works around this problem. Yes, it does work with Linux 2.4 (up to and including 2.4.23).
But it doesn't, at least not for me. ;)

I'm getting the same (or a very similar) OOPS on 2.6.0. Unless you updated the patch after about ... 3 PM EST yesterday?

ringerc 12-23-03 08:59 AM

ksymoops output
 
1 Attachment(s)
[edit]: The problem described here is the same as that others have been seeing, and was fixed by using the patches from minion.de . A few tweaks were required to get the patches to work on FC1 with a stock FC kernel - please see my later post on the matter. The post title begins with FC1[/edit]

I'm attaching the output of ksymoops, as taken from the `dmesg` snippet containing the oops. I hope this will be useful in getting this fixed.

On the upside, these drivers enable me to switch to the text console (VGACON, not VESA or rivafb) - with the last couple of releases the console has been totally nonfunctional or "invisible" (input accepted but no display). They're also the first non-beta drivers that've worked on my system (FC1, GF4Ti4200, 1.5GHz Athlon 1800+, Via KT266, 768MB RAM)

Note: I'm also seeing messages like this from the kernel:

0: NVRM: couldn't find pre-allocated memory!
0: NVRM: couldn't find pre-allocated memory!

whenever I run an OpenGL application (glxgears, for example).

Please note that I'm using the standard FC1 kernel (2.4.22-1.2129.nptl). ksymoops seems to have issues finding some loaded modules, which is odd, but produces a trace anyway. Hopefully it'll be useful. I can be reached at "craig <at> postnewspapers [dot] com **au**" if needs be.

I've also attached a full dmesg.


All times are GMT -5. The time now is 03:34 AM.

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