PIII patches and bproc

[Erik Arjan Hendriks]

On Tue, Jan 16, 2001 at 12:17:53PM -0500, Rob Latham wrote:
> First off, i know the answer is going to be "well, don't apply the PII
> patches".  Yeah, that works, but i'm looking to have both.  sue me :>
> 
> anyway, what i've done is patched a 2.2.18 kernel with bproc and with
> the PIII patches ( from http://people.redhat.com/dledford/PIII.html ).
> The PIII patch rearanges some headers, and moves some stuff (like
> the unlazy_fpu() macro ) into asm-i386/i387.h.  
> 
> So i added #include <asm/i387.h> to vmadump.c, rebuilt, and when the
> vmadump.o module is loaded, it can't find the symbol kern_fpu_lock:
> 
> root@mcbain2 bproc-2.0.2]# insmod vmadump/vmadump.o 
> vmadump/vmadump.o: unresolved symbol kern_fpu_lock 
> 
> root@mcbain2 bproc-2.0.2]# grep kern_fpu_lock /boot/System.map-2.2.18 
> 80247e24 D kern_fpu_lock
> 
> kern_fpu_lock is declared (after the patch) in
> arch/i386/kernel/setup.c with
> 	spinlock_t kern_fpu_lock = SPIN_LOCK_UNLOCKED;
> 
> and the asm/i387.h header declares
> 	extern spinlock_t kern_fpu_lock;

For modules to find symbols, they need to be explicitly exported by
the kernel.  The system.map file contains all the symbols, including
the ones which aren't exported.  You'll want to grep /proc/ksyms to
see if the symbol you're looking for is there.  If not, you'll have to
add an export statement some where.  Probably with a line like
"EXPORT_SYMBOL(kern_fpu_lock);" in arch/i386/i386_ksyms.c.

If it is there but looks something like kern_fpu_lock_R123b1c, then
you need to kick the modversions stuff in the kernel and get it
generate new modversions.  "make clean ; make dep" might do it.  If
not, then start with a clean (never built) tree and try again.

Good luck,
- Erik

-- 
Erik Arjan Hendriks          Printed On 100 Percent Recycled Electrons
erik@hendriks.cx                   Contents may settle during shipment