> On Jan 5, 2019, at 11:27 PM, Toke Høiland-Jørgensen wrote:
>
> Pete Heist writes:
>
>>> On Jan 5, 2019, at 9:10 PM, Toke Høiland-Jørgensen wrote:
>>>
>>> Well, it's the same WARN_ON(), and if that patch had been applied,
>>> debugging our issue would have been a lot harder, I think.
>>
Pete Heist writes:
>> On Jan 5, 2019, at 9:10 PM, Toke Høiland-Jørgensen wrote:
>>
>> Well, it's the same WARN_ON(), and if that patch had been applied,
>> debugging our issue would have been a lot harder, I think.
>
> Yikes, this is what I mean. I’d rather suffer the warning than be
>
Pete Heist writes:
> That first bug report looks decidedly similar to mine, but Toke would
> have to comment on the specifics. So far I see the patch to
> sch_codel.c you mentioned and another two-liner to remove the warning
> in hfsc.c (https://patchwork.ozlabs.org/patch/933611/). It would be
>
That first bug report looks decidedly similar to mine, but Toke would have to
comment on the specifics. So far I see the patch to sch_codel.c you mentioned
and another two-liner to remove the warning in hfsc.c
(https://patchwork.ozlabs.org/patch/933611/). It would be really good to know
that
Dear all,
I am most likely wrong, but did you have a look at
https://bugs.openwrt.org/index.php?do=details_id=1136 yet?
Especially https://bugzilla.kernel.org/show_bug.cgi?id=109581 and
https://www.spinics.net/lists/netdev/msg450655.html might be related to Pete's
bug.
Then again, I might be
Pete Heist writes:
>> On Jan 5, 2019, at 2:35 PM, Toke Høiland-Jørgensen wrote:
>>
>> Pete Heist writes:
>>
On Jan 5, 2019, at 2:10 PM, Toke Høiland-Jørgensen wrote:
Hmm, that's odd. Could you try adding this debugging line in
adjust_parent_qlen(), right before the
> On 5 Jan, 2019, at 5:34 pm, Pete Heist wrote:
>
> There’s nobody in MAINTAINERS for hfsc, so we may not get much of a response
> to any bug submissions...
Most likely it defaults to Eric Dumazet in that case.
- Jonathan Morton
___
Cake mailing
> On Jan 5, 2019, at 2:35 PM, Toke Høiland-Jørgensen wrote:
>
> Pete Heist writes:
>
>>> On Jan 5, 2019, at 2:10 PM, Toke Høiland-Jørgensen wrote:
>>>
>>> Hmm, that's odd. Could you try adding this debugging line in
>>> adjust_parent_qlen(), right before the sch->q.qlen += n line:
>>>
>>>
Pete Heist writes:
>> On Jan 5, 2019, at 2:10 PM, Toke Høiland-Jørgensen wrote:
>>
>> Hmm, that's odd. Could you try adding this debugging line in
>> adjust_parent_qlen(), right before the sch->q.qlen += n line:
>>
>> net_info_ratelimited("Adjusting parent qdisc %d with pkt +=
> On Jan 5, 2019, at 2:10 PM, Toke Høiland-Jørgensen wrote:
>
> Hmm, that's odd. Could you try adding this debugging line in
> adjust_parent_qlen(), right before the sch->q.qlen += n line:
>
> net_info_ratelimited("Adjusting parent qdisc %d with pkt += %d,
> len += %d",
>
Pete Heist writes:
> Ok, that fixes the compiler warnings, but I get this now. Same as
> before it’s repeated until reboot, stack sometimes changes but I
> always see sch_hfsc.c:1427 at the beginning:
Hmm, that's odd. Could you try adding this debugging line in
adjust_parent_qlen(), right
Pete Heist writes:
> Quick update to the trace because I had to apply the patch manually
> and missed one line to remove (qdisc_tree_reduce_backlog...), just so
> it doesn’t through off the addresses for you, but it still does the
> same thing:
Ah, my bad; you need to replace
Giving you this also, for how it’s set up...
IFACE=eth0
RATE=100mbit
tc qdisc add dev $IFACE root handle 1: hfsc default 1
tc class add dev $IFACE parent 1: classid 1:1 hfsc ls rate $RATE ul rate $RATE
tc class add dev $IFACE parent 1: classid 1:2 hfsc ls rate $RATE ul rate $RATE
tc qdisc add
Nope, egress on both eth0 and eth0.3300.
Dunce question, but I’m applying the patch manually because copying it from
email didn’t seem to work- how to get patch to work?
root@apu1a:~/src/sch_cake# patch sch_cake.c ../hfsc.patch
patching file sch_cake.c
patch: malformed patch at line 7:
On 5 January 2019 11:44:44 CET, Jonathan Morton wrote:
>> On 5 Jan, 2019, at 12:34 am, Toke Høiland-Jørgensen
>wrote:
>>
>> This basically means that we can't use CAKE as a leaf qdisc with GSO
>> splitting as it stands currently. I *think* the solution is for CAKE
>to
>> notify its parents;
Quick update to the trace because I had to apply the patch manually and missed
one line to remove (qdisc_tree_reduce_backlog...), just so it doesn’t through
off the addresses for you, but it still does the same thing:
root@apu1a:~/src/sch_cake# [ 697.089814] BUG: unable to handle kernel NULL
> On Jan 5, 2019, at 11:06 AM, Toke Høiland-Jørgensen wrote:
>
> Hmm, try this version for 3.16 - probably doesn't work on later kernels.
> I'll look into a proper backport once you've confirmed that it works :)
Thanks! Quick reminder, I’ve only seen this happen with hfsc, not when cake is
a
> On 5 Jan, 2019, at 12:34 am, Toke Høiland-Jørgensen wrote:
>
> This basically means that we can't use CAKE as a leaf qdisc with GSO
> splitting as it stands currently. I *think* the solution is for CAKE to
> notify its parents; could you try the patch below and see if it helps?
Is this also a
Pete Heist writes:
>> On Jan 4, 2019, at 11:34 PM, Toke Høiland-Jørgensen wrote:
>>
>> Pete Heist writes:
>>
>> This basically means that we can't use CAKE as a leaf qdisc with GSO
>> splitting as it stands currently. I *think* the solution is for CAKE to
>> notify its parents; could you try
19 matches
Mail list logo
