Bug 219380
| Summary: | ath12k: bad interaction with ath11k - neither will work out of the box | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Mihai Moldovan (ionic) |
| Component: | network-wireless | Assignee: | drivers_network-wireless (drivers_network-wireless) |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
| Attachments: |
ath11k debug log on boot, initializing correctly.
ath12k being loaded after ath11k was loaded - and failing to initialize |
||
|
Description
Mihai Moldovan
2024-10-12 22:07:52 UTC
Thank you all the help, or for that matter even acknowledging the issue. Stellar. In any case, I've since upgraded to ath-202410221503, enabled debugging for ath11k, ath11k_pci, mhi, qmi-helpers, qrtr and qrtr-mhi and also blacklisted ath12k to get a defined good state at boot up time with just ath11k(_pci) being loaded and working. I'll include a full debug log after booting up with ath11k(_pci) only and then another log after loading up ath12k at a later time. As I already expected, and could confirm through additional debug info, the issue seems to be that uploading the firmware to the second card (in this case powered by ath12k, but I could also change the setup so that ath12k is loaded first and works and loading ath11k(_pci) later which fails) fails once the card enters AMSS/Mission Mode because the new QMI FW loading service is bound to both QMI sockets instead of "the right one" and the firmware probably sent to the "wrong" server, which means that the second card hangs in AMSS waiting for a firmware upload. (Subsequent kernel module unloads and reloads will result in the card failing to even reach the MHI POWER_ON state, because it's still waiting for a firmware upload and a reset is not taking it out of this mode. Unfortunately, the only way to reset the card is to remove power to its PCIe socket, which requires a complete shutdown (a reboot won't do). This, however, is an unrelated bug, I'm just pointing it out for posterity.) The interesting part is this: === [ T122] ath12k_pci 0000:01:00.0: mhi notify status reason MHI_CB_EE_MISSION_MODE [ T122] [122] qcom_mhi_qrtr mhi1_IPCR: Qualcomm MHI QRTR driver probed [ T535] [535] qrtr_ns_worker: QRTR_TYPE_NEW_SERVER: &sq = 00000000599df612, service = 69, instance = 257, node = 7, port = 1 [ T535] [535] lookup_notify: new = 1 [ T535] [535] lookup_notify: (hopefully for QRTR_TYPE_NEW_SERVER) qrtr_ns.sock = 00000000ca5b39c2, service = 69, instance = 257, node = 7, port = 1 [ T535] [535] lookup_notify: new = 1 [ T535] [535] lookup_notify: (hopefully for QRTR_TYPE_NEW_SERVER) qrtr_ns.sock = 00000000ca5b39c2, service = 69, instance = 257, node = 7, port = 1 [ T535] [535] lookup_notify: new = 1 [ T535] [535] lookup_notify: (hopefully for QRTR_TYPE_NEW_SERVER) qrtr_ns.sock = 00000000ca5b39c2, service = 69, instance = 257, node = 7, port = 1 [ T535] [535] qmi_recv_ctrl_pkt: received QRTR_TYPE_NEW_SERVER: qmi_handle = 000000000428dfc2, service = 69, instance = 257, node = 7, port = 1 [ T535] [535] qmi_recv_new_server: qmi_handle = 000000000428dfc2, service = 69, instance = 257, node = 7, port = 1 [ T535] ath11k_pci 0000:03:00.0: qmi wifi fw qmi service connected [ T535] [535] qmi_recv_ctrl_pkt: received QRTR_TYPE_NEW_SERVER: qmi_handle = 00000000a08def4c, service = 69, instance = 257, node = 7, port = 1 [ T535] [535] qmi_recv_new_server: qmi_handle = 00000000a08def4c, service = 69, instance = 257, node = 7, port = 1 [ T535] ath12k_pci 0000:01:00.0: qmi wifi fw qmi service connected [ T67] ath11k_pci 0000:03:00.0: qmi indication register request [ T67] ath11k_pci 0000:03:00.0: qmi host cap request [ T535] ath12k_pci 0000:01:00.0: no valid response from PHY capability, choose default num_phy 2 [ T535] ath12k_pci 0000:01:00.0: qmi about to send indication register request [ T67] ath11k_pci 0000:03:00.0: host capability request failed: 1 90 [ T67] ath11k_pci 0000:03:00.0: failed to send qmi host cap: -22 === qmi_handle = 428dfc2 is associated with the ath11k-based card, while qmi_handle = a08def4c is associated with the ath12k-based card. Unfortunately, ath11k binds the FW service before ath12k, so ath12k initialization will get stuck indefinitely. Knowing that is great, but I still have to figure out how qrtr routes the packets to the actual QMI handles... and then find a way to figure out how to send packets on to the correct QMI handle only. Created attachment 307053 [details]
ath11k debug log on boot, initializing correctly.
Created attachment 307054 [details]
ath12k being loaded after ath11k was loaded - and failing to initialize
Essentially a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=218480, closing. If you feel like it's not a duplicate, feel free to reopen. *** This bug has been marked as a duplicate of bug 218480 *** |