Fenvi T919 Bluetooth Disabled on Monterey

[Jaws3]

I’ve been having an intermittent (now fairly constant) issue since updating to Monterey months ago, where Bluetooth becomes disabled upon boot in Monterey. The on/off toggle doesn’t do anything. Reboots, NVRAM, and BIOS resets don’t fix it. The only thing that seems to work is physically removing and reinserting the PCI card. Once this is done, it’s typically enabled and works natively and flawlessly in Monterey, and will continue to work through shutdowns and reboots until it doesn’t again. Fenvi wifi has always worked flawlessly, and continues to work when the Bluetooth is disabled. I have no idea why this is occurring, but would love to be able to fix it. Does anyone know what might be going on?

Some more information:

• Fenvi T919 Wifi/Bluetooth card - ASRock X570 Taichi (internal Intel BT disabled in Bios)
• Issue occurs with custom USB mapping and generic USB map
• When BT works, everything works flawlessly and natively, without kexts. AirDrop, Universal Control, and Apple Watch Unlock all work.
• Wifi never stops working, even when BT is disabled.
• Fenvi BT is connected via USB header. I have tried different headers, and it doesn’t fix it. Reconnecting the USB header without removing the PCI card too doesn’t fix it.
• The only thing that I have found to re-enable the card natively, without additional kexts, is to remove and reinsert the Fenvi PCI card. It doesn’t matter if the USB header is reinserted. Everything works flawlessly after doing this, until it doesn’t for whatever reason.
• When Bluetooth works natively, one of the things that seems to de-enable it indefinitely is a power cut (unplugging the computer or turning off the PSU).
• This has occurred across months of OpenCore updates, so it isn’t a new config issue.
• Enabling the BlueToolFixup kext will enable BT without a PCI reinsertion, but MacOS sees it as a “third-party dongle” and it doesn’t work as well as natively (AppleWatch unlock won’t work). The kext shouldnt be necessary.
• The fact BlueToolFixup will re-enable BT, along with Wifi never stopping, tells me there is no physical issue with the Fenvi card, PCI port, or hardware.

I do not understand why a PCI reinsertion will cause MacOS to pick up the BT card as native again, especially considering it’s connected via USB header. It seems there is something going on with Monterey’s ability to recognize the board as being native, and thus enabling it - and whatever this is, a power cut can interrupt it. Considering BlueToolFixup will re-enable the card without an PCI reinsertion, and wifi never stops working, I don’t think there is a hardware issue. I also don’t think there is a USB mapping issue. Does anyone have any idea what is going on or how to fix it?

 

[Jaws3]

When bluetooth is disabled and not working, Apple System Profiler lists the bluetooth controller as (it appears to 'see' it, but won't enable it):

Bluetooth Controller:​

Address: NULL​

State: Off​

Chipset: BCM_4350C2​

Discoverable: Off​

Firmware Version: v0 c0​

Product ID: 0x0001​

Supported services: 0x382039 < HFP AVRCP A2DP HID Braille AACP GATT Serial >​

Transport: UART​

Vendor ID: 0x004C (Apple)​

 

[baronerosso]

I also had the same problem and solved it using IntelBluetoothFirmware.kext

 

[Jaws3]

I also had the same problem and solved it using IntelBluetoothFirmware.kext

I'm not using the built-in Intel bluetooth in the X570 Taichi, so I don't understand why using the IntelBluetoothFirmware.kext would have anything to do the with Fenvi T919 card with a Broadcom bluetooth chip that's natively supported by MacOS? I have the BT radio disabled in BIOS. Unless the BIOS is not fully disabling it, even though it says "disabled."

 

[Galve2000]

The only thing that I have found to re-enable the card natively, without additional kexts, is to remove and reinsert the Fenvi PCI card. It doesn’t matter if the USB header is reinserted. Everything works flawlessly after doing this, until it doesn’t for whatever reason.

My motherboard doesn't have a PCIx1 slot. So I have the Fenvi T919 seated in the last x4 slot. when I seat the card in such a way that I can screw the backplate properly, Wifi is not recognized. (this may be also true of BT, but its been so long since I have troubleshooted this, that I don't recall at the moment)

When I seat the card in such a way that it looks like it is partially hanging out of the slot and screwing in the backplate is impossible, everything works flawlessly. it's not ideal, but at least it works.

try reseating the card and not screwing it in. see how long your BT uptime lasts.

I may be wrong here, but i suspect that the BT portion of the card gets power from the PCI header as well as the USB header.

 

[Jaws3]

My motherboard doesn't have a PCIx1 slot. So I have the Fenvi T919 seated in the last x4 slot. when I seat the card in such a way that I can screw the backplate properly, Wifi is not recognized. (this may be also true of BT, but its been so long since I have troubleshooted this, that I don't recall at the moment)

When I seat the card in such a way that it looks like it is partially hanging out of the slot and screwing in the backplate is impossible, everything works flawlessly. it's not ideal, but at least it works.

try reseating the card and not screwing it in. see how long your BT uptime lasts.

I may be wrong here, but i suspect that the BT portion of the card gets power from the PCI header as well as the USB header.

My first thought was a bad or loose PCI connection, hence why reseating it fixed things. I’ve tried both screwed in to the case and not. However, if this is true, then why does the BluetoolFixup.kext renable the Fenvi Bluetooth without touching the PCI card (and it works fine, just without the aux things like Apple Watch unlock)? And i would think wifi would have issues if there was a bad PCI connection, yet it has always worked flawlessly, and even when it’s disabled, MacOS still sees the Bluetooth adapter, but won’t enable it. I can also use it fine booted into Linux and Windows. So I don’t really think it’s a PCI connection issue. I had used this Fenvi card with the same motherboard and case, and never had this issue pop up until Monterey, and I know a lot of the Monterey Bluetooth stack code was changed.

I have absolutely no idea what is going on, but my hunch at this point is there is some NVRAM type thing that is responsible for MacOS Monterey to recognize the card natively. This gets reset when the PCI card is reinserted, hence recognition. But something clears or alters this, hence it becoming disabled. Maybe there is some new genuine check being performed that clears it. Maybe it’s a power cut or booting into Windows or Linux? Or something with OpenCore? I’m really not sure. But once whatever it is gets cleared or corrupted, Monterey won’t re-enable the Bluetooth, and the only way I have found to get it to work is reinserting the PCI card OR enabling BlueToolFixup without additional firmware files for “non-native” support.

I know a lot of people use the Fenvi T919, so I’m surprised if this is a widespread issue, I haven’t seen anything more about it. Perhaps it has to do with my individual configuration, but I can’t figure out what that might be.

 

[Edhawk]

Could be an issue with the USB port you are using to connect the BCM Bluetooth module. Might be that Monterey is inadvertently dropping/not activating the USB port for the Bluetooth USB device.

Do you have a USBMap.kext or similar USB configuration for your system?

How have you configured the Bluetooth module port, should be set with connector type Internal (255).

If you have an Intel WIFI/BT card installed as well as the Broadcom card, you shouldn't include the USB port for the Intel Bluetooth in your USBMap.kext.

 

[Jaws3]

Could be an issue with the USB port you are using to connect the BCM Bluetooth module. Might be that Monterey is inadvertently dropping/not activating the USB port for the Bluetooth USB device.

Do you have a USBMap.kext or similar USB configuration for your system?

How have you configured the Bluetooth module port, should be set with connector type Internal (255).

If you have an Intel WIFI/BT card installed as well as the Broadcom card, you shouldn't include the USB port for the Intel Bluetooth in your USBMap.kext.

I've tried different internal USB headers and it doesn't make a difference. I have a USBMap.kext. A bluetooth module showed up while mapping, which I assumed was the Fenvi/Broadcom. It didn't specify. Only one bluetooth module appeared. I have the built-in Intel BT radio turned off in BIOS settings. In MacOS, a bluetooth search in IORegistryExplorer only shows the Broadcom. It is set to type internal in the USB map.

 

[Galve2000]

you should remove the BluetoolFixup.kext from your config.plist and OC folder. then reseat the card and see how long BT uptime lasts for. the Fenvi T919 works in Monterey without any patching or kexts.

 

[Jaws3]

you should remove the BluetoolFixup.kext from your config.plist and OC folder. then reseat the card and see how long BT uptime lasts for. the Fenvi T919 works in Monterey without any patching or kexts.

I don't leave bluetoolfixup.kext enabled. I use the Fence natively without any kexts. I was just saying that enabling the kext causes the Fenvi bluetooth to be seen, enabled, and working again when it's disabled natively for whatever the reason.

Is it necessary to remove disabled kexts from the OpenCore EFI folders when they are disabled in the config?

 

[Galve2000]

I don't leave bluetoolfixup.kext enabled. I use the Fence natively without any kexts. I was just saying that enabling the kext causes the Fenvi bluetooth to be seen, enabled, and working again when it's disabled natively for whatever the reason.

Is it necessary to remove disabled kexts from the OpenCore EFI folders when they are disabled in the config?

I'm not sure it's necesary, but it is certainly best practice.

 

[Jaws3]

Update: I have confirmed that a power loss, such as unplugging or switching off the PSU, causes the Fenvi T919 bluetooth to be disabled upon MacOS boot. It can still be seen in MacOS, it's just disabled. Works fine in Linux and Windows with appropriate drivers. Removing and reinserting the PCI card causes MacOS to recognize the bluetooth again, and everything works flawlessly. I've just had a week uptime with the bluetooth through multiple shutdowns, reboots, boots into Linux and Windows, and everything kept working until I unplugged the machine.

So what could be causing this, and is there a way to fix it? Has anyone else experienced anything like this? It seems like there might be some NVRAM-sort of detection of the chip that gets lost when the power gets cut.