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@xxxxxxxxxx [mailto:crash-utility-bounces@xxxxxxxxxx] 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: "cannot access vmalloc'd module memory" when loading kdump'ed vmcore in crash ----- "Kevin Worth" <kevin.worth@xxxxxx> 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
