Bug 212211 - mrsas (4) does not allow smartctl to access S.M.A.R.T data from physical drive hidden under /dev/daX
Summary: mrsas (4) does not allow smartctl to access S.M.A.R.T data from physical driv...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.3-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2016-08-28 10:56 UTC by Andrii Stesin
Modified: 2021-08-17 12:06 UTC (History)
8 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Andrii Stesin 2016-08-28 10:56:56 UTC
Given FreeBSD 10.3 system with LSI MegaRAID 9271-8i SATA/SAS RAID controller.

Recommended (and supported) driver for this newer controller is mrsas (4). mrsas (4) provides OS with virtual drives /dev/daXX - although I found that /dev/passX devices are also created for whatever purpose (/dev/daN has corresponding /dev/passN) in case it matters.

Each /dev/daXX hides some (1 or more) physical SAS/SATA drives hidden under it. Using MegaCLI utility, you can list PDs which of these are located by:

- either with a pair of values [EnclosureID:SlotID],
- or with the "device ID" which LSI MegaRAID somehow assigns to them.

I have fresh actual smartmontools installed:

smartctl 6.5 2016-05-07 r4318 [FreeBSD 10.3-STABLE amd64] (local build)

I want to get S.M.A.R.T. status of any physical drive attached to MegaRAID, i.e. of an SSD which MegaRAID assigned device ID is 12, and it is hidden under /dev/da0 virtual drive. But what I actually get:

[root@chort /]# smartctl -a /dev/da0
smartctl 6.5 2016-05-07 r4318 [FreeBSD 10.3-STABLE amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
Vendor: LSI
Product: MR9271-8i
Revision: 3.46
User Capacity: 199,481,098,240 bytes [199 GB]
Logical block size: 512 bytes
Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
[root@chort /]# 

Ok, I understand: /dev/da0 is not a physical drive, maybe it's a striped array of 2 drives, smartctl gets confused, this is expected behavior.

Looking deeper, I discovered, that Linux version of smartctl is aware of this situation, it allows the following syntax, where "-d megaraid,12" should tell that we are dealing with LSI MegaRAID and we actually want to question the disk with "device ID" 12. Tried with Ubuntu live CD, it actually works well.

But on FreeBSD this mode is not supported:

[root@chort /]# smartctl -a -d megaraid,12 /dev/da0
smartctl 6.5 2016-05-07 r4318 [FreeBSD 10.3-STABLE amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
/dev/da0: Unknown device type 'megaraid,12'
=======> VALID ARGUMENTS ARE: ata, scsi, nvme[,NSID], sat[,auto][,N][+TYPE], usbcypress[,X], usbjmicron[,p][,x][,N], usbprolific, usbsunplus, 3ware,N, hpt,L/M/N, cciss,N, areca,N/E, atacam, auto, test <=======
Use smartctl -h to get a usage summary
[root@chort /]#

I already opened the ticket at https://www.smartmontools.org/ticket/734 but I think that a clarification is needed here: does mrsas (4) support this kind of queries at all, as of today?

Do we need some modifications to mrsas (4) in order to support the syntax like:

smartctl -a -d megaraid,12

or even better,

smartctl -a -d 'megaraid,[9:11'

or both? Or this is completely on the side of smartmontools? Thanks in advance!

Andrii Stesin
Comment 1 Andrii Stesin 2016-08-28 11:02:49 UTC
Sorry for misprint (missed bracket), I meant

smartctl -a -d 'megaraid,[9:11]'
Comment 2 Andrii Stesin 2016-08-28 21:06:02 UTC
BTW, while trying to reach AVAGO people who deal with mrsas (4) I opened the /usr/src/sys/dev/mrsas.c file, at line 4 it says: "Support: freebsdraid@avagotech.com" - this mail does not work, the mailbox is rejected by AVAGO. At the bottom of initial copyright message, there is another email listed: megaraidfbsd@avagotech.com and this one does not work either (also rejected).

Maybe AVAGO dropped FreeBSD support at all? Or what I am doing wrong?
Comment 3 Piotr Kubaj freebsd_committer 2016-08-29 12:55:53 UTC
I can confirm that sysutils/smartmontools doesn't work with mrsas(4). sysutils/storcli also doesn't work:
[root@gen ~/storcli_all_os/FreeBSD]# storcli /call show all
Status = Failure
Description = No Controller found

Using the newest storcli from AVAGO doesn't help:
[root@gen ~/storcli_all_os/FreeBSD]# ./storcli64 /call show all
Status = Failure
Description = No Controller found

Strangely, MegaCli works, but it doesn't provide enough functionality for me.
Comment 4 Oleksii Samorukov freebsd_committer 2017-10-12 18:31:53 UTC
Hi i am smartmontools developer. it should be possible to implement this functionality in the FreeBSD build. Please drop me a note in the ticket if you want to participate in testing.
Comment 5 Josh Paetzel freebsd_committer 2017-10-13 02:17:36 UTC
Yes, I'd be very interested in participating in testing.
Comment 6 Terry Kennedy 2019-08-11 04:47:59 UTC
Just posting to register my interest in this as well. 12-STABLE amd64 with a SAS3108 (Dell PERC H730) controller, just in case this PR has been languishing because it was filed against a no-longer-supported FreeBSD release.

The mfi driver package provided the mfip kernel module, which exposed each of the controller's drives as a passN device, regardless of configuration / array / etc. status.

With some newer controllers only supported by mrsas, and mfi being deprecated (or at least not suggested as the path to the future), FreeBSD needs functionality similar to mfip in order for smartmontools (and perhaps other software) to work on drives attached to a mrsas controller.

It looks like r342065 added a lot of the support needed for this to mrsas:

Perhaps someone more familiar with this driver could finish up adding passthru support? My company could contribute some reasonable funding (and test hardware) toward getting this implemented if necessary.
Comment 7 Oleksii Samorukov freebsd_committer 2019-10-02 15:40:56 UTC
Hi Terry. 

Please connect with me about adding this support, samm@os2.kiev.ua and samm@net-art.cz. I will need remote access to the hw
Comment 8 Mark Linimon freebsd_committer freebsd_triage 2021-05-12 20:09:06 UTC
^Triage: assignee has returned his bit for safekeeping.
Comment 9 henrime 2021-08-17 12:06:47 UTC
Still present today with 13.0-CURRENT