Re: Warning: Latest Kernel Sources on Sid

On Mon, 2006-05-08 at 18:22 +0300, David Baron wrote:
On Monday 08 May 2006 18:11, Greg Folkert wrote:
On Mon, 2006-05-08 at 17:36 +0300, David Baron wrote:
On Monday 08 May 2006 17:10, Greg Folkert wrote:
On Mon, 2006-05-08 at 16:04 +0300, David Baron wrote:
On Sunday 07 May 2006 23:17, H.S. wrote:
David Baron wrote:
You may get the following on modules previously compiled against
kernel sources:

Kqemu and Nvidia's driver were hit by this. Easy enough to
fix--recompile 'em.

I noticed this too. I am using nvidia module. I just did (after
booting in the new kernel version):
#> m-a auto-install nvidia

and it seemed to have done the trick.

The Nvidia driver I downloaded from Nvidia comes with its own .run
file which does more than simply check and recompile the driver (too
much actually for a repeat compile!). Would m-a "know" to run this?

Other modules need to be made with various arguments pointing to
kernel source directory, etc.

m-a == Debian's Module Assistant.

Yes, it will get the stuff proper for the driver.

Now the library links are taken care of by the nvidia-glx and
nvidia-glx-dev packages.

Neither module effected was from a Debian package, however.
Kqemu is "non-free" and made from source.
The nvidia videa driver was downloaded from their site and as I said, it
has its own installation program. (What is the difference between what is
on Debian and theirs?)

The Debian nVidia is a much easier and more updateable version. And you
get an integrated package for Debian for the drivers. ATIs stuff is
there too. Plus TONS of other modules, like wifi, crypto etc... ta boot..

ATI stuff was why I went over to the Geforce.

I was just commenting that IF they can get ATIs crap to work properly
using m-a... you might consider using it.

I used to run a script I developed myself, to do everything exactly like
M-A does. When I explained what my script did... well an m-a maintainer
mentioned that Debian does it with many modules.

How long does it take for you to run your installer and get the proper
kernel compiled and/or then the proper headers for the nVidia module to
compile against, how many steps are there?

Their installer is simple: run it with root privileges.
1. Checks for precompiled version on their ftp.
2. None? Compiles it
3. Places it in ..../drivers/video
4. Will modify xorg.conf to use this driver. Saves old file just in case
5. Voile.

The point is though:

This was the nVidia Modules and packages, are maintained and
kept track of by debconf. You don't have to re-run you installer
*JUST* to get the libc links back (should libc get updated) and
any real problems, are typically caught before the go into
incoming.

I remember last year or, nVidia updated the drivers and the installer
literally removed half of you libraries on your system. That was caught
by the nVidia package(s) maintainer(s) and never ruined any machine
except maybe the chroot environment.

Are you putting the module where it should go, according to Debian's
policy? If not, then you will always have cruft building up. Plus you'll
no longer have to worry if the installer puts the links in the proper
directories for the video libraries... and the recent changes to X.org
have also been included in compilation of the nVidia Module.
(hint: apt-get install module-assistant)

I have it.

Using module-assistant (m-a is a shortname for module-assistant) for the
*CURRENT* Kernel you are running doing:

m-a update ; m-a a-i nvidia

Does the update, install of everything needed and compiles and installs
the resulting deb package file.

Of course, the nvidia-glx and the nvidia-glx-dev will need to be
installed too.

Are all these kept more up-to-date and better running than the manufacturer's
module? I have heard recommendations for both sides of this.

All I can tell you, since I deprecated my script and switched to m-a, my
life has been much easier. Upgrades on nVidia versions are trival. Now
there is something else you should know, there is a Legacy version of
the nvidia source and glx packages... these are for GF2 and before
cards... that was a rude awakening (which was also when I started my own
script)

kqemu, isn't a kernel module... I am sorry I mislead you in any way on
that.

kqemu IS a kernel module, .ko. Needs be compiled against kernel source and
installed in .../drivers/misc.

Are we talking the same package? http://kqemu.sourceforge.net/

Which runs QEmu inside of it?

http://packages.debian.org/unstable/misc/qemu

And it does NOT need to be compiled against the Kernel SOURCE.

The "kernel-headers-2.6-<arch>" or "smp" added is all the you need. Same
goes for the nVidia drivers. They only need the Kernel Headers. No need
to compile your own kernel. There is really no reason to compile your
own kernel. Not even to compile *IN* modules for you exact hardware.

I stopped doing new kernels all the time when the 2.6 tree popped up in
Debian. Everything I was patching into the 2.4 kernel (using make-kpkg)
was already in the 2.6 tree.

The kernel is equivalently fast in mono or module modes. (I can
guarantee you'll *NEVER* be able to tell if it is faster or not) I have
been using Debian for quite a few years, in fact I am using an "8 year
old build" right now on an Athlon64 3500+, I just keep transferring the
image around and around and around. You could never do that with a
hard-compiled kernel.

Debian is all about EASE of maintenance, not making it hard to keep
things updated. It is why I keep coming back to Debian (and UBUNTU for
my friends and cow-orkers), its all about maint.
--
greg, greg@xxxxxxxxxxxxxxx

The technology that is
Stronger, Better, Faster: Linux

Use Debian GNU/Linux, its a bazaar thing

NOTICE: Due to Presidential Executive Orders, the
National Security Agency may have read this email
without warning, warrant, or notice, and certainly
without probable cause. They may do this without
any judicial or legislative oversight. You have no
recourse nor protection.

Attachment: signature.asc
Description: This is a digitally signed message part

Relevant Pages

  • Re: Warning: Latest Kernel Sources on Sid
    ... Kqemu and Nvidia's driver were hit by this. ... I am using nvidia module. ... booting in the new kernel version): ... Their installer is simple: ...
    (Debian-User)
  • Re: F7 nvidia-96xx driver problem and [rant]
    ... I too use the NVIDIA driver. ... Now, if you can duplicate the problem using the nv driver, which we as a group, do have the src code for, then someone might be able to help you. ... So as long as you and I use that driver, there is absolutely zero chance that a kernel bug report filed by either of us will get more attention than cleared with a notabug, kernel is tainted note in bugzilla. ... You might also take your problem to nvidia, where legit bugs are usually fixed and new drivers issued in just a few days. ...
    (Fedora)
  • Re: Fedora 7 - RPM Build Nvidia 9755 [revisited]
    ... Livna NVIDIA driver RPMs doesn't mean that the same problem exists ... to have to do it everytime I boot a different kernel, ... echo install of nvidia.ko driver failed ...
    (Fedora)
  • Re: Fedora Core 6 HUGE problem - Binary drivers.
    ... in installing the driver that Nvidia makes freely available. ... The party-line argument that third party drivers cause support problems kind of falls on its face when the included driver doesn't work at all... ... the inability or refusal of the kernel developers to define a driver interface. ... In fedora the users lose. ...
    (Fedora)
  • nvidia whats wrong?
    ... Nvidia display driver kernel module ... Re-added the mysteriously vanished sleep line in the init script ...
    (Fedora)