amd64/172575: ioctl CAMGETPASSTHRU fails with mfi driver

[John Baldwin]

The following reply was made to PR kern/172575; it has been noted by GNATS.

From: John Baldwin <jhb at freebsd.org>
To: freebsd-amd64 at freebsd.org
Cc: John Klug <john.klug at unisys.com>,
 freebsd-gnats-submit at freebsd.org
Subject: Re: amd64/172575: ioctl CAMGETPASSTHRU fails with mfi driver
Date: Fri, 12 Oct 2012 11:09:39 -0400

 On Wednesday, October 10, 2012 11:35:40 am John Klug wrote:
 > 
 > >Number:         172575
 > >Category:       amd64
 > >Synopsis:       ioctl CAMGETPASSTHRU fails with mfi driver
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       low
 > >Responsible:    freebsd-amd64
 > >State:          open
 > >Quarter:        
 > >Keywords:       
 > >Date-Required:
 > >Class:          sw-bug
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Wed Oct 10 22:58:20 UTC 2012
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     John Klug
 > >Release:        9.0 p3
 > >Organization:
 > UNISYS
 > >Environment:
 > FreeBSD usrv-cse14.rsvl.unisys.com 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: 
 Thu Oct  4 15:55:24 CDT 2012     root at usrv-
 tsegp2:/usr/obj/freebsd/usr/src/sys/FREEBSD-amd64  amd64
 > >Description:
 > This problem causes sysutils/smartmontools to fail with the mfi driver 
 peripheral devices.
 > 
 > # camcontrol inquiry /dev/mfid0
 > camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed
 > cam_lookup_pass: No such file or directory
 > cam_lookup_pass: either the pass driver isn't in your kernel
 > cam_lookup_pass: or mfid0 doesn't exist
 > 
 > 
 > # kldstat
 > Id Refs Address            Size     Name
 >  1   19 0xffffffff80200000 1409420  kernel
 >  2    1 0xffffffff8f20a000 17cf0    isboot.ko
 >  6    2 0xffffffff8f419000 6e90     mfi.ko
 >  7    1 0xffffffff8f420000 c3f      mfip.ko
 >  8    1 0xffffffff8f421000 132317   zfs.ko
 >  9    1 0xffffffff8f554000 3001     opensolaris.ko
 > 
 > usrv-cse14:/var/log# dmesg | grep mfid0
 > mfid0: <MFI Logical Disk> on mfi0
 > mfid0: 285568MB (584843264 sectors) RAID volume '' is optimal
 > GEOM: mfid0: the secondary GPT header is not in the last LBA.
 > 
 > # dmesg | grep mfid0
 > mfid0: <MFI Logical Disk> on mfi0
 > mfid0: 285568MB (584843264 sectors) RAID volume '' is optimal
 > GEOM: mfid0: the secondary GPT header is not in the last LBA.
 > 
 > # camcontrol inquiry /dev/pass2
 > pass2: <TOSHIBA MBF2300RC DA06> Fixed Uninstalled SCSI-6 device
 > pass2: Serial Number EB03PB302RPS
 > pass2: 150.000MB/s transfers
 > 
 > # smartd -d --configfile=/var/etc/smartd.conf  --logfacility=local5
 > smartd 5.42 2011-10-20 r3458 [FreeBSD 9.0-RELEASE-p3 amd64] (local build)
 > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
 > 
 > Opened configuration file /var/etc/smartd.conf
 > Configuration file /var/etc/smartd.conf parsed.
 > Device: /dev/mfid0, unable to autodetect device type
 > Device: /dev/mfid1, unable to autodetect device type
 > Device: /dev/mfid2, unable to autodetect device type
 > Device: /dev/mfid3, unable to autodetect device type
 > Device: /dev/mfid4, unable to autodetect device type
 > Device: /dev/mfid5, unable to autodetect device type
 > Device: /dev/mfid6, unable to autodetect device type
 > Device: /dev/mfid7, unable to autodetect device type
 > Unable to monitor any SMART enabled devices. Try debug (-d) option. 
 Exiting...
 > 
 > 
 > This problem makes it difficult to relate zpool devices to the device serial 
 number and SMART information.
 
 mfidX are logical volumes, not physical drives.  passX are physical drives and 
 that is what smartd needs to monitor.  This is not a bug, this is just how you 
 have to use smartd with drives behind an mfi(4) controller.
 
 -- 
 John Baldwin