bugs in mpt(4) and mptutil(8)

[John Baldwin]

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