From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 14 13:23:30 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E26D498D for ; Sat, 14 Mar 2015 13:23:30 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BF3CFE for ; Sat, 14 Mar 2015 13:23:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426339385; l=3301; s=domk; d=fuckner.net; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:From:Date; bh=+Ol8Yu1HYdwAc//Bj3YOMzlgxsYz4sxAokSDkz1XlNU=; b=ZPQ3UuBsVZozdmBC3vP/pgT/ADQDJtHBIZ4J+a5EkURzw7Z+r0RJAoC97WWVx6h0bNg Vmzzi4pTSaY4JN337SSAZRFsbSNF1FSyMNfBQOgjMlQhyazjb84VuDsuD9jAt5b6UBC+j jhY3RYwAlkF3ak2MykTkN5KK6KgOSPpBALs= X-RZG-AUTH: :IWUHfUGtd9+6EujMWHx57N4dWae4bmTL/JIGbzkGUoozgknstV9BEzWRmW1UTIElHLUn9j9pNI6Yw3ftahX9+/V6TY7Maqcasg== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:2028:737:9301:59e9:4863:b903:5e51] (some-ipv6-address.wtnet.de [IPv6:2a02:2028:737:9301:59e9:4863:b903:5e51]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPSA id R02cb4r2EDMqC8R (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate); Sat, 14 Mar 2015 14:22:52 +0100 (CET) Message-ID: <5504362C.9000904@fuckner.net> Date: Sat, 14 Mar 2015 14:22:52 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Steven Hartland , Ryan Stone Subject: Re: Server with 3TB Crashing at boot References: <550046F7.1050205@fuckner.net> <550093DD.5040603@freebsd.org> <55015D3B.6030605@fuckner.net> <5501DD57.7030305@freebsd.org> <5503234A.4060103@fuckner.net> <55032C1B.5030004@multiplay.co.uk> <275339388.395931.1426279324879.JavaMail.open-xchange@ptangptang.store> <5503DC66.40409@fuckner.net> <55041EF5.9080200@multiplay.co.uk> In-Reply-To: <55041EF5.9080200@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 13:23:31 -0000 On 3/14/2015 12:43 PM, Steven Hartland wrote: > > > 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 >>> 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: 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 >> >> 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 did your patch for queue size and sense size. I just saw: http://dedi3.fuckner.net/~molli123/temp/mpr2.cap (just the second half of the boot, but nothing changed but the two debug echos) root@s4l:~ # dmesg |grep mpr mpr0: port 0x2000-0x20ff mem 0xaba00000-0xaba0ffff irq 42 at device 0.0 on pci4 mpr0: IOCFacts : mpr0: Firmware: 07.00.01.00, Driver: 05.255.05.00-fbsd mpr0: IOCCapabilities: 7a85c mpr0: attempting to allocate 1 MSI-X vectors (96 supported) mpr0: using IRQ 300 for MSI-X mpr1: 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 mpr1: Cannot allocate sense size 258048 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 (probe0:mpr0:0:0:0): Down reving Protocol Version from 4 to 0? da0 at mpr0 bus 0 scbus0 target 0 lun 0 pass0 at mpr0 bus 0 scbus0 target 0 lun 0 In Bios I have VT-d enabled. In the VT-d Menu there are two other options: ATS (Non-Iscoh VT-D Engine ATS Support), default: enabled Coherency Support(Non Iscoh VT_D Engine Coherency Support), default: Disabled In the Processor Configuration tab there also was extended apic support (default is disabled) Should I give this option a try? Regards, Michael!