mt7921u pending tx #410
Comments
|
here is the next: |
|
Also seeing that in journalctl as well: Mar 28 22:22:52 hostname here kernel: mt7921u 1-1.4:1.3: timed out waiting for pending tx Seems to be associated with the random failure to forward packets issue I have seen over the past few weeks on mt7921u and mt7921k. Fortunately, this is mitigated by restarting hostapd most of the time, but very rarely I will need to full reboot the machine the mt7921 is attached to, too. I will try to come up with concrete steps to replicate the issue. |
|
After seeing the first message I have been keeping an eye open. It is clear that @fhteagle is in AP mode but it is not clear what mode @Simon566 is in. That would be good info to know. I have seen some errors like this when inadequate or failing power supplies were involved. I have a mt7921au based adapter in AP Mode on a Pi4B. It is running RasPiOS with kernel 6.6. I'm not seeing this. Can you go into more detail about:
|
|
Hi , its the same here. Im running AP mode on X86-64 hardware, running Debian Bookworm with latest kernel 6.6.23 and hostapd from git mainline. Having a single client doesnt seem to trigger the fault, even when using things like openspeedtest or similar sites. But when i put the AP into my real network with 10 clients , it fails within a day mostly. Using a rtl8812au AP runs for weeks at least before having some issues, also on USB hardware. regards, |
|
I cannot give a cause of the issue, nor how to reproduce reliably. Best pattern I can describe now is three general classes of failure, that may or may not be related:
All 3 failure modes can be cleared with ~95%+ success rate by a simple systemd restart of the hostapd service for that adapter. ~5% of the time I have to reboot to clear the failure mode. The pending tx journal message is most strongly associated with failure modes 2 and 3, but not perfectly correlated. I can have a mode 2 or mode 3 failure with or without the journal message. With the journal message, there will always be either mode 2 or mode 3 failure. Again, I'm running bleeding edge hostapd-git , so entirely possible this is the root cause. Behavior seen on arch x86_64 and aarch64 (raspberry pi 3b and 4b) hosts, using MT7921K (pci) and MT7921AU (usb) cards. Adapters are bridged, either via systemd/networkd config, or the bridge = option in hostapd.conf, with one or more ethernet NIC and other adapter device on each host. |
|
I've spent the past several hours trying to get to the bottom of this issue. The I added some debug log messages to trace the flow of command messages to/from the mt7921u chip. Setting up the chip takes several dozen command messages, as one might expect: (For brevity, I abridged the long runs of In the above log, you can see that some commands elicit replies from the MCU (the microcontroller in the mt7921 that is running the firmware), while other commands do not. This is very likely the expected operation of the protocol between the driver and the firmware. One thing does stand out to me as wrong, indicated by the line that says When I now connect my Android phone to the AP, the following command messages are logged: All appears well. The MCU has replied to the last At this point, I run Ookla Speedtest on my Android phone, a usage scenario that reliably kills the AP every time. Crucially, no additional command messages are logged during the speedtest or the hang that results from it. This suggests that the actual problem is triggered by a data message rather than by a command message. It is only when I attempt to bring down the interface, subsequent to the hang, that the driver notices a problem. There appear to be multiple failure modes at this point, depending on which particular command message the driver sends next when I run Failure mode 1: driver next sends
|
|
Hi @whitslack great troubleshooting. I learned a few things thanks to your comment but don't have a fix myself. I recently bought EDUP EP-AX1672 that use the same driver and I am getting the same pending tx errors which make the adapter unusable till hostapd restart. I wanted to add that until yesterday, I used it in AP mode on my desktop x86_64 using the latest archlinux kernel 6.10.6 without any issues. Then I tried my new raspberrypi 5 and that's when pending errors started. I suspect that it is something to do with the usb 3.0 root hub that can't handle both ports at high utilization( the other port is used for a usb<-> 1gbps ethernet). So this morning, I moved the ethernet adapter to one of the usb 2.0 ports and so far it seems fine ( speedtests, heavy transfer files). The rpi5 is also running archlinuxarm with the linux-rpi-16k kernel (currently 6.6.47-2). |
|
@gdluca: The problem is definitely not caused by USB 3. I can readily reproduce the hang with an mt7921u adapter plugged into a system that does not have any USB 3 controllers. |
|
@whitslack I see. Then mine will probably get errors again at some point.. Will try to do more tests in the weekend. |
|
The search continues. |
|
And here it is my second EDUP. Currently I am testing like this:
・SSD:nXXXXX - OLD EDUP on desktop
I was able to reproduce it again with the new EDUP afater ~322seconds of iperf3. Good at least now there is no impact on my remote job and I can test at the same time hehe. |
|
@gdluca: When your AP hangs, see if you can dump the queue states from the (This assumes you have I spent close to 12 hours this past weekend going through the mt76 USB code with a fine-toothed comb. I did find some places where the code makes some assumptions that don't strike me as obviously valid, and I also found an area where I believe there may be a race condition caused by the omission of needed memory barriers. It would be helpful to see a dump of those debug files taken while the driver is hung, as it could confirm my suspicion that the driver may be failing to wake up its kernel worker task despite a queue not being empty. I will also be dumping those files the next time my AP hangs, but you might beat me to it if I get lucky. |
|
For below queue results, I redid an iperf3, waited and the AP hung. There are no dmesg messages yet and I have not restarted hostapd. It is still in this situation so if you want more logs, I should be able to get them. |
|
@whitslack !! I waited I think 20 min (I am away from the pc but more or less) and the AP is back automatically!! Now I have dmesg errors Current queue status |
|
@gdluca: Thanks. I'll have to dig back into the driver code to remember what those numbers mean. No promises on when I'll get around to that. Can you also check your kernel log to see if the mt76 driver has complained about any URB mismatches? (It would appear before the message about pending tx.) |
|
before the pending tx, I have which is when I plugged in the adapter. |
|
Alright. There won't necessarily be a mismatched URB. I suspect that occurs due to an entirely separate problem in the code: namely, that the driver assumes that URB completion callbacks will execute serially despite that there is no guarantee (to my knowledge) that the kernel executes URB completion callbacks in a single tasklet thread. The mt76 driver takes care to synchronize access to its queue structures with a spinlock, but there is no guarantee about the order in which racing tasklet threads would enter the spinlock, so there is no guarantee that the driver will observe its submitted URBs to have completed in the same order as it submitted them. That the mt76 driver would implement its own URB queue from scratch strikes me as odd since the kernel already offers a standard Independent of the URB mismatch issue, I suspect that the mt76 driver code that manages the worker tasks that process the queues of completed URBs may have inadequate memory synchronization to ensure that a queue will always be serviced. It looks like there may be the possibility, with very low probability (but in multithreaded coding, anything that can happen will happen eventually), that a completed URB may be enqueued after the worker has already decided to go to sleep but before it has actually done so (and so the URB completion callback's attempt to awaken the worker does nothing since the worker is not yet asleep). The mt76 code does try to guard against this, but I believe it may be making invalid assumptions about CPU cache coherency. Again, it strikes me as odd that the mt76 driver attempts to roll its own queue worker implementation from scratch since the kernel already provides standard mechanisms for work queues. It kind of smells like whoever wrote the mt76 driver is a fairly decent programmer but one who isn't too experienced with coding within the Linux kernel and one who might not fully appreciate the need for memory barriers when writing thread synchronization code (which is why the kernel provides standard, battle-hardened implementations, because getting it right is tricky). |
|
I've been perusing the mt76 code some more…
These^ are the USB receive queues. They each show 128 URBs enqueued, which means that the driver has handed off 128 buffers to the USB subsystem to be filled with packets coming from the USB device, and none of those URBs have been completed, or in other words, the driver has received no packets from the hardware that the driver has not yet processed. This is good.
These^ are the USB transmit queues. While examining the transmit code paths, I found something that looks very bad and like it could potentially be causing nasty issues. In |
|
I can only appreciate your knowledge and dedication, @whitslack . I cannot read that code so thanks! |
Nope. I think it's a good fix, and I will submit it to the linux-wireless listserv, but it's not sufficient to cure our problem. The search continues. |
|
Another interesting observation: the MT7921AUN hardware advertises two USB inbound (device-to-host) bulk endpoints, ostensibly with the first being for normal network traffic and the second being for command responses from the microcontroller (MCU), yet the firmware actually only ever sends command responses on the first inbound bulk endpoint, mixed in with all the network traffic. The mt7921u driver is prepared to receive command responses on the second endpoint, but it never actually receives any, as all command responses from the MCU arrive on the first endpoint. I conjecture that command responses could be getting dropped if the first endpoint is overly busy with network traffic. This would manifest in exactly the scenario we are observing, where the driver times out while waiting to receive a response to a command that it has sent to the MCU. I posit that the MCU received the command, processed it, and tried to respond, but the response could not be enqueued to the first endpoint due to all the other traffic clogging it up. It may be telling that the mt7915 driver did recently receive a patch to retry sending commands to the MCU whenever a wait to receive a response times out. I am going to try porting that new functionality over to the mt7921u driver to see if it can work around the hang we're experiencing. Note, it will only be a workaround; the proper fix would be for the firmware to respond to commands on the second endpoint so its responses can't be drowned out by network traffic. |
Nope. The retry logic does activate, but by the time that happens, the chip is already out to lunch. In fact, an Ookla Speedtest on my phone can hang the AP without there being any command messages pending (and so none to timeout and hit the retry logic). After a while, HostAPd will time out the station association and try to remove the station from the AP, and that action does cause a command message to be sent to the MCU. Curiously, the USB subsystem confirms completion of that outbound URB, but then the mt7921u driver times out while awaiting a response from the MCU, at which point the new retry logic kicks in and attempts to retransmit the command, but then the USB subsystem times out the retry URB. That's a different kind of timeout: in the former case, the command URB completes, and the mt7921u driver subsequently times out while awaiting a command response message from the MCU, but in the latter case, the command URB does not complete, and so the mt7921u driver does not progress to the point of awaiting a command response. It is as though the the MCU accepts the first command for processing (and acknowledges receipt of that command) but then hangs while processing the command and so is unavailable to acknowledge any subsequent commands. Note, it is not the command that is causing the problem, as the chip is already buggered before the command is even sent to it. The MCU's failure to respond to the command is a symptom of the hung state that the chip is already in.
I augmented the Thinking that the high bandwidth of the speed test might be overrunning a queue or buffer in the chip and crashing the firmware, I tried reducing the number of transmit URBs that can be outstanding concurrently (from 224 to 96), but that had no effect on the hangs. I guess maybe I'll try sending out all traffic on the first outbound endpoint rather than distributing it among the endpoints according to WMM service class. Now I am really just stabbing at the air. |
|
thanks for trying!
Indeed and I still have to make it crash with an iperf test limited to 100Mbps... however! Once (and only once so who knows) I made it hang with just opening a video file from a sshfs mounted (basically streaming via ssh) and the video was not that high quality to go over 100Mbps, not event 50Mbps. |
|
I think I have found a workaround. The firmware doesn't seem to be able to cope when multiple outbound endpoints are heavily loaded, but sending out all the
The only change you really have to make is: --- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -923,7 +923,7 @@ static u8 mt76u_ac_to_hwq(struct mt76_dev *dev, u8 ac)
return lmac_queue_map[ac];
}
- return mt76_ac_to_hwq(ac);
+ return mt76_chip(dev) == 0x7961 && ac == IEEE80211_AC_BK ? 0 : mt76_ac_to_hwq(ac);
}
static int mt76u_alloc_tx(struct mt76_dev *dev) |
|
fantastic news! I will try it |
|
It didn't work for me. Hope it stays stable for you so I know it is something on my side.
edit: after 18 minutes, AP is up again automatically (with pending tx errors in dmesg). |
You might also need the status worker spinlock fix, and you could try putting all outgoing traffic on the same endpoint. --- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -772,6 +772,7 @@
if (!q)
continue;
+ spin_lock(&q->lock);
while (q->queued > 0) {
if (!q->entry[q->tail].done)
break;
@@ -779,11 +780,13 @@
entry = q->entry[q->tail];
q->entry[q->tail].done = false;
+ spin_unlock(&q->lock);
mt76_queue_tx_complete(dev, q, &entry);
+ spin_lock(&q->lock);
}
-
if (!q->queued)
wake_up(&dev->tx_wait);
+ spin_unlock(&q->lock);
mt76_worker_schedule(&dev->tx_worker);
}
@@ -923,7 +926,7 @@
return lmac_queue_map[ac];
}
- return mt76_ac_to_hwq(ac);
+ return mt76_chip(dev) == 0x7961 ? 0 : mt76_ac_to_hwq(ac);
}
static int mt76u_alloc_tx(struct mt76_dev *dev)
I suspect I'm not entirely avoiding the problem in the firmware, merely reducing the probability of hitting it. My wild guess is that they have a reëntrancy problem in their code, such that processing of a packet arriving on one endpoint gets interrupted by the arrival of a packet on a second endpoint, and the processing of the second packet corrupts the internal state of the processing of the first packet. They would need to disable interrupts on all endpoints while processing a packet received on any endpoint. (This is an absolutely wild guess made with no knowledge of their architecture, so I could be way off base.) You might also like to enhance your --- a/drivers/net/wireless/mediatek/mt76/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/debugfs.c
@@ -56,15 +56,20 @@
struct mt76_dev *dev = dev_get_drvdata(s->private);
int i;
- seq_puts(s, " queue | hw-queued | head | tail |\n");
+ seq_puts(s, " queue | hw-idx | hw-queued | first | head | tail |\n");
for (i = 0; i < ARRAY_SIZE(dev->phy.q_tx); i++) {
struct mt76_queue *q = dev->phy.q_tx[i];
if (!q)
continue;
- seq_printf(s, " %9d | %9d | %9d | %9d |\n",
- i, q->queued, q->head, q->tail);
+ seq_printf(s, " %9d | %6d | %9d | %9d | %9d | %9d | ",
+ i, q->hw_idx, q->queued, q->first, q->head, q->tail);
+ if (q->queued)
+ for (int j = q->tail; j != q->head; j = (j + 1) % q->ndesc)
+ seq_printf(s, "%c", q->entry[j].done ? 'd' : '.');
+ seq_printf(s, "%s%s\n",
+ q->stopped ? " stopped" : "", q->blocked ? " blocked" : "");
}
return 0; |
That bluetooth problem has been a problem since late last year and was reported in Jan. of this year. Glad to see the recognition that it is a bluetooth problem and not a wifi problem. Hopefully this patch fixes the problem and we can put this behind us. It seems to have taken the involvement of several Mediatek devs to get to the bottom it. |
|
What are you trying to run? WiFi 6 on 5 GHz? Can you post your hostapd,conf |
|
Here is my new conf: https://pastebin.com/qM7f2k4s |
0 and 42 do not go together. 42 is for 80 MHz channel width. If you really want a 40 MHz channel width, you need to look in the docs to see what to set. Look below and see what you are missing for he: There are some other issues as well. Recommend you look again at the working example that I pointed you toward. |
|
Thank you, after looking at the documentation again, I fixed this issue. |
|
Hi,
I Just recognized this Patch for xhci. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.11.5&id=1417b23ec81aed90e4142f406ec291da39cb690f
Might this affect us?
Regards,
Simon
20.10.2024 18:56:23 Krobix ***@***.***>:
…
Thank you, after looking at the documentation again, I fixed this issue.
—
Reply to this email directly, view it on GitHub[#410 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKOIFAL6XXAFXDSJ3TFWNP3Z4PODLAVCNFSM6AAAAABFCX5B7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRVGEYTQMBTGU].
You are receiving this because you were mentioned.
[Verfolgungsbild][https://github.com/notifications/beacon/AKOIFAJ36UMCBKSBLPKFLULZ4PODLA5CNFSM6AAAAABFCX5B7KWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUQRROVG.gif]
|
|
Possibly. I am watching a few things right now regarding bluetooth and usb because we have seen a lot of problems in the usb wifi adapter world since kernel 6.6. |
|
Hi, here is the crash when plugging in the ALFA mt7921u device with a vanilla 6.11.5 kernel. i will try the bluetooth patch mentioned before soon: [Fr Okt 25 17:35:50 2024] usbcore: deregistering interface driver mt7921u regards, |
|
This looks like the bluetooth problem some adapters have been experiencing. It is a bluetooth issue and not a wifi issue. Yes, there are patches in progress. You are welcomed to try to the patch but to confirm it is the same bluetooth problem we have been seeing, simply delete the mt7921u bluetooth firmware file. mt7921u uses two wifi firmware files and there's a bluetooth firmware file. Try deleting it and see what happens. |
|
The Bluetooth Firmware was alredy deleted in Ruhe First try
Now im trying the Bluetooth reset Patch mentioned earlier. Will Report tomorrow
25.10.2024 20:42:54 morrownr ***@***.***>:
…
@Simon566[https://github.com/Simon566]
This looks like the bluetooth problem some adapters have been experiencing. It is a bluetooth issue and not a wifi issue. Yes, there are patches in progress. You are welcomed to try to the patch but to confirm it is the same bluetooth problem we have been seeing, simply delete the mt7921u bluetooth firmware file. mt7921u uses two wifi firmware files and there's a bluetooth firmware file. Try deleting it and see what happens.
—
Reply to this email directly, view it on GitHub[#410 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKOIFALCQ252HFMEANFJNJ3Z5KGKZAVCNFSM6AAAAABFCX5B7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZYGU3TIMZQGU].
You are receiving this because you were mentioned.
[Verfolgungsbild][https://github.com/notifications/beacon/AKOIFAPAU2WIDVIVGN7ZOF3Z5KGKZA5CNFSM6AAAAABFCX5B7KWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTURLGYOC.gif]
|
|
IT also Crashes, could only Take a Screenshot, the system Crashes hard. ITS a skb list corruption
Where can i Paste a Screenshot?
25.10.2024 22:58:30 Simon Huelck ***@***.***>:
… The Bluetooth Firmware was alredy deleted in Ruhe First try
Now im trying the Bluetooth reset Patch mentioned earlier. Will Report tomorrow
25.10.2024 20:42:54 morrownr ***@***.***>:
>
> @Simon566[https://github.com/Simon566]
>
> This looks like the bluetooth problem some adapters have been experiencing. It is a bluetooth issue and not a wifi issue. Yes, there are patches in progress. You are welcomed to try to the patch but to confirm it is the same bluetooth problem we have been seeing, simply delete the mt7921u bluetooth firmware file. mt7921u uses two wifi firmware files and there's a bluetooth firmware file. Try deleting it and see what happens.
>
> —
> Reply to this email directly, view it on GitHub[#410 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKOIFALCQ252HFMEANFJNJ3Z5KGKZAVCNFSM6AAAAABFCX5B7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZYGU3TIMZQGU].
> You are receiving this because you were mentioned.
> [Verfolgungsbild][https://github.com/notifications/beacon/AKOIFAPAU2WIDVIVGN7ZOF3Z5KGKZA5CNFSM6AAAAABFCX5B7KWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTURLGYOC.gif]
>
|
|
@Simon566: Please open a new issue report for each distinct issue you're experiencing. Nothing you've been reporting is related to the |
|
Hi, I realize that I had forgotten to check back on this issue, simply because the error had disappeared completely on my end after I fixed the hostapd configuration. As of the significance of this, I do not know, but I figured that i should at least update. Thanks |
|
Unclear if it is the same issue, but I also see a similar device hang with pending TX on my Bus 004 Device 005: ID 0e8d:7961 MediaTek Inc. Wireless_Device. What is interesting is that everybody here seems to see the issue when using the device as an AP, while I see it using the device in infrastructure mode (connecting to an AP). This is when I generate a lot of traffic (typically doing backups). |
@callegar: There's nothing about the bug that's inherent to AP mode. Any time you're using multiple hardware transmit queues concurrently you can trigger it. Does my patch work around the problem for you too? |
|
I still need to test it. Building custom kernels for my distro is unfortunately not the well documented task it should. |
I'm using the receiver in infrastructure mode and the patch seems to work. Previously I could somewhat reliably trigger the failure (see below). |
|
After a week without problems it triggered again :/ |
|
@ttrei: Sorry to hear that. I am not able to get any further into this. Have you tried any kernel versions that include upstream's reworking of the queues in the mt7921u driver? |
|
Haven't tried newer versions yet, maybe later this weekend. But this is not a pressing issue for me, and i don't have a reliable way to reproduce the failure. |
|
Update: i've been running kernel 6.12 for a while now with similar network load patterns as before, and the driver hasn't crashed yet. |
|
What firmware version are you using? $ ethtool -i interface name |
|
|
i will try and give it a shot . im on 6.12.10 , but im experiencing the bluetooth oops with the ALFA adapter ..... the firmware is the same on my side |
can you please post the reworked patch for 6.12.7 ? the original patch doesnt apply anymore :-( |
|
@Simon566 |
|
@ttrei but you are running in client mode correct , or also AP mode ? |
|
only as a client, haven't used the adapter as access point |
I decided to start a FAQ and the first thing I added is the current workaround for the Bluetooth Opps problem: https://github.com/morrownr/USB-WiFi/blob/main/home/FAQ.md |
[Do Mär 21 22:48:23 2024] mt7921u 1-1:1.3: Message 00020003 (seq 6) timeout
[Do Mär 21 22:48:24 2024] mt7921u 1-1:1.3: timed out waiting for pending tx
[Do Mär 21 22:48:24 2024] mt7921u 1-1:1.3: HW/SW Version: 0x8a108a10, Build Time: 20240219110958a
[Do Mär 21 22:48:24 2024] mt7921u 1-1:1.3: WM Firmware Version: ____010000, Build Time: 20240219111038
[Fr Mär 22 06:17:31 2024] mt7921u 1-1:1.3: vendor request req:63 off:d02c failed:-110
[Fr Mär 22 06:17:34 2024] mt7921u 1-1:1.3: vendor request req:63 off:d054 failed:-110
[Fr Mär 22 06:17:37 2024] mt7921u 1-1:1.3: vendor request req:63 off:d058 failed:-110
[Fr Mär 22 06:17:41 2024] mt7921u 1-1:1.3: vendor request req:63 off:53b8 failed:-110
.....alot more of the -110
[Fr Mär 22 06:42:20 2024] task:kworker/u8:3 state:D stack:0 pid:1179348 ppid:2 flags:0x00004000
[Fr Mär 22 06:42:20 2024] Workqueue: phy0 mt792x_mac_work [mt792x_lib]
[Fr Mär 22 06:42:20 2024] Call Trace:
[Fr Mär 22 06:42:20 2024]
[Fr Mär 22 06:42:20 2024] __schedule+0x3c4/0xb50
[Fr Mär 22 06:42:20 2024] schedule+0x61/0xe0
[Fr Mär 22 06:42:20 2024] schedule_preempt_disabled+0x18/0x30
[Fr Mär 22 06:42:20 2024] __mutex_lock.constprop.0+0x3b4/0x700
[Fr Mär 22 06:42:20 2024] mt792x_mac_work+0x28/0xb0 [mt792x_lib]
[Fr Mär 22 06:42:20 2024] process_one_work+0x171/0x340
[Fr Mär 22 06:42:20 2024] worker_thread+0x27b/0x3a0
[Fr Mär 22 06:42:20 2024] ? __pfx_worker_thread+0x10/0x10
[Fr Mär 22 06:42:20 2024] kthread+0xf4/0x130
[Fr Mär 22 06:42:20 2024] ? __pfx_kthread+0x10/0x10
[Fr Mär 22 06:42:20 2024] ret_from_fork+0x31/0x50
[Fr Mär 22 06:42:20 2024] ? __pfx_kthread+0x10/0x10
[Fr Mär 22 06:42:20 2024] ret_from_fork_asm+0x1b/0x30
[Fr Mär 22 06:42:20 2024]
[Fr Mär 22 06:42:20 2024] Future hung task reports are suppressed, see sysctl kernel.hung_task_warnings
[Fr Mär 22 06:42:22 2024] mt7921u 1-1:1.3: vendor request req:63 off:4230 failed:-110
[Fr Mär 22 06:42:25 2024] mt7921u 1-1:1.3: vendor request req:63 off:4230 failed:-110
The text was updated successfully, but these errors were encountered: