[Crash-utility] "cannot access vmalloc'd module memory" when loading kdump'ed vmcore in crash

Dave Anderson anderson at redhat.com
Fri Oct 10 20:45:52 UTC 2008


----- "Kevin Worth" <kevin.worth at hp.com> wrote:

> Dave,
> 
> I do indeed have a /dev/kmem on my live system. One other thing... is
> the physical limit of 0xb8000000 imposed because of the amount of
> memory on my system or because it is the maximum addressable memory
> without using PAE? My kernel does have PAE enabled (CONFIG_HIGHMEM_32G
> or whatever the option is), though not sure if that makes a
> difference, just checking. Things work just fine on an identical
> system that has 2GB of memory instead of 4GB. :\

The physical limit is imposed by how much physical memory
can be unity-mapped by the architecture's virtual address
space, or more simply put how many bits of kernel virtual
address space are available, coupled with how you split
your virtual memory between user space and kernel space.  

On 32-bit systems with kernel virtual space starting at
c0000000, there is only 1GB of virtual memory between
c0000000 and ffffffff+1.  Also the system needs to
reserve some of that 1GB (128MB to be exact) for vmalloc
space.  So that leaves 896MB of directly-mappable 
(unity-mapped) kernel virtual space, so "high_memory"
is set to (c0000000 + 896MB) or f8000000.

On your system, kernel virtual memory starts at 40000000,
so there's 3GB of kernel virtual space.  It still needs
the 128MB of vmalloc space, so your high_memory limit
is still f8000000, but there's a much larger directly-mappable
range between 40000000 and f8000000.
 
It has nothing to do with PAE.  And the reason things work
"fine" on your 2GB system is because /dev/mem can always
access 2GB because its unity-mapped equivalent is less
than high_memory.  It's only going to be a problem when
your system has more than 3GB of physical memory.  (3GB-128MB)
to be exact...

Dave




More information about the Crash-utility mailing list