Link Copied
Thank you, @DmitryKh. I've since learned a bit more about the issue by observing the btmon output when the error occurred. In one of your earlier posts, you mentioned this:
After ~1 hour of successful receiving of the packets (each one contains 22-25 bytes of "manufacturer-specific data") this is what I can see in the logs:
HCI_VENDOR_EVENT[0x87]: 878003010100070107061c00000000741611005e000880000207007416110000000000000000000514005f0180761611001ec91300da3414001ec9130043104ac11300c0ed110038203dc141204220
I'm getting the exact same event, but btmon decoded it better. As you can see in the picture I've pasted below, it looks like the "0x87" isn't actually the vendor event, but the first byte in the two-byte vendor prefix for intel (0x8780). The next byte, 0x03, apparently represents "Intel Extended Telemetry", followed by an Extended Event Type (0x01), an unknown 0x01 (maybe a length field?), then a 0x00 which means "System Exception", some sub-event 0x07, and so on. The chain of events went as so: Read request on characteristic, 2 seconds later the Intel chip reported a "Soft software reset" with the Reset reason being a "System Exception", followed by this "Extended telemetry" which only Intel can likely decode, followed by the Hardware Error 0x0c.
Unlike in your case, where you're only listening for advertisements, our sensors require actual connections. But our sensors switch between LE 1M and LE CODED PHY, perhaps that's a common factor?
After reading an attached output in one of your earlier posts, I noticed you were using a Compulab gateway. Coincidentally, we use the Compulab IOT-GATE-IMX8PLUS, which has the AX210. If you don't mind me asking, did you request the new M.2 card in the same Compulab device? If so, how difficult/expensive was it to make this change? (Feel free to email me at mbllarena@simbex.com - it seems our projects are similar)
@AlfredoS_Intel I'm a bit disappointed, though not surprised, with how apathetic and unconcerned Intel's support seems to be. It took 8 days to review a trivial hciconfig and dmesg output and the only outcome was a suggestion to check rfkill and try a Bluetooth mouse? The original poster's first message stated that "after a couple of hours BT adapter (hci0) begins to report "network is down" and becomes unusable" - if rfkill was in effect, the adapter never would've worked for hours in the first place, and the reported hardware error wouldn't be received from the AX210. The suggestion to try a Bluetooth mouse is also irrelevant - OP stated that the error occurs while scanning: no connections are active. All other suggestions: "update firmware, update OS, update BIOS" - it's all just throwing things at the wall and seeing what sticks. No direction towards an actionable solution, such as a documented bug or patch that explicitly involves this issue. But perhaps the most disappointing part of this thread is when OP stated that they were "very close to the decision to abandon Intel-based cards in favour of another vendor", which was immediately met with the uncaring concession:
"I understand your decision regarding on how you will move forward with your project or planned configuration. Thank you for appreciating our effort and for choosing Intel."
The irony is lost here. They are quite literally not choosing Intel... Because their issue cannot be resolved.... Most vendors would do everything in their power to prevent losing customers, apparently Intel just does not care and would even agree with a customer's decision to use another vendor because it's not worth their time as a multi-billion dollar company.
I'd like to believe that Intel can prove me wrong, starting by responding to the same, unanswered question asked by Dmitry in November 2024. What does this vendor-specific error mean and how can we prevent it?
