Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Sep 2012 18:11:13 -0400
From:      Mike Tancsa <mike@sentex.net>
To:        Jim Harris <jimharris@freebsd.org>
Cc:        FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, delphij@freebsd.org
Subject:   Re: tws bug ? (LSI SAS 9750)
Message-ID:  <505CE601.4070106@sentex.net>
In-Reply-To: <CAJP=Hc9=Rk5EvbmSe=XJJq_r0WO7DW3oUvxxK3ALAbJRUSgX7g@mail.gmail.com>
References:  <505CC8EC.4030608@sentex.net> <CAJP=Hc9=Rk5EvbmSe=XJJq_r0WO7DW3oUvxxK3ALAbJRUSgX7g@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <ACPI PCI bus> on pcib2
LSI 3ware device driver for SAS/SATA storage controllers, version:
10.80.00.003
tws0: <LSI 3ware SAS/SATA Storage Controller> 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: <Intel(R) PRO/1000 Network Connection 7.3.2> 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: <LSI 9750-4i    DISK 5.12> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?505CE601.4070106>