"Comm: tc Tainted: P W O" messages in the log

[Volt]

With Adaptive QOS enabled, I regularly get the "Comm: tc Tainted: P W O" messages in the log on RT-AX56U. They usually appear when playing media over DLNA using Samsung TV, but I'm not 100% sure that this is the root cause. This issue occurs on both 384 and latest 386 ASUSWRT branches. Does anyone know whether these are errors or just information messages? If I understand right, the "tainted" message per se in not an error, it can just mean that a proprietary kernel module was loaded, but who knows. Looks like they also appear on RT-AX86U, so the issue is definitely not model-specific.
Thanks in advance!

 

[RMerlin]

If I understand right, the "tainted" message per se in not an error, it can just mean that a proprietary kernel module was loaded, but who knows.

That's correct. What this message is telling you is that the "tc" command has crashed, which is rather odd since this is just a basic iproute2 command using to configure routing and QOS. Never seen any other reports of crashes from that command, so it could be an issue with your router.

 

[Volt]

That's correct. What this message is telling you is that the "tc" command has crashed, which is rather odd since this is just a basic iproute2 command using to configure routing and QOS. Never seen any other reports of crashes from that command, so it could be an issue with your router.

Hmm, probably you are right. But what I found is that the same problem is reported here for RT-AX86U (latest firmware), and another user in the next post (looks like he uses RT-AX88U) confirmed that he sees similar messages too.

 

[Volt]

I think I finally figured out what is causing this error (for reference, I get exactly the same error as mentioned in the link in the previous post about RT-AX86, that is first goes the net/sched/sch_htb.c:568 htb_qlen_notify error, and then Comm: tc Tainted: P W O 4.1.52 #2).

In this post regarding the incorrect classification of traffic it was mentioned that the "Learn-From-Home" category is made up of "Audio and Video Streaming" plus "Web Surfing" categories. As a result, if the latter two are above the "Learn-From-Home" category, the traffic will never be classified as "Learn-From-Home". The opposite is also true, that is if the "Learn-From-Home" category is on top, the "Audio and Video Streaming" category will never be reached.

Previously, I always had "Audio and Video Streaming" on top of "Learn-From-Home", but placing "Learn-From-Home" above the "Audio and Video Streaming" category makes the issue disappear. I don't know whether this is an issue with firmware or Trend Micro signatures, but something's not right with how QOS categories are configured.

 

[slyderz]

I think I finally figured out what is causing this error (for reference, I get exactly the same error as mentioned in the link in the previous post about RT-AX86, that is first goes the net/sched/sch_htb.c:568 htb_qlen_notify error, and then Comm: tc Tainted: P W O 4.1.52 #2).

In this post regarding the incorrect classification of traffic it was mentioned that the "Learn-From-Home" category is made up of "Audio and Video Streaming" plus "Web Surfing" categories. As a result, if the latter two are above the "Learn-From-Home" category, the traffic will never be classified as "Learn-From-Home". The opposite is also true, that is if the "Learn-From-Home" category is on top, the "Audio and Video Streaming" category will never be reached.

Previously, I always had "Audio and Video Streaming" on top of "Learn-From-Home", but placing "Learn-From-Home" above the "Audio and Video Streaming" category makes the issue disappear. I don't know whether this is an issue with firmware or Trend Micro signatures, but something's not right with how QOS categories are configured.

I will give this a try and see if it fixes the issue for me.

 

[Volt]

Arghhhh, these messages appeared in the log again, this time after three days of usage. I give up.

 

[Volt]

Unfortunately, even after updating to the latest firmware 3.0.0.4.386_45898 and performing a factory reset, I still regularly get the following messages when Adaptive QOS is enabled:

Oct 12 06:57:06 kernel: ------------[ cut here ]------------
Oct 12 06:57:06 kernel: WARNING: CPU: 2 PID: 5640 at net/sched/sch_htb.c:568 htb_qlen_notify+0x6c/0x70()
Oct 12 06:57:06 kernel: Modules linked in: tdts_udbfw(O) init_addr(  (null) -   (null)), core_addr(bf0aa000 - bf0aedd8)
Oct 12 06:57:06 kernel:  tdts_udb(PO) init_addr(  (null) -   (null)), core_addr(bf22b000 - bf249a34)
Oct 12 06:57:06 kernel:  tdts(PO) init_addr(  (null) -   (null)), core_addr(bfc09000 - bfc43790)
.......
Oct 12 06:57:07 kernel:  [last unloaded: nf_conntrack_ftp]

Oct 12 06:57:07 kernel: CPU: 2 PID: 5640 Comm: tc Tainted: P        W  O    4.1.52 #2
Oct 12 06:57:07 kernel: Hardware name: Generic DT based system
Oct 12 06:57:07 kernel: [<c0026e60>] (unwind_backtrace) from [<c0022c38>] (show_stack+0x10/0x14)
Oct 12 06:57:07 kernel: [<c0022c38>] (show_stack) from [<c047cda4>] (dump_stack+0x8c/0xa0)
.......
Oct 12 06:57:07 kernel: ---[ end trace 6da1d91f41d54698 ]---

Does anyone else have such messages in the log? And what could be the cause?

 

[Volt]

A small update. Based on the reports from other users, this error periodically occurs on RT-AX56U, AX58U, AX82U and (rarely) AX86U and still has not been fixed in 3.0.0.4.386_49XXX and Merlin 386.7_2. This error is quite easy to reproduce:

1. Make sure that Adaptive QOS is enabled.
2. Run a speed test on www.speedtest.net a couple of times from your desktop/laptop Web browser, regardless of the operating system (was tested on Safari on Mac and Chrome/Firefox on Windows, but did not try it on mobile).
3. Disconnect the client on which the test was run from the WiFi and wait for one hour.
4. Exactly one hour later observe the error in the log.

This message could have been ignored, but I'm not sure that it does not affect QOS. In a couple of days, I periodically start experiencing severe bufferbloat that goes away after disabling and immediately re-enabling QOS back again.