I just installed !7.01 Rc1 and SQM. I received the following errors after the section Configuring packages
SQM: ERROR: QDISC codel is NOT useable.
SQM: ERROR: QDISC pie is NOT useable.
SQM: ERROR: QDISC sfq is NOT useable.
The device is a HooToo TM-02 travel router with 8/32mb. The installation did not indicate any other issues and I have yet to configure or test. Can someone please shed some light on what this indicates?
Installing luci-app-sqm (1.1.2-1) to root...
Installing sqm-scripts (1.1.2-1) to root...
Installing tc (4.4.0-8) to root...
Installing kmod-sched-core (4.4.42-1) to root...
Installing kmod-sched-cake (4.4.42+2017-01-21-69449f3c-1) to root...
Installing kmod-ifb (4.4.42-1) to root...
Installing iptables-mod-ipopt (1.4.21-2) to root...
Installing kmod-ipt-ipopt (4.4.42-1) to root...
Installing iptables-mod-conntrack-extra (1.4.21-2) to root...
Installing kmod-ipt-conntrack-extra (4.4.42-1) to root...
Those errors are likely just cosmetic and harmless.
To my knowledge codel, pie and sfq have are not used by the included scripts in SQM, but the software still (unnecessarily) checks for them, as SQM has originally been designed to be extendable and enable writing personal scripts using a wide selection of qdiscs.
Why the error materialised now, is due to the change in kmod-sched and kmod-sched-core contents. Two small "core" qdiscs (htb, tbf) were moved from the larger kmod-sched to kmod-sched-core, and SQM was changed to depend only on the smaller kmod-sched-core (without pie, sfq and codel):
This is unfortunately not that simple to remove as we sytill want to allow users to select sfq, pie and codel in the GUI, if and only if those qdiscs are available so we need to check them. We also use the same function to check availability of qdisc at run time where it is an ERROR if the selected qdisc is not functional. I agree that in RangerZ's case the ERROR label is a bit overeager, and an INFO label might be more appropriate (I still believe we should let the users know).
Mmh, maybe we can set the log-level for that message dependent on whether this is the generic check or whether it is the .qos-script specific one... Let me think about this...
not that simple, simple.qos and simplest.qos will honor the seected qdisc and use for example pie instead of fq_codel if the user selects pie in the qdisc drop down list. So we really want to populate that drop-down list with all qdiscs we know how to handle. That said in the lost we creare we are missing pfifo_fast and bfifo...
As you point out this will need to be solved by playing with the logging level for the different verify_qdisc invocations. I might have a go at that tonight.
To be explicit, the code in question does not try to detect all qdiscs, but basically to figure out whch of the supported leaf qdiscs are available as we only want our users to select from available qdiscs.
PLease note that this just cropped up since we escalated the not useable messages from info to error, as otherwise failures during the attempt to run an actual .qos-script simply failed silently, which seems even worse that the log messages that started this thread. But this is just for perspective on how we got here, I fully agree that we want/need to fix that. Heck we might even just log a single line, listing the missing qdiisc with a pointer which packet might contain them (if they are missing in the first place).