3:45 p.m.
----- "Kevin Worth" <kevin.worth(a)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
3:59 p.m.
New subject: "cannot access vmalloc'd module memory" when loading kdump'ed vmcore in crash
Thanks for the explanation, Dave.
I tried adding some printf's to memory.c (before the goto try_dev_kmem, then before
and after the call to read_dev_kmem). It does in fact look like it's taking the
read_dev_kmem path... a couple examples (a ton of these are printed, so if there is any
specific address to look for let me know, but I presume this is just confirming what you
suspected.
-Kevin
...
About to goto try_dev_kmem. paddr is 3aa10000
going to read_dev_kmem with addr f8841000 bufptr 84346c0 cnt 4096
readcnt from read_dev_kmem is 4096
About to goto try_dev_kmem. paddr is 3aa07000
going to read_dev_kmem with addr f8842000 bufptr 84356c0 cnt 1796
readcnt from read_dev_kmem is 1796
...
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf
Of Dave Anderson
Sent: Friday, October 10, 2008 1:46 PM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] "cannot access vmalloc'd module memory" when
loading kdump'ed vmcore in crash
----- "Kevin Worth" <kevin.worth(a)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
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
5891
days inactive
5891
days old
devel@lists.crash-utility.osci.io
1 comments
2 participants
participants (2)
-
Dave Anderson -
Worth, Kevin