Date: Sun, 25 Mar 2007 14:50:27 -0500 From: Kevin Day <toasty@dragondata.com> To: Scott Long <scottl@samsco.org> Cc: freebsd-current@freebsd.org Subject: Re: aac & PAE not happy in -current Message-ID: <AC102898-3A43-4A82-B287-0770CD18E40A@dragondata.com> In-Reply-To: <4606A3B2.9050005@samsco.org> References: <52299CBE-F3AD-439D-820D-3FC3458614F8@dragondata.com> <4600C451.2020407@samsco.org> <1A67BF14-031C-4771-B4CD-82A46BBDA739@dragondata.com> <4606A3B2.9050005@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 25, 2007, at 11:30 AM, Scott Long wrote: > Kevin Day wrote: >> 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. Okay, I tried: 400 - no difference 500 - Gets further into the boot, but runs out when it tries to exec init(?) 550 - aac0 complains "Not enough contiguous memory available", then the next PCI device that tries to run can't alloc anything 600 - back to what was happening at 400, aac0 can't alloc enough kernel virtual memory Any other suggestions? -- Kevin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC102898-3A43-4A82-B287-0770CD18E40A>