Mailinglist Archive: opensuse (3637 mails)

< Previous Next >
Re: [SLE] NVIDIA drivers (again!) and unresolved symbols
  • From: Paul Abrahams <abrahams@xxxxxxx>
  • Date: Tue, 29 May 2001 17:26:33 -0400
  • Message-id: <3B141409.8D9677C5@xxxxxxx>
Mark Hounschell wrote:

> Paul Abrahams wrote:
> >
> > For about the fourth time I've tried to generate and install
> > the NVIDIA drivers (newest version, 1251). And each time
> > things get worse. The main problem I have is with the
> > kernel module. When I attempt to install it I get a
> > notification of an unresolved symbol _mmx_memcpy. Until
> > the most recent iteration I could still get the server to
> > run, albeit defectively. But now it won't run at all -- I
> > get the message "failed to initialize the NVdriver kernel
> > module". Supposedly that's because I'm using the wrong
> > header files, but the generation scripts seem to indicate
> > that the correct kernel include files are being summoned.
> >
> > I've tried doing the install using both the rpm's and the
> > tar files, with essentially the same result either way.
> > I've also tried specifying the include files explicitly with
> > the SYSINCLUDE parameter. The only difference I've found
> > between using the rpms and the tarfiles is that the rpms put
> > the NVdriver module in
> > /lib/modules/2.4.4/kernel/drivers/video while the tarfiles
> > put it in /lib/modules/2.4.4/kernel/video, one level higher
> > in the tree.
>
> First off these locations for the module are a BAD THING. Nothing
> but native kernel modules should go into these locations. They
> should be reserved for that only because as of 2.4 kernel the
> kernel build process "make modules_install" removes anything
> in them. So first off remove all instances of NVdriver in
> all locations in /lib/modules/2.4.4/. Use the find command.

That use of misc would solve another problem: losing the ALSA sound modules
after a kernel module remake.

> Also rmmod any instance of the driver that may be already loaded.
> Then modify the Makefile from the tarball. (always use the tarball)
>
> Change this:
>
> ifeq ($(shell if test -d $(KERNDIR)/kernel; then echo yes; fi),yes)
> INSTALLDIR=$(KERNDIR)/kernel/video
> else
> INSTALLDIR=$(KERNDIR)/video
> endif
>
> to:
> ifeq ($(shell if test -d $(KERNDIR)/misc; then echo yes; fi),yes)
> INSTALLDIR=$(KERNDIR)/misc/video
> else
> INSTALLDIR=$(KERNDIR)/video
> endif
>
> Note: KERNDIR is set by the following line:
> KERNDIR=/lib/modules/$(shell uname -r)
>
> This will save you headaches if you ever get it to work and need to
> recompile
> your kernel. Next make sure /usr/src/linux is a link to
> /usr/src/linux-2.4.4
> and that you are indeed running the kernel that came from
> /usr/src/linux.

"uname -r" says 2.4.4, and it is indeed a vanilla kernel that I compiled
myself.

> I have 4 boxes with TNT2
> chipset
> running 2.4.4 kernel(vanilla). I havn't tried the 2.4.4 sources from
> Mantels directory so I can't vouch for it. I don't know exactly where
> the _mmx_memcopy thing is comming from but I have seen it also.

That's reassuring. I've tried recursive greps in a number of places,
including the source directory, and have found nothing as to where the
_mmx_memcopy thing originates. I think it's being brought in indirectly.

> And it
> seems that the makefile isn't
> finding the correct things it needs from your kernel source tree.

I can believe that, but I can't explain it. /usr/src/linux is definitely
symlinked to /usr/src/linux-2.4.4. Your experience in also encountering
the _mmx_memcopy problem suggests that the problem is not just a failure to
refer to the correct kernel version.


> Be
> sure not
> to turn on any agp settings in your kernel if they don't match your
> chipset.

I couldn't find any agp-related settings through "make xconfig" in
/usr/src/linux.


> If unsure, leave them all off. Also if you have an AMD irongate chipset
> make
> sure to turn OFF framebuffer support. So once you are sure you have your
> kernel
> built and running and every thing above has been done then do your make
> install
> from the nvidia directory and see what happens. Hope it helps and let
> us know.

Alas, moving the driver from /lib/modules/2.4.4/kernel/video to
/lib/modules/2.4.4/video made no difference whatsoever in the behavior,
either in terms of the messages during the build or the failure afterwards.

At least I have things set up so that I can run experiments. In my
/etc/X11 directory I have two files, XF86Config.000 and XF86Config.001.
The 000 file calls the nv driver; the 001 file calls the NVidia driver. I
just copy one or the other to XF86Config. So when the NVidia drivers
fail, as they now do consistently, I revert to the nv drivers and can get
back on the air to send messages such as this one.

Paul



< Previous Next >
Follow Ups