Well, I am not amused about that -- I am as we speak, running through xconfig prior to building 2.6.33, and I am leaving my preempt the way it is (CONFIG_PREEMPT) until I see it fail because I want to experience this firsthand.

FWIW, a couple years ago, when I came up with a few workarounds for the Intel 536EP modem driver on various kernel versions, that driver at some stage in its life, and with certain new kernel release, also would not work with the PREEMPT kernel options set to "low latency" and it gave "invalid module format" too; but it DID work with the other available preempt option(s). A few kernel versions later, that problem was rectified.

I am currently (have been for a long time) using the "low-latency" model, so we'll see.. Maybe I'm a sucker for punishment. Must try for myself though.

Off Topic slightly -- I see that the "Anticipatory" I/O scheduler has 'disappeared' from the new kernel; only Deadline and CFQ remain. Hmmm..

I worked on this late last night, so I might have not been thinking straight when I first posted my problem. lol Anyway, it appears that my problem was solved by making that change. I am interested though in what kind of results you get.

I think problems can arise *maybe* if nvidia modules are built with multilib gcc when the kernel has been built probably with the stock gcc from current: that could be the reason of the "invalid module format" message.

I rebuild usually my custom kernel with zen patches and I have done the same this time (with a "make oldconfig" based on slackware stock /proc/config.gz) and the nvidia module inserted fine in the kernel.
maybe also rebuilding the stock kernel with the same config but with alien's gcc can solve, have to try.

on huge 2.6.33 shipped with slackware I had that message too at first after upgrading everything on my multilib install.

btw, I have CONFIG_PREEMPT=y (and CONFIG_HZ_2000=y )

I'm not using a multilib enviroment though.

It works fine with Preemptive enabled. The huge kernel had to be rebuilt to work. Made no changes, just copied the config over, rebuilt, installed, edit lilo, reboot. Should be using the generic kernel, or building your own anyways

Attached Thumbnails

 

Not sure about everything in this thread but this worked for me

NVIDIA-Linux-x86_64-190.53-pkg2.run --apply-patch nvidia-190.53-2.6.33.patch.txt

This produces NVIDIA-Linux-x86_64-190.53-pkg2-custom.run

which installs and works fine for me
the patch is attached I think

john

2 members found this post helpful.

If you do not need 3D acceleration, better use the "nouveau" driver, it works very well. You'll find it under "staging drivers" in the kernel tree.

Didn't work for me. I am getting an Invalid module format message samac

i can confirm, cp /boot/config-huge-2.6.33 /usr/src/linux-2.6.33/.config && cd /usr/src/linux-2.6.33 && make && make modules_install && cp arch/x86_64/boot/bzImage /boot/vmlinuz && lilo && echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf && telinit 6 will allow the patched 190.53 nvidia drivers to work

patched as per AlleyTrotters post above.

this is with multilib enabled on slackware64-current

1 members found this post helpful.

I upgraded to -current last night also and I am unable to build my nvidia driver with ./NVIDIA**.sh.

I am on 32bit current with no multilib.

The error I get is that the kernel source version is not properly identified/configured or something to that effect.

I haven't tried any of the suggestions mentioned above yet -- but typically there are no issues compiling my NVIDIA driver after a -current update.

I've been running 2.6.33-rc5 for a month now and both 190.53 and the beta drivers will build with the patch. There is also a workaround (nothing more than creating a symlink) needed for the Vbox kernel module on the 2.6.33 kernel unless that has been recently addressed on the Vbox side.

Try adding blacklist nouveau to /etc/modprobe.d/blacklist.conf. Reboot and try it again.

It's been running with 190.53 as well as the 195.30 beta drivers for a month. It may be different in the final release, but I doubt it. The .config started as a slack generic 2.6.32.x and then had a lot of stuff removed and filesystem support added, plus customization for processor.

I read somewhere that the NVIDIA unix/linux driver team were having some issues getting the betas stablilized, which was preventing the betas from getting released in a timely fashion. This might be the reason that 2.6.33 support wasn't immediately available in the stable driver since it may have been intended to be replaced prior to the 2.6.33 release.

Oh, do share on that one. I'm having that issue now with vbox.

Create this symlink to build the virtualbox kernel module for 2.6.33 since the 2.6.33 kernel no longer has autoconf.h

1 members found this post helpful.