Date: Wed, 10 Feb 2010 08:53:18 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: Gerrit =?iso-8859-1?q?K=FChn?= <gerrit@pmp.uni-hannover.de> Subject: Re: bugs in mpt(4) and mptutil(8) Message-ID: <201002100853.18088.jhb@freebsd.org> In-Reply-To: <20100210105226.5c825b48.gerrit@pmp.uni-hannover.de> References: <20100210105226.5c825b48.gerrit@pmp.uni-hannover.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > <http://forums.freebsd.org/showthread.php?t=3D9407>; >=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 <WDC WD5002ABYS-0 3B02> SATA bus 0 id 0 > da1 ( 466G) ONLINE <WDC WD5002ABYS-0 3B02> SATA bus 0 id 1 > da6 ( 466G) ONLINE <WDC WD5002ABYS-0 3B02> SATA bus 0 id 2 > da11 ( 466G) ONLINE <WDC WD5002ABYS-0 3B02> SATA bus 0 id 3 > da3 ( 466G) ONLINE <WDC WD5001ABYS-0 1D01> SATA bus 0 id 0 > da4 ( 466G) ONLINE <WDC WD5001ABYS-0 1D01> SATA bus 0 id 1 > da5 ( 466G) ONLINE <WDC WD5001ABYS-0 1D01> SATA bus 0 id 2 > da2 ( 75G) ONLINE <ST380815AS B> SATA bus 0 id 3 > da7 ( 75G) ONLINE <ST380815AS B> SATA bus 0 id 4 > da8 ( 466G) ONLINE <ST3500641NS C> SATA bus 0 id 5 > da9 ( 466G) ONLINE <ST3500641NS C> SATA bus 0 id 6 > da10 ( 466G) ONLINE <ST3500641NS C> SATA bus 0 id 7 > da12 ( 3824M) ONLINE <ST 4GB 0000> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201002100853.18088.jhb>