Page MenuHomeFreeBSD

ThunderX WORKAROUND: enumerate only one slot for now
ClosedPublic

Authored by emaste on Sep 21 2015, 7:34 PM.

Details

Summary

From @wma_semihalf.com:

It looks that the problem with em0 is exactly the same which we faced on some other hw - the em card is detected 32 times, like it was present on every pci function on the bus which is connected to.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

emaste updated this revision to Diff 8869.Sep 21 2015, 7:34 PM
emaste retitled this revision from to ThunderX WORKAROUND: enumerate only one slot for now.
emaste updated this object.
emaste edited the test plan for this revision. (Show Details)
emaste added reviewers: wma_semihalf.com, andrew.
emaste added subscribers: jhb, kib, wma_semihalf.com.
emaste added a subscriber: arm64.
andrew edited edge metadata.Sep 21 2015, 8:48 PM

Would it make sense to make this configurable from loader?

In D3706#76485, @andrew wrote:

Would it make sense to make this configurable from loader?

It depends on what the underlying issue is, I think. We really need to just fix the underlying issue and I'd commit this hack temporarily to get the ThunderX at Sentex usable in the short term.

wma_semihalf.com accepted this revision.Sep 22 2015, 5:44 AM
wma_semihalf.com edited edge metadata.

I'm fine with that workaround. Also, don't think the configuration variable is necessary. I've just tested few cards and the em is not the only one prone to multi-enumeration. Let's leave it as is, we'll only loose the ability of using pcie switches in thuderx external pci, which is in fact an extremely rare scenario.
This week I'll try to at least check the generic pci to ensure it properly configures thunderx internal bridge.

This revision is now accepted and ready to land.Sep 22 2015, 5:44 AM
This revision was automatically updated to reflect the committed changes.
jhb added a comment.Sep 22 2015, 5:01 PM

It might be a bug in the PCI config space access. I.e. if you are hardcoding slot 0 in the MCFG access for some reason. Presumably if that were broken at the MCFG level you wouldn't be getting this far though. Is ARI (or something like it) enabled on the bridge by chance?

Good point, John. That would also explain why sriov-capable cards are working fine and do not require this hack. I'll look at ari configuration more closely.