On Fri, 9 Jun 2000 [EMAIL PROTECTED] wrote:
> Has anyone tried building the DAC960 driver as a module with the 2.2.16
> kernel? I've tried with 2.2.16 stock, and 2.2.16 + DAC960-2.2.6. Either
> way, when the initrd loads and tries to insmod DAC960.o, I get:
>
> unresolved symbol waitqueue_lock
>
> stock 2.2.14 and 2.2.15 build with DAC960 as a module and do not have this
> problem.
While looking into this, I've noticed another oddity I suspected was also
a bug in symbol versioning.
[from end of nm on DAC960.o in 2.2.15smp with modvers]
U vsprintf_Rsmp_13d9cea7
U wait_for_request_Rsmp_f8c36762
U waitqueue_lock_Rsmp_fcdc212d
[from end of nm on DAC960.o in 2.2.16smp with modvers]
U vsprintf_R13d9cea7
U wait_for_request_R37d32d70
U waitqueue_lock
This and some messages on the kernel list between Scott McDermott
<[EMAIL PROTECTED]> and Keith Owens <[EMAIL PROTECTED]> made it
apparent that the problem is not actually a kernel bug, but a kernel
building problem. When I first compiled from this tree, I was building
for a non-smp system. I've since done make menuconfig ; make dep ; make
clean, make bzImage modules several times switching back and forth between
SMP and non SMP. Apparently you can't do this as module versioning
doesn't get regenerated by these steps. I haven't read the README for
some time (thought I knew what I was doing :), but maybe something should
be added to it cautioning about what happens when you change the value of
CONFIG_SMP and rebuild the kernel and modules.
So, in short, it's not a bug in the kernel code, and not new to 2.2.16.
It's just coincidence that I first ran into it while upgrading to 2.2.16.
----------------------------------------------------------------------
Jon Lewis *[EMAIL PROTECTED]*| I route
System Administrator | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
