[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