Mailinglist Archive: opensuse (3637 mails)

< Previous Next >
Re: [SLE] NVIDIA drivers (again!) and unresolved symbols
  • From: Mark Hounschell <dmarkh@xxxxxxxxxx>
  • Date: Wed, 30 May 2001 08:14:27 -0400
  • Message-id: <3B14E423.B9884856@xxxxxxxxxx>
Paul Abrahams wrote:
>
> 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
>

How did you build your kernel. You know that in the top makefile /boot
is commented
out such that the make bzlilo or make zlilo command will put your new
kernel in / and
not /boot.
Just fishing for a cause. Also the agp stuff in your kernel is in char
devices right
below the ftape entry (if you are doing make xconfig). It's easily
missed. It looks like _mmx_memcpy has somthing to do with pentium/mmx
setting in .config file. Maybe try changing cpu type in your kernel.
I have basically duplicated your problem simply by building a kernel
after changing my cpu type to pentium mmx instead of athlon and then
trying do load the NVdriver without rebuilding it. I get the same
message
about mmx_memcpy. It still points to, your not running the kernel you
think
you are. Did you do zlilo or bzlilo???

Mark

--
Mark Hounschell
dmarkh@xxxxxxxxxx

< Previous Next >
Follow Ups