Hi!
I am seeing dropouts in 5GHz and 2.5GHz wifi and seeking for help.
HP laptop with RTL8822CE 802.11ac PCIe Wireless Network Adapter,
Fedora36 with 6.2.9-100.fc36.x86_64, the AP is Ubiquity, it is 5m away
behind a thin wall, a house in low density area (I do not see neighbors
APs in "iw dev scan").
Pinging a gateway (1gbit ethernet between AP and GW) suddenly goes from
3-5ms to >1000ms. Good and bad "iw" output is below. Moving laptop by
2cm (or its lid) helps sometime.
These 2 observation made me suspect the linux driver:
1) If I reboot the laptop to Windows10 without moving/touching it after
it went bad in linux - there pings are 1-2ms and occasionally may go up
to hundreds but for a very short time, feels like the driver notices
something and fixes it.
2) Two other laptops with Intel Wifi cards on the same spot with the
same fedora on the same network do not show the problem at all.
Changing txpower 10..23dBm (where 2300 is the maximum) does not help,
done via "iw dev wlp1s0 set txpower limit 2300", "iw dev wlp1s0 info"
confirms that it changes.
I have these in /etc/modprobe.d/50-rtw88.conf
options rtw88_core disable_lps_deep=y
options rtw88_pci disable_aspm=y
no change either.
Is there anything else to try? Thanks,
64 bytes from _gateway (192.168.10.200): icmp_seq=26 ttl=64 time=6.97 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=27 ttl=64 time=3.68 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=28 ttl=64 time=3.44 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=29 ttl=64 time=3.97 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=30 ttl=64 time=3.68 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=31 ttl=64 time=17.0 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=32 ttl=64 time=33.1 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=33 ttl=64 time=697 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=34 ttl=64 time=1130 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=35 ttl=64 time=114 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=36 ttl=64 time=1796 ms
64 bytes from _gateway (192.168.10.200): icmp_seq=37 ttl=64 time=749 ms
Good status:
[root@aiemdeew wlp1s0]# iw dev wlp1s0 info ; iw wlp1s0 link
Interface wlp1s0
ifindex 2
wdev 0x1
addr 50:c2:e8:5d:ba:fd
type managed
wiphy 0
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 22.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
Connected to f4:92:bf:04:1a:ce (on wlp1s0)
SSID: aikhomenet
freq: 5180
RX: 37035326 bytes (60439 packets)
TX: 2880943 bytes (14231 packets)
signal: -53 dBm
rx bitrate: 130.0 MBit/s VHT-MCS 7 VHT-NSS 2
tx bitrate: 390.0 MBit/s VHT-MCS 4 80MHz short GI VHT-NSS 2
bss flags: short-slot-time
dtim period: 2
beacon int: 100
Bad status:
Interface wlp1s0
ifindex 2
wdev 0x1
addr 50:c2:e8:5d:ba:fd
type managed
wiphy 0
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
txpower 22.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol
tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
Connected to f4:92:bf:04:1a:ce (on wlp1s0)
SSID: aikhomenet
freq: 5180
RX: 38078401 bytes (68758 packets)
TX: 3039702 bytes (15006 packets)
signal: -62 dBm
rx bitrate: 117.0 MBit/s VHT-MCS 6 VHT-NSS 2
tx bitrate: 433.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 1
bss flags: short-slot-time
dtim period: 2
beacon int: 100
--
Alexey
On 5/3/23 02:13, Alexey Kardashevskiy wrote:
> Hi!
>
> I am seeing dropouts in 5GHz and 2.5GHz wifi and seeking for help.
>
> HP laptop with RTL8822CE 802.11ac PCIe Wireless Network Adapter, Fedora36 with
> 6.2.9-100.fc36.x86_64, the AP is Ubiquity, it is 5m away behind a thin wall, a
> house in low density area (I do not see neighbors APs in "iw dev scan").
>
> Pinging a gateway (1gbit ethernet between AP and GW) suddenly goes from 3-5ms to
> >1000ms. Good and bad "iw" output is below. Moving laptop by 2cm (or its lid)
> helps sometime.
>
> These 2 observation made me suspect the linux driver:
>
> 1) If I reboot the laptop to Windows10 without moving/touching it after it went
> bad in linux - there pings are 1-2ms and occasionally may go up to hundreds but
> for a very short time, feels like the driver notices something and fixes it.
>
> 2) Two other laptops with Intel Wifi cards on the same spot with the same fedora
> on the same network do not show the problem at all.
>
> Changing txpower 10..23dBm (where 2300 is the maximum) does not help, done via
> "iw dev wlp1s0 set txpower limit 2300", "iw dev wlp1s0 info" confirms that it
> changes.
>
> I have these in /etc/modprobe.d/50-rtw88.conf
> options rtw88_core disable_lps_deep=y
> options rtw88_pci disable_aspm=y
> no change either.
>
> Is there anything else to try? Thanks,
>
>
> 64 bytes from _gateway (192.168.10.200): icmp_seq=26 ttl=64 time=6.97 ms
> 64 bytes from _gateway (192.168.10.200): icmp_seq=27 ttl=64 time=3.68 ms
> 64 bytes from _gateway (192.168.10.200): icmp_seq=28 ttl=64 time=3.44 ms
> 64 bytes from _gateway (192.168.10.200): icmp_seq=29 ttl=64 time=3.97 ms
> 64 bytes from _gateway (192.168.10.200): icmp_seq=30 ttl=64 time=3.68 ms
> 64 bytes from _gateway (192.168.10.200): icmp_seq=31 ttl=64 time=17.0 ms
> 64 bytes from _gateway (192.168.10.200): icmp_seq=32 ttl=64 time=33.1 ms
> 64 bytes from _gateway (192.168.10.200): icmp_seq=33 ttl=64 time=697 ms
> 64 bytes from _gateway (192.168.10.200): icmp_seq=34 ttl=64 time=1130 ms
> 64 bytes from _gateway (192.168.10.200): icmp_seq=35 ttl=64 time=114 ms
> 64 bytes from _gateway (192.168.10.200): icmp_seq=36 ttl=64 time=1796 ms
> 64 bytes from _gateway (192.168.10.200): icmp_seq=37 ttl=64 time=749 ms
>
> Good status:
>
> [root@aiemdeew wlp1s0]# iw dev wlp1s0 info ; iw wlp1s0 link
> Interface wlp1s0
> ifindex 2
> wdev 0x1
> addr 50:c2:e8:5d:ba:fd
> type managed
> wiphy 0
> channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
> txpower 22.00 dBm
> multicast TXQ:
> qsz-byt qsz-pkt flows drops marks overlmt hashcol
> tx-bytes tx-packets
> 0 0 0 0 0 0 0 0 0
> Connected to f4:92:bf:04:1a:ce (on wlp1s0)
> SSID: aikhomenet
> freq: 5180
> RX: 37035326 bytes (60439 packets)
> TX: 2880943 bytes (14231 packets)
> signal: -53 dBm
> rx bitrate: 130.0 MBit/s VHT-MCS 7 VHT-NSS 2
> tx bitrate: 390.0 MBit/s VHT-MCS 4 80MHz short GI VHT-NSS 2
>
> bss flags: short-slot-time
> dtim period: 2
> beacon int: 100
>
>
> Bad status:
>
> Interface wlp1s0
> ifindex 2
> wdev 0x1
> addr 50:c2:e8:5d:ba:fd
> type managed
> wiphy 0
> channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
> txpower 22.00 dBm
> multicast TXQ:
> qsz-byt qsz-pkt flows drops marks overlmt hashcol
> tx-bytes tx-packets
> 0 0 0 0 0 0 0 0 0
> Connected to f4:92:bf:04:1a:ce (on wlp1s0)
> SSID: aikhomenet
> freq: 5180
> RX: 38078401 bytes (68758 packets)
> TX: 3039702 bytes (15006 packets)
> signal: -62 dBm
> rx bitrate: 117.0 MBit/s VHT-MCS 6 VHT-NSS 2
> tx bitrate: 433.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 1
>
> bss flags: short-slot-time
> dtim period: 2
> beacon int: 100
>
Something certainly changed for your signal strength to drop from -53 to -62
dBm. The higher value is acceptable, but will not provide high data rates. The
lower value is marginal.
There are some changes between kernel 6.2 and the current contents of the
wireless-next repo, which is the code to be found in kernel 6.4 when it is
released. Could you try the code in https://github.com/lwfinger/rtw88.git? This
repo has the code found in wireless-next modified to build on older kernels. You
would need to blacklist rtw88_8822ce. This sequence should do it for you:
sudo dnf install git kernel-headers kernel-devel
sudo dnf group install "C Development Tools and Libraries"
git clone https://github.com/lwfinger/rtw88.git
cd rtw88
make
sudo make install
sudo touch /usr/lib/modprobe.d/50-blacklist-8822ce.conf
As root, using your favorite editor, add the following line to the above file:
blacklist rtw88_8822ce
Then reboot. Report if there are any changes. This way, we will be able to
determine if the problem has already been fixed.
Larry
On 4/5/23 00:42, Larry Finger wrote:
> On 5/3/23 02:13, Alexey Kardashevskiy wrote:
>> Hi!
>>
>> I am seeing dropouts in 5GHz and 2.5GHz wifi and seeking for help.
>>
>> HP laptop with RTL8822CE 802.11ac PCIe Wireless Network Adapter,
>> Fedora36 with 6.2.9-100.fc36.x86_64, the AP is Ubiquity, it is 5m away
>> behind a thin wall, a house in low density area (I do not see
>> neighbors APs in "iw dev scan").
>>
>> Pinging a gateway (1gbit ethernet between AP and GW) suddenly goes
>> from 3-5ms to >1000ms. Good and bad "iw" output is below. Moving
>> laptop by 2cm (or its lid) helps sometime.
>>
>> These 2 observation made me suspect the linux driver:
>>
>> 1) If I reboot the laptop to Windows10 without moving/touching it
>> after it went bad in linux - there pings are 1-2ms and occasionally
>> may go up to hundreds but for a very short time, feels like the driver
>> notices something and fixes it.
>>
>> 2) Two other laptops with Intel Wifi cards on the same spot with the
>> same fedora on the same network do not show the problem at all.
>>
>> Changing txpower 10..23dBm (where 2300 is the maximum) does not help,
>> done via "iw dev wlp1s0 set txpower limit 2300", "iw dev wlp1s0 info"
>> confirms that it changes.
>>
>> I have these in /etc/modprobe.d/50-rtw88.conf
>> options rtw88_core disable_lps_deep=y
>> options rtw88_pci disable_aspm=y
>> no change either.
>>
>> Is there anything else to try? Thanks,
>>
>>
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=26 ttl=64 time=6.97 ms
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=27 ttl=64 time=3.68 ms
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=28 ttl=64 time=3.44 ms
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=29 ttl=64 time=3.97 ms
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=30 ttl=64 time=3.68 ms
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=31 ttl=64 time=17.0 ms
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=32 ttl=64 time=33.1 ms
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=33 ttl=64 time=697 ms
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=34 ttl=64 time=1130 ms
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=35 ttl=64 time=114 ms
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=36 ttl=64 time=1796 ms
>> 64 bytes from _gateway (192.168.10.200): icmp_seq=37 ttl=64 time=749 ms
>>
>> Good status:
>>
>> [root@aiemdeew wlp1s0]# iw dev wlp1s0 info ; iw wlp1s0 link
>> Interface wlp1s0
>> ifindex 2
>> wdev 0x1
>> addr 50:c2:e8:5d:ba:fd
>> type managed
>> wiphy 0
>> channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
>> txpower 22.00 dBm
>> multicast TXQ:
>> qsz-byt qsz-pkt flows drops marks overlmt
>> hashcol tx-bytes tx-packets
>> 0 0 0 0 0 0 0 0 0
>> Connected to f4:92:bf:04:1a:ce (on wlp1s0)
>> SSID: aikhomenet
>> freq: 5180
>> RX: 37035326 bytes (60439 packets)
>> TX: 2880943 bytes (14231 packets)
>> signal: -53 dBm
>> rx bitrate: 130.0 MBit/s VHT-MCS 7 VHT-NSS 2
>> tx bitrate: 390.0 MBit/s VHT-MCS 4 80MHz short GI VHT-NSS 2
>>
>> bss flags: short-slot-time
>> dtim period: 2
>> beacon int: 100
>>
>>
>> Bad status:
>>
>> Interface wlp1s0
>> ifindex 2
>> wdev 0x1
>> addr 50:c2:e8:5d:ba:fd
>> type managed
>> wiphy 0
>> channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
>> txpower 22.00 dBm
>> multicast TXQ:
>> qsz-byt qsz-pkt flows drops marks overlmt
>> hashcol tx-bytes tx-packets
>> 0 0 0 0 0 0 0 0 0
>> Connected to f4:92:bf:04:1a:ce (on wlp1s0)
>> SSID: aikhomenet
>> freq: 5180
>> RX: 38078401 bytes (68758 packets)
>> TX: 3039702 bytes (15006 packets)
>> signal: -62 dBm
>> rx bitrate: 117.0 MBit/s VHT-MCS 6 VHT-NSS 2
>> tx bitrate: 433.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 1
>>
>> bss flags: short-slot-time
>> dtim period: 2
>> beacon int: 100
>>
>
> Something certainly changed for your signal strength to drop from -53 to
> -62 dBm. The higher value is acceptable, but will not provide high data
> rates. The lower value is marginal.
Well, one of the other laptops (Intel nic) reports -68 dBm and pings are
solid 2ms. The one with realtek reports -61dBm and pings are 3.5ms+.
Never saw 2ms with Realtek in Fedora but I saw that in Windows10. But
probably Windows' ping calculates times differently :)
> There are some changes between kernel 6.2 and the current contents of
> the wireless-next repo, which is the code to be found in kernel 6.4 when
> it is released. Could you try the code in
> https://github.com/lwfinger/rtw88.git? This repo has the code found in
> wireless-next modified to build on older kernels. You would need to
> blacklist rtw88_8822ce. This sequence should do it for you:
>
> sudo dnf install git kernel-headers kernel-devel
> sudo dnf group install "C Development Tools and Libraries"
> git clone https://github.com/lwfinger/rtw88.git
> cd rtw88
> make
> sudo make install
> sudo touch /usr/lib/modprobe.d/50-blacklist-8822ce.conf
>
> As root, using your favorite editor, add the following line to the above
> file:
> blacklist rtw88_8822ce
>
> Then reboot. Report if there are any changes. This way, we will be able
> to determine if the problem has already been fixed.
My bad, I should have mentioned that I tried this one as well,
https://github.com/lwfinger/rtw88/commit/75e2c81 3weeks old, no
difference there.
And it does not look like there was any change related to my problem
since then, is it still worth trying the very latest version? Btw reboot
is not really required, it is Linux, not Windows, rmmod+modprobe should
do ;) Thanks,
--
Alexey
On 5/3/23 22:10, Alexey Kardashevskiy wrote:
> My bad, I should have mentioned that I tried this one as well,
> https://github.com/lwfinger/rtw88/commit/75e2c81 3weeks old, no difference there.
>
> And it does not look like there was any change related to my problem since then,
> is it still worth trying the very latest version? Btw reboot is not really
> required, it is Linux, not Windows, rmmod+modprobe should do ???? Thanks,
I added a bunch of stuff on April 24-25, so a 3-week old pull would have missed
some important stuff.
The problem with rmmod+modprobe is that the rtw88_core module is not removed,
certainly not with a 'sudo modprobe -rv rtw88_8822ce, and it is really easy to
get a mixed bunch. I get tired of explaining that to a bunch of newbies, thus I
recommend a reboot. Of course, I do not reboot.
Larry
On 5/5/23 01:04, Larry Finger wrote:
> On 5/3/23 22:10, Alexey Kardashevskiy wrote:
>> My bad, I should have mentioned that I tried this one as well,
>> https://github.com/lwfinger/rtw88/commit/75e2c81 3weeks old, no
>> difference there.
>>
>> And it does not look like there was any change related to my problem
>> since then, is it still worth trying the very latest version? Btw
>> reboot is not really required, it is Linux, not Windows,
>> rmmod+modprobe should do ???? Thanks,
>
> I added a bunch of stuff on April 24-25, so a 3-week old pull would have
> missed some important stuff.
>
> The problem with rmmod+modprobe is that the rtw88_core module is not
> removed, certainly not with a 'sudo modprobe -rv rtw88_8822ce, and it is
> really easy to get a mixed bunch. I get tired of explaining that to a
> bunch of newbies, thus I recommend a reboot. Of course, I do not reboot.
Turns out I had to reboot because of the module signature :-/
Anyway it does not appear to work any better. Below are bad ping and
good ping, the difference is moving laptop 2cm to the left. I believe
the right driver is loaded as the modules are "rtw_" and not "rtw88_".
It is quite bizarre how moving the laptop for a little bit helps and
moving it back does not necessarily put it in the bad state, may be
there is a microcrack in some PCB or something :-/
aik@aiemdeew ~> ping -c3 192.168.10.200 ; iw wlp1s0 link | grep signal
PING 192.168.10.200 (192.168.10.200) 56(84) bytes of data.
64 bytes from 192.168.10.200: icmp_seq=1 ttl=64 time=7707 ms
64 bytes from 192.168.10.200: icmp_seq=2 ttl=64 time=6677 ms
64 bytes from 192.168.10.200: icmp_seq=3 ttl=64 time=5653 ms
--- 192.168.10.200 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2054ms
rtt min/avg/max/mdev = 5653.382/6679.203/7706.911/838.350 ms, pipe 3
signal: -56 dBm
aik@aiemdeew ~> ping -c3 192.168.10.200 ; iw wlp1s0 link | grep signal
PING 192.168.10.200 (192.168.10.200) 56(84) bytes of data.
64 bytes from 192.168.10.200: icmp_seq=1 ttl=64 time=3.35 ms
64 bytes from 192.168.10.200: icmp_seq=2 ttl=64 time=3.48 ms
64 bytes from 192.168.10.200: icmp_seq=3 ttl=64 time=3.84 ms
--- 192.168.10.200 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.347/3.553/3.837/0.207 ms
signal: -55 dBm
aik@aiemdeew ~> modinfo rtw_8822ce
filename:
/lib/modules/6.2.9-100.fc36.x86_64/kernel/drivers/net/wireless/realtek/rtw88/rtw_8822ce.ko.xz
license: Dual BSD/GPL
description: Realtek 802.11ac wireless 8822ce driver
author: Realtek Corporation
alias: pci:v000010ECd0000C82Fsv*sd*bc*sc*i*
alias: pci:v000010ECd0000C822sv*sd*bc*sc*i*
depends: rtw_pci,rtw_8822c
retpoline: Y
name: rtw_8822ce
vermagic: 6.2.9-100.fc36.x86_64 SMP preempt mod_unload
sig_id: PKCS#7
signer: Custom MOK
sig_key: 0C:F6:31:12:B9:95:09:20:A6:62:E6:72:4F:D1:85:00:F4:A6:A9:B6
sig_hashalgo: sha256
signature: 9F:F1:74:86:E8:B6:63:FA:F5:EC:2C:84:02:75:63:DC:66:C8:99:92:
9D:A8:1E:2F:FB:5F:50:EE:DD:59:A5:EC:DE:5F:AB:8A:4C:F9:D3:8A:
CC:CE:BE:3B:55:C8:E9:D9:AF:12:D0:A4:DE:B7:FB:A4:44:B2:F0:96:
CD:E2:C0:69:0C:A8:EB:1C:9C:BF:A8:91:3E:D2:7F:AD:9B:7D:22:A4:
3F:33:8F:86:40:DD:B3:42:B9:96:5B:94:CD:0B:E3:38:A0:8E:4E:8C:
62:38:11:01:D6:16:EC:B6:E2:28:48:07:A0:C4:6C:6C:55:04:01:F6:
C6:82:7E:F9:DE:EA:D0:20:63:41:4F:0A:D8:27:56:49:F6:84:E2:B9:
21:DF:3E:4B:C2:A7:C6:0A:8C:B7:66:17:E5:81:13:D6:5E:CA:94:D1:
E7:60:EF:B1:9D:52:E0:64:F8:4D:C5:54:CE:EF:F5:DC:2F:AA:22:5C:
81:52:CE:AF:9B:FA:9B:8B:88:99:2F:2C:8E:6A:A3:44:58:3B:6B:08:
78:43:B1:E9:27:C9:43:E6:49:BB:86:0E:23:10:0E:05:33:0C:23:B0:
5E:47:92:EE:0B:96:EA:65:92:89:69:DC:73:50:1D:A5:96:5A:11:32:
C6:2A:69:7A:B6:FE:6A:22:7F:69:61:B1:9B:F1:CF:66
aik@aiemdeew ~> lsmod | grep rtw
rtw_8822ce 16384 0
rtw_8822c 499712 1 rtw_8822ce
rtw_pci 40960 1 rtw_8822ce
rtw_core 319488 2 rtw_8822c,rtw_pci
mac80211 1486848 2 rtw_core,rtw_pci
cfg80211 1273856 2 rtw_core,mac80211
--
Alexey
On 5/4/23 20:23, Alexey Kardashevskiy wrote:
>
>
> On 5/5/23 01:04, Larry Finger wrote:
>> On 5/3/23 22:10, Alexey Kardashevskiy wrote:
>>> My bad, I should have mentioned that I tried this one as well,
>>> https://github.com/lwfinger/rtw88/commit/75e2c81 3weeks old, no difference
>>> there.
>>>
>>> And it does not look like there was any change related to my problem since
>>> then, is it still worth trying the very latest version? Btw reboot is not
>>> really required, it is Linux, not Windows, rmmod+modprobe should do ???? Thanks,
>>
>> I added a bunch of stuff on April 24-25, so a 3-week old pull would have
>> missed some important stuff.
>>
>> The problem with rmmod+modprobe is that the rtw88_core module is not removed,
>> certainly not with a 'sudo modprobe -rv rtw88_8822ce, and it is really easy to
>> get a mixed bunch. I get tired of explaining that to a bunch of newbies, thus
>> I recommend a reboot. Of course, I do not reboot.
>
> Turns out I had to reboot because of the module signature :-/
>
> Anyway it does not appear to work any better. Below are bad ping and good ping,
> the difference is moving laptop 2cm to the left. I believe the right driver is
> loaded as the modules are "rtw_" and not "rtw88_". It is quite bizarre how
> moving the laptop for a little bit helps and moving it back does not necessarily
> put it in the bad state, may be there is a microcrack in some PCB or something :-/
>
>
> aik@aiemdeew ~> ping -c3 192.168.10.200 ; iw wlp1s0 link | grep signal
> PING 192.168.10.200 (192.168.10.200) 56(84) bytes of data.
> 64 bytes from 192.168.10.200: icmp_seq=1 ttl=64 time=7707 ms
> 64 bytes from 192.168.10.200: icmp_seq=2 ttl=64 time=6677 ms
> 64 bytes from 192.168.10.200: icmp_seq=3 ttl=64 time=5653 ms
>
> --- 192.168.10.200 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2054ms
> rtt min/avg/max/mdev = 5653.382/6679.203/7706.911/838.350 ms, pipe 3
> signal: -56 dBm
> aik@aiemdeew ~> ping -c3 192.168.10.200 ; iw wlp1s0 link | grep signal
> PING 192.168.10.200 (192.168.10.200) 56(84) bytes of data.
> 64 bytes from 192.168.10.200: icmp_seq=1 ttl=64 time=3.35 ms
> 64 bytes from 192.168.10.200: icmp_seq=2 ttl=64 time=3.48 ms
> 64 bytes from 192.168.10.200: icmp_seq=3 ttl=64 time=3.84 ms
>
> --- 192.168.10.200 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2003ms
> rtt min/avg/max/mdev = 3.347/3.553/3.837/0.207 ms
> signal: -55 dBm
>
>
> aik@aiemdeew ~> modinfo rtw_8822ce
> filename:
> /lib/modules/6.2.9-100.fc36.x86_64/kernel/drivers/net/wireless/realtek/rtw88/rtw_8822ce.ko.xz
> license: Dual BSD/GPL
> description: Realtek 802.11ac wireless 8822ce driver
> author: Realtek Corporation
> alias: pci:v000010ECd0000C82Fsv*sd*bc*sc*i*
> alias: pci:v000010ECd0000C822sv*sd*bc*sc*i*
> depends: rtw_pci,rtw_8822c
> retpoline: Y
> name: rtw_8822ce
> vermagic: 6.2.9-100.fc36.x86_64 SMP preempt mod_unload
> sig_id: PKCS#7
> signer: Custom MOK
> sig_key: 0C:F6:31:12:B9:95:09:20:A6:62:E6:72:4F:D1:85:00:F4:A6:A9:B6
> sig_hashalgo: sha256
> signature: 9F:F1:74:86:E8:B6:63:FA:F5:EC:2C:84:02:75:63:DC:66:C8:99:92:
> 9D:A8:1E:2F:FB:5F:50:EE:DD:59:A5:EC:DE:5F:AB:8A:4C:F9:D3:8A:
> CC:CE:BE:3B:55:C8:E9:D9:AF:12:D0:A4:DE:B7:FB:A4:44:B2:F0:96:
> CD:E2:C0:69:0C:A8:EB:1C:9C:BF:A8:91:3E:D2:7F:AD:9B:7D:22:A4:
> 3F:33:8F:86:40:DD:B3:42:B9:96:5B:94:CD:0B:E3:38:A0:8E:4E:8C:
> 62:38:11:01:D6:16:EC:B6:E2:28:48:07:A0:C4:6C:6C:55:04:01:F6:
> C6:82:7E:F9:DE:EA:D0:20:63:41:4F:0A:D8:27:56:49:F6:84:E2:B9:
> 21:DF:3E:4B:C2:A7:C6:0A:8C:B7:66:17:E5:81:13:D6:5E:CA:94:D1:
> E7:60:EF:B1:9D:52:E0:64:F8:4D:C5:54:CE:EF:F5:DC:2F:AA:22:5C:
> 81:52:CE:AF:9B:FA:9B:8B:88:99:2F:2C:8E:6A:A3:44:58:3B:6B:08:
> 78:43:B1:E9:27:C9:43:E6:49:BB:86:0E:23:10:0E:05:33:0C:23:B0:
> 5E:47:92:EE:0B:96:EA:65:92:89:69:DC:73:50:1D:A5:96:5A:11:32:
> C6:2A:69:7A:B6:FE:6A:22:7F:69:61:B1:9B:F1:CF:66
> aik@aiemdeew ~> lsmod | grep rtw
> rtw_8822ce 16384 0
> rtw_8822c 499712 1 rtw_8822ce
> rtw_pci 40960 1 rtw_8822ce
> rtw_core 319488 2 rtw_8822c,rtw_pci
> mac80211 1486848 2 rtw_core,rtw_pci
> cfg80211 1273856 2 rtw_core,mac80211
You do have the right modules. It would take a really strange environment where
moving the computer 2 cm would have a drastic effect.
I think I have gone as far as I can.
Larry
On 5/5/23 11:35, Larry Finger wrote:
> On 5/4/23 20:23, Alexey Kardashevskiy wrote:
>>
>>
>> On 5/5/23 01:04, Larry Finger wrote:
>>> On 5/3/23 22:10, Alexey Kardashevskiy wrote:
>>>> My bad, I should have mentioned that I tried this one as well,
>>>> https://github.com/lwfinger/rtw88/commit/75e2c81 3weeks old, no
>>>> difference there.
>>>>
>>>> And it does not look like there was any change related to my problem
>>>> since then, is it still worth trying the very latest version? Btw
>>>> reboot is not really required, it is Linux, not Windows,
>>>> rmmod+modprobe should do ???? Thanks,
>>>
>>> I added a bunch of stuff on April 24-25, so a 3-week old pull would
>>> have missed some important stuff.
>>>
>>> The problem with rmmod+modprobe is that the rtw88_core module is not
>>> removed, certainly not with a 'sudo modprobe -rv rtw88_8822ce, and it
>>> is really easy to get a mixed bunch. I get tired of explaining that
>>> to a bunch of newbies, thus I recommend a reboot. Of course, I do not
>>> reboot.
>>
>> Turns out I had to reboot because of the module signature :-/
>>
>> Anyway it does not appear to work any better. Below are bad ping and
>> good ping, the difference is moving laptop 2cm to the left. I believe
>> the right driver is loaded as the modules are "rtw_" and not "rtw88_".
>> It is quite bizarre how moving the laptop for a little bit helps and
>> moving it back does not necessarily put it in the bad state, may be
>> there is a microcrack in some PCB or something :-/
>>
>>
>> aik@aiemdeew ~> ping -c3 192.168.10.200 ; iw wlp1s0 link | grep signal
>> PING 192.168.10.200 (192.168.10.200) 56(84) bytes of data.
>> 64 bytes from 192.168.10.200: icmp_seq=1 ttl=64 time=7707 ms
>> 64 bytes from 192.168.10.200: icmp_seq=2 ttl=64 time=6677 ms
>> 64 bytes from 192.168.10.200: icmp_seq=3 ttl=64 time=5653 ms
>>
>> --- 192.168.10.200 ping statistics ---
>> 3 packets transmitted, 3 received, 0% packet loss, time 2054ms
>> rtt min/avg/max/mdev = 5653.382/6679.203/7706.911/838.350 ms, pipe 3
>> signal: -56 dBm
>> aik@aiemdeew ~> ping -c3 192.168.10.200 ; iw wlp1s0 link | grep signal
>> PING 192.168.10.200 (192.168.10.200) 56(84) bytes of data.
>> 64 bytes from 192.168.10.200: icmp_seq=1 ttl=64 time=3.35 ms
>> 64 bytes from 192.168.10.200: icmp_seq=2 ttl=64 time=3.48 ms
>> 64 bytes from 192.168.10.200: icmp_seq=3 ttl=64 time=3.84 ms
>>
>> --- 192.168.10.200 ping statistics ---
>> 3 packets transmitted, 3 received, 0% packet loss, time 2003ms
>> rtt min/avg/max/mdev = 3.347/3.553/3.837/0.207 ms
>> signal: -55 dBm
>>
>>
>> aik@aiemdeew ~> modinfo rtw_8822ce
>> filename:
>> /lib/modules/6.2.9-100.fc36.x86_64/kernel/drivers/net/wireless/realtek/rtw88/rtw_8822ce.ko.xz
>> license: Dual BSD/GPL
>> description: Realtek 802.11ac wireless 8822ce driver
>> author: Realtek Corporation
>> alias: pci:v000010ECd0000C82Fsv*sd*bc*sc*i*
>> alias: pci:v000010ECd0000C822sv*sd*bc*sc*i*
>> depends: rtw_pci,rtw_8822c
>> retpoline: Y
>> name: rtw_8822ce
>> vermagic: 6.2.9-100.fc36.x86_64 SMP preempt mod_unload
>> sig_id: PKCS#7
>> signer: Custom MOK
>> sig_key:
>> 0C:F6:31:12:B9:95:09:20:A6:62:E6:72:4F:D1:85:00:F4:A6:A9:B6
>> sig_hashalgo: sha256
>> signature:
>> 9F:F1:74:86:E8:B6:63:FA:F5:EC:2C:84:02:75:63:DC:66:C8:99:92:
>> 9D:A8:1E:2F:FB:5F:50:EE:DD:59:A5:EC:DE:5F:AB:8A:4C:F9:D3:8A:
>> CC:CE:BE:3B:55:C8:E9:D9:AF:12:D0:A4:DE:B7:FB:A4:44:B2:F0:96:
>> CD:E2:C0:69:0C:A8:EB:1C:9C:BF:A8:91:3E:D2:7F:AD:9B:7D:22:A4:
>> 3F:33:8F:86:40:DD:B3:42:B9:96:5B:94:CD:0B:E3:38:A0:8E:4E:8C:
>> 62:38:11:01:D6:16:EC:B6:E2:28:48:07:A0:C4:6C:6C:55:04:01:F6:
>> C6:82:7E:F9:DE:EA:D0:20:63:41:4F:0A:D8:27:56:49:F6:84:E2:B9:
>> 21:DF:3E:4B:C2:A7:C6:0A:8C:B7:66:17:E5:81:13:D6:5E:CA:94:D1:
>> E7:60:EF:B1:9D:52:E0:64:F8:4D:C5:54:CE:EF:F5:DC:2F:AA:22:5C:
>> 81:52:CE:AF:9B:FA:9B:8B:88:99:2F:2C:8E:6A:A3:44:58:3B:6B:08:
>> 78:43:B1:E9:27:C9:43:E6:49:BB:86:0E:23:10:0E:05:33:0C:23:B0:
>> 5E:47:92:EE:0B:96:EA:65:92:89:69:DC:73:50:1D:A5:96:5A:11:32:
>> C6:2A:69:7A:B6:FE:6A:22:7F:69:61:B1:9B:F1:CF:66
>> aik@aiemdeew ~> lsmod | grep rtw
>> rtw_8822ce 16384 0
>> rtw_8822c 499712 1 rtw_8822ce
>> rtw_pci 40960 1 rtw_8822ce
>> rtw_core 319488 2 rtw_8822c,rtw_pci
>> mac80211 1486848 2 rtw_core,rtw_pci
>> cfg80211 1273856 2 rtw_core,mac80211
>
> You do have the right modules. It would take a really strange
> environment where moving the computer 2 cm would have a drastic effect.
>
> I think I have gone as far as I can.
This turned out to be an hdmi cable via an usb-c->hdmi adapter, the
cable seemed decent as it can do hdmi2.0/4K/60Hz. I was starting ping,
making it stop by moving a laptop and then unpluging the adapter and
ping would resume the same instance. Bizarre. I replaced with another
dongle and cable, this time usb-c->displayport and things are great.
Sorry for the noise.
--
Alexey
On 5/24/23 01:29, Alexey Kardashevskiy wrote:
>
>
> On 5/5/23 11:35, Larry Finger wrote:
>> On 5/4/23 20:23, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 5/5/23 01:04, Larry Finger wrote:
>>>> On 5/3/23 22:10, Alexey Kardashevskiy wrote:
>>>>> My bad, I should have mentioned that I tried this one as well,
>>>>> https://github.com/lwfinger/rtw88/commit/75e2c81 3weeks old, no difference
>>>>> there.
>>>>>
>>>>> And it does not look like there was any change related to my problem since
>>>>> then, is it still worth trying the very latest version? Btw reboot is not
>>>>> really required, it is Linux, not Windows, rmmod+modprobe should do ???? Thanks,
>>>>
>>>> I added a bunch of stuff on April 24-25, so a 3-week old pull would have
>>>> missed some important stuff.
>>>>
>>>> The problem with rmmod+modprobe is that the rtw88_core module is not
>>>> removed, certainly not with a 'sudo modprobe -rv rtw88_8822ce, and it is
>>>> really easy to get a mixed bunch. I get tired of explaining that to a bunch
>>>> of newbies, thus I recommend a reboot. Of course, I do not reboot.
>>>
>>> Turns out I had to reboot because of the module signature :-/
>>>
>>> Anyway it does not appear to work any better. Below are bad ping and good
>>> ping, the difference is moving laptop 2cm to the left. I believe the right
>>> driver is loaded as the modules are "rtw_" and not "rtw88_". It is quite
>>> bizarre how moving the laptop for a little bit helps and moving it back does
>>> not necessarily put it in the bad state, may be there is a microcrack in some
>>> PCB or something :-/
>>>
>>>
>>> aik@aiemdeew ~> ping -c3 192.168.10.200 ; iw wlp1s0 link | grep signal
>>> PING 192.168.10.200 (192.168.10.200) 56(84) bytes of data.
>>> 64 bytes from 192.168.10.200: icmp_seq=1 ttl=64 time=7707 ms
>>> 64 bytes from 192.168.10.200: icmp_seq=2 ttl=64 time=6677 ms
>>> 64 bytes from 192.168.10.200: icmp_seq=3 ttl=64 time=5653 ms
>>>
>>> --- 192.168.10.200 ping statistics ---
>>> 3 packets transmitted, 3 received, 0% packet loss, time 2054ms
>>> rtt min/avg/max/mdev = 5653.382/6679.203/7706.911/838.350 ms, pipe 3
>>> signal: -56 dBm
>>> aik@aiemdeew ~> ping -c3 192.168.10.200 ; iw wlp1s0 link | grep signal
>>> PING 192.168.10.200 (192.168.10.200) 56(84) bytes of data.
>>> 64 bytes from 192.168.10.200: icmp_seq=1 ttl=64 time=3.35 ms
>>> 64 bytes from 192.168.10.200: icmp_seq=2 ttl=64 time=3.48 ms
>>> 64 bytes from 192.168.10.200: icmp_seq=3 ttl=64 time=3.84 ms
>>>
>>> --- 192.168.10.200 ping statistics ---
>>> 3 packets transmitted, 3 received, 0% packet loss, time 2003ms
>>> rtt min/avg/max/mdev = 3.347/3.553/3.837/0.207 ms
>>> signal: -55 dBm
>>>
>>>
>>> aik@aiemdeew ~> modinfo rtw_8822ce
>>> filename:
>>> /lib/modules/6.2.9-100.fc36.x86_64/kernel/drivers/net/wireless/realtek/rtw88/rtw_8822ce.ko.xz
>>> license: Dual BSD/GPL
>>> description: Realtek 802.11ac wireless 8822ce driver
>>> author: Realtek Corporation
>>> alias: pci:v000010ECd0000C82Fsv*sd*bc*sc*i*
>>> alias: pci:v000010ECd0000C822sv*sd*bc*sc*i*
>>> depends: rtw_pci,rtw_8822c
>>> retpoline: Y
>>> name: rtw_8822ce
>>> vermagic: 6.2.9-100.fc36.x86_64 SMP preempt mod_unload
>>> sig_id: PKCS#7
>>> signer: Custom MOK
>>> sig_key: 0C:F6:31:12:B9:95:09:20:A6:62:E6:72:4F:D1:85:00:F4:A6:A9:B6
>>> sig_hashalgo: sha256
>>> signature: 9F:F1:74:86:E8:B6:63:FA:F5:EC:2C:84:02:75:63:DC:66:C8:99:92:
>>> 9D:A8:1E:2F:FB:5F:50:EE:DD:59:A5:EC:DE:5F:AB:8A:4C:F9:D3:8A:
>>> CC:CE:BE:3B:55:C8:E9:D9:AF:12:D0:A4:DE:B7:FB:A4:44:B2:F0:96:
>>> CD:E2:C0:69:0C:A8:EB:1C:9C:BF:A8:91:3E:D2:7F:AD:9B:7D:22:A4:
>>> 3F:33:8F:86:40:DD:B3:42:B9:96:5B:94:CD:0B:E3:38:A0:8E:4E:8C:
>>> 62:38:11:01:D6:16:EC:B6:E2:28:48:07:A0:C4:6C:6C:55:04:01:F6:
>>> C6:82:7E:F9:DE:EA:D0:20:63:41:4F:0A:D8:27:56:49:F6:84:E2:B9:
>>> 21:DF:3E:4B:C2:A7:C6:0A:8C:B7:66:17:E5:81:13:D6:5E:CA:94:D1:
>>> E7:60:EF:B1:9D:52:E0:64:F8:4D:C5:54:CE:EF:F5:DC:2F:AA:22:5C:
>>> 81:52:CE:AF:9B:FA:9B:8B:88:99:2F:2C:8E:6A:A3:44:58:3B:6B:08:
>>> 78:43:B1:E9:27:C9:43:E6:49:BB:86:0E:23:10:0E:05:33:0C:23:B0:
>>> 5E:47:92:EE:0B:96:EA:65:92:89:69:DC:73:50:1D:A5:96:5A:11:32:
>>> C6:2A:69:7A:B6:FE:6A:22:7F:69:61:B1:9B:F1:CF:66
>>> aik@aiemdeew ~> lsmod | grep rtw
>>> rtw_8822ce 16384 0
>>> rtw_8822c 499712 1 rtw_8822ce
>>> rtw_pci 40960 1 rtw_8822ce
>>> rtw_core 319488 2 rtw_8822c,rtw_pci
>>> mac80211 1486848 2 rtw_core,rtw_pci
>>> cfg80211 1273856 2 rtw_core,mac80211
>>
>> You do have the right modules. It would take a really strange environment
>> where moving the computer 2 cm would have a drastic effect.
>>
>> I think I have gone as far as I can.
>
>
> This turned out to be an hdmi cable via an usb-c->hdmi adapter, the cable seemed
> decent as it can do hdmi2.0/4K/60Hz. I was starting ping, making it stop by
> moving a laptop and then unpluging the adapter and ping would resume the same
> instance. Bizarre. I replaced with another dongle and cable, this time
> usb-c->displayport and things are great. Sorry for the noise.
>
>
I am glad to hear that your problem is fixed. That explains why no one else was
seeing the problem. Cables can be a real hassle to debug.
I am having some difficulty in figuring out how usb-c is involved with a PCIe
adapter. Please send me your configuration via private E-mail.
Larry
Larry