Nvidia drivers and 2.6.x kernel

Hi Everyone

I'm not sure if this has been done to death or not, but i can not get the 4496 and 5328 versions of the NVidia kernel to work on the 2.6.1 version of (you guessed it) Linux.

I've googled about but not really found any great stuff. I did find this:

http://www.kerneltrap.org/node/view/1804
and from there the link to http://minion.de

I've tried it with both versions of the driver, with both versions of the drivers Makefile (Makefile.nvidia and Makefile.kbuild).

With the installer and with just make install (make kernel_module_install). The message i get is that the module is the wrong format.
The files that i can get to appear in:
/lib/modules/2.6.1/kernel/drivers/video are nvidia.ko & nvidia.o Originally i thought they were the same file, but they have different sizes (afterall)

chakkerz@stormcrow:/lib/modules/2.6.1/kernel/drivers/video$ ls -l
total 4648
-rw-rw-r--    1 root     root      2376880 Jan 21 12:14 nvidia.ko
-rw-rw-r--    1 root     root      2376702 Jan 21 12:15 nvidia.o

so: i've tried unpatched, patched, old and new drivers, installer and make, make in the installers root, and it's sub director usr/src/nv ... oh yes, and different versions of the patch.

could someone please tell me where to find out how to make this work, because linux without GUI is little use to me.

In case it matters:
This is an AMD Athlon XP 2800+ on a Gigabyte GA-7N400 Pro2 MoBo (nforce2). The FFX is an Abit Siluro GeForce 4 Ti4200 OTES. 2 sticks of 256 Corsair DDR in dual channel. The kernel compiles i tried were with AGPGART integrated (and the nforce/nforce2 also integrated) as well as AGPGART as a module. Most of the stuff i tried with AGPGART as a module.

with kind regards,
  Christian Unger

"You don't need eyes to see, you need vision" (Faithless - Reverence)

  Mobile:            0402 268904
  Internet:          http://naiv.sourceforge.net
  NAIV Status:
     Stable       Testing       Development
      0.2.3r2      0.3.0         0.3.1 - File Handling

"May there be mercy on man and machine for their sins" (Animatrix)

Well ... i've applied the patch and downloaded the pre-patched drivers, sacrificed a virgin, installed the module loading stuff (just in case) and still no joy.

So i think the fault is not with NVidia. or the patch. Maybe it's a flaw in Slackware 9.1, or i'm just too thick.

I did get X to work with nv, but since i have a dodgy old monitor i can't get the vertical alignment right (there probably is a way to do it -- SAX in SuSE does the trick).

with kind regards,
  Christian Unger

"You don't need eyes to see, you need vision" (Faithless - Reverence)

  Mobile:            0402 268904
  Internet:          http://naiv.sourceforge.net
  NAIV Status:
     Stable       Testing       Development
      0.2.3r2      0.3.0         0.3.1 - File Handling

"May there be mercy on man and machine for their sins" (Animatrix)

How strange. I run slack 9.1 and 2.6.1, just grabbed the 4496 pre-patched file from http://www.sh.nu/download/nvidia/ and installed it as I would on 2.4. Works a charm.

Hmm ... that does worry me a little then ... as there then is absolutely NO reason for it not to work.

Maybe the virgin was not pure enough ... :)

Would you be able to possibly mail me a copy of your kernel configuration file. In case i mucked something in it up .... i can't imagine what ... but still if you could forward me a copy of the file, i'll try that.

with kind regards,
  Christian Unger

"You don't need eyes to see, you need vision" (Faithless - Reverence)

  Mobile:            0402 268904
  Internet:          http://naiv.sourceforge.net
  NAIV Status:
     Stable       Testing       Development
      0.2.3r2      0.3.0         0.3.1 - File Handling

"May there be mercy on man and machine for their sins" (Animatrix)

Kieran (et al)

Ok i tried the configuration you sent, and after working out that you have a different motherboard chipset which caused the kernel to hang here whenever i did anything that involved the hard disk (copy the drivers from my backup partition to my work partition for instance - to ensure that i was using "good copies") i even had signs of success.

Mere signs though. I continue being told it's an invalid format:
FATAL: Error inserting nvidia (/lib/modules/2.6.1/kernel/drivers/video/ nvidia.ko): Invalid module format

So ... i'm out of ideas ... i don't get why it ain't doing for me what it is doing for everyone else. I am wondering IF something screwed up when i upgraded Slackware 9.1 from 9.0 ... and in the interest of testing that theory might do a rm -f / later and start from scratch. I haven't decided if 2.6 is worth that much yet though.

with kind regards,
  Christian Unger

"You don't need eyes to see, you need vision" (Faithless - Reverence)

  Mobile:            0402 268904
  Internet:          http://naiv.sourceforge.net
  NAIV Status:
     Stable       Testing       Development
      0.2.3r2      0.3.0         0.3.1 - File Handling

"May there be mercy on man and machine for their sins" (Animatrix)

nVidia has released drivers supporting kernel 2.6 on their website.

They run nicely for me.

Hmmm... why do people say "they" when talking about a "driver"?

shannon "AT" widomaker.com -- ["An Irishman is never drunk as long as he
can hold onto one blade of grass and not fall off the face of the earth."]

Followup note: Running the new nVidia drivers, I see a huge drop in the size of the X server.

My normal X server virgual memory size was around 260MB. If I played a game like Infiltration, it would rise to 300MB. After exiting the game, the virtual size stayed where it was. It never shrunk, and it ate a lot of swap space too.

Then I upgraded to the new nVidia drivers which support the 2.6 kernel, and things have changed.

I noticed my system was swapping a lot less, but didn't have time to look into it.

Today I did.

My X server now hovers around 76MB, virtual size. Loading Infiltration causes it to grow to around 98MB. When I exit the game, it drops back down to 76MB virtual.

It also seems to release memory after a program like The Gimp has been running, though I've done less testing with that. I've observed a 110MB->78MB drop when exiting The Gimp, but didn't record the event.

Wow... I started out on 8-bit micros, and talking about "drops" of 32MB amazes me sometimes.

Questions:

Is the new driver able to hide the graphics aperature, showing a more true statistic on memory use?

Was the 2.6 kernel always capable of showing the right thing, and the new driver being made for 2.6 is just working better?

Why does the virtual memory size shrink now? Could the new driver be unmapping vitual memory to free it up?

I'm going to ask nVidia, but wanted to post here and also see if anyone else noticed this.

shannon "AT" widomaker.com -- ["Star Wars Moral Number 17: Teddy bears are
dangerous in herds."]

How's the performance?

I have found the 4496 and 5328 drivers lowered my performance.

5328 is supposed to be faster mip-mapping and faster when running with vertical blank sync, but I didn't see it myself. It also caused quite a few sound artifacts from my Live! sound card.

Anyone done a driver-by-driver benchmark?

I got tired of it, but here's the performance order on my system from fastest to slowest:

4620
3xxx (last stable 3xxx driver)
4496
5328

Mostly what I look for are not benchmark numbers, but notable hesitation in programs and interactive response, and side effects like bad sound artifacts.

UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com

Are there any known issues with pci_alloc_consistent() allocating more than 1MB?
One of our developers seems to recall a thread but we can't find it...

We are using pci_alloc_consistent() in our 10GbE driver, to allocate memory for DMA transfers between
host and device.
If we allocate under 1MB, everything works fine. When the allocation is more than 1 MB, allocation call does not return any failure but some data corruption seems to take place beyond the 1 MB space.

Is this a known problem? The system is 2-way Itanium, running 2.4.21 kernel.

Thanks in advance, Leonid

http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Leonid> Are there any known issues with pci_alloc_consistent() Leonid> allocating more than 1MB? One of our developers seems to Leonid> recall a thread but we can't find it...

[snip]

Leonid> Is this a known problem? The system is 2-way Itanium, running Leonid> 2.4.21 kernel.

Leonid,

What type of Itanium box? It's possible what you're seeing is caused by a bug in the IOMMU code, but we would need to know which one (HP, SGI or someone else's).

Cheers,
Jes

Hi Jes,

The problem with pci_alloc_consistent()above 1MB happens on HP rx2600 (this is 2U dual-Itanium 900MHz pci-x 133 box). I don't believe it happens on 64 bit Opterons. Today we are going to test Dell and SGI Itanium systems, as well as a bit newer rx 2600 with Itanium-2 1.5GHz - I'll let you know by the end of the day.

Thanks, Leonid

The iommu code on zx1 boxes is currently limited to consistent
mappings of 64 * PAGE_SIZE. We need to implement the consistent dma mask interface so that 64bit devices can bypass the iommu and dma as much as they'd like. If you change your system page size to 64k, you should be able to get up to 4MB mappings with the current code. Sounds like we need to do a BUG or something to make it more obvious how this is failing. It should be a pretty simple update to sba_iommu to make it start looking at consistent_dma_mask in this path. I'll try to get a patch sent out for it on 2.6. Thanks,

Alex

I have no problem myself.

I use the driver *.run files that have been patched to work with 2.6 kernels.

I don't have to build a thing, I just install them like I would under kernel 2.4.

If you look at the minion website, there is a mirror in the download list, and that mirror has install packages modified for 2.6.

It's completely automatic.

Maybe you should try that.

It will fail when it goes to the nvidia website to find precompiled glue code, and then proceed to build the glue locally.

UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com