[ENBD] 2.4.21 dual athlon 1GB ram enbd problem

Peter T. Breuer enbd@lists.community.tummy.com
Wed, 6 Aug 2003 07:09:49 +0200 (MET DST)


"Keith Lewis wrote:"
> 	The client is giving me trouble.
> 
> 	The client is a dual Athlon mp2200+ box with a GA-7DPXDW+ motherboard,
> and 1GB of expensive RAM.  (cheap RAM doesn't work in this board...)
> 
> 	I'm trying to get enbd to run under linux 2.4.21

I haven't tried kernel 2.4.21 yet.

> 	I fetched nbd-2.4.31.tgz from ftp://oboe.it.uc3m.es/pub/Programs
> (on the 5th Aug GMT+10)
> 
> 	changed SMP to 1 in the Makefile.
> 
> 	Changed LINUXDIR to /usr/src/linux-2.4.21, which is where the
> currently running kernel was built

> 
> 	did a Make
> 
> 	then as root this:
> 
> # insmod /tmp/enbd.o
> /tmp/enbd.o: unresolved symbol kunmap_high
> /tmp/enbd.o: unresolved symbol highmem_start_page
> /tmp/enbd.o: unresolved symbol kmap_high

Well, those ought to be in the kernel, or something like them.
kunmap_high is introduced in asm/highmem.h (in my 2.4.20-xfs).
Now, I do not call kunmap_high in my code, but I do call kunmap.

So I would guess that kunmap is being translated to kunmap_high
when highmem is turned on in the kernel compilation. highmem.h defines
it this way ...


static inline void kunmap(struct page *page)
{
        if (in_interrupt())
                out_of_line_bug();
        if (page < highmem_start_page)
                return;
        kunmap_high(page);
}


and that defn is always active. kunmap_high is defined in mm/highmem.c:


void kunmap_high(struct page *page)
{
        unsigned long vaddr;
        unsigned long nr;
        ...

and it's not static. So I believe the linker should have satisfied
itself that it is available at link time.


I don't know what the 2.4.21 code does, but could you investigate? It
looks as though there is some mixup.




> # CONFIG_NOHIGHMEM is not set
> CONFIG_HIGHMEM4G=y
> # CONFIG_HIGHMEM64G is not set
> CONFIG_HIGHMEM=y
> CONFIG_HIGHIO=y


I suspect the answer may also lie in the above.


Peter