Re: aac & PAE not happy in -current

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: <AAC RAID Channel> port 0xcc00-0xccff mem 
>>> 0xfccff000-0xfccfffff irq 30 at device 6.0 on pci5
>>> aacch1: <AAC RAID Channel> port 0xc800-0xc8ff mem 
>>> 0xfccfe000-0xfccfefff irq 31 at device 6.1 on pci5
>>> aac0: <Dell PERC 3/Di> 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