>Date: Thu, 17 Oct 2002 21:05:51 -0600
>From: Josh Cogliati <jjc@rupert.honors.montana.edu>
>
>On Fri, Oct 18, 2002 at 02:05:11PM +1300, Andreas K?h?ri wrote:
>> Good day,
>> 
>> I'm having the exact same problem as Josh Cogliati had
>> in September [1] but with a 64Mb machine (166MHz Digital
>> Celebris FX-2).  The problem boils down to a kernel panic
>> in some UVM code (causing a immediate reboot).  Copy from
>> Josh's post:
>> 
>> Warning: Can't allocate memory segment 0x100000/0xf00000/0x1 from IOMEM Extent map.
>> Panic: uvm_page_physload: start >= end
>For those of you who are curious, I installed netbsd 1.4.2, and then 
>installed the 1.6 kernel, and it booted with that fine.  Any idea what
>could fail with the boot disks, but not with the kernel?  (I did not 
>install anything on the 1.4.2 system, except the new kernel.)

I submitted a PR for this (with a patch that fixes it) well over a
year ago.  So far this patch has been ignored, even though three
different developers with commit access have said they would take care
of it.  I'm starting to think I must have leprosy or something.

It would be really nice if someone with commit privileges could have a
look at it, and get this committed.

        http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=13399

The patch was a little bit out of date last time I checked.  If
someone is really going to take care of this, let me know and I will
generate a new patch if necessary.

I believe that you aren't experiencing the problem right now because
the boot loader from 1.4.2 doesn't pass the extent maps to the kernel.
So the kernel uses different memory detection code which doesn't blow
up.  The real answer is to simply fix the bugs that cause it to blow
up in the first place.

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.