Page MenuHomeFreeBSD

Fix mpr device mapper fallback logic for busses with multiple expanders.
AbandonedPublic

Authored by asomers on Feb 16 2018, 9:32 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 17 2024, 7:19 AM
Unknown Object (File)
Dec 20 2023, 2:26 AM
Unknown Object (File)
Oct 13 2023, 4:31 PM
Unknown Object (File)
Sep 14 2023, 7:42 PM
Unknown Object (File)
Jun 18 2023, 4:28 PM
Unknown Object (File)
Mar 24 2023, 5:58 PM
Unknown Object (File)
Feb 1 2023, 5:18 PM
Unknown Object (File)
Jan 16 2023, 12:52 AM
Subscribers

Details

Reviewers
scottl
slm
Summary

Fix mpr device mapper fallback logic for busses with multiple expanders.

r308217 added fallback logic for mpr's device mapper, to be used in case the
card's nonvolatile mapping table is corrupt. The fallback logic simply uses a
device's phy number as its SCSI target id. But this doesn't work on SAS busses
with multiple expanders, because phy numbers are only unique per-expander.

Change the fallback logic to use a combination of the Enclosure Handle and
Slot.

Test Plan

Tested on several systems with corrupt drive mapping tables, each with a bus
that has two enclosures and 36 drives, plus another bus with one enclosure,
three expanders, and 97 drives.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 15092
Build 15185: arc lint + arc unit

Event Timeline

This is the change I mentioned at lunch on Wednesday. Would this fail for your setup? Is there something that could make it work for both of us? Perhaps different behavior based on whether use_phynum is 1 or 2?

slm requested changes to this revision.Feb 20 2018, 5:24 PM
slm added inline comments.
sys/dev/mpr/mpr_sas_lsi.c
846

'fallible'

864

Does this work for directly attached devices too, with no enclosures?

1296

Do you need to account for NVMe?

This revision now requires changes to proceed.Feb 20 2018, 5:24 PM
sys/dev/mpr/mpr_sas_lsi.c
864

Probably not.

1296

I don't know. Do I? I don't have any tri-mode hardware.

sys/dev/mpr/mpr_sas_lsi.c
864

It might work, but I guess it should be tested to be sure. I think the EnclosureHandle will be 1 for direct-attached devices. Can you explain why you're subtracting 1 here?

1296

I'm thinking we should handle them the same way.

sys/dev/mpr/mpr_sas_lsi.c
864

I'm subtracting one just to make the best use out of my 1024 available IDs. The first enclosure always has enclosure handle 1, not 0. The problem with directly-attached devices is that their Slot is probably 0. But I don't have any to test with.

1296

Do I need to make any changes for them?

sys/dev/mpr/mpr_sas_lsi.c
864

I was just concerned about an EnclosureHandle of 0, but that's an invalid value that shouldn't be returned and it's probably OK. The way it works is that the EnclosureHandle will be 1 for direct-attached devices and it represents a virtual Enclosure to the FW. I believe the Slot or Phy number should be valid, even for direct-attached devices. It's probably OK to leave it as is, and it will work. You can't attach any drives directly to test?

1296

You should be able to make the exact same changes here just to cover both device types. If you don't there might be confusion later if things are working for SAS but not NVMe.

I no longer have access to any hardware that can exercise this change. @slm do you want to commandeer the revision? Otherwise I'll abandon it.

sys/dev/mpr/mpr_sas_lsi.c
864

I don't think I have the right type of cables for direct attaching a drive. Everything I do uses expanders.

Abandoning the revision because I no longer have relevant hardware to develop on. @slm can commandeer the revision if he wants to.