On jeu., 2016-03-03 at 16:24 -0800, Tom Herbert wrote:
> I suppose that case is protected by est_lock and e->bstats == NULL.
Yes, c7de2cf053420d63bac85133469c965d4b1083e1 was supposed
to fix some issues ...
On Thu, Mar 3, 2016 at 3:58 PM, Tom Herbert wrote:
> On Thu, Mar 3, 2016 at 3:52 PM, Eric Dumazet wrote:
>> On jeu., 2016-03-03 at 14:24 -0800, Tom Herbert wrote:
>>> This a kernel based on 3.10. We believe the lockups coincide with
>>> removing/readding qdiscs.
>>
>> You could backport 64153ce0a
On Thu, Mar 3, 2016 at 3:52 PM, Eric Dumazet wrote:
> On jeu., 2016-03-03 at 14:24 -0800, Tom Herbert wrote:
>> This a kernel based on 3.10. We believe the lockups coincide with
>> removing/readding qdiscs.
>
> You could backport 64153ce0a7b61b2a
> ("net_sched: htb: do not setup default rate estim
On jeu., 2016-03-03 at 14:24 -0800, Tom Herbert wrote:
> This a kernel based on 3.10. We believe the lockups coincide with
> removing/readding qdiscs.
You could backport 64153ce0a7b61b2a
("net_sched: htb: do not setup default rate estimators"),
unless you desperately want these rate estimators...
This a kernel based on 3.10. We believe the lockups coincide with
removing/readding qdiscs.
Thanks,
Tom
Mar 3 14:19:24 kernel: [2611792.157733] BUG: soft lockup - CPU#5
stuck for 22s! [swapper/5:0]
Mar 3 14:19:24 kernel: [2611792.158925] Modules linked in:
netconsole mpt2sas raid_class k10tem
On Tue, Mar 1, 2016 at 3:16 PM, Tom Herbert wrote:
> We are seeing a number of softlockups occurring with HTB upon removing
> the qdisc. We are still attempting to repro the exact circumstances,
> however looking at the code I'm very suspicious of this block in
> net_tx_action and its interaction
On mar., 2016-03-01 at 15:16 -0800, Tom Herbert wrote:
> We are seeing a number of softlockups occurring with HTB upon removing
> the qdisc. We are still attempting to repro the exact circumstances,
> however looking at the code I'm very suspicious of this block in
> net_tx_action and its interacti
We are seeing a number of softlockups occurring with HTB upon removing
the qdisc. We are still attempting to repro the exact circumstances,
however looking at the code I'm very suspicious of this block in
net_tx_action and its interaction with dev_deactivate (called through
tc_modify_qdisc):
