lkml.org 
[lkml]   [2003]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject2.4.18 + 2.4.20 bigmem iounmap bug
Date
Hello all.

I have been having problems using ioremap and iounmap on systems with more
than 1Gb of memory.
My current machine has an athlon processor and 1.5Gb of memory.

I created a driver with the following code:

#define MAXHM 0x1000000 // 16 Mb
int init_module(void)
{
void *kHighMem;

printk(KERN_ERR"before ioremap\n");
kHighMem = ioremap(__pa(high_memory), MAXHM);
printk(KERN_ERR"ioremap ret: %x\n",kHighMem);
iounmap(kHighMem);
printk(KERN_ERR"iounmap passed\n");

return 0;
}

void cleanup_module(void) {
printk(KERN_ERR,"module successfully unloaded.\n");
}

I have compiled the code into a module named "test.o" and have added the
append="mem=1280" to lilo for both kernels.
Under 2.4.18:
If I run "insmod test.o" , I get a Segmentation fault (see attached messages
file).

Under 2.4.20:
I can run "insmod test.o" and "rmmod test" without a problem. But then it
seems if I run any program that accesses memory (a simple user mode program
that malloc's multiple buffers for example) I get a Kernel Panic and the
computer locks up. The panic I get is:
Unable to handle kernel NULL pointer dereference at virtual address 00000004
printing eip:
c012ca6e
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c012ca6e>] Not tainted
EFLAGS: 00010092
eax: ebx: ecx: edx: esi: edi: ebp: esp: ds: es: ss: ...
Process init (pid: 521, stackpage=f6ed1000)
Stack: ...
Call Trace: ...
Code: 89 50 04 89 02 c7 43 04 00 00 00 00 c7 03 00 00 00 00 d1 6c

I have not yet to tried to trace into the 2.4.20 lockup.

If append="mem=768" or less the problem doesn't happen, but ioremap is
unable to map the entire amount of remaining memory above the kernel and a
boundary is reached of kernel memory + ioremaped memory <= 1Gb (i.e. if
append="mem=384" ioremap can only map up to 640mb).

From what I can guess, it looks like ioremap may be corrupting the page
tables when the highmem functionality is being used. I noticed that my
PAGE_OFFSET is still at 0xc0000000 which according to <include/page.h> means
that I will always have only 950MB of virtual address space. I would have
thought that setting CONFIG_HIGHMEM4G=y would have changed the PAGE_OFFSET
value.
Has anyone experienced similar problems? Does anyone know a different way
of allocating large contiguous amounts of DMA capable memory other than
using ioremap or vmalloc?

Any help would be appreciated.
Robert Murphy


[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.033 / U:1.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site