[Bug 294353] mfiutil(8)/mrsasutil(8): Information on enclosures is ambiguous and poorly documented
Date: Sun, 13 Sep 2026 19:57:38 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294353
Michael Osipov <michaelo@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |Open
Assignee|bugs@FreeBSD.org |michaelo@FreeBSD.org
--- Comment #2 from Michael Osipov <michaelo@FreeBSD.org> ---
Created attachment 274705
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=274705&action=edit
Git-formatted patch
Patch tested on two machines, results confirm the fix.
Patched mfiutil(8)/mrsasutil(8) to display and parse the Exx:Syy drive location
notation using the enclosure's Device ID (encl_device_id) instead of its
firmware-internal position index (encl_index), aligning with Broadcom's own
storcli64 numbering.
Machine 1 — deblndw014x (AVAGO Thunderbolt SAS controller):
Before patch: mrsasutil show drives showed E1:Sxx for all 12 drives.
After patch:
4 ( 279G) JBOD <SEAGATE ST9300653SS 5301 serial=6XN1LGJJ @#87980> SAS
E16:S13
5 ( 838G) JBOD <SEAGATE ST9900805SS 5101 serial=6XS2W2A9> SAS E16:S0
6 ( 838G) JBOD <SEAGATE ST9900805SS 5101 serial=6XS2W2CT> SAS E16:S1
Compare with storcli64 /c0 show all — PD LIST:
------------------------------------------------------------------------------
EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp Type
------------------------------------------------------------------------------
16:13 4 JBOD - 279.396 GB SAS HDD N N 512B ST9300653SS U -
16:0 5 JBOD - 838.363 GB SAS HDD N N 512B ST9900805SS U -
16:1 6 JBOD - 838.363 GB SAS HDD N N 512B ST9900805SS U -
------------------------------------------------------------------------------
EID:Slt matches E<N>:S<M> exactly. Slot numbers were already correct before the
patch and remain unchanged.
Machine 2 — denbgvo010 (HPE MR408i-o Gen11):
Before patch: E1:Sxx for all 8 drives.
After patch:
0 ( 279G) ONLINE <HPE EG000300JWSJP HPD6 serial=Y532A0E9FJSL> SCSI-6 E252:S1
1 ( 2236G) ONLINE <HPE EG002400JXLWC HPDB serial=WBMAHAQ0> SCSI-6 E252:S3
Compare with storcli64 /c0 show all — PD LIST:
-----------------------------------------------------------------------------
EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp Type
-----------------------------------------------------------------------------
252:1 0 Onln - 300.00 GB SAS HDD N N 512B EG000300JWSJP U JBOD
252:3 1 Onln - 2.40 TB SAS HDD N N 512B EG002400JXLWC U JBOD
-----------------------------------------------------------------------------
Again an exact match. Additionally confirmed independently via dmesg on this
box, which shows the VirtualSES enclosure's own SCSI target ID as 0xfc (= 252
decimal):
mrsas0: System PD created target ID: 0xfc
ses0 at mrsas0 bus 1 scbus1 target 252 lun 0
This confirms encl_device_id is pulling a real, independently-verifiable
firmware/SCSI target identifier, not an arbitrary value.
Conclusion: across two different controllers/firmware families (a
plain-passthrough AVAGO SAS HBA and an HPE-branded MegaRAID RAID controller),
the patched output now matches Broadcom's own storcli64 enclosure numbering
exactly, on both the enclosure ID and slot number. Slot numbering was never
ambiguous and remains untouched by this patch.
Patch is scoped to usr.sbin/mfiutil/mfi_drive.c (mfi_drive_name() display,
mfi_lookup_drive() input parsing) — no kernel/driver changes required, since
both encl_device_id and encl_index were already fetched from firmware; only the
field selected for display/matching changed.
Note: this is a user-visible behavior change (the numeric value of Exx differs
from before on enclosures where EID and position index don't match), so it
targets main/current only and is not being proposed for backport to stable
branches.
--
You are receiving this mail because:
You are the assignee for the bug.