I’ve seen some forums talk about a similar issue, however no real tangible answer. I have installed linux-firmware. I have tried some of the drivers on the aurs but those don’t work. How could I either get the drives needed or get them detected if they are there? How do I check if the drivers needed are present?
I would look at the man page for lsmod; to my unexperienced eye it sounds like the kernel module containing the driver is not loaded. I am guessing that is what UNCLAIMED refers to; no kernel driver is claiming this PCIe device as its responsibility.
Missing firmware is usually an error visible in dmesg, and it is an error message from the appropriate kernel driver/module in effect saying, “I am here, I found the device I am responsible for, but I have no firmware to give it”; this appears to be more like a situation in which lshw is saying, in effect, “I found a Mediatek device, and my PCI ID database says it is a Network Controller, but nothing in the kernel knows what to do with it.”
Edit: this device was completely missing from the PCI ID database, therefore that is not where it was identified as a “Network Controller”.
Ah, that is what I was about to ask for, the PCI vendor and product id. It looks like it is a fairly new device; I am not seeing it in the public PCI ID database that everyone (at least in open source land) uses: https://pci-ids.ucw.cz/read/PC/14c3
You say this is an Asus X570-e Gaming Wifi II, that would make this the product page, right? The information there, even on the specifications page is still unhelpful:
While MT7921 is on the wiki page showing supported devices, I do not see MT7921K there; this could just be a case of out-of-date documentation, however, I do see this askUbuntu post also dealing with a [14c3:0608] device, where the respondent mentions that,
Linux kernel’s driver module mt7921e does work with this card. I’m on 5.15.2 .
I am not positive what the relationship is between the mt7921e module and the mt76 driver proper, but mt7921e appears to be in some way a subcomponent of mt76. It really is irritating how the kernel wiki and web documentation makes no mention of mt7921e, despite it being the name that users will need to give to modprobe.
Anyway, the aforementioned askUbuntu response links to a new kernel patch that supposedly is approved; so maybe it will be sorted by the next kernel release?
Regardless, the issue seems to be that the while the existing driver supports your MediaTek wireless lan controller, it does not know to look for the new PCI ID until that patch is added to the kernel. So, the respondent on askUbuntu recommended either modifying some config files, or running two commands at runtime each boot; both seem to be telling the mt7921e driver to try to use a device it does not natively recognise.
Personally, since you do not need it currently, I would just run the commands at runtime:
this way you do not have to remember to revert the configuration files when a new kernel officially supporting it is released.
Also, I find the runtime commands easier to understand, the /new_id feature is described here in the Linux documentation; whereas I would want to more thoroughly read through how udev rules work before recommending that to you do that.
I found the thread above on GitHub with someone discussing this same issue again, and thanks to a link there, I can confirm (assuming the GitHub kernel mirror is accurate) that the fix is committed and present since tag v5.17-rc1:
AMD RZ608
While looking at the AskUbuntu response above, I noticed that the original question talked about RZ608, and the respondent used rz608 in the name of the newly made config file and udev rule.
Searching for RZ608 led me to the following AnandTech page. Maybe the reason for this unfamiliar PCI ID is that it is an AMD rebrand of MediaTek’s MT7921K?
The only question remaining is, do non-AMD-rebranded MT7921K devices also have a PCI ID of [14c3:0608]? I can find no instance of just a MT7921K entry in the PCI ID database, only for MT7921.
What you mentioned did work, I have functionality with my network card. Thank you. I do want to see this through though. Brand differences have been cropping up and making an issue recently to begin with.
There is nothing left to see through; just waiting until 5.17 is released and then packaged for your distro. If you need wireless before then, either use the runtime commands I gave above, or create the udev rule and modprobe.d files containing the lines mentioned in the askUbuntu post.
When I looked at Phoronix for 5.17 changes, I found the following comment, so it looks like an AMD RZ616 component is similarly having issues being recognised, and probably corresponds to the PCI ID [14c3:0616] entry in the kernel patch,
An additional gripe I have during my research, is that the Linux kernel.org. Patchwork system has a broken “patch series” link when looking at seemingly the same patch via the linux-wireless project URL rather than the linux-mediatek URL:
Note how in the first link there is no mention of the patch being approved, but the patch series link does actually work, whereas in the second (linux-wireless URL) link, the patch series link is not working, but at least we see that the patch is approved and assigned to Felix Fietkau (nbd, or nbd168 on GitHub).
In May, the CEO of Ayaneo, which is making a handheld gaming device based on the AMD Ryzen 5 4500U APU, blew the RZ608’s cover. CEO Arthur Zhang stated “[t]he RZ608 announced today has never been revealed on the Internet, so many of you don’t believe it.”
I wonder if this was partly the problem, if AMD or MediaTek was overly aggressive in keeping these rebranded devices under wraps, and therefore their PCI IDs did not make it into the Linix kernel drivers in time.