From nobody@FreeBSD.org  Mon Nov  9 13:16:04 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id F41701065679
	for <freebsd-gnats-submit@FreeBSD.org>; Mon,  9 Nov 2009 13:16:03 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id E32198FC17
	for <freebsd-gnats-submit@FreeBSD.org>; Mon,  9 Nov 2009 13:16:03 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id nA9DG3Qu070511
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 9 Nov 2009 13:16:03 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id nA9DG31g070510;
	Mon, 9 Nov 2009 13:16:03 GMT
	(envelope-from nobody)
Message-Id: <200911091316.nA9DG31g070510@www.freebsd.org>
Date: Mon, 9 Nov 2009 13:16:03 GMT
From: "Stephane D'Alu" <Stephane.DAlu@insa-lyon.fr>
To: freebsd-gnats-submit@FreeBSD.org
Subject: mfi driver stuck in timeout
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         140416
>Category:       kern
>Synopsis:       [mfi] [patch] mfi driver stuck in timeout
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    delphij
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Nov 09 13:20:07 UTC 2009
>Closed-Date:    Tue Feb 07 22:01:16 UTC 2012
>Last-Modified:  Tue Feb 07 22:01:16 UTC 2012
>Originator:     Stephane D'Alu
>Release:        8.0-RC2
>Organization:
INSA Lyon
>Environment:
FreeBSD mil.citi.insa-lyon.fr 8.0-RC2 FreeBSD 8.0-RC2 #0: Thu Nov  5 17:29:05 CET 2009     root@mil.citi.insa-lyon.fr:/usr/obj/usr/src/sys/GENERIC  amd64

>Description:
Systeme is a 32Go memory, 2 cpus 4 cores 2 SMT threads

The computer is configured to use ZFS with disks attached to the mfi controller
when performing for example zfs scrub, the controller enter in timeout and doesn't leave this state:

mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 41 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 71 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 101 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 131 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 161 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 191 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 221 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 251 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 281 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 311 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 341 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 371 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 401 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 431 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 461 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 491 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 521 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 551 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 581 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 611 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 641 SECONDS
mfi0: COMMAND 0xffffff80009c4b90 TIMEOUT AFTER 671 SECONDS

I can perform further diagnostics on the systems, just tell me what command need to be run
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:

From: Stephane D'Alu <sdalu@sdalu.com>
To: bug-followup@FreeBSD.org, Stephane.DAlu@insa-lyon.fr
Cc:  
Subject: Re: kern/140416: mfi driver stuck in timeout
Date: Mon, 09 Nov 2009 15:16:59 +0100

 Adapter is (mfiutil show adapter)
 
 mfi0 Adapter:
      Product Name: PERC 6/E Adapter
     Serial Number: 1122334455667788
          Firmware: 6.2.0-0013
       RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50
    Battery Backup: present
             NVRAM: 32K
    Onboard Memory: 512M
    Minimum Stripe: 8K
    Maximum Stripe: 1M
 
 
 ZFS pool:
    pool: fs
   state: ONLINE
   scrub: scrub in progress for 1h5m, 14.36% done, 6h28m to go
 config:
 
          NAME                STATE     READ WRITE CKSUM
          fs                  ONLINE       0     0     0
            raidz2            ONLINE       0     0     0
              label/fs-zfs-0  ONLINE       0     0     0
              label/fs-zfs-1  ONLINE       0     0     0
              label/fs-zfs-2  ONLINE       0     0     0
              label/fs-zfs-3  ONLINE       0     0     0
              label/fs-zfs-4  ONLINE       0     0     0
              label/fs-zfs-5  ONLINE       0     0     0
              label/fs-zfs-6  ONLINE       0     0     0
              label/fs-zfs-7  ONLINE       0     0     0

From: Stephane D'Alu <Stephane.DAlu@insa-lyon.fr>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/140416: [mfi] mfi driver stuck in timeout
Date: Thu, 12 Nov 2009 16:00:49 +0100

 when enabling MFI_DEBUG and dumping information on timeout:
 
 
 mfi0: COMMAND 0xffffff80009c2660 TIMEOUT AFTER 36 SECONDS
 mfi0: cm=0xffffff80009c2660 index=12 total_frame_size=52 extra_frames=0
 mfi0: flags=83<MAPPED,DATAIN,Q_BUSY>
 mfi0: cmd=LD_READ target_id=5 sg_count=1 data_len=128 lba=1505643648
 mfi0: flags=12<SGL64,READ>
 SG List:
 0x9664a000:065536
 mfi0: mfi_timeout 2527 COMMAND 0xffffff80009c2660 S/G count bad 0 65536 
 65536 0x9664a000
 mfi0: cm=0xffffff80009c2660 index=12 total_frame_size=52 extra_frames=0
 mfi0: flags=83<MAPPED,DATAIN,Q_BUSY>
 mfi0: cmd=LD_READ target_id=5 sg_count=1 data_len=128 lba=1505643648
 mfi0: flags=12<SGL64,READ>
 SG List:
 0x9664a000:065536
 0000   01 80 00 00 05 00 00 01 0c 00 00 00 00 00 00 00
 0010   12 00 00 00 80 00 00 00 00 06 fa 02 00 00 00 00
 0020   80 4c be 59 00 00 00 00 00 a0 64 96 00 00 00 00
 0030   00 00 01 00
 0000   05 00 00 00 00 00 00 01 12 00 00 00 00 00 00 00
 0010   12 00 00 00 00 01 00 00 00 05 04 01 2b 03 00 00
 0020   ff ff 00 00 00 00 00 00 00 db d9 0b 00 00 00 00
 0030   00 01 00 00
 
 
 mfi0: COMMAND 0xffffff80009c2660 TIMEOUT AFTER 308 SECONDS
 mfi0: cm=0xffffff80009c2660 index=12 total_frame_size=52 extra_frames=0
 mfi0: flags=83<MAPPED,DATAIN,Q_BUSY>
 mfi0: cmd=LD_READ target_id=5 sg_count=1 data_len=128 lba=1505643648
 mfi0: flags=12<SGL64,READ>
 SG List:
 0x9664a000:065536
 mfi0: mfi_timeout 2527 COMMAND 0xffffff80009c2660 S/G count bad 0 65536 
 65536 0x9664a000
 mfi0: cm=0xffffff80009c2660 index=12 total_frame_size=52 extra_frames=0
 mfi0: flags=83<MAPPED,DATAIN,Q_BUSY>
 mfi0: cmd=LD_READ target_id=5 sg_count=1 data_len=128 lba=1505643648
 mfi0: flags=12<SGL64,READ>
 SG List:
 0x9664a000:065536
 0000   01 80 00 00 05 00 00 01 0c 00 00 00 00 00 00 00
 0010   12 00 00 00 80 00 00 00 00 06 fa 02 00 00 00 00
 0020   80 4c be 59 00 00 00 00 00 a0 64 96 00 00 00 00
 0030   00 00 01 00
 0000   05 00 00 00 00 00 00 01 12 00 00 00 00 00 00 00
 0010   12 00 00 00 00 01 00 00 00 05 04 01 2b 03 00 00
 0020   ff ff 00 00 00 00 00 00 00 db d9 0b 00 00 00 00
 0030   00 01 00 00

From: Neil  Schelly <nschelly@dyn.com>
To: bug-followup@FreeBSD.org, Stephane.DAlu@insa-lyon.fr
Cc:  
Subject: Re: kern/140416: [mfi] mfi driver stuck in timeout
Date: Tue, 8 Mar 2011 20:04:56 -0500 (EST)

 ------=_Part_97141_16009456.1299632696194
 Content-Type: text/plain; charset=utf-8
 Content-Transfer-Encoding: 7bit
 
 As posted here: http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004832.html
 
 We've got some more information about the mpt testing we've been doing here.  The setup we're testing is Dell PowerEdge r610 servers with PERC H800 SAS/RAID cards connected to MD1200 shelves full of 12 SAS drives.  We've recreated the same problem on other configurations, including combinations of r510s, MD1220 shelves, PERC H700 cards, etc.  We've also eliminated any particular piece of hardware as faulty by running these on identical hardware configurations in mirrored setups on different physical pieces  of hardware.  We've experienced these issues in FreeBSD 7.3, 8.1, and 8.2.  We've experienced this issue with either RAID10 logical drive configurations formatted with UFS or 6-disk JBOD configurations setup in a ZFS raidz volume.  We've triggered the problem with both bonnie++ and iozone.  All machines are runnning the latest firmware on the H700 and H800 cards.
 
 The easiest method to reproduce this problem is with a ZFS configuration and using `iozone -a`.  We have a 6-disk raidz partition with a ZFS filesystem on it.  We just run `iozone -a` from within that filesystem, and I'd say 3 out of 4 times, it will eventually pause.  After 45-50 seconds of pausing, you'll start seeing the console and /var/log/messages output that looks something like: 
   mfi0: COMMAND 0xffffff8000db5fe0 TIMEOUT AFTER 105 SECONDS
 
 If we let it go for a few days, it may actually "finish" and recover, but it's essentially just stuck and not recovering.  The system is responsive and fully operational except the dead controller at this point.  We cannot kill the iozone process that is hung on these IO operations, even with `kill -9`.  Like others have reported, we can run any of the mfiutil commands and the controller immediately begins to respond normally again.  Usually, the iozone test will complete, but sometimes it will even get st uck again on the same run.  
 
 We compiled mfiutil with debugging symbols so we could run it with gdb and see exactly what was causing the controller to become responsive again.  It's the ioctl() call that does it.  For example:
 
 `mfiutil show volumes` eventually gets to something like:
   mfi_dcmd_command (fd=7, opcode=50397184, buf=0x7fffffffe4a0, bufsize=1032, mbox=0x0, mboxlen=0, statusp=0x0)
   at /usr/src/usr.sbin/mfiutil/mfi_cmd.c:257
  * fd=7 is /dev/mfi0, where the command will be sent with an ioctl command
  * opcode=50397184 is the MFI_DCMD_LD_GET_LIST command
 
 `mfiutil show battery` eventually gets to something like:
   mfi_dcmd_command (fd=7, opcode=84017152, buf=0x7fffffffea20, bufsize=48, mbox=0x0, mboxlen=0, statusp=0x7fffffffe9cf "")
   at /usr/src/usr.sbin/mfiutil/mfi_cmd.c:257
  * fd=7 is /dev/mfi0, where the command will be sent with an ioctl command
  * opcode=84017152 is the MFI_DCMD_BBU_GET_CAPACITY_INFO command
 
 I wrote a small self-contained C program that can easily be modified to run any ioctl command you'd like and send it to /dev/mfi0 (attached).  Use it if you'd like at your own risk, but it's essentially just running an arbitrary command with ioctl, putting nothing into the memory range normally passed by the *buf pointer.  I did try sending random opcodes, and it didn't work, so it does have to be an opcode that the firmware will recognize at least, but it doesn't seem to matter which one.
 
 I'm not sure where else we should be looking for a fix.  We can reliably reproduce the problem, analyze the system during the issue, and recover the system to a normal state.  If there's anyone who can help us troubleshoot this with any information we can gather or even a local login remotely accessible, we're open to ideas.  
 
 --
 Neil Schelly
 Director of Uptime
 Dynamic Network Services, Inc.
 W: 603-296-1581
 M: 508-410-4776
 http://www.dyndns.com
 
 
 ------=_Part_97141_16009456.1299632696194
 Content-Type: text/x-csrc; name=testperc.c
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename=testperc.c
 
 I2luY2x1ZGUgPGZjbnRsLmg+CiNpbmNsdWRlIDxzdGRpbnQuaD4KI2luY2x1ZGUgPGlvY2NvbS5o
 PgoKI2RlZmluZSBNRklfTUJPWF9TSVpFICAgICAgICAgICAxMgojZGVmaW5lIE1GSV9DTURfRENN
 RCAgICAgICAgICAweDA1CiNkZWZpbmUgTUZJSU9fUEFTU1RIUlUgIF9JT1dSKCdDJywgMTAyLCBz
 dHJ1Y3QgbWZpX2lvY19wYXNzdGhydSkKCi8qIERpcmVjdCBjb21tYW5kcyAqLwp0eXBlZGVmIGVu
 dW0gewogICAgICAgIE1GSV9EQ01EX0NUUkxfR0VUSU5GTyA9ICAgICAgICAgMHgwMTAxMDAwMCwK
 ICAgICAgICBNRklfRENNRF9DVFJMX01GQ19ERUZBVUxUU19HRVQgPTB4MDEwZTAyMDEsCiAgICAg
 ICAgTUZJX0RDTURfQ1RSTF9NRkNfREVGQVVMVFNfU0VUID0weDAxMGUwMjAyLAogICAgICAgIE1G
 SV9EQ01EX0NUUkxfRkxVU0hDQUNIRSA9ICAgICAgMHgwMTEwMTAwMCwKICAgICAgICBNRklfRENN
 RF9DVFJMX1NIVVRET1dOID0gICAgICAgIDB4MDEwNTAwMDAsCiAgICAgICAgTUZJX0RDTURfQ1RS
 TF9FVkVOVF9HRVRJTkZPID0gICAweDAxMDQwMTAwLAogICAgICAgIE1GSV9EQ01EX0NUUkxfRVZF
 TlRfR0VUID0gICAgICAgMHgwMTA0MDMwMCwKICAgICAgICBNRklfRENNRF9DVFJMX0VWRU5UX1dB
 SVQgPSAgICAgIDB4MDEwNDA1MDAsCiAgICAgICAgTUZJX0RDTURfUFJfR0VUX1NUQVRVUyA9ICAg
 ICAgICAweDAxMDcwMTAwLAogICAgICAgIE1GSV9EQ01EX1BSX0dFVF9QUk9QRVJUSUVTID0gICAg
 MHgwMTA3MDIwMCwKICAgICAgICBNRklfRENNRF9QUl9TRVRfUFJPUEVSVElFUyA9ICAgIDB4MDEw
 NzAzMDAsCiAgICAgICAgTUZJX0RDTURfUFJfU1RBUlQgPSAgICAgICAgICAgICAweDAxMDcwNDAw
 LAogICAgICAgIE1GSV9EQ01EX1BSX1NUT1AgPSAgICAgICAgICAgICAgMHgwMTA3MDUwMCwKICAg
 ICAgICBNRklfRENNRF9USU1FX1NFQ1NfR0VUID0gICAgICAgIDB4MDEwODAyMDEsCiAgICAgICAg
 TUZJX0RDTURfRkxBU0hfRldfT1BFTiA9ICAgICAgICAweDAxMGYwMTAwLAogICAgICAgIE1GSV9E
 Q01EX0ZMQVNIX0ZXX0RPV05MT0FEID0gICAgMHgwMTBmMDIwMCwKICAgICAgICBNRklfRENNRF9G
 TEFTSF9GV19GTEFTSCA9ICAgICAgIDB4MDEwZjAzMDAsCiAgICAgICAgTUZJX0RDTURfRkxBU0hf
 RldfQ0xPU0UgPSAgICAgICAweDAxMGYwNDAwLAogICAgICAgIE1GSV9EQ01EX1BEX0dFVF9MSVNU
 ID0gICAgICAgICAgMHgwMjAxMDAwMCwKICAgICAgICBNRklfRENNRF9QRF9HRVRfSU5GTyA9ICAg
 ICAgICAgIDB4MDIwMjAwMDAsCiAgICAgICAgTUZJX0RDTURfUERfU1RBVEVfU0VUID0gICAgICAg
 ICAweDAyMDMwMTAwLAogICAgICAgIE1GSV9EQ01EX1BEX1JFQlVJTERfU1RBUlQgPSAgICAgMHgw
 MjA0MDEwMCwKICAgICAgICBNRklfRENNRF9QRF9SRUJVSUxEX0FCT1JUID0gICAgIDB4MDIwNDAy
 MDAsCiAgICAgICAgTUZJX0RDTURfUERfQ0xFQVJfU1RBUlQgPSAgICAgICAweDAyMDUwMTAwLAog
 ICAgICAgIE1GSV9EQ01EX1BEX0NMRUFSX0FCT1JUID0gICAgICAgMHgwMjA1MDIwMCwKICAgICAg
 ICBNRklfRENNRF9QRF9HRVRfUFJPR1JFU1MgPSAgICAgIDB4MDIwNjAwMDAsCiAgICAgICAgTUZJ
 X0RDTURfUERfTE9DQVRFX1NUQVJUID0gICAgICAweDAyMDcwMTAwLAogICAgICAgIE1GSV9EQ01E
 X1BEX0xPQ0FURV9TVE9QID0gICAgICAgMHgwMjA3MDIwMCwKICAgICAgICBNRklfRENNRF9MRF9H
 RVRfTElTVCA9ICAgICAgICAgIDB4MDMwMTAwMDAsCiAgICAgICAgTUZJX0RDTURfTERfR0VUX0lO
 Rk8gPSAgICAgICAgICAweDAzMDIwMDAwLAogICAgICAgIE1GSV9EQ01EX0xEX0dFVF9QUk9QID0g
 ICAgICAgICAgMHgwMzAzMDAwMCwKICAgICAgICBNRklfRENNRF9MRF9TRVRfUFJPUCA9ICAgICAg
 ICAgIDB4MDMwNDAwMDAsCiAgICAgICAgTUZJX0RDTURfTERfSU5JVF9TVEFSVCA9ICAgICAgICAw
 eDAzMDYwMTAwLAogICAgICAgIE1GSV9EQ01EX0xEX0RFTEVURSA9ICAgICAgICAgICAgMHgwMzA5
 MDAwMCwKICAgICAgICBNRklfRENNRF9DRkdfUkVBRCA9ICAgICAgICAgICAgIDB4MDQwMTAwMDAs
 CiAgICAgICAgTUZJX0RDTURfQ0ZHX0FERCA9ICAgICAgICAgICAgICAweDA0MDIwMDAwLAogICAg
 ICAgIE1GSV9EQ01EX0NGR19DTEVBUiA9ICAgICAgICAgICAgMHgwNDAzMDAwMCwKICAgICAgICBN
 RklfRENNRF9DRkdfTUFLRV9TUEFSRSA9ICAgICAgIDB4MDQwNDAwMDAsCiAgICAgICAgTUZJX0RD
 TURfQ0ZHX1JFTU9WRV9TUEFSRSA9ICAgICAweDA0MDUwMDAwLCAgICAgCiAgICAgICAgTUZJX0RD
 TURfQ0ZHX0ZPUkVJR05fSU1QT1JUID0gICAweDA0MDYwNDAwLAogICAgICAgIE1GSV9EQ01EX0JC
 VV9HRVRfU1RBVFVTID0gICAgICAgMHgwNTAxMDAwMCwKICAgICAgICBNRklfRENNRF9CQlVfR0VU
 X0NBUEFDSVRZX0lORk8gPTB4MDUwMjAwMDAsCiAgICAgICAgTUZJX0RDTURfQkJVX0dFVF9ERVNJ
 R05fSU5GTyA9ICAweDA1MDMwMDAwLAogICAgICAgIE1GSV9EQ01EX0NMVVNURVIgPSAgICAgICAg
 ICAgICAgMHgwODAwMDAwMCwKICAgICAgICBNRklfRENNRF9DTFVTVEVSX1JFU0VUX0FMTCA9ICAg
 IDB4MDgwMTAxMDAsCiAgICAgICAgTUZJX0RDTURfQ0xVU1RFUl9SRVNFVF9MRCA9ICAgICAweDA4
 MDEwMjAwCn0gbWZpX2RjbWRfdDsKCnN0cnVjdCBtZmlfZnJhbWVfaGVhZGVyIHsKICAgICAgICB1
 aW50OF90ICAgICAgICAgY21kOwogICAgICAgIHVpbnQ4X3QgICAgICAgICBzZW5zZV9sZW47CiAg
 ICAgICAgdWludDhfdCAgICAgICAgIGNtZF9zdGF0dXM7CiAgICAgICAgdWludDhfdCAgICAgICAg
 IHNjc2lfc3RhdHVzOwogICAgICAgIHVpbnQ4X3QgICAgICAgICB0YXJnZXRfaWQ7CiAgICAgICAg
 dWludDhfdCAgICAgICAgIGx1bl9pZDsKICAgICAgICB1aW50OF90ICAgICAgICAgY2RiX2xlbjsK
 ICAgICAgICB1aW50OF90ICAgICAgICAgc2dfY291bnQ7CiAgICAgICAgdWludDMyX3QgICAgICAg
 IGNvbnRleHQ7CiAgICAgICAgdWludDMyX3QgICAgICAgIHBhZDA7CiAgICAgICAgdWludDE2X3Qg
 ICAgICAgIGZsYWdzOwojZGVmaW5lIE1GSV9GUkFNRV9EQVRBT1VUICAgICAgIDB4MDgKI2RlZmlu
 ZSBNRklfRlJBTUVfREFUQUlOICAgICAgICAweDEwCiAgICAgICAgdWludDE2X3QgICAgICAgIHRp
 bWVvdXQ7CiAgICAgICAgdWludDMyX3QgICAgICAgIGRhdGFfbGVuOwp9IF9fcGFja2VkOwoKc3Ry
 dWN0IG1maV9zZzMyIHsKICAgICAgICB1aW50MzJfdCAgICAgICAgYWRkcjsKICAgICAgICB1aW50
 MzJfdCAgICAgICAgbGVuOwp9IF9fcGFja2VkOwoKc3RydWN0IG1maV9zZzY0IHsKICAgICAgICB1
 aW50NjRfdCAgICAgICAgYWRkcjsKICAgICAgICB1aW50MzJfdCAgICAgICAgbGVuOwp9IF9fcGFj
 a2VkOwoKdW5pb24gbWZpX3NnbCB7CiAgICAgICAgc3RydWN0IG1maV9zZzMyIHNnMzJbMV07CiAg
 ICAgICAgc3RydWN0IG1maV9zZzY0IHNnNjRbMV07Cn0gX19wYWNrZWQ7CgpzdHJ1Y3QgbWZpX2Rj
 bWRfZnJhbWUgewogICAgICAgIHN0cnVjdCBtZmlfZnJhbWVfaGVhZGVyIGhlYWRlcjsKICAgICAg
 ICB1aW50MzJfdCAgICAgICAgb3Bjb2RlOwogICAgICAgIHVpbnQ4X3QgICAgICAgICBtYm94W01G
 SV9NQk9YX1NJWkVdOwogICAgICAgIHVuaW9uIG1maV9zZ2wgICBzZ2w7Cn0gX19wYWNrZWQ7Cgpz
 dHJ1Y3QgbWZpX2lvY19wYXNzdGhydSB7CiAgICAgICAgc3RydWN0IG1maV9kY21kX2ZyYW1lICAg
 aW9jX2ZyYW1lOwogICAgICAgIHVpbnQzMl90ICAgICAgICAgICAgICAgIGJ1Zl9zaXplOwogICAg
 ICAgIHVpbnQ4X3QgICAgICAgICAgICAgICAgICpidWY7Cn0gX19wYWNrZWQ7CgppbnQgbWFpbigp
 IHsKICAgICAgICBpbnQgZmQgPSBvcGVuKCIvZGV2L21maTAiLCBPX1JEV1IpOwogICAgICAgIHN0
 cnVjdCBtZmlfaW9jX3Bhc3N0aHJ1IGlvYzsKICAgICAgICBzdHJ1Y3QgbWZpX2RjbWRfZnJhbWUg
 KmRjbWQ7CgljaGFyKiBidWY7CgogICAgICAgIGRjbWQgPSAmaW9jLmlvY19mcmFtZTsKICAgICAg
 ICBkY21kLT5oZWFkZXIuY21kID0gTUZJX0NNRF9EQ01EOwogICAgICAgIGRjbWQtPmhlYWRlci50
 aW1lb3V0ID0gMDsKICAgICAgICBkY21kLT5oZWFkZXIuZmxhZ3MgPSAwOwogICAgICAgIGRjbWQt
 PmhlYWRlci5kYXRhX2xlbiA9IDA7CiAgICAgICAgZGNtZC0+b3Bjb2RlID0gTUZJX0RDTURfQ0ZH
 X0FERDsKLy8gICAgICAgIGRjbWQtPm9wY29kZSA9IDA7CiAgICAgICAgCiAgICAgICAgaW9jLmJ1
 ZiA9IGJ1ZjsKICAgICAgICBpb2MuYnVmX3NpemUgPSA4OyAKICAgICAgICBpb2N0bChmZCwgTUZJ
 SU9fUEFTU1RIUlUsICZpb2MpOwoKfQoK
 ------=_Part_97141_16009456.1299632696194--

From: Neil  Schelly <nschelly@dyn.com>
To: bug-followup@FreeBSD.org, Stephane DAlu <Stephane.DAlu@insa-lyon.fr>
Cc:  
Subject: Re: kern/140416: [mfi] mfi driver stuck in timeout
Date: Tue, 22 Mar 2011 14:46:34 -0400 (EDT)

 We came up with a patch and explanation to resolve this issue.  The patch should be credited to Scott Long.
 
 See my explanation and the small patch here: 
 http://lists.freebsd.org/pipermail/freebsd-scsi/2011-March/004839.html
 
 --
 Neil Schelly
 Director of Uptime
 Dynamic Network Services, Inc.
 W: 603-296-1581
 M: 508-410-4776
 http://www.dyndns.com

From: geoffroy desvernay <dgeo@centrale-marseille.fr>
To: bug-followup@FreeBSD.org, Stephane.DAlu@insa-lyon.fr
Cc:  
Subject: Re: kern/140416: [mfi] [patch] mfi driver stuck in timeout
Date: Sun, 23 Oct 2011 14:20:11 +0200

 This patch works for me(r) on 8-STABLE from yesterday and 9-RC1
 On dell PowerEdge 415 (PERC H700 Adapter) and PE515 (PERC H700 Integrated=
 )
 
 Without the patch, same problem occurs (especially with ZFS).
 
 --=20
 *Geoffroy Desvernay*
 C.R.I - Administration syst=C3=A8mes et r=C3=A9seaux
 Ecole Centrale de Marseille
 
 

From: Vincent Hoffman <vhoffman@names.co.uk>
To: bug-followup@FreeBSD.org, Stephane.DAlu@insa-lyon.fr
Cc:  
Subject: Re: kern/140416: [mfi] [patch] mfi driver stuck in timeout
Date: Wed, 02 Nov 2011 22:05:10 +0000

 I had to manually apply this patch to 8-STABLE but it appears to have
 resolved the stalls i was seeing with my
 
 mfi0@pci0:5:0:0:        class=0x010400 card=0x070015d9 chip=0x00791000
 rev=0x04 hdr=0x00
     vendor     = 'LSI Logic (Was: Symbios Logic, NCR)'
     class      = mass storage
     subclass   = RAID
 
 [root@banshee /mnt/tmp]# mfiutil -u0 show adapter
 mfi0 Adapter:
     Product Name: Supermicro SMC2108
    Serial Number:
         Firmware: 12.12.0-0047
      RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50
   Battery Backup: present
            NVRAM: 32K
   Onboard Memory: 512M
   Minimum Stripe: 8k
   Maximum Stripe: 1M
 [root@banshee /mnt/tmp]# mfiutil -u0 show firmware
 mfi0 Firmware Package Version: 12.12.0-0047
 mfi0 Firmware Images:
 Name  Version                        Date         Time         Status
 APP   2.120.53-1235                  Mar 25 2011  17:37:57     active
 BIOS  3.22.00_4.11.05.00_0x05020000   3/16/2011
    3/16/2011
   active
 PCLI  04.04-017:#%00008              Oct 12 2010  11:32:58     active
 BCON  6.0-37-e_32-Rel                Mar 23 2011  10:30:10     active
 NVDT  2.09.03-0013                   Mar 29 2011  02:35:36     active
 BTBL  2.02.00.00-0000                Sep 16 2009  21:37:06     active
 BOOT  01.250.04.219                  4/28/2009    12:51:38     active
 
 
State-Changed-From-To: open->patched 
State-Changed-By: jhb 
State-Changed-When: Mon Nov 14 18:25:42 UTC 2011 
State-Changed-Why:  
Fix committed to head in 227409. 


Responsible-Changed-From-To: freebsd-bugs->delphij 
Responsible-Changed-By: jhb 
Responsible-Changed-When: Mon Nov 14 18:25:42 UTC 2011 
Responsible-Changed-Why:  
Fix committed to head in 227409. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=140416 
State-Changed-From-To: patched->closed 
State-Changed-By: delphij 
State-Changed-When: Tue Feb 7 22:00:10 UTC 2012 
State-Changed-Why:  
The fix was MFC'ed as r227611 and r227533 to RELENG_8 and RELENG_9 
so close this PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=140416 
>Unformatted:
