I noticed that usage of
mei_dsm_cb_func_hook is patched out in the Lantiq VDSL MEI driver in OpenWrt:
This is a callback function that would be defined in another kernel module which is currently missing from OpenWrt. The purpose of this callback is to send error samples to the VCE (Vectoring Control Entity).
Without those error samples, vectoring obviously can't work properly, so that would explain reports about instability with vectoring.
Copies of the missing driver are available at https://github.com/brunompena/dwr-966/tree/master/target/linux/lantiq/files/drivers/net/lantiq_ppa/vectoring and https://gitlab.com/gplmirror/fritzbox-7560-v1/-/tree/master/source-files-FRITZ.Box_7560-06.51/GPL-release_kernel/linux-3.10/drivers/net/lantiq_ppa/vectoring
It looks like the callback in the driver just sends the data on
ptm0 (this would be
dsl0 on OpenWrt).
Looking at the vectoring specification (ITU G.993.5), this implements the L2 Ethernet encapsulation of the backchannel. Alternatively, the error samples could also be transmitted using the eoc (embedded operation channel). I don't know where that is handled, but I suspect it is done entirely within the DSL firmware. Anyway, the actual encapsulation to be used is selected by the VCE, so both methods need to be supported.
If anyone here is using a VR9 device with OpenWrt on a vectoring line, the output of
dsl_cpe_pipe.sh dsmstatg would be interesting (and also
dsl_cpe_pipe.sh dsmsg to verify that vectoring is enabled). If the value
n_mei_dropped_no_pp_cb is non-zero, this means that error samples were dropped due to the missing callback.
I will probably test this myself soon, but I will have to use my actual DSL connection for that, and want to limit unnecessary interruptions of the line (I am not using an OpenWrt modem normally).