USB port map issue with internal designation.

[zearp]

USB port map issue with internal designation.

[zearp]

I really have no idea but there's a lot of going on under the hood. Maybe it does make some kind of hwid based on components and if something changes it freaks out a bit.

Could also be a "bug" or something cuz it should't throw such errors around willy nilly. Some people might think they get data loss or have some kind of big problem while it's probingly nothing at all.

I've had one maybe once or twice in my hacks and they went away on their own and never came back. I was not able to find a way to reproduce it as I don't even know what caused them in the first place lol.

On very old macOS versions it used to show a bomb with a lit fuse in their error messages with a number you had to look up in a paper manual. Some scare tactics probably work to keep some people from doing silly or stupid things. The old Macs are fun to tinker with though. Very open hardware and such at the time!

[mgrimace]

USBports.kext:

Hackintool:

[mgrimace]

Oh, I might be oblivious: Hackintool starts numbering its ports with HS03, while the kext starts at HS01. By this logic HS09 in Hackintool should correspond to HS07 in the kext. I'll do some testing and report back.

[mgrimace]

Ok that fixed the internal designation. I have been successfully using handoff and other wifi/bt features purely by luck for the better part of what... a year or more now? This might also explain why that front port occasionally generates a crash when I plug in a peripheral. The numbering discrepancy between the kext and hackintool might be worth adding to the USB port map portion of the guide (unless this is a quirk unique to me).

Next, I'm going to test and see if this internal/external thing has any bearing on the hash mismatch errors that were vaguely related to BT previously (which didn't make sense, but if it's something internal/external that might make more sense). I'll report back those findings, but won't mess around with it until later today.

[zearp]

That is very weird indeed. I was planning on re-doing the usb map using a different method that also maps companion ports. This means a port that can do usb2 and usb3 will be labeled twice as usb 3. I did this on my NUC, not sure if I've done here as well already. I might have done it already.

This type of map is very rigid though, they map psychical ports so not much that can go wrong. Maybe Hackintool is not reading it properly for some reason, unlikely though.

I don't have access to my Dell machines at the moment as I'm away for work and then holiday but when I get back home in 2 weeks I will have a look at it and see whats what.

I use the same as you in my media Dell, Broadcom routed to the outside and mapped that port as internal. So our cases are pretty much identical maybe apart from the Broadcom card used. I use an Apple Airport card on a pci-e converter card but the end resulting the same as a Fenvi does. They also use the exact same Broadcom chipsets that Apple uses right?

You could try booting into Windows and make a new map using the USBToolBox tool. It can create a few kinds, I made the kind that uses 1 kext only, it can also generate some different kext that needs a helper kext too.

https://github.com/USBToolBox

There's a tool and a kext, I've used the tool in Windows to make a map that doesn't need their helper kext. I tried both methods and there was no difference so I went for the one with the least additional files.

(The end result was the same as the map I made with Hackintool ages ago but slightly nicer formatted and it uses the companion ports which is supposed to be a good thing.)

There is also USBMap but when I tried that it was using some kind of blinking and scrolling in the terminal that gave me a nasty headache.

https://github.com/corpnewt/USBMap

[zearp]

You're right about the numbering being off. It might not matter as it's just a naming thing and all 10 usb 2 ports are defined in there. I do wonder if making a new map with the latest software or manually fixing the numbers to start at HS03 and end at HS12 would fix your issue. I use the same map though and I have no issues.

https://github.com/zearp/OptiHack/blob/master/EFI/OC/Kexts/USBPorts.kext/Contents/Info.plist

Companion ports are done in that map. You can see the usb 2 speed only ports have a 0 and all ports that capable of both have a 3.

Let me know if having the numbering match with what Hackintool thinks the ports are helps. I wonder why it starts at HS03 and not whats defined in the map. I'll run a test and see if I change the ports to some higher number if Hackintool matches the map or displays what it thinks it sees.

[zearp]

To experiment I've changed HS01 to HS99 in my map, I will reboot now and then start Hackintool, remove all the ports from the list and refresh to see what it finds. I am curious if it remains HS01 or becomes HS99 as I specified in the map.

[zearp]

As expected it is really just a naming thing. You could probably call them ZZ01 etc and it'll show up like that. Did you select all the ports in Hackintool and removed them with the big minus button and then clicked the refresh button? I needed to do that before HS9 showed up. It shows a cache of the last known ports when you start it. It must be manually refreshed.

[mgrimace]

I do wonder if making a new map with the latest software or manually fixing the numbers to start at HS03 and end at HS12 would fix your issue. I use the same map though and I have no issues.

It did! While it showed as HS09 in Hackintool, I changed HS07 in the kext and the card is now correctly showing as connected to an internal port. Specifically, the card shows up as a BRCM20702 Hub, and it is connected via internal in Hackintool. It still shows the internal port as HS09 in Hackintool, while the kext is HS07 but it is truly just is the difference in numbering starting from HS01 vs., HS03 between the two.

[mgrimace]

Did you select all the ports in Hackintool and removed them with the big minus button and then clicked the refresh button? I needed to do that before HS9 showed up. It shows a cache of the last known ports when you start it. It must be manually refreshed.

Yes, hitting minus then the refresh icon fixed the numbering/naming to be consistent with the kext! Good call there. I set this up forever ago so I may very well have missed that step, then never noticed all this time until I started plugging in USB sticks recently!

[zearp]

Hackintool should display whatever you put in the map as my little experiment showed. If it shows something else it is Hackintool's fault and was probably displaying the cache of the last time the usb page was opened. The cache thing is annoying and confusing. It has become muscle memory for me to select all the ports, delete them and click refresh whenever I need to check something usb related in Hackintool. The behaviour is by design thought, for making usb maps but it can cause some confusion! An option to always refresh the usb tab when opened would be nice once you have map.

[mgrimace]

If it shows something else it is Hackintool's fault and was probably displaying the cache of the last time the usb page was opened. The cache thing is annoying and confusing.

I think that's exactly it, and it's definitely in the instruction steps to do the minus then refresh cycle when first creating the map. I think what happened for me was that I added the card much later, so it was likely that I didn't notice the discrepancy and just chugged along with a quick glance at the port in Hackintool. Best practice would be to do the minus-refresh cycle each time I check the ports. Fixed now!

[mgrimace]

Ok, remember how I drew a tenuous linkage between my hash mismatch errors and bluetooth? Even though bluetooth wouldn't make sense logically? Well well well, I think this is the culprit.

So after OC 0.80 or so, I started getting hash mismatches. It didn't happen in earlier versions for some reason, and I know that the hash mismatch thing also happens mysteriously on stock Macs. That being said, it seemed related to bluetooth, for no discernable reason (e.g., when engaging with bluetooth it would trigger the error).

Now it turns out that I have an internal card providing wireless and bluetooth with a data cable running to an external port. That external port should appear to the system as internal, but I labelled it wrong in the kext so it was connecting to an externally-labelled port.

On real Macs, as best as I can understand, the hash error would show up if something corrupts the Sealed System Volume. So, my best explanation for the error is that the system thought bluetooth had been tampered with. It should not appear as connected externally to a mac mini, which perhaps triggered that hardware system element as corrupted.

This is entirely speculation, but after fixing the internal designation for the bluetooth USB, and running the newest test EFI I now have zero errors!

[mgrimace]

Ok, another random finding re. hash-mismatch. In the Dortania guide on the subject of hash-mismatch (link) they suggest:

"Additionally, it can help to disable FeatureUnlock in Settings -> Misc Settings as this tool can be strenuous on systems with weaker memory stability."

This is another thing I tried in my less-than-scientific investigations, especially since featureunlock relates to bluetooth use/access. In short, proper port-mapping (internal) + disabling FeatureUnlock seem to have stopped my hash error. I wonder if the error wasn't just triggered by bluetooth but by something relating to sidecar (e.g., bringin my iPad nearby, etc.). Pure speculation, but I figured worth keeping track.

Noting the whole 'strenuous' comment, I wonder if it might also be generally useful to disable the featureunlock.kext if sidecare features are not used to improve system stability/performance (?).

[zearp]

Additionally, it can help to disable FeatureUnlock in Settings -> Misc Settings as this tool can be strenuous on systems with weaker memory stability.

I have no idea what tool they are referring to. Where can I find these settings? all I know is thats its a kext to get some features to work like AirPlay receiving an such. I am not aware of any utility with those settings. The page doesn't mention what tool they mean.

You can always try to disable a kext and see if it helps, I need it to have all macOS features available. But if you don't use such features you can disable the kext though I don't think it would cause any issues. The guide is very unclear what they mean with weaker memory stability and that page is a misc section of all kinds of things. If your memory isn't stable you'd get crashes all the time.

This might be a red herring. The whole mismatch thing is harmless and a known bug. Unless you experience crashes I wouldn't worry about it!