Re: Bug#631945: HFSC warning issue

[Michal Soltys <soltys@ziu.info>]

On 11-07-11 17:07, 00bormoj@gmail.com wrote:
> Oops - my logs are again filled with the WARN_ON from
> net/sched/sch_hfsc.c:1427. Sorry for the confusion, it looks like
> "initialize parent's cl_cfmin properly in init_vf()" is not to blame.
>

Ah, ok then. It would be really weird if that was the actual cause. I
have few patches stacked for later, so it made me feel a bit uneasy :)

> This is an amd64 system. Vanilla kernel.org kernel except with fglrx
> (the amd/ati radeon proprietary driver - yes it is a router and an
> HTPC...) loaded. I should probably start bisecting then, but it's a
> little tough when it can take more than two days to trigger :(
>

 From what I can see, and if I haven't missed or misread anything:

That warning that gets triggered when next_time == 0 in
hfsc_schedule_watchdog() implies, that hfsc_dequeue() tried to dequeue a
packet, but no leaf had anything eligible for scheduling (realtime
criterion) and linksharing was upperlimited.

Now if there IS something to dequeue, then I don't see how next_time
could possibly be zero - that would mean there's no packet to schedule
at all. But if that happened, then hfsc_dequeue() would simply exit at
the very beginning due to: if (sch->q.qlen == 0) .

So it does look weird (like if something external messed with hfsc's
qlen) ...

Also note - the changes to sch_hfsc.c were pretty minimal since the last
kernel that worked for you. You might be searching for something else ...


ps.

You don't have to upperlimit every single class (which will cripple
linksharing between siblings) - if your aim is to match some interface's
speed, just set it in the single top class of your class hierarchy.