Hello everybody!
There was a problem, my OrangePI R1 with the Armbian Stretch OS running works in the access point + bridge mode (hostapd & bridge-utils), and when the client downloads a large file from the network, the RTWHALXT process loads the CPU by 100% and rtw_xmit_thread by 20% (watched using top) as a result, the processor freezes. How to fix it?
Thanks in advance, sorry for my English I am from Uzbekistan.

17 minutes ago, RedCat said:

How to fix it?

 

Without logs (armbianmonitor -u) you are wasting time. And with logs is also hard since we can't cover a work of 1.000 people and on our expense. (by googling) I suspect this is some generic bug in the kernel drivers, but since you provide no exact information about the kernel and no logs, there is nothing more to speculate.

 

What logs except armbianmonitor -u are needed? A little later, I will try to provide all the logs and reports that are required. As far as I understood from the search, but the information is not enough that this problem is related to the OS kernel and WiFi drivers

Just now, RedCat said:

What logs except armbianmonitor -u are needed? A little later, I will try to provide all the logs and reports that are required. As far as I understood from the search, but the information is not enough that this problem is related to the OS kernel and WiFi drivers

armbianmonitor is a bare minimum and I could already give you some hints, but without it is totally pointless that you are asking anything. Armbian is too diverse out of the box and nobody around has supernatural abilities , that's why this is required.

5 hours ago, Igor said:

(armbianmonitor -u)

How to use it?

Type this into the console.

9 minutes ago, Igor said:

Type this into the console.

System diagnosis information will now be uploaded to(I pressed enter)
Could not find the database of available applications, run update-command-not-found as root to fix this

3 minutes ago, RedCat said:

System diagnosis information will now be uploaded to(I pressed enter)
Could not find the database of available applications, run update-command-not-found as root to fix this

Are you running armbian? Something looks corrupted or broken then. Can you start with a clean image?

yes

ARMBIAN 5.75 stable Debian GNU/Linux 9 (stretch) 4.19.20-sunxi
 

5 minutes ago, Igor said:

Could not find the database of available applications, run update-command-not-found as root to fix this

Kernel looks O.K., Did you perhaps uninstall something or run some dirty scripts? Do you have a working network connection?

On this system? Yes, this hardware distributes the Internet to my house, and it is now located about 500 meters from me

Spoiler

 

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.240.3  netmask 255.255.255.0  broadcast 255.255.255.255
        inet6 fe80::c274:2bff:feff:f42c  prefixlen 64  scopeid 0x20<link>
        ether c0:74:2b:ff:f4:2c  txqueuelen 1000  (Ethernet)
        RX packets 57503  bytes 3600845 (3.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 53900  bytes 35972762 (34.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
enxc0742bfff42c: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether c0:74:2b:ff:f4:2c  txqueuelen 1000  (Ethernet)
        RX packets 1200513  bytes 1190307502 (1.1 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1154809  bytes 176479396 (168.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 02:42:26:2e:9a:e0  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 39
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 16  bytes 1296 (1.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16  bytes 1296 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::d6b7:61ff:feaa:31b3  prefixlen 64  scopeid 0x20<link>
        ether d4:b7:61:aa:31:b3  txqueuelen 1000  (Ethernet)
        RX packets 1193979  bytes 212348235 (202.5 MiB)
        RX errors 0  dropped 107872  overruns 0  frame 0
        TX packets 1206367  bytes 1232094064 (1.1 GiB)
        TX errors 0  dropped 5 overruns 0  carrier 0  collisions 0

 

Edited April 26, 20197 yr by Tido
added spoiler

2 minutes ago, RedCat said:

On this system? Yes, this hardware distributes the Internet to my house, and it is now located about 500 meters from me

I am looking for this:

igorp@bananapim2plus:~$ sudo su
root@bananapim2plus:/home/igorp# armbianmonitor -u
System diagnosis information will now be uploaded to http://ix.io/1HfY
Please post the URL in the forum where you've been asked for.

 

root@orangepi:~# armbianmonitor -u
System diagnosis information will now be uploaded to http://ix.io/1HfY
Please post the URL in the forum where you've been asked for.

And..... Nothing...

1 hour ago, RedCat said:

And..... Nothing...

This must work. Please start with a clean image, use our way of creating AP mode and try to recreate this problem. Then we might be able to solve something. I am out of ideas.

6 hours ago, Igor said:

use our way of creating AP mode

And you can tell about this method, I know only one way to programmatically create an access point, this is hostapd

... and our scripts are using (patched/optimised/fixed) hostapd. Its better than stock Debian OOB. We need known/the same environment to fight possible bugs.

Wrote on mobile

I have the same problem with my Orange Pi Zero Plus (Not Plus 2), RTWHALXT and RTW_XMIT_THREAD make the CPU spike to 100% when I download something.

Weirdly, I think there was this 2 times when it just started working really well, and used pretty much no CPU, but after a reboot the issue came back.

It's probably a kernel or driver bug.

I even tried updating to Linux 5.2 using armbian-config and the results are the same.

@Igor Have you heard of anyone else with similar problems with the rtl8189fs driver (RTL8189FTV chip)?

On 8/20/2019 at 9:12 PM, Click said:

I even tried updating to Linux 5.2 using armbian-config and the results are the same.

 

There were some changes in 5.3.y but I am not sure this is fixed. In theory it should be enough if you change to nightly repository and update (also in armbian-config).

On 4/26/2019 at 3:06 PM, RedCat said:

And..... Nothing...

Did you use the command armbianmonitor -u as root-user or with sudo?

2 hours ago, Igor said:

 

There were some changes in 5.3.y but I am not sure this is fixed. In theory it should be enough if you change to nightly repository and update (also in armbian-config).

I just upgraded to nightly and installed linux 5.3, so far it seems to be solved. I even tested with iperf3.

Well. It seems that the problem started again.

I quit trying and stopped using the builtin wifi.

Hello,

 

Since a few moment, I got that same issue multiple times a day: RTWHALXT takes all CPU and freezes an Orange Pi PC plus that never had such issues.

I found this might be related to WiFi driver and so I removed WiFi for now, keeping only pure NIC link.

 

We'll see...

this is a fucking bug in realtek, bugs exist since many year ago and realtek wont fix it!

it is a POWER-SAVE function issue in AP-mode

 

when realtek wifi work as AP mode, and STA go to SLEEP mode, this bug may happen

This should be solved in https://github.com/armbian/build/pull/3697 (see https://github.com/jwrdegoede/rtl8189ES_linux/pull/71)

Has the problem been solved yet?