bugs in mpt(4) and mptutil(8)
John Baldwin
jhb at freebsd.org
Wed Feb 10 13:54:06 UTC 2010
On Wednesday 10 February 2010 4:52:26 am Gerrit Kühn wrote:
> Hi,
>
> 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 disconnecting
> disks as described here:
> <http://forums.freebsd.org/showthread.php?t=9407>
>
> 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
>
> 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...]
>
> 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?
>
>
> One more thing I noticed is that mptutil does not play well with my
> controllers:
>
> 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
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
>
>
> 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 that
CAM returns from the bus scan using gdb, but I haven't heard back.
Unfortunately I do not have access to any hardware with this sort of setup to
debug this.
--
John Baldwin
More information about the freebsd-stable
mailing list