Open jpap opened 1 year ago
This is where the first failure happens:
If I comment out line 993 above, it works! :D Perhaps this hardware revision changed the definitions of the bits in that register?
Hi @jpap
Interesting. This is a new one on me. Run it for a while with the line commented out and see what happens. I'd like to know.
By the way, the approval was given today for the new in-kernel driver for this chipset to be mainlined. I'm not sure if it will make it into 6.2 or 6.3 but there is something to be excited about going on. Imagine not having to compile a driver.
It's been very stable. I've been running it as an AP client for the past week 24/7 and have had no problems. When the Raspberry Pi reboots, it always comes back up and associates.
Hi @jpap
That is good news. I think I am going to borrow your fix above and see what happens on other adapters. In looking at the code, it does not seem necessary for that code to exist anyway but we'll see. Thanks.
Nick
My guess is that the check is there to just make sure the adapter is responding to the commands issued to it before issuing more for that mode.
It might be that with my device they changed the register value, dropped it entirely (no other driver code reads or writes that register), or there’s a race condition for that value to be valid. I am getting a second T4U for another use case, now that it works with Linux, and will see if that exhibits the same behaviour.
If there’s time, I’ll add a sleep or delay to see if the problem is caused by a race, or confirm if the hardware registers were changed in that silicon revision.
Thank you otherwise for your maintenance work and quick responses to these issues. I would’ve had a paperweight on my hands otherwise!
@jpap
Response much appreciated. I would appreciate information from your further testing so as to note it here. If you can't find anything and want to submit a PR, that would be fine.
I am getting a second T4U for another use case, now that it works with Linux...
A couple of things to point out to you:
https://github.com/morrownr/USB-WiFi
Menu items 1 and 2 give a lot of information about wifi adapters and use on Linux. Keep in mind that there are adapters with the new mt7921au chipset available and it is WiFi 6e capable. It is very fast on 5 GHz in AC mode. Still testing WiFi 6 and WiFi 6e.
I plan to test once 6.2 rc1 is released here in a couple of weeks. I don't know about the quality yet.
Nick
My second device (the same brand/model) arrived by mail today... and it works without the above patch!
Given that my first device worked under Windows without any issues, I'm not convinced it is a hardware problem per-se. It could be a different revision of the silicon (I haven't opened them up, because I don't want to destroy the bottom sticker and void the warranty), or maybe it is indeed a race condition in the driver.
Since a) my "buggy device" works fine for an extended period with the change outlined above, b) the register was not written to, and c) the register doesn't appear anywhere else in the driver, I'd be inclined to recommend making that change permanently for everyone.
If I get a chance, I'll add a spin/sleep to confirm or rule out the race condition idea; but I might not be able to do that for some time as that device is running remotely at present.
Please close this issue, along with a commit or not, as you feel. I'd also be happy to submit a PR and do it that way if you prefer.
Since a) my "buggy device" works fine for an extended period with the change outlined above, b) the register was not written to, and c) the register doesn't appear anywhere else in the driver, I'd be inclined to recommend making that change permanently for everyone.
No need to submit a PR. I've already made the change locally and will push it later today. Thanks for investigating.
I have a TP-Link Archer T4U ver.3 that was recently purchased. It works 100% under Windows, and I am trying to get it working on Linux.
I've tried VMs on amd64 (Linux kernel 5.15) and arm64 (Debian; Linux kernel 5.10), and a bare metal armv6l (kernel 5.15; Raspberry Pi B+): they all give the same result shown below.
Just in case, I tried it with a rtl8812au driver, and the device didn't register with the driver when plugged in; so it almost surely appears to be the BU chipset?
A full driver debug log is here. Perhaps the reason for the failure are the following two lines:
The
README.md
recommended dump is here.While I can see the network interface, I can't run a scan (nothing else works).
Appreciate any advice. :)