Closed kroeckx closed 3 years ago
I can confirm getting much the same errors, firmware crash, reset, etc... using a BT-HomeHub-v5-Type-A with the same OpenWRT 21.02SNAPSHOT with same ath10k firmware CT as well. I also have older logs from running older 'master' build of OpenWRT from January without issue I believe. I would like to provide more info / collect more debugging from console(serial)-log and syslog, if I know what debugging to turn on and what to get // what would be worthwhile....
I cannot make progress on firmware crashes that are for this reason: [ 3702.764066] ath10k_pci 0000:00:00.0: Cannot communicate with firmware, previous wmi cmds: 40859:849904 36904:849785 36904:849780 36904:849775, jiffies: 850688, attempting to fake crash and restart firmware, dev-flags: 0x42 The firmware stopped responding to the driver, so driver fakes a crash to recover. That is likely as good as I can do. In case those wmi-cmds are always the same in your crashes, just possibly they provide a clue, but I have dug through that code for weeks at a time with not much progress over the years...
Note that my dmesg contains 2 such crashes:
ath10k_pci 0000:00:00.0: Cannot communicate with firmware, previous wmi cmds: 36904:353754 36954:353752 36904:353749 36952:353584, jiffies: 354560, attempting to fake crash and restart firmware, dev-flags: 0x42
ath10k_pci 0000:00:00.0: Cannot communicate with firmware, previous wmi cmds: 40859:849904 36904:849785 36904:849780 36904:849775, jiffies: 850688, attempting to fake crash and restart firmware, dev-flags: 0x42
They don't seem to have anything in common.
I've now switched that device to non-ct, and it works without problems so far.
Should any firmware version work with the driver I have? If @SimonIremonger can say which firmware version worked I can try to do a bisect, but I guess it will be slow since it's takes time to reproduce.
I might have misunderstand what's in this git repo. I now think it's only the driver, not the firmware.
The wave-1 CT firmware is based on a pretty old upstream firmware, and all of it is closed source. If QCA firmware works better for you then, that is probably best. The ath10k-ct driver should work fine with upstream QCA firmware, but the stock ath10k driver may work fine for you as well.
@greearb I see a possible approach to switch ath10k-ct beacon mode to "BURST". This mode should (I guess) avoid some timing or queuing issues in firmware.
Informal reports indicate issues here occurring into OpenWRT 21.02 rc (imminent release...) versions, informed users needing to switch to non -ct firmware. Will try to add some serial logging and debugging/monitoring to my ath10k-containing gadgets...
The -ct firmware for wave-2 is completely different beast from the wave-1 -ct firmware. Please be specific about what platform(s) and/or chipsets seem to have issues or not.
@greearb From what I know the UniFi AC Mesh has a rebranded QCA9886. Isn't that wave 2? Is it possible the wrong firmware was chosen for it or something?
9886 is wave-2. 9888 aka 988x is wave-1.
The original bug report was about wave-1, radio times out, and I don't know how to fix. The driver did recover the system after the radio became un-responsive. Closing this bug
I've recently upgraded my UniFi AC Mesh to OpenWRT 21.02 snapshot r15831-c74df745fd
After running a while, I had the following in dmesg: