Le jeu. 28 mars 2019 à 20:18, Mauro Carvalho Chehab <mchehab+samsung@xxxxxxxxxx> a écrit : > > Em Thu, 28 Mar 2019 19:48:35 +0100 > Samuel CHEMLA <chemla.samuel@xxxxxxxxx> escreveu: > > > Hi, > > Please, don't top post. > > > > > > 1) I did reproduce the bug with a serial console, but the serial > > console was also frozen, and there was no message before freeze. > > The only way for a machine to freeze even on serial console is due to > a very serious Kernel or hardware bug, like a bad lock/semaphore. > > > 2) I also tried a powered USB HUB but it didn't change anything. > > Ok. > > > 3) I tried DVBJet, from https://github.com/lightful/DVBdirect , it is > > a tuner that directly does ioctl on linux kernel DVB device. > > I couldn't reproduce the issue with DVBJet. > > I don't know DVBJet. If it uses the same Kernel drivers, maybe > it could then be a race issue: send commands on a slower way to > the Kernel would be solving the issue. > > > It's been running for almost 48Hrs now, without a crash. > > I collect all PIDs on the multiplex, just like dvbv5-zap, so the USB > > port is solicited at it's maximum. > > > > That makes me think it is not a hardware issue. > > I'm pretty sure dvbv5-zap can still improve, and it already did when > > you fixed: struct arguments args = {}; > > Everything can be improved, but the thing is that we need first to > discover the root cause :-) > > Can you post on pastebin (or equivalent) the dmesg with the > DVBJet running? Maybe it could be printing some Kernel messages > that might help to discover what's going wrong. Here is the dmesg: https://pastebin.com/3XRim4XL Just look at the code, it's quite straightforward, just a few ioctl. > > Btw, could you also apply this patch: > https://patchwork.linuxtv.org/patch/55274/ OK, I'll give it a try and provide feedback > > It is probably unrelated, but this is the kind of bug that could cause > such issues. > > > > > > > Regards > > > > Le mar. 26 mars 2019 à 16:31, Mauro Carvalho Chehab > > <mchehab+samsung@xxxxxxxxxx> a écrit : > > > > > > Em Tue, 26 Mar 2019 16:10:33 +0100 > > > Samuel CHEMLA <chemla.samuel@xxxxxxxxx> escreveu: > > > > > > > Hi, > > > > > > > > > > > > > Earlier you said "random hangs are back". When this happens, does the whole > > > > > device become unresponsive or just dvbv5-zap? > > > > The device completely freeze, you can't even switch numlock on/off. > > > > > > dvbv5-tools can't hang the machine. this is very likely happening due to > > > a Kernel crash. > > > > > > > I said "the issue is back", it is because I **thought** it was gone. > > > > To be more precise: > > > > - on raspberry zero W, the issue is gone since Mauro's patch > > > > (https://git.linuxtv.org/v4l-utils.git/commit/?id=22b06353227e04695b1b0a9622b896b948adba89) > > > > - on raspberry 2, the issue, it is still there and the patch has no > > > > effect (the issue was and is still there) > > > > > > RPi2 has a serious issue with their USB ports: on devices that require > > > more than a few mW to work, it causes several device disconnection and > > > re-connection, as it cannot sustain the required 5V. > > > > > > Depending on how fast this happens, it could be triggering some Kernel > > > bug. > > > > > > That affects most V4L and DVB devices. You should either use a powered > > > USB 2.0 hub (with may be problematic, as the USB host driver on RPi > > > has issues - and may cause data loss on high sustained ISOC traffic, > > > specially when used with hubs) or a device that has its own power > > > supply, like DVBSky T680C or S960. > > > > > > > > Since this issue is "back", > > > > > I wouldn't be surprised this is unrelated to the fixes in 1.12.7 and 1.16.4. > > > > The issue doesn't appear anymore on raspberry zero W since Mauro's commit. > > > > So it did improve on that platform. > > > > > > > > > It would be useful to see the output from dmesg (best thing would be after > > > > > the issue occurs). > > > > You can't, device is frozen. > > > > Logs are not flushed to disk, and journalctl -f freeze before showing anything > > > > > > You can use a serial port in order to get the logs. On a serial console, > > > use something like: > > > > > > # dmesg -n 8 > > > > > > In order to make sure it will display all Kernel messages at console. > > > > > > > > > > > > Also what dvb hardware are you using? > > > > I reproduced it with different two tuners: rtl2832U from RTL-SDR.COM > > > > and a TerraTec Cinergy T Stick+ > > > > > > None of them supports an external power supply. > > > > > > > You can found all the details here: > > > > https://bugs.launchpad.net/raspbian/+bug/1819650 > > > > > > > > > > > > Sam > > > > > > > > > > > > Le mar. 26 mars 2019 à 14:26, Sean Young <sean@xxxxxxxx> a écrit : > > > > > > > > > > Hi Sam, > > > > > > > > > > On Tue, Mar 26, 2019 at 08:35:44AM +0100, Samuel CHEMLA wrote: > > > > > > Hi, > > > > > > > > > > > > > > > > > > I am struggling with valgrind because it always complain with either : > > > > > > ASan runtime does not come first in initial library list; you > > > > > > should either link runtime to your application or manually preload it > > > > > > with LD_PRELOAD > > > > > > -> When I LD_PRELOAD, I'm getting a segfault, but I couldn't find > > > > > > any core dump > > > > > > > > > > > > or, if I link statically libasan with -static-libasan: > > > > > > Shadow memory range interleaves with an existing memory mapping. > > > > > > ASan cannot proceed correctly. ABORTING. > > > > > > ASan shadow was supposed to be located in the > > > > > > [0x00007fff7000-0x10007fff7fff] range. > > > > > > > > > > > > > > > > > > I retested again on my raspberry zero W, and I confirm i cannot > > > > > > reproduce the hang. > > > > > > Your fix did work on that device. > > > > > > I am testing with same OS (raspbian with latest updates, same kernel), > > > > > > same configure options, same USB dongle... :-( > > > > > > The only differences are CPU architecture (armv6 vs armv7), memory > > > > > > constraints, and I was not using the same channels.conf, I'll fix that > > > > > > today and re-check > > > > > > > > > > Earlier you said "random hangs are back". When this happens, does the whole > > > > > device become unresponsive or just dvbv5-zap? Since this issue is "back", > > > > > I wouldn't be surprised this is unrelated to the fixes in 1.12.7 and 1.16.4. > > > > > > > > > > It would be useful to see the output from dmesg (best thing would be after > > > > > the issue occurs). > > > > > > > > > > Also what dvb hardware are you using? > > > > > > > > > > Thanks, > > > > > > > > > > san > > > > > > > > > > > > > > > > > > > > > > > Sam > > > > > > > > > > > > On 25/03/2019 18:08, Mauro Carvalho Chehab wrote: > > > > > > > > > > > > Em Mon, 25 Mar 2019 17:33:30 +0100 > > > > > > Samuel CHEMLA <chemla.samuel@xxxxxxxxx> escreveu: > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > I'm afraid I'm coming with sad news. > > > > > > I just tried both stable-1.12 and stable-1.16 on a raspberry pi 2, and > > > > > > random hangs are back (see https://bugs.launchpad.net/raspbian/+bug/1819650 > > > > > > ). > > > > > > I previously test both branches on a raspberry zero and issues were gone > > > > > > (same raspbian version). > > > > > > There may be more memory issues somewhere... > > > > > > > > > > > > Could you test it with valgrind? > > > > > > > > > > > > Sam > > > > > > > > > > > > Le jeu. 21 mars 2019 ŕ 20:59, Gregor Jasny <gjasny@xxxxxxxxxxxxxx> a écrit : > > > > > > > > > > > > Hello, > > > > > > > > > > > > On 21.03.19 12:30, Mauro Carvalho Chehab wrote: > > > > > > > > > > > > I went ahead and cherry-picked the relevant patches to -1.12, -1.14 and > > > > > > -1.16, and tested both dvbv5-zap and dvbv5-scan with all versions. So, > > > > > > > > > > > > we can > > > > > > > > > > > > release a new minor version for all those stable branches. > > > > > > > > > > > > After the patches, on my tests, I didn't get any memory leaks or > > > > > > double-free issues. > > > > > > > > > > > > I issues a new 1.12, 1.14, and 1.16 release. > > > > > > > > > > > > Thanks, > > > > > > Gregor > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Mauro > > > > > > > > > > > > Thanks, > > > Mauro > > > > Thanks, > Mauro
