Server with 3TB Crashing at boot

[Steven Hartland]

On 14/03/2015 06:59, Michael Fuckner wrote:
> On 3/13/2015 10:17 PM, Ryan Stone wrote:
>> On Fri, Mar 13, 2015 at 4:42 PM, Michael Fuckner <michael at fuckner.net>
>> wrote:
>>
>>>    Now I can kldload zfs without exploding kernel. I'll do some more 
>>> tests
>>> tomorrow, but this looks fine!
>>>
>>
>> Excellent news!  I'd be interested to know whether this fixes the panics
>> that you saw when zfs.ko was loaded by the bootloader.  It's definitely
>> possible, as the symptoms of this bug are likely to be random memory
>> corruption after zfs initializes, but your crash happened pretty 
>> early on
>> and I'm not sure whether zfs would have had a chance to do anything that
>> early.
>>
>> Thanks for all of the work that you did to debug this.
>
>
> Currently there is another issue that prevents me from testing ZFS: 
> only one HBA gets initialized.
>
> mpr0: 9300-8i with 8x Intel S3700
> mpr1: 9300-4i4e with 4x Intel S3700 and an external JBOD with 24HDD.
>
> mpr0 initializes fine, mpr1 fails
>
> root at s4l:~ # dmesg |grep mpr
> mpr1: <LSI SAS3008> port 0xf000-0xf0ff mem 0xfb100000-0xfb10ffff irq 
> 112 at device 0.0 on pci195
> mpr1: IOCFacts  :
> mpr1: Firmware: 07.00.01.00, Driver: 05.255.05.00-fbsd
> mpr1: IOCCapabilities: 
> 7a85c<ScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,EventReplay,MSIXIndex,HostDisc>
> mpr1: Cannot allocate queues memory
> mpr1: mpr_iocfacts_allocate failed to alloc queues with error 12
> mpr1: mpr_attach IOC Facts based allocation failed with error 12
> device_attach: mpr1 attach returned 12
>
> Any idea? Should I post to freebsd-scsi?
Thats failing in bus_dmamem_alloc so as a guess I'd say there's no space 
below the 4GB boundary for the allocation of size qsize.

The attached patch will print out the maxsize of the attempted 
allocation which may be interesting, although I wouldn't expect it to be 
anything strange as its pretty much device specific and not connected to 
total memory that I can see.

Given that I suspect something else in the earlier part of the boot 
process has allocated a large chunk of memory making available space 
below 4GB scarce.

A verbose boot up to this point may provide some indication as to this.

     Regards
     Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpr.patch
Type: text/x-patch
Size: 509 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20150314/694a1ccb/attachment.bin>