From owner-freebsd-stable@FreeBSD.ORG Fri Sep 21 22:11:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17505106566B; Fri, 21 Sep 2012 22:11:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id CBE9B8FC12; Fri, 21 Sep 2012 22:11:19 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id q8LMBIE9017518; Fri, 21 Sep 2012 18:11:19 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <505CE601.4070106@sentex.net> Date: Fri, 21 Sep 2012 18:11:13 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jim Harris References: <505CC8EC.4030608@sentex.net> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: FreeBSD-STABLE Mailing List , delphij@freebsd.org Subject: Re: tws bug ? (LSI SAS 9750) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 22:11:20 -0000 On 9/21/2012 4:59 PM, Jim Harris wrote: >> boot. Anyone know whats up ? Is this something that should be sent >> directly to LSI ? > > Through a code inspection, this mutex is being recursed whether or not > debugging is enabled. There is no code path here specific to > INVARIANTS. And the main IO path in this driver is always recursing > on this lock - it is not specific to the initialization callstack you > listed below. > > The best course of action seems to be initializing the lock with > MTX_RECURSE, since the driver seems to expect to be able to recurse on > the io_lock. Can you try the following patch? > > diff --git a/sys/dev/tws/tws.c b/sys/dev/tws/tws.c > index b1615db..d156d40 100644 > --- a/sys/dev/tws/tws.c > +++ b/sys/dev/tws/tws.c > @@ -197,7 +197,7 @@ tws_attach(device_t dev) > mtx_init( &sc->q_lock, "tws_q_lock", NULL, MTX_DEF); > mtx_init( &sc->sim_lock, "tws_sim_lock", NULL, MTX_DEF); > mtx_init( &sc->gen_lock, "tws_gen_lock", NULL, MTX_DEF); > - mtx_init( &sc->io_lock, "tws_io_lock", NULL, MTX_DEF); > + mtx_init( &sc->io_lock, "tws_io_lock", NULL, MTX_DEF | MTX_RECURSE); > > if ( tws_init_trace_q(sc) == FAILURE ) > printf("trace init failure\n"); Thanks, that allows it to boot up now! pci2: on pcib2 LSI 3ware device driver for SAS/SATA storage controllers, version: 10.80.00.003 tws0: port 0x4000-0x40ff mem 0xc2460000-0xc2463fff,0xc2400000-0xc243ffff irq 17 at device 0.0 on pci2 tws0: Using MSI tws0: Controller details: Model 9750-4i, 8 Phys, Firmware FH9X 5.12.00.007, BIOS BE9X 5.11.00.006 em0: port 0x5040-0x505f mem 0xc2500000-0xc251ffff,0xc2570000-0xc2570fff irq 19 at device 25.0 on pci0 . then a lot of . (probe65:tws0:0:65:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe65:tws0:0:65:0): CAM status: Invalid Target ID (probe65:tws0:0:65:0): Error 22, Unretryable error (probe1:tws0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe1:tws0:0:1:0): CAM status: Invalid Target ID (probe1:tws0:0:1:0): Error 22, Unretryable error (probe2:tws0:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe2:tws0:0:2:0): CAM status: Invalid Target ID . . . (probe63:tws0:0:63:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe63:tws0:0:63:0): CAM status: Invalid Target ID (probe63:tws0:0:63:0): Error 22, Unretryable error (probe64:tws0:0:64:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe64:tws0:0:64:0): CAM status: Invalid Target ID (probe64:tws0:0:64:0): Error 22, Unretryable error da0 at tws0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 6000.000MB/s transfers da0: 953654MB (1953083392 512 byte sectors: 255H 63S/T 121573C) SMP: AP CPU #1 Launched! SMP: AP CPU #4 Launched! >> >> >> >> Also, any reason NOT to set hw.tws.enable_msi=1 in /boot/loader.conf ? Any thoughts on msi vs no msi ? Time to run some stress tests. Its certainly a fast little controller for the money! ---Mike