On Sun, Oct 15, 2000 at 09:33:38AM -0700, Kenward Vaughan wrote:
> I assume that the problem involves its compilation from the package. I've
> always dl'd the .deb, unzipped it where it lay in /usr/src, and run the
> script to make the package. This is followed by its installation.
That's right. You ought to be able to untar it anywhere, actually,
unless you're using kernel-package to build it, in which case it
*needs* to be in /usr/src/modules/device3dfx
> Is this wrong?? Should it be unzipped somewhere inside of /usr/src/linux
> and compiled With the kernel? Does a line for it show up when one uses "make
> menuconfig?" I don't recall ever seeing errors on compilation.
No, it doesn't integrate with the kernel like that. (Unfortunately).
> Another thought is whether I should change something in the Makefile
> which would make it compatible with my Athlon??? (obviously assuming
> something there would screw that up...)
Well, not afaik, but mismatching your processor shouldn't cause the
link errors you're seeing anyway. (One would hope that the 3dfx source
code would use your CONFIG_MK7 setting if necessary, anyway).
> hpotter:/home/daddy# insmod 3dfx
> Using /lib/modules/2.2.17/misc/3dfx.o
> /lib/modules/2.2.17/misc/3dfx.o: unresolved symbol remap_page_range
> /lib/modules/2.2.17/misc/3dfx.o: unresolved symbol unregister_chrdev
> /lib/modules/2.2.17/misc/3dfx.o: unresolved symbol register_chrdev
> /lib/modules/2.2.17/misc/3dfx.o: unresolved symbol printk
> hpotter:/home/daddy#
The main point to check is that you are actually compiling the module
against the headers used to build your kernel. Particularly, that
you're using the right <linux/autoconf.h> file, and hence getting the
right setting of CONFIG_MODVERSIONS...
So, from the device3dfx directory (where you run debian/buildpkg),
check like this (output is from my machine):
bash$ nm 3dfx.o | grep printk
U printk_R1b7d4074
bash$ grep printk /proc/ksyms
c0115f4c printk_R1b7d4074
Now, your address and version hash will likely be different BUT the
vital point is that the version hash (_R1b7d4074) must match in the
3dfx.o file and /proc/ksyms. If they don't match, this suggests you
compiled against the wrong kernel headers. Check your KSRC setting,
and check you did "make clean" and that a compile is really
happening. (You should see this sort of command:
gcc -O2 -m486 -fomit-frame-pointer -DMODULE -D__KERNEL__ -I/home/steve/kernel/linux/include -pipe -fno-strength-reduce -malign-loops=2 -malign-jumps=2 -malign-functions=2 -c -o 3dfx.o 3dfx_driver.c
during compilation. Note the -I flag pointing at the kernel headers.)
NB I am not really a kernel hacker, but I'm fairly sure this is a
suitable check to run.
HTH
SRH
--
Steve Haslam http://www.arise.demon.co.uk/ steve@arise.demon.co.uk
Debian GNU/Linux Maintainer araqnid@debian.org
almost called it today, turned to face the void, numb with the suffering
and the question- "Why am I?" [queensrÿche]
Attachment:
pgp_O6AsgYbby.pgp
Description: PGP signature