New versions of this chipset #298
Comments
|
Did you check if it already works? According to that commit, RFE 6 is handled the same way as RFE 0, which I'm pretty sure already works. |
Yes, I already checked this and the driver is never claimed by the chipset. This is the output of dmesg with this driver: No errors, but it doesn't work either :( |
|
What does |
01:00.0 Network controller [0280]: Realtek Semiconductors ... Network Adapter [10ec:c821] |
|
Okay, that's not the problem. That ID has been known to the driver for years. Is that all you see in dmesg? If you were using grep, try without it. |
|
But probably there is nothing useful. Try changing CONFIG_RTW_LOG_LEVEL back to 4 in the Makefile and recompile. That should make the driver a lot more chatty. |
Yes, this is the output |
By default, I see that |
|
Oh, okay. I was looking at this old commit: 47cbf27 Perhaps what you need is CONFIG_RTW_DEBUG=y. |
Here we go HALMAC initialize FAIL Seems to be the exact same error I found with the rtw88_8821 kernel driver. A mac issue. More info: This issue had to do with the ASPM platform (Active State Power Management) I think that incidentally, @tomaspinho thought that |
|
Here is the whole LOG by the way |
|
Full logs are good. Let's see what the chip_id actually is: diff --git a/hal/halmac/halmac_api.c b/hal/halmac/halmac_api.c
index d9e3645..645cac6 100644
--- a/hal/halmac/halmac_api.c
+++ b/hal/halmac/halmac_api.c
@@ -518,7 +518,7 @@ get_chip_info(void *drv_adapter, struct halmac_platform_api *pltfm_api,
adapter->chip_id = HALMAC_CHIP_ID_8812F;
} else {
adapter->chip_id = HALMAC_CHIP_ID_UNDEFINE;
- PLTFM_MSG_ERR("[ERR]Chip id is undefined\n");
+ PLTFM_MSG_ERR("[ERR]Chip id is undefined: 0x%x\n", chip_id);
return HALMAC_RET_CHIP_NOT_SUPPORT;
}
|
There you go |
|
Weird. Does this work? diff --git a/hal/halmac/halmac_api.c b/hal/halmac/halmac_api.c
index d9e3645..6f966cc 100644
--- a/hal/halmac/halmac_api.c
+++ b/hal/halmac/halmac_api.c
@@ -504,6 +504,12 @@ get_chip_info(void *drv_adapter, struct halmac_platform_api *pltfm_api,
adapter->chip_ver = (enum halmac_chip_ver)chip_ver;
+ // Hack for a specific device which is known to be 8821ce,
+ // but the chip_id is 0xff. Technically this driver will only
+ // try to handle 8821ce devices anyway, so it's fine.
+ adapter->chip_id = HALMAC_CHIP_ID_8821C;
+
+ /*
if (chip_id == CHIP_ID_HW_DEF_8822B) {
adapter->chip_id = HALMAC_CHIP_ID_8822B;
} else if (chip_id == CHIP_ID_HW_DEF_8821C) {
@@ -521,6 +527,7 @@ get_chip_info(void *drv_adapter, struct halmac_platform_api *pltfm_api,
PLTFM_MSG_ERR("[ERR]Chip id is undefined\n");
return HALMAC_RET_CHIP_NOT_SUPPORT;
}
+ */
return HALMAC_RET_SUCCESS;
} |
|
Same dog but new collar :) |
|
Try this, together with the other patch: diff --git a/hal/halmac/halmac_88xx/halmac_func_88xx.c b/hal/halmac/halmac_88xx/halmac_func_88xx.c
index 22a90d6..c835e81 100644
--- a/hal/halmac/halmac_88xx/halmac_func_88xx.c
+++ b/hal/halmac/halmac_88xx/halmac_func_88xx.c
@@ -3864,7 +3864,10 @@ halmac_parse_intf_phy_88xx(
curr_cut = (u16)HALMAC_INTF_PHY_CUT_TESTCHIP;
break;
default:
- return HALMAC_RET_FAIL;
+// return HALMAC_RET_FAIL;
+ curr_cut = (u16)HALMAC_INTF_PHY_CUT_A;
+ PLTFM_MSG_ERR("[ERR]Unknown chip version %d. Pretending it's version 0 (cut A).\n", pHalmac_adapter->chip_version);
+ break;
}
pCurr_phy_para = pIntf_phy_para; |
|
lwfinger/rtw88#98 - Aha. I was going to ask if this device works with rtw88. |
|
Did you ever boot Windows on this system? Fast Startup is known to cause problems with the wifi in Linux. |
In fact, I have installed the latest kernel I've found just to see if this works out of the box, and it doesn't.
Yep, it booted firstly in W10 fine, and then I tried W11 for testing and worked flawlessly out of the box. But I have completely wiped both Windows. I'm going to test now your halmac patch to see how it performs. |
|
It's not going to perform at all if the chip can't be turned on. You need to get a Windows 10/11 back, disable Fast Startup, and reboot it once or twice. |
Do you think that the chipset is off? |
Same error with this patch... |
|
rtw88 fails at the step where it's supposed to turn on a part of the device. It's pointless to modify this driver further if the Windows Fast Startup messed with the device. The solution is to disable Fast Startup and shut down Windows. Or if you can completely cut the power to this computer, maybe that will also work. Unplug it from mains, remove the battery. I don't know if anyone tried that. Maybe it's easier to reinstall Windows. |
What do you mean with Windows Fast Startup? I don't remember activating such option in my last installation of W11 (just to try that the chipset actually worked) Is a feature of Wlan devices in Windows? Or a general feature of Windows? I can't understand how this may interfere, if I have completely wiped Windows from the system. |
|
It's a feature of Windows, not specifically related to wifi but apparently it does things to the wifi cards. It's on by default, you don't have to turn it on yourself. Based on that description, it should only have an effect the first time you boot Linux after "shutting down" Windows. I don't know. Maybe that's not the problem. Maybe there is something else wrong. If you can't find a solution, send an email to |
|
It explicitly says: "dual boot". I'm not dual booting. So that chipset power off theory is not valid (unless, maybe there is a dual boot as mentioned!). Anyway I have decided to format and check this topic, because I'm worried that there might be some pesky thing in all this plot. I need to have things in sorts before moving on. |
|
After reinstalling Windows, and removing the Fast boot thing, I'm back to Linux and I still see that pesky I have not tried this yet, but something suggests to me that the Fastboot was completely placebo. AT least I can tick this out of my checklist |
|
My last findings show that for some reason the chipset is dropping constantly. With the lwfinger's rtw88 driver, I seem to spot the wireless networks but it drops almost immediately, Definitely a little step forward but not enough to consider this stable by any means. Only when I have the laptop connected to the power cable, it works stable. But with this rtl8821ce driver, it doesn't even work when connected to power cable. So probably this is what solves the question of the rtw88 drops (not the Fastboot theory) |
|
@dubhater accidentally I have discovered "the wlan power-on protocol" Now I can make this card work with any driver, rtw88 from lwfinger, even the kernel driver and this one I posted here I've found the (weird) method to make this work always (but with a ton of flaws)
As soon as I unplug the power cord, the connection drops Feels the oddest thing ever. |
This project seems to be a little bit abandoned, but I feel it is more practical than the core rtw88 driver (because it's embedded on the latest kernel changes which makes it a hassle to keep it up in more stable Linux distros)
I wondered if you could be planning to support newer versions of this chipset like 8821CE RFE 6 devices (some SoCs with latest fw version launched late 2021)
This is the changes that Ping-Ke Shih from Realtek committed into the RTW88 driver to make this functional:
torvalds/linux@e109e36
The text was updated successfully, but these errors were encountered: