> On Jul 2, 2018, at 7:04 PM, Pete Heist <[email protected]> wrote:
>
>
>
>> On Jul 2, 2018, at 6:14 PM, Toke Høiland-Jørgensen <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Aha! I think I figured out what is going on:
>>
>> The gen_stats facility will add an nlattr header at the beginning of the
>> qdisc stats, which is the toplevel TLV that contains all stats (and that
>> we put our stats inside). It stores a reference to this header, and when
>> all the per-qdisc callbacks have finished adding their stats, it goes
>> back and fixes up the length of the containing header.
>>
>> The problem is that on architectures that need padding, the padding TLV
>> is added *first*, which means that the nlattr pointer that is stored
>> before the callbacks are performed points to the padding TLV and not the
>> stats TLV. And so, when the header is fixed up, the result (from the
>> parser's perspective) is just a very big padding TLV.
>>
>> The options TLV is before the stats TLV, so the bug only occurs if the
>> options happen to have a length that means the stats will need padding.
>> Which is why messing with the number of options "fixes" the bug.
>>
>> Could you try applying the patch below (to the kernel) and see if that
>> resolves the issue, please?
>
> Awesome Toke! It looks like from Kevin’s email that it works for him, but it
> didn’t work for me the first time around. This may have to do with how I
> added the patch as I’m still not that familiar with OpenWRT’s build system
> (first kernel patch I tried). I wasn’t sure if it should go into generic or
> platform, for one, so I tried generic…is that right?
Ok, I got it to work after re-flashing with tftp. :) It looks like the OM2P is
not always successfully performing sysupgrades, perhaps due to its limited
memory (64M), but I’m not sure.
I still have my debugging in place and do still have one question. The pointer
in TCA_STATS2 is now valid, but there is still a pointer value in TCA_PAD,
which is pointing to a place 32 bits before TCA_STATS2. Is that expected?
root@OpenWrt:/tmp# tc -s -d qdisc show dev eth0
TCA_STATS2 val=00000007
TCA_PAD val=00000009
tb[TCA_UNSPEC]=00000000
tb[TCA_KIND]=773a73fc
tb[TCA_OPTIONS]=773a7408
tb[TCA_STATS]=773a772c
tb[TCA_XSTATS]=00000000
tb[TCA_RATE]=00000000
tb[TCA_FCNT]=00000000
tb[TCA_STATS2]=773a7494
tb[TCA_STAB]=00000000
tb[TCA_PAD]=773a7490
tb[TCA_DUMP_INVISIBLE]=00000000
tb[TCA_CHAIN]=00000000
tb[TCA_HW_OFFLOAD]=00000000
tb[TCA_INGRESS_BLOCK]=00000000
tb[TCA_EGRESS_BLOCK]=00000000
qdisc cake 8001: root refcnt 2 bandwidth unlimited diffserv3 triple-isolate rtt
100.0ms raw overhead 0
tca_stats 2000320300 tca_stats2 2000319636 tca_xstats 0
…
Also, if you agree, I’d like to see this tested on 32-bit ARM (George, or my
Raspi?) and 64-bit Intel, at least. What do you think?
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
