2.4.18 + 2.4.20 bigmem iounmap bug

2.4.18 + 2.4.20 bigmem iounmap bug

Post by Rob Murph » Thu, 20 Feb 2003 23:40:11



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;

Quote:}

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

Quote:}

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

  messages
1K Download
 
 
 

1. Patching redhat 8.0 kernel 2.4.18 to 2.4.20

I have redhat 8.0 with kernel 2.4.18 running. I want to apply patch
for kernel 2.4.20 so that i have a pure vanilla kernel. I could not
find a linux directory in /usr/src/ so i wonder if the source code for
linux directory has been shifted to some other place in red hat 8.0

Can anybody please tell me how to apply patch in this case.

Thanks
Raj

2. installation hang

3. Kernel "mem=" parameter - 2.4.18 vs. 2.4.20

4. Is dosemu 0.63.XX require yacc to compile?

5. OOPS with kernels 2.4.18 2.4.19 2.4.20

6. loadable kernel module load--NOT!

7. Q: WLAN support in RH 2.4.18-24 vs. Stock 2.4.20 kernel ?

8. Help in fixing a bug in solaris 1.1.1

9. Alot of DMA errors in 2.4.18, 2.4.20 and 2.5.52

10. What has changed in the graphics part between 2.4.18 and 2.4.20

11. Ooops in 2.4.18 through 2.4.20, now kswapd is defunct

12. Hyperthreading on 2.4.18 and 2.4.20 (Redhat)

13. 2.2.24-rc2/2.4.18/2.4.20 UMSDOS hardlink OOPS