LSI has been bought by Broadcom years ago and that employee is now with
Broadcom: https://lwn.net/Articles/841061/
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 65614 Build 62497: arc lint + arc unit
Event Timeline
No, they didn't, but I have already reached out to him via his broadcom.com address. Waiting for a reply.
Honestly, I prefer rather no email address rather than one that is not working.
Unless someone more senior weighs in then I think we should not touch this unless we hear from the author. They wrote this working for lsi and "lsi wrote it" and... Nuances.
I strongly dislike the authors section. I never use it, except when forced to (e.g. builtin(1) had AUTHORS so I couldn't remove it or leave it, out of respect to the listed author). It doesn't age well. After 20 years manuals usually barely resemble whatever the person who wrote their name in the AUTHORS wrote.
No response, I have added him to the reviewers and will try to reach out next week again.
What would be extremely helpful and needs to be done, especially for someone who has and knows this hardware, is fixing the HARDWARE section.
It gets pulled into the hardware release notes and it doesn't look good currently. I put a style guide in style.mdoc(5).
For consistency it'd be great to fix the SYNOPSIS too.
share/man/man4/mrsas.4 | ||
---|---|---|
106 | This is wrong | |
127 | Supports the following what, 12gb SAS? The specific connector type would be more helpful I think, since literal decades of SAS, the term alone is meaningless. | |
129 | These brackets render totally hideous and break the table in the hardware note. | |
152 | This list ending and another starting breaks the table too |
Let me give you guys background why I started this in the first place. We need a bunch of new servers from HPE which include MR408i-o RAID controller with Broadcom SAS3908 ROC for OEMs. I had a hell of a time to figure out which chip that it and which driver supports this card. Spent days. Hoped Broadcom would answer. What I have figured out that the PCI device IDs don't match the manpages (read outdated) and you have to read the source code. After a longer discussion with @eugen_grosbein.net on the Russian FreeBSD TG channel and Git archeology we figured out that @kadesai has added support many years ago (https://cgit.freebsd.org/src/commit/?id=2909aab4cfc296bcf83fa3e87ed41ed1f4244fea), but never touched the manpage. IMHO only Broadcom or @imp are able to properly update this manpage.
Did any see that flash of smoke or smell sulphur and brimstone just now? Oh, that's just me....
I responded to Michael in private just now. For posterity, my advice is to release the self-imposed vendor lock, they stopped officially supporting freebsd many years ago.
The "3908" nomenclature suggests MPR family, but the "ROC" suffix suggests MFI or MRSAS families. Broadcom blurred the lines here many years ago and I haven't had a secret decoder ring since 2018.
Best of luck
Well, at least all specsheets list FreeBSD 12.x+ as supported OS. Even the 14.x line.
The "3908" nomenclature suggests MPR family, but the "ROC" suffix suggests MFI or MRSAS families. Broadcom blurred the lines here many years ago and I haven't had a secret decoder ring since 2018.
It seems to be mrsas(4) as we idenfied from https://ubuntu.com/certified/202312-33276/24.04%20LTS with the device ID for the Areo family. Really really confusing what Broadcom is doing...
If the hardware falls into the MRSAS family then there's a better chance that it'll work with just a PCI ID addition to the driver. Doesn't hurt to try.
OK. The SAS3908 is the chip that powers several of the 9500 cards. Google results strongly suggest this is the MegaRaid version of their products. But of late the lines are somewhat blurred between the different lines, as Scott has said. I can't tell for sure which family this belongs to from the part number alone (although all the hits for SAS3908 have MegaRaid in them, and as has been pointed out, the Linux driver uses the mrsas attachment as well). I don't have a better decoder ring for these.
Yes, it's confusing. We have to live with it.
I agree with Scott that it wouldn't be too hard to add the PCI Ids and see what happens. My guess is that it will only kinda sorta work. The mrsas driver we have in tree is documented as working with the 9200 and 9300 series of cards (6G and 12G). The 9500 is a 24G board that adds support for NVMe connection as well (again, going off what Google has to say). When they did this to their other line, we went from the mps driver to the mpr driver. There were a lot of changes for the mpr driver, but it's very very close to the mps driver and the global query-replace hides a number of non-obvious differences where data structure sizes changes between MPI 2.5 and MPI 2.6. I have no access to the MRSAS family of firmware, nor its associated docs, so I can only speculate here.
mpr and mps haven't had a vendor update in a long time. the only bug fixes have come from users (like Netflix and iX). We're to the 'any sane changes accepted' level of support and I try to keep my eye on them. It doesn't look like the SAS3908 is used for them, though. I'd be happy to review any mrsas changes, but have no hardware and only a little time for HBA work.
There's also a new mpi3mr driver that we got from Broadcom for their 9600 series of cards. It works OK, but not great. There's support from Broadcom for this (in fact their latest driver release was just ported to FreeBSD and posted for review earlier in the week). Before I started googling, I thought this card might be one of those, but google strongly suggests not, as does its presence in the mrsas Linux driver.
I don't have access to non-public lists of Broadcom products, so can't help with that aspect of the problem.
You can ask Broadcom for the FreeBSD driver, though I fear it will just be a binary if its like their other cards. They ship binaries, but have generally tried to give back their changes to us. However, since the last 6 or so years, shakeups internally have meant things aren't so close anymore.