From owner-freebsd-current@FreeBSD.ORG Sun Mar 25 16:30:57 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37B9516A402 for ; Sun, 25 Mar 2007 16:30:57 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id DC36713C44B for ; Sun, 25 Mar 2007 16:30:56 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l2PGUmb1012170; Sun, 25 Mar 2007 10:30:53 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4606A3B2.9050005@samsco.org> Date: Sun, 25 Mar 2007 10:30:42 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Kevin Day References: <52299CBE-F3AD-439D-820D-3FC3458614F8@dragondata.com> <4600C451.2020407@samsco.org> <1A67BF14-031C-4771-B4CD-82A46BBDA739@dragondata.com> In-Reply-To: <1A67BF14-031C-4771-B4CD-82A46BBDA739@dragondata.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sun, 25 Mar 2007 09:30:53 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: aac & PAE not happy in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 25 Mar 2007 16:30:57 -0000 Kevin Day wrote: > > On Mar 21, 2007, at 12:36 AM, Scott Long wrote: >>> Booting the same kernel without PAE I get the same thing: >>> aacch0: port 0xcc00-0xccff mem >>> 0xfccff000-0xfccfffff irq 30 at device 6.0 on pci5 >>> aacch1: port 0xc800-0xc8ff mem >>> 0xfccfe000-0xfccfefff irq 31 at device 6.1 on pci5 >>> aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 >>> on pci4 >>> aac0: [FAST] >>> aac0: Adaptec Raid Controller 2.0.0-1 >>> and it works fine. >>> Is this a known problem, or is there any other info I can give? Happy >>> to try anything anyone might suggest. :) >> >> The device is asking for 128MB of register space. This is exhausting >> the limit on the amount of kernel mapped memory, hence the panic. The >> difference between PAE and non-PAE is likely that the non-PAE case >> isn't consuming as much kernel address space for the extra page tables, >> so you're squeaking by. >> >> The 128MB of register space is wrong, but it's something that the aac >> firmware is causing. I don't have a 2650, but my 2450 only tries to >> claim 4K for registers for the aac device, and the hardware is basically >> identical to the 2650. Maybe try flashing in a newer (or older) >> firmware? Knowing what firmware version you have would help. > > Okay, after spending the better part of the weekend trying to figure out > how to PXE boot the floppies that Dell gives you (using their own > version of DOS), I've upgraded to the very latest system BIOS, > controller firmware and kernel, and it's still requesting 128MB of > memory. Nothing seems to have changed really. > > Any other suggestions? Booting into Linux seems to show that it's also > eating 128MB of memory space there, so it's nothing FreeBSD is doing to > cause this. > > Does your controller have the 128MB dimm for caching? I still can't see > why they'd expose that to the host, but it's my only theory at the moment. > Sorry for the confusion, it turns out that my math was wrong and my machine is mapping all of the DIMM space as well, though it's not 128MB. Exposing the full DIMM size to the host is really just an act of laziness on the part of the firmware engineers; it's convenient for debugging the firmware and doing other development tasks, but it's not useful for anything else. So, we're left with figuring out workarounds. I'm not sure if the driver can force less of the space to be mapped, I'll look into that. The other workaround is to change VM_KMEM_SIZE_MAX in /sys/i386/include/vmparam.h to a larger value, but probably no more than around 500. Scott