From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 13:54:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8C011065676 for ; Wed, 10 Feb 2010 13:54:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 754DD8FC0A for ; Wed, 10 Feb 2010 13:54:06 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0B77246B52; Wed, 10 Feb 2010 08:54:06 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 3DB7B8A021; Wed, 10 Feb 2010 08:54:05 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 10 Feb 2010 08:53:18 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <20100210105226.5c825b48.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100210105226.5c825b48.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201002100853.18088.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Feb 2010 08:54:05 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Gerrit =?iso-8859-1?q?K=FChn?= Subject: Re: bugs in mpt(4) and mptutil(8) 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: Wed, 10 Feb 2010 13:54:06 -0000 On Wednesday 10 February 2010 4:52:26 am Gerrit K=FChn wrote: > Hi, >=20 > I have 2 8port cards with lsi chips installed in one machine that are > driven by mpt(4). I see about the same problem (I think) when disconnecti= ng > disks as described here: > >=20 > When I simply pull a disk (without offlineing it first), zfs does not > notice it (is still listed as "online") and I get lots of >=20 > mpt1: mpt_cam_event: 0x16 > mpt1: mpt_cam_event: 0x12 > mpt1: mpt_cam_event: 0x16 > mpt1: mpt_cam_event: 0x16 > mpt1: mpt_cam_event: 0x16 > mpt1: request 0xffffff80005e0bf0:2419 timed out for ccb 0xffffff0005802800 > (req->ccb 0xffffff0005802800) mpt1: attempting to abort req > 0xffffff80005e0bf0:2419 function 0 mpt1: completing timedout/aborted req > 0xffffff80005e0bf0:2419 mpt1: abort of req 0xffffff80005e0bf0:0 completed > mpt1: request 0xffffff80005dc000:2810 timed out for ccb 0xffffff000fa66800 > (req->ccb 0xffffff000fa66800) mpt1: request 0xffffff80005dc3f0:2811 timed > out for ccb 0xffffff0005802800 (req->ccb 0xffffff0005802800) mpt1: > attempting to abort req 0xffffff80005dc000:2810 function 0 mpt1: > completing timedout/aborted req 0xffffff80005dc3f0:2811 mpt1: completing > timedout/aborted req 0xffffff80005dc000:2810 > [...goes on for ages...] >=20 > I don't know if this would ever stop. It ceased when I put the disk back > in. In the thread above it is mentioned that there are some fixes for mpt > (4) in -current to try out. However, I do not want to run -current on this > machine. So, does anyone here know how the chances are that the mentioned > patches are MFCed soon? >=20 >=20 > One more thing I noticed is that mptutil does not play well with my > controllers: >=20 > pigpen# mptutil show adapter > mpt0 Adapter: > Board Name: USASLP-L8i > Board Assembly: USASLP-L8i > Chip Name: C1068E > Chip Revision: B3 > RAID Levels: none > mptutil: Reading config page header failed: Invalid configuration page You can ignore this message, and it is cleaned up in HEAD. Use 'mptutil -u= 1=20 show adapter' to examine the second controller. > pigpen# mptutil show drives > mpt0 Physical Drives: > da0 ( 466G) ONLINE SATA bus 0 id 0 > da1 ( 466G) ONLINE SATA bus 0 id 1 > da6 ( 466G) ONLINE SATA bus 0 id 2 > da11 ( 466G) ONLINE SATA bus 0 id 3 > da3 ( 466G) ONLINE SATA bus 0 id 0 > da4 ( 466G) ONLINE SATA bus 0 id 1 > da5 ( 466G) ONLINE SATA bus 0 id 2 > da2 ( 75G) ONLINE SATA bus 0 id 3 > da7 ( 75G) ONLINE SATA bus 0 id 4 > da8 ( 466G) ONLINE SATA bus 0 id 5 > da9 ( 466G) ONLINE SATA bus 0 id 6 > da10 ( 466G) ONLINE SATA bus 0 id 7 > da12 ( 3824M) ONLINE SCSI-0 bus 0 id 0 >=20 >=20 > This output is definitely wrong, because the drives are split up on mpt0 > and mpt1 (and the USB stick is not connected to mpt at all :-) as can be > seen with camcontrol: Hmm, I asked the previous reporter to debug this by examining the results t= hat=20 CAM returns from the bus scan using gdb, but I haven't heard back. =20 Unfortunately I do not have access to any hardware with this sort of setup = to=20 debug this. =2D-=20 John Baldwin