Hi Toke, > On 14 Dec 2019, at 13:59, Toke Høiland-Jørgensen <[email protected]> wrote: > > Thibaut <[email protected]> writes: > >>> On 14 Dec 2019, at 13:09, Jonathan Morton <[email protected]> wrote: >>> >>>> On 14 Dec, 2019, at 1:59 pm, Thibaut <[email protected]> wrote: >>>> >>>> I’m wondering if this could be an “use of uninitialized data” type of bug. >>> >>> This is why I wouldn't keep working on an old kernel that's full of vendor >>> patches. >> >> Forgive me for trying to use cake on a supported stable distro. >> >> All distros are full of vendor patches (OpenWRT is no exception). The >> subset of linux machines that use vanilla is ‘below measurable >> threshold’... > > The Linux kernel development moves at a fairly rapid pace, and sadly > it's not practical to have fully supported backwards compatibility in a > community effort such as CAKE. > > Now, this doesn't mean that we won't take patches to fix things for old > kernels; or even help with debugging on old versions, as you've already > seen in this thread. But the reality is unfortunately that the bulk of > this effort is going to have to be on the users running on those > kernels. I.e., you in this case. Such is open source: everyone scratches > their own itch and the end result is something that (mostly) works for > everyone :)
I understand that, I’m familiar with the kernel development philosophy (I used to be a contributor in a previous life). I’m also familiar with the fact that most kernel hackers tend to assume that the people who use their code and report bugs will know said code like the back of their hand and will be capable to spot where to look for the cause of the behavior they’re seing and provide a patch without further ado. I hope you can see why this cannot be the case especially with something as delicate and complex as a traffic shaper :) That’s why I’m happy to debug as much as possible and possibly try to cook a patch if needed, but without a bit of help/feedback (and thus interest) from the authors, this is a lost cause. Meanwhile, I can add that not all traffic crawls to a grinding halt: speedtests and fluctuating traffic (such as, in the case of the buildbots, the upstreaming of the build stdio) appear to be mostly unaffected (I see sustained traffic at line speed every now and then, especially during very verbose build output). But for some reason, when the rsync of the build results begins, cake appears adamant (at least when it exposes the offending behavior) that it must be killed with extreme prejudice ;P Would that ring any bell? Cheers, Thibaut _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
