2b91 camcontrol and mfi driver failure [Archive] - The FreeBSD Forums
PDA

View Full Version : camcontrol and mfi driver failure

klugja
September 13th, 2012, 22:11
There doesn't appear to be a way to get the SCSI target or LUN from the mfi driver devices:

# camcontrol periphlist /dev/mfi0
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 mfi0 doesn't exist
# camcontrol periphlist /dev/cd0
pass0: generation: 4 index: 1 status: MORE
cd0: generation: 4 index: 2 status: LAST

Basically, CAMGETPASSTHRU fails to find the passthrough driver, so you can't find any more information about the drive without guessing the passhthrough driver index. Is this the case?

Apparently this is a very old issue:
http://lists.freebsd.org/pipermail/freebsd-scsi/2005-March/001776.html
Somari
September 14th, 2012, 07:32
Is the mfip kernel module loaded? kldstat -v | grep mfip should confirm that.

If so issuing a, camcontrol rescan [bus/all] should get the pass driver instances and then finding the SCSI target and LUN could be based on the output of, camcontrol devlist -v and further to get camcontrol periphlist to work, use the bus:target combination as the device ID to get the details of the pass instance.

Conjecture warning: In the case of mfi driver, the mfip driver is needed to create the pass through driver, and hence this is not mapped to the actual driver/disk instance like mfi0 etc. as a result, camcontrol periphlist /dev/mfi0 fails even if the mfip kernel module is loaded, hence the usage of camcontrol devlist and then using the device ID with periphlist etc. as suggested above. The warning because I think this is what is happening and am not sure, but does provide a solution to the problem posted, to my knowledge.
klugja
September 17th, 2012, 16:53
I did not know after loading the mfip driver, that a rescan was needed.

Does anyone know if there are other drivers included with the FreeBSD distribution that have this problem:


# camcontrol periphlist /dev/mfi0
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 mfi0 doesn't exist

It seems if you are buying new hardware, this driver should be avoided.
klugja
September 17th, 2012, 17:09
I appologize for post #3. I was on the wrong system when I tested the suggestions.

I already knew about the mfip driver and it was loaded.

Even after doing a rescan, I don't see how to map /dev/mfi[n] to a specific controller, LUN and SCSI target. That is the issue I am trying to solve. camcontrol devlist will not tell you which mfi device corresponds to a given passthrough device.

Are there are any other HBA adapters included in the FreeBSD distribution that cannot map the peripheral device to the passthrough device?
Somari
September 18th, 2012, 08:18
Even after doing a rescan, I don't see how to map /dev/mfi[n] to a specific controller, LUN and SCSI target. That is the issue I am trying to solve. camcontrol devlist will not tell you which mfi device corresponds to a given passthrough device.

I am not entirely sure why this is needed, but here is an alternative, fix the names of the devices using the device.hints file (/boot/device.hints). This would need you to first determine the SCSI bus:target:lun, which can be done using the camcontrol devlist and mfiutil show drives output combination. Post this the names should be fixed for your use.

Example:
camcontrol devlist -v
...
scbus3 on mfi0 bus 0:
<ATA WDC WD5003ABYX-0 1S02> at scbus3 target 17 lun 0 (pass3)
<ATA WDC WD5003ABYX-0 1S02> at scbus3 target 18 lun 0 (pass4)
...


Use the bus:target:lun from here to statically assign the device names in the device.hints file.

The mfiutil show drives output is optional anyway, but can be useful,
mfiutil show drives
mfi0 Physical Drives:
17 ( 465G) ONLINE <WDC WD5003ABYX-0 1S02 serial=WD-WMAYP3271013> SATA E1:S0
18 ( 465G) ONLINE <WDC WD5003ABYX-0 1S02 serial=WD-WMAYP3275912> SATA E1:S1

But, if you could elaborate on why you need the /dev/mfi[n] names in particular, rather than just use the bus:target:lun combination, it may help see what and why something is missing.

Although at the end of the day, this maybe just a solution for the mfi case that you are seeing.
klugja
September 18th, 2012, 17:20
camcontrol devlist -v lists the disk drives.

How do I know which disk is /dev/mfid5, for instance?

If this fails, and zpool status says /dev/mfid5 has an issue, which SCSI target/LUN/controller is it?

What if I have two LSI logic controllers, then how do I replace the disk?

Maybe it is obvious to you, but it isn't to me.
Somari
September 19th, 2012, 06:52
My suggestion on device.hints is elaborated here,
ZFS and Virtual to physical Drive Mapping on an LSI 9201-16 HBA Card (http://forums.freebsd.org/showpost.php?p=184744&postcount=8)

If you already have a zpool created, this maybe the best option that I can think of. That way you need not touch the disks again.

Other options are using labeled disks, see these posts, probably best if you are going to create the zpool afresh,
HOWTO: Add full disk labels to an existing zfs system (http://forums.freebsd.org/showthread.php?t=28181)
ZFS and disk labeling question (http://forums.freebsd.org/showthread.php?t=33896)
klugja
September 25th, 2012, 15:46
Labeling the disks would not help with smartctl commands, which could not be matched back to the ZFS (mfid) drivers.

I would assume device.hints would require a reboot every time the file was changed?
klugja
October 3rd, 2012, 20:13
Looks like device.hints has trouble getting a match. It reserved the devices, but didn't match up.

# camcontrol devlist
<TSSTcorp DVD+-RW TS-H653J D100> at scbus0 target 0 lun 0 (pass0,cd0)
<Single Flash Reader 1.00> at scbus2 target 0 lun 0 (pass1,da0)
<TOSHIBA MBF2300RC DA06> at scbus3 target 0 lun 0 (pass2)
<TOSHIBA MBF2300RC DA06> at scbus3 target 1 lun 0 (pass3)
<TOSHIBA MBF2300RC DA06> at scbus3 target 2 lun 0 (pass4)
<TOSHIBA MBF2300RC DA06> at scbus3 target 3 lun 0 (pass5)
<TOSHIBA MBF2300RC DA06> at scbus3 target 4 lun 0 (pass6)
<TOSHIBA MBF2300RC DA06> at scbus3 target 5 lun 0 (pass7)
<TOSHIBA MBF2300RC DA06> at scbus3 target 6 lun 0 (pass8)
<TOSHIBA MBF2300RC DA06> at scbus3 target 7 lun 0 (pass9)
<DP BACKPLANE 1.09> at scbus3 target 32 lun 0 (pass10,ses0)

# kenv | grep mfi
hint.mfid.0.at="scbus3"
hint.mfid.0.target="0"
hint.mfid.0.unit="0"
hint.mfid.1.at="scbus3"
hint.mfid.1.target="1"
hint.mfid.1.unit="0"
hint.mfid.2.at="scbus3"
hint.mfid.2.target="2"
hint.mfid.2.unit="0"
hint.mfid.3.at="scbus3"
hint.mfid.3.target="3"
hint.mfid.3.unit="0"
hint.mfid.4.at="scbus3"
hint.mfid.4.target="4"
hint.mfid.4.unit="0"
hint.mfid.5.at="scbus3"
hint.mfid.5.target="5"
hint.mfid.5.unit="0"
hint.mfid.6.at="scbus3"
hint.mfid.6.target="6"
hint.mfid.6.unit="0"
hint.mfid.7.at="scbus3"
hint.mfid.7.target="7"
hint.mfid.7.unit="0"
hint.scbus.3.at="mfi0"

# ls /dev/mfi*
/dev/mfi0 /dev/mfid11 /dev/mfid13 /dev/mfid15 /dev/mfid8p1 /dev/mfid9p1
/dev/mfid10 /dev/mfid12 /dev/mfid14 /dev/mfid8 /dev/mfid9


So what do I have to do to get the mfid[device#] to take the hints?
0