Messages in this thread | | | From | "Rob Murphy" <> | Subject | 2.4.18 + 2.4.20 bigmem iounmap bug | Date | Wed, 19 Feb 2003 16:32:59 -0500 |
| |
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] | |