From owner-freebsd-current@FreeBSD.ORG Thu Sep 30 08:32:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D2BE16A4CE for ; Thu, 30 Sep 2004 08:32:00 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 484E543D41 for ; Thu, 30 Sep 2004 08:32:00 +0000 (GMT) (envelope-from scottl@FreeBSD.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8U8Whh9071567; Thu, 30 Sep 2004 02:32:43 -0600 (MDT) (envelope-from scottl@FreeBSD.org) Message-ID: <415BB667.9000302@FreeBSD.org> Date: Thu, 30 Sep 2004 01:31:51 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claus Guttesen References: <20040930071732.46940.qmail@web14122.mail.yahoo.com> In-Reply-To: <20040930071732.46940.qmail@web14122.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: "Dag-Erling \"SmXrgrav\"" cc: freebsd-current@FreeBSD.org cc: Lawrence Farr Subject: Re: unable to install beta6 [amd64] on Dell 2850 with 4 GB RAM,workaround X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2004 08:32:00 -0000 Claus Guttesen wrote: >>You need to increase VM_KMEM_SIZE_MAX in your kernel >>config, e.g. >>options VM_KMEM_SIZE_MAX=536870912 > > > Did that, but it panicked, hand-transcribed screen: > > vm_fault on nofault entry, addr : ffffffffb091d000 > KDB stack backtrace > panic() at 0xffffffff8020bf17 = panic+0x2a7 > vm_fault() at 0xffffffff802f57b0 = vm_fault+0x1ce0 > trap_pfault() at 0xffffffff80330350 = > trap_pfault+0x2a0 > alltraps_with_regs_pushed() at 0xffffffff8031c3fb = > alltraps_with_regs_pushed+0x5 > amr_mapcmd() at 0xffffffff80184f34 = amr_mapcmd+0x114 > amr_start() at 0xffffffff801850e0 = amr_start+0x170 > amr_startio() at 0xffffffff801857ce = amr_startio+0x3e > amr_submit_bio() at 0xffffffff80185bb0 = > amr_submit_bio+0x20 > g_disk_start() at 0xffffffff801ed02a = > g_disk_start+0xea > g_io_schedule_down() at 0xffffffff801cf4ca = > g_io_schedule_down+0xea > g_down_procbody() at 0xffffffff801cfa28 = > g_down_procbody+0x28 > fork_exit() at 0xffffffff801f17af = fork_exit+0x8f > fork_trampoline() at 0xffffffff8031c5fe = > fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffffffba13cd00, rbp = 0 > > Claus > The AMR driver cannot handle >4GB of RAM. Even though you only have 4GB, your chipset is remapping part of it to the >4GB region. The driver incorrectly interfaces with busdma and cannot handle this scenario very well. The panic is to be expected. You can verify this by setting the tunable 'hw.physmem' in the loader to some value under 4GB to artifically limit the amount of RAM that the OS sees. Scott