camcontrol and mfi driver failure

There doesn't appear to be a way to get the SCSI target or LUN from the mfi driver devices:

Code:
# 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
 
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.
 
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:

Code:
# 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.
 
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(4) device corresponds to a given pass-through device.

Are there are any other HBA adapters included in the FreeBSD distribution that cannot map the peripheral device to the pass-through device?
 
Last edited by a moderator:
klugja said:
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:
Code:
camcontrol devlist -v
...
scbus3 on mfi0 bus 0:
<ATA WDC WD5003ABYX-0 1S02>        at [B]scbus3 target 17 lun 0[/B] (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,
Code:
mfiutil show drives
mfi0 Physical Drives:
[B]17[/B] (  465G) ONLINE <WDC WD5003ABYX-0 1S02 serial=WD-WMAYP3271013> SATA E1:S0
[B]18[/B] (  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(4) case that you are seeing.
 
Last edited by a moderator:
# 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.
 
Last edited by a moderator:
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?
 
Looks like device.hints has trouble getting a match. It reserved the devices, but didn't match up.

Code:
# 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?
 
Last edited by a moderator:
I also had some problems finding a way to map mfid disk names to drive numbers. I found Somari's suggestion to use mfiutil super useful, especially mfiutil show config

Code:
# mfiutil show config
mfi0 Configuration: 29 arrays, 29 volumes, 0 spares
    array 0 of 1 drives:
        drive  0 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D18Z5A> SATA
    array 1 of 1 drives:
        drive  1 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D26ZHF> SATA
    array 2 of 1 drives:
        drive 20 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D1PAVK> SATA
    array 3 of 1 drives:
        drive 10 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D1QYB2> SATA
    array 4 of 1 drives:
        drive 22 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D1P67N> SATA
    array 5 of 1 drives:
        drive 19 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D2667P> SATA
    array 6 of 1 drives:
        drive 21 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D28ZTL> SATA
    array 7 of 1 drives:
        drive 25 ( 3726G) ONLINE <WDC WD40EFRX-68W 0A82 serial=WD-WCC4E2CDEJ0Y> SATA
        
# mfiutil show volumes
mfi0 Volumes:
  Id     Size    Level   Stripe  State   Cache   Name
 mfid0 ( 4657G) RAID-0      64K OPTIMAL Enabled
 mfid1 ( 4657G) RAID-0      64K OPTIMAL Enabled
 mfid2 ( 4657G) RAID-0      64K OPTIMAL Enabled
 mfid3 ( 4657G) RAID-0      64K OPTIMAL Enabled
 mfid4 ( 4657G) RAID-0      64K OPTIMAL Enabled
 mfid5 ( 4657G) RAID-0      64K OPTIMAL Enabled
 mfid6 ( 4657G) RAID-0      64K OPTIMAL Enabled
 mfid7 ( 3725G) RAID-0      64K OPTIMAL Enabled
 
# mfiutil show drives
mfi0 Physical Drives:
 0 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D18Z5A> SATA E1:S0
 1 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D26ZHF> SATA E1:S1
 6 ( 2795G) ONLINE <ST3000DM001-1CH1 CC24 serial=W1F1H6J9> SATA E1:S6
 7 ( 2795G) ONLINE <ST3000DM001-1CH1 CC24 serial=W1F1H5WW> SATA E1:S7
 9 ( 5589G) ONLINE <ST6000VN0001-1SF AN02 serial=S4D0WDBE> SATA E1:S9
10 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D1QYB2> SATA E1:S10
11 ( 3726G) ONLINE <WDC WD40EFRX-68W 0A82 serial=WD-WCC4E5DEVNYZ> SATA E1:S11
13 ( 5589G) ONLINE <ST6000VN0001-1SF AN02 serial=S4D0VWQM> SATA E2:S0
14 ( 5589G) ONLINE <ST6000VN0001-1SF AN02 serial=S4D0WE7L> SATA E2:S1
15 ( 5589G) ONLINE <ST6000VN0001-1SF AN02 serial=S4D0WEA7> SATA E2:S2
16 ( 5589G) ONLINE <ST6000VN0001-1SF AN02 serial=S4D0S8KR> SATA E2:S3
17 ( 5589G) ONLINE <ST6000VN0001-1SF AN02 serial=S4D0T2HH> SATA E2:S4
18 ( 5589G) ONLINE <ST6000VN0001-1SF AN02 serial=S4D0WDGY> SATA E2:S5
19 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D2667P> SATA E2:S6
20 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D1PAVK> SATA E2:S7
21 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D28ZTL> SATA E2:S8
22 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D1P67N> SATA E2:S9
23 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D18NWW> SATA E2:S10
24 ( 4658G) ONLINE <ST5000VN0001-1SF AN02 serial=Z4D115ZZ> SATA E2:S11
25 ( 3726G) ONLINE <WDC WD40EFRX-68W 0A82 serial=WD-WCC4E2CDEJ0Y> SATA E2:S12

From that I was able to deduce that the name is derived from the array number. This is configured all drives as raid0 on the hardware controller.
 
Back
Top