SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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..
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 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.
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 )
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.
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
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
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.
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.
Code:
Linux i7 2.6.33-rc5 #1 SMP PREEMPT Wed Jan 27 22:47:34 CST 2010 x86_64 Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz GenuineIntel GNU/Linux
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.
Quote:
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 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.
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.
Oh, do share on that one. I'm having that issue now with vbox.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.