[Bug 284050] mrsasutil(8) "show volumes" command triggers multiple kernel messages

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284050

--- Comment #11 from Terry Kennedy <terry-freebsd@glaver.org> ---
(In reply to Doug Ambrisko from comment #10)
True.

The kernel definitely knows the mapping (from dmesg.boot):

da0 at mrsas0 bus 0 scbus0 target 0 lun 0
da1 at mrsas0 bus 0 scbus0 target 1 lun 0
da2 at mrsas0 bus 0 scbus0 target 2 lun 0
da3 at mrsas0 bus 0 scbus0 target 3 lun 0
da4 at mrsas0 bus 0 scbus0 target 4 lun 0

Obviously, we can't blithely assume that mrsas volume 0 is /dev/da0, because it
depends on what else is in the device tree and the order of probing those
devices.

Is this info held somewhere that either the mrsas driver or mrsasutil utility
can fetch it from? Ideally it would be in the mrsas driver, so that any other
utility / application that wants to get the device name of a mrsas volume can
do so, using the same methods that work for mfi. That would also cause the
least changes in mrsasutil, since it seems to be built from the same source
code as mfiutil.

I did some reading in the architecture handbook but couldn't figure out if
mrsas gets the actual /dev/daX names back when it registers the volumes through
CAM, or even if that's mrsas's job - maybe once it provides a controller to
CAM, CAM handles probing the controller for devices?

If this is all too complex, maybe mfiutil could check if it was invoked as
mrsasutil and just print the volume numbers as reported by the controller,
without trying to find out the actual device name? That might prevent the
current situation of asking the driver for data that doesn't exist and
triggering these kernel messages.

---

As an unrelated issue (let me know if you want me to PR it separately), when
mrsas enumerates disks to CAM, it apparently passes a constant speed of
150MB/s. I don't think that information is easily obtainable from the
controller, so it just makes up a plausible (for that era) speed and a serial
number from somewhere (where the first 6 bytes are unique and the last 10 bytes
are constant, at least for any given controller):

da0 at mrsas0 bus 0 scbus0 target 0 lun 0
da0: <DELL PERC H730 Mini 4.30> Fixed Direct Access SPC-3 SCSI device
da0: Serial Number 009f16ab082653142f00fdd86ba06d86
da0: 150.000MB/s transfers
da0: 762496MB (1561591808 512 byte sectors)

The speed is coming from

mrsas_cam.c:                    ccb->cpi.base_transfer_speed = 150000;

I don't see offhand where the serial number is coming from.

This causes a number of mailing list / forum posts about "My disks are faster
than that - why is it showing a slower speed?"

Is there a speed we can set this to (perhaps 0 or -1) that will cause the
kernel to omit the "daX: xMB/s transfers" line?

-- 
You are receiving this mail because:
You are the assignee for the bug.