Open satmandu opened 4 years ago
@satmandu, The issue is within the function called rtw_cfg80211_ch_switch_notify. I've pasted it below. You need to initialize the struct cfg80211_chan_def chdef. I've done that below like this:
struct cfg80211_chan_def chdef = {};
It should be around line 416 in os_dep/linux/ioctl_cfg80211.c.
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 5, 0))
u8 rtw_cfg80211_ch_switch_notify(_adapter *adapter, u8 ch, u8 bw, u8 offset, u8 ht)
{
struct wiphy *wiphy = adapter_to_wiphy(adapter);
u8 ret = _SUCCESS;
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 8, 0))
struct cfg80211_chan_def chdef = {};
ret = rtw_chbw_to_cfg80211_chan_def(wiphy, &chdef, ch, bw, offset, ht);
if (ret != _SUCCESS)
goto exit;
@satmandu I've noticed also that several static structs defined within os_dep/linux/ioctl_cfg80211.c and initialized using macros here https://github.com/aircrack-ng/rtl8812au/blob/76c3cf81fdc71af4338571b6404beb2ba3835a62/os_dep/linux/ioctl_cfg80211.c#L106 do not initialize all the fields within the structs. Could this be an issue?
For example, in kernel 5.4, the ieee80211_channel is defined as below within include/net/cfg80211.h:
struct ieee80211_channel {
enum nl80211_band band;
u32 center_freq;
u16 hw_value;
u32 flags;
int max_antenna_gain;
int max_power;
int max_reg_power;
bool beacon_found;
u32 orig_flags;
int orig_mag, orig_mpwr;
enum nl80211_dfs_state dfs_state;
unsigned long dfs_state_entered;
unsigned int dfs_cac_ms;
};
Yet the macros that initialize the static channels defined in os_dep/linux/ioctl_cfg80211.c are defined like so:
#define CHAN2G(_channel, _freq, _flags) { \
.band = NL80211_BAND_2GHZ, \
.center_freq = (_freq), \
.hw_value = (_channel), \
.flags = (_flags), \
.max_antenna_gain = 0, \
.max_power = 30, \
}
#define CHAN5G(_channel, _flags) { \
.band = NL80211_BAND_5GHZ, \
.center_freq = 5000 + (5 * (_channel)), \
.hw_value = (_channel), \
.flags = (_flags), \
.max_antenna_gain = 0, \
.max_power = 30, \
}
Note all the fields missing from initialization.
I always had this error on x86_64 running fedora 31 and TP-Link Archer T9UH v1 [Realtek RTL8814AU]
. Despite those errors it was quite stable until recently.
And within the past 24h I got 2 kernel panics!
What I did is reboot the machine which had the effect of running Fedora's latest stock kernel 5.6.18-200.fc31.x86_64
.
The first panic occured on version 5.6.4.2
, so I upgraded to 5.7.0
and had another kernel panic since then. I'm using dkms.
Good work guys. This was merely an annoyance until recently, now it is a nuisance and needs fixing.
I am looking at this and the kernel 5.8 update. Will report back when I have some kind of sane fixes in place.
On my laptop, I have kernel 5.4.40 and driver 5.6.4.2
https://github.com/gordboy/rtl8812au-5.6.4.2
and the warning is from
WARNING: CPU: 1 PID: 786 at net/wireless/nl80211.c:3157 nl80211_send_chandef+0x142/0x160 [cfg80211]
but the very next lines in the call stack is for
? __nla_put+0x20/0x30
nl80211_ch_switch_notify.constprop.0+0xcf/0x170 [cfg80211]
so something is clearly needing some love, the sooner the better.
So early indications are that the first fix mentioned by @guspoveda fixes my first kernel dmesg mishap. But there is more badness.
After pulling the device in and out a few times and doing modprobe -r and modprobe and stuff, I started to get another problem
WARNING: CPU: 1 PID: 2234 at net/wireless/sme.c:756 __cfg80211_connect_result+0x3b9/0x3f0 [cfg80211]
but the call stack is not all that helpful
? apic_timer_interrupt+0xa/0x20
cfg80211_process_wdev_events+0x13a/0x1a0 [cfg80211]
? cfg80211_process_wdev_events+0x13a/0x1a0 [cfg80211]
none of which is in the driver. It may be that my cfg80211 is also faulty. I will report back with any more progress.
Another idea to ponder, maybe the current badness is occasioned by newer compilers "optimizing" things away that should remain. Currently testing different compiler optimization flags on GCC 9.
Am I the only one to experience regular kernel panics with my TP-Link Archer T9UH v1 [Realtek RTL8814AU]?
About one panic per week in average. I use the machine as a docker server (there's no physical ethernet cable to the Internet) so it may be because the wireless adapter is under more stress than the average user (who uses it with the laptop or desktop). I use Fedora 31 and experience panics with stock kernels: 5.6.18-200.fc31.x86_64 and more recently 5.6.19-200.fc31.x86_64, using dkms. I've tried both v5.6.4.2 (regularly updated) as well as v5.7.0 branches.
What is the 5.7.0 branch? 5.7.0 is a kernel version, not a driver version ...
First post suggest issue on branch 5.7.0, latest one. The latest branch got a lot newer 8814au and 8821au HAL in it, but I see it as a little tricky yet, it works fine but isn't much maintained atm because I don't have time :+1:
Adding GCC 10 patches and others shortly.
Hello @kimocoder is 5.7.0 from Realtek FTP site, cos the last one I thought before they shut down the FTP site was 5.6.4.2 ?
Also welcome back .... :+1:
No, v5.7.0 was added because the rtl8821au had a newer HAL that was added. while rtl8814au now is standalone.
I haven't done much with this driver for quite some time. Let me read all this issue reports and work out what I am going to do.
New driver 5.9.3.2 seems to have fixed this. Still testing.
Hi, haven't had much time to do much lately, lost overview atm, be back soon 👍
Roger that good buddy, 10-4 and Wilco :)
New driver 5.9.3.2 seems to have fixed this. Still testing.
You have access to newer drivers?
Someone gave me a zip file. I don't have FTP access. And there is no changelog. But I have a new repo here -
https://github.com/gordboy/rtl8812au-5.9.3.2
And you can also grab it at the beginning, before any of my changes -
https://github.com/gordboy/rtl8812au-5.9.3.2/tree/1c1eb645f229759a7ab10a0805f60a9ae21a16de
Enjoy
Getting dmesg errors, but network seems to come up properly.