Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Mar 2015 11:43:49 +0000
From:      Steven Hartland <killing@multiplay.co.uk>
To:        Michael Fuckner <michael@fuckner.net>, Ryan Stone <rysto32@gmail.com>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: Server with 3TB Crashing at boot
Message-ID:  <55041EF5.9080200@multiplay.co.uk>
In-Reply-To: <5503DC66.40409@fuckner.net>
References:  <550046F7.1050205@fuckner.net> <CAJ-VmokruCyo3M5up9n%2BAfvkr7VFBtUftpdgc=52ES%2BNt6=JZA@mail.gmail.com> <CAPQ4ffsd-SpsLTbGL8BdBsNHLx9HhVQ4Wh%2B95M98fCmT5idPAg@mail.gmail.com> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <CAJ-Vmom%2BZy_6ZCcTA_h4LFL-wDdaCmbqAgN5shpOsBBgWJw1mg@mail.gmail.com> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <CAFMmRNzmr0Z1vXYK5y2QLk3eyUqXyK8TELgh4KHZ%2BDQVDXWZAg@mail.gmail.com> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <CAFMmRNya8ZV=D3z0dE1%2BDsprAVBvcHZFGN1g1Ezd8k84nE3kVA@mail.gmail.com> <5503DC66.40409@fuckner.net>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------090702070101020508050506
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit



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@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@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

--------------090702070101020508050506
Content-Type: text/x-patch;
 name="mpr.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="mpr.patch"

--- sys/dev/mpr/mpr.c.orig	2015-03-14 11:32:43.256662663 +0000
+++ sys/dev/mpr/mpr.c	2015-03-14 11:33:23.682658734 +0000
@@ -1125,7 +1125,7 @@ mpr_alloc_queues(struct mpr_softc *sc)
         }
         if (bus_dmamem_alloc(sc->queues_dmat, (void **)&queues, BUS_DMA_NOWAIT,
 	    &sc->queues_map)) {
-		device_printf(sc->mpr_dev, "Cannot allocate queues memory\n");
+		device_printf(sc->mpr_dev, "Cannot allocate queues size %d memory\n", qsize);
 		return (ENOMEM);
         }
         bzero(queues, qsize);

--------------090702070101020508050506--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55041EF5.9080200>