Posts by hbogert

meanwhile in ubuntu land, i'll probably have to wait months. Glad this is solved in libreelec though

okaaaay, well that was a waste of time, fix is already in: https://lore.kernel.org/linux-media/b3…[email protected]/

> media: anysee: accept read buffers of length 1 in anysee_master_xfer

Dear lord, the bisecting is rather arcane, only to be made worse by debian/ubuntu's irritating default to just friggin' rebuild the WHOLE thing after each iteration.

But, you came up with the 'modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules' one right?

That's a red herring I guess. The problem is definitely with this one:

c30411266fd67ea3c02a05c157231654d5a3bdc9 media: anysee: fix null-ptr-deref in anysee_master_xfer

diff --git a/drivers/media/usb/dvb-usb-v2/anysee.c b/drivers/media/usb/dvb-usb-v2/anysee.c
index fb6d99dea3..08fdb9e5e3 100644
--- a/drivers/media/usb/dvb-usb-v2/anysee.c
+++ b/drivers/media/usb/dvb-usb-v2/anysee.c
@@ -202,7 +202,7 @@ static int anysee_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msg,
       while (i < num) {
               if (num > i + 1 && (msg[i+1].flags & I2C_M_RD)) {
-                       if (msg[i].len > 2 || msg[i+1].len > 60) {
+                       if (msg[i].len != 2 || msg[i + 1].len > 60) {
                               ret = -EOPNOTSUPP;
                               break;
                       }

I'm no kernel developer, but the commit message states this is to fix a nullptr deref of msg[i].buf. If that's the intended behaviour, then why not check explicitly for msg.buff == NULL?

Well, I reverted the patch and introduced my proposed NULL check, so:

diff --git a/drivers/media/usb/dvb-usb-v2/anysee.c b/drivers/media/usb/dvb-usb-v2/anysee.c
index 08fdb9e5e3..9d72b7924c 100644
--- a/drivers/media/usb/dvb-usb-v2/anysee.c
+++ b/drivers/media/usb/dvb-usb-v2/anysee.c
@@ -202,7 +202,7 @@ static int anysee_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msg,

        while (i < num) {
                if (num > i + 1 && (msg[i+1].flags & I2C_M_RD)) {
-                       if (msg[i].len != 2 || msg[i + 1].len > 60) {
+                       if (msg[i].buf == NULL || msg[i].len > 2 || msg[i + 1].len > 60) {
                                ret = -EOPNOTSUPP;
                                break;
                        }

Lo and behold, it works again. Not sure if my NULL check is equivalently safe as the author of the patch intended. I'll try to get this upstreamed.

Maybe this is a Anysee e30 *combo* edge case we're running into? Maybe the msg.len is actually 2 for other variants of the E30 and 1 for the combo?

No idea how the device and the driver work with regards to initialization. Come to think, my only other linux kernel contribution was 15 years ago or something, I had to supply a patch for the E30C to get it working after suspend to ram.

Yeah I'm hitting this. Mighty irritating. Previously I just loaded an old kernel and be done with it, but it's getting harder and harder to stay on such an older kernel.

I'll try to debug somewhere this month. Haven't done a bisect with kernels yet, that'll be interesting. Anyone got an idea how to bisect this efficiently? VM in a VM with USB passthrough? It would really suck to do this manually.

The patch referred to in the IR Remote intermittently not working seems to be here:

https://github.com/torvalds/linux…450831c8766d12a

Not sure why HiassofT in said thread mentioned that it's in 5.10.80, it doesn't seem to be included in the upstream kernel until 5.16.

Kernel 5.10.80 seems to be debians backports version. Does LE use debian kernels?

Does the project honor requests for kernel upgrades? Kernels between 5.10.x-5.10.80 introduced a regression regarding the IR receiver in common devices. Can we bump the kernel version and release LE 10.0.3 ? See this thread as well, IR Remote intermittently not working

If this is not usually done, is it feasible for someone who hasn't built this project locally yet, to make my own version with a newer kernel?

The wife is not happy, you know the drill.

latest LE, 10.0.2, still has 5.10.76, so it's to be expected that I'm still experiencing this issue right?

So is there also a way to get the more common behaviour of having Kodi just boot up as normal, and then having a tty on one of the consoles (like ctrl-alt-x) as well?

Also, if you want to add a one-time kernel parameter like the "textmode" you say, can you do this without actually changing the config of syslinux on the filesystem?

C'mon, I just explained ssh will not work with wifi problems. I'm just perplexed that local console access has been made so difficult to activate. If someone can explain this I'm willing to put this in a wiki.

Yes; I searched.

Ctrl-alt-F3 is giving me a blinking underscore. I really need this to debug Wifi issues, i.e., SSH will not do it.

This is on x86-64 / generic / 8.2.5 btw

I can confirm this as well. The sync has never been really good, but it's even more hit and miss now. Some streams are fine, others are off by multiple hundreds of miliseconds.

/edit
I'm using the intel NUC with HDMI directly to the TV. So no extra receiver of any kind. I reset the playback configs to defaults in the GUI and only enabled the refresh rate change.
I'll follow up with a debug log soon.