On Thu, Apr 17, 2008 at 03:38:00PM +0200, Kevin D. Kissell wrote: >> That will be incorrect for systems with highmem. So I think the right >> fix is to replace all references to max_pfn in vpe.c with max_low_pfn. >> > Which will still be incorrect for systems with highmem, right? The reason > I propose fixing max_pfn instead of just hacking vpe.c is that, as per my > email of a couple of weeks ago, there are other, architecture independent, > bits of code in the 2.6.24 kernel where max_pfn is assumed to be sane, > and the value of zero may result in otherwise inexplicable Bad Things > happening. So even if you want to change vpe.c to use max_low_pfn > instead of max_pfn, I believe that we really want that patch to setup.c > until such time as we've verified that the kernel is max_pfn-free. Hmm.. yes. But your 0002-Propagate-max_low_pfn-as-max_pfn-fo patch uses max_low_pfn after it has already been cut down to exclude highmem. Moving the assignment a few lines up just before the if statement should fix the issue. Ralf
