From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wilfried.Weissmann@gmx.at Date: Mon, 21 Jul 2003 08:49:41 +0000 Subject: Re: [LARTC] [HTB] htb_dequeue_tree assertion (kernel 2.4.21-ac4) Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org > devik wrote: > >>>If you read comment above htb_dequeue_tree, it should be called > >>>only when it is sure that there are packets inside of the level/prio. > >>>It is known by other HTB mechanism (per-level activity lists). > >>> > >>>Thus the bugtrap is to catch case where class was inserted > >>>into activity list because it had packets in its sub-qdisc > >>>but when we actually decide to dequeue - it has no packet. > >>>It is weird - can qdisc lose packets even when dequeue was > >>>not called ?? > >> > >>If you change the depth of the leave queue then it is possible to drop > >>packets or if you completely exchange the queue. Which would also > >>explain why the assertion only occurs when the configuration is altered. Now I verified that the problem is indeed the 0 queue length and not a NULL class pointer. > >=20 > >=20 > > Well, I agree that there is something wrong. Now it is neccessary to > > find scenario where it does happen so that it is fixed in right way. > > I have not much time these days to test these cases but your > informations > > would lead to following hypothesis: > >=20 > > Classe's child qdisc is replaced while old one still has nonzero queue. > > New empty qdisc is grafted under class instead. What about attached > > patch (it is against my latest version so you can see offset warnings) ? >=20 > This would not work if there are several intermediates HTB queues from=20 > the device to the leave queue. In this case every queue from the queue=20 > that was changed to the root has to be notified about the change. (The=20 > setup we want to use involves such a configuration.) Maybe it is better=20 > to just deactivate a class when a dequeue from its leave failes due to a = > zero queue length. If you are concerned about performance then an audit=20 > process could be implemented. For example to check one leave queue every = > 64 packets +/- initial random offset to create some entropy similar to=20 > the maximum mount count in the ext2 filesystem. Maybe there are better=20 > ways to do this. I am not so familiar with the code. >=20 > I will make some tests with the patch tomorrow. If my theory is true=20 > then it should still help a lot. With the patch applied it is much harder to find the right ceil settings to trigger the assertion, however it does not fix the problem. I also got the following log entry: HTB: dequeue bug (8,270045,270045), report it please ! Maybe this massages is just a side effect of the bug. Greetings, Wilfried >=20 > bye, > wilfried >=20 > >=20 > > devik > >=20 > >=20 > > ------------------------------------------------------------------------ > >=20 > > --- sch_htb.c 2003/07/05 10:37:11 1.21 > > +++ sch_htb.c 2003/07/20 07:24:59 > > @@ -1286,6 +1286,10 @@ static int htb_graft(struct Qdisc *sch,=20 > > return -ENOBUFS; > > sch_tree_lock(sch); > > if ((*old =3D xchg(&cl->un.leaf.q, new)) !=3D NULL) { > > + /* TODO: test it */ > > + if (cl->prio_activity) > > + htb_deactivate ((struct htb_sched*)sch->data,cl); > > + > > /* TODO: is it correct ? Why CBQ doesn't do it ? */ > > sch->q.qlen -=3D (*old)->q.qlen;=09 > > qdisc_reset(*old); --=20 +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Jetzt ein- oder umsteigen und USB-Speicheruhr als Pr=E4mie sichern! _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/