Ok, my reboots were because I need to compile with om-watchdog support, otherwise the OM2P’s hardware watchdog reboots every few minutes. Thus, my sysupgrades were not _actually_ working (watchdog was interrupting them), thus the unknown symbols / dependency problems, etc, so that’s behind me. :/
And yes, I get no tin stats without the patch. With the patch, I get tin stats as expected. This is probably nothing new. I also compiled on a Raspi 2 (32-bit ARM) running Debian 9.4, and it works as expected without the patch. This probably just confirms what George reported, because I think his wrt1900acs also uses 32-bit ARM. So yes, MIPS 32-bit, both le and be are both fails. What next? We could test more archs, but it might be more productive to attempt to figure it out in the code when I can at least repro it on MIPS. You mentioned earlier netlink_parse_nested doesn’t seem to handle 64-bit values but I’m not seeing where that is. I’m getting my head around how stats work so just writing out loud…looks like there are qstats from struct Qdisc then the tin stats which are probably custom for Cake and stored at some address obtained from qdisc_priv, which is right after the regular Qdisc struct. Interesting. I’m searching now for how this data ends up in tc’s hands, which looks like happens in cake_print_xstats with parse_rtattr_nested, then the printing gets underway, and at some point if st[TCA_CAKE_STATS_TIN_STATS] is true it gets into the tin printing business. What’s the condition that fails to make the tin stats not be printed? Best I know is to add debugging statements to figure it out, which I might give a try later today. Am I on the right track? > On Jul 1, 2018, at 9:18 AM, Pete Heist <[email protected]> wrote: > > Ok, so I’ve got to figure out what’s up with my build in general, so I’m > blowing away my source tree and will build master without any patches. > > I don’t know if the kernel panics and unknown symbols are related somehow, > but they’re not helping(!) so I’ll try to get past that. I don’t actually get > logs in /sys/kernel/debug/crashlog, so I can’t even prove it’s a panic, but > it’s rebooting that usually happens just as I do something net related, like > start typing in ssh or do an scp, after some period of inactivity. If it’s > reproducible on an unpatched build I’ll head over to the OpenWRT universe. > > (the stats alignment is just proportional vs fixed fonts- they look fine in > vim) > >> On Jul 1, 2018, at 4:37 AM, Georgios Amanakis <[email protected]> wrote: >> >> The stats got mangled in by the email, in the terminal they are >> properly aligned. >> >> >> ---------- Forwarded message ---------- >> From: Georgios Amanakis <[email protected]> >> Date: Sat, Jun 30, 2018 at 10:35 PM >> Subject: Re: [Cake] Cake on openwrt - falling behind >> To: Pete Heist <[email protected]> >> >> >> I just tested this on my wrt1900acs but it is behaving as it should. I >> used Kevin's RFC patches for iproute2 and kmod-sched-cake. >> >> root@lede:/tmp# tc -s qdisc show dev eth0 >> qdisc cake 8004: root refcnt 9 bandwidth 2500Kbit diffserv3 >> triple-isolate split-gso rtt 100.0ms raw overhead 0 >> Sent 122745 bytes 691 pkt (dropped 0, overlimits 419 requeues 0) >> backlog 0b 0p requeues 0 >> memory used: 6416b of 4Mb >> capacity estimate: 2500Kbit >> min/max network layer size: 42 / 1186 >> min/max overhead-adjusted size: 42 / 1186 >> average network hdr offset: 13 >> >> Bulk Best Effort Voice >> thresh 156248bit 2500Kbit 625Kbit >> target 116.3ms 7.3ms 29.1ms >> interval 232.6ms 102.3ms 124.1ms >> pk_delay 0us 196us 8.6ms >> av_delay 0us 13us 1.3ms >> sp_delay 0us 2us 38us >> backlog 0b 0b 0b >> pkts 0 414 277 >> bytes 0 38367 84378 >> way_inds 0 0 0 >> way_miss 0 20 2 >> way_cols 0 0 0 >> drops 0 0 0 >> marks 0 0 0 >> ack_drop 0 0 0 >> sp_flows 0 1 0 >> bk_flows 0 0 1 >> un_flows 0 0 0 >> max_len 0 206 1186 >> quantum 300 300 300 >> >> root@lede:/tmp# opkg list-installed | grep cake >> kmod-sched-cake - 4.14.50+2018-06-26-0520a6cb-1 >> >> root@lede:/tmp# uname -a >> Linux lede 4.14.50 #0 SMP Wed Jun 27 21:48:32 2018 armv7l GNU/Linux >> >> George >> >> On Sat, Jun 30, 2018 at 7:20 PM, Pete Heist <[email protected]> wrote: >>> Ok, same result (unknown symbols and routine crashing) after a make clean >>> and re-build, but I just force installed the kmod-sched-cake package with >>> --force-depends and it seems to work. This reproduces it, right? no stats >>> and the debug output? >>> >>> root@LEDE:~# tc qdisc add dev eth0 root cake >>> root@LEDE:~# tc -s -d qdisc show dev eth0 >>> qdisc cake 8001: root refcnt 2 bandwidth unlimited diffserv3 triple-isolate >>> rtt 100.0ms raw overhead 0 >>> tca_stats 2005579564 tca_stats2 0 tca_xstats 0 >>> calling print_tcstats_attr() >>> print_tcstats_attr() >>> got stats >>> Sent 9070 bytes 66 pkts (dropped 0, overlimits 0) >>> got xstats 0 tca_stats 2005579564 tca_stats2 0 tca_xstats 0 >>> >>> root@LEDE:~# cat /proc/cpuinfo >>> system type : Atheros AR7240 rev 2 >>> machine : OpenMesh OM2P >>> processor : 0 >>> cpu model : MIPS 24Kc V7.4 >>> BogoMIPS : 265.42 >>> wait instruction : yes >>> microsecond timers : yes >>> tlb_entries : 16 >>> extra interrupt vector : yes >>> hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, >>> 0x0ffb, 0x0ffb] >>> isa : mips1 mips2 mips32r1 mips32r2 >>> ASEs implemented : mips16 >>> shadow register sets : 1 >>> kscratch registers : 0 >>> package : 0 >>> core : 0 >>> VCED exceptions : not available >>> VCEI exceptions : not available >>> >> _______________________________________________ >> Cake mailing list >> [email protected] >> https://lists.bufferbloat.net/listinfo/cake > _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
