Date: Fri, 12 Oct 2012 16:00:01 GMT From: John Baldwin <jhb@freebsd.org> To: freebsd-scsi@FreeBSD.org Subject: Re: amd64/172575: ioctl CAMGETPASSTHRU fails with mfi driver Message-ID: <201210121600.q9CG01wq025998@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/172575; it has been noted by GNATS. From: John Baldwin <jhb@freebsd.org> To: freebsd-amd64@freebsd.org Cc: John Klug <john.klug@unisys.com>, freebsd-gnats-submit@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201210121600.q9CG01wq025998>