QuadHD USB not stable on Debian

[brad112358]

Greetings. I recently purchased one of these to add some tuners to my MythTV setup and to test it for a couple of friends who are interested in MythTV as I want them to have a good experience.

I applied patches/mainline-extra/tip/90.usb.quadhd.xml692/* to my stock Debian kernel source (4.19.98 based). It built fine, and seemed to work at first, but as soon as the MythTV backend closed the device, it stopped working. I have been able to get it to work longer by commenting out the sleep hook in the mxl692_ops structure. It seemed that once it was put to sleep, it never worked again. I'm still seeing lots of errors in the kernel logs. A partial log is attached.

Have I missed another patch I need to get this working correctly? At one point, I tried patching with the full set of Ubuntu-bionic-4.15.0 patches, but even after fixing most of the obvious patch failures, the resulting kernel seemed to have the same issue.

Most of the errors seem to be related to i2c read/write errors.

Thanks! --Brad dmesg.log

[b-rad-NDi]

but if you remove the sleep callback everything is fine?

[b-rad-NDi]

This change is part of my local builds already, I just haven't committed them. We're aware of wake up issues.

[b-rad-NDi]

also, you should file a ticket on my media_tree repo, since you're just using the series from other there pretty much.

[brad112358]

but if you remove the sleep callback everything is fine?

No, better, but not fine. It works for longer without the sleep callback, but I still see the errors I attached and sometimes a tuner gets hung up somehow and stops working. Restarting the mythtv backend does not fix it, But un/re-plugging the USB cable and then restarting the backend seems to fix it. It sometimes runs for a day or two without problems.

[b-rad-NDi]

hmm...unfortunately my driver is a directly ported reference driver from maxlinear. We are currently triaging the issue with mxl, hopefully we can sort out something.

[brad112358]

but if you remove the sleep callback everything is fine?

No, better, but not fine. It works for longer without the sleep callback, but I still see the errors I attached and sometimes a tuner gets hung up somehow and stops working. Restarting the mythtv backend does not fix it, But un/re-plugging the USB cable and then restarting the backend seems to fix it. It sometimes runs for a day or two without problems.

[brad112358]

Sorry. Didn't mean to close this. Is there anything I can do to help resolve this? I'm happy to test any source code you'd like to throw my way or collect more debugging logs. I suppose I do need to decide soon if I should return the tuner. I purchased it directly from Hauppauge and I don't see a clear statement on the web site how long I have to return it.

[b-rad-NDi]

We're awaiting word from downstream on how they fixed the windows driver. I'm unsure if my linux driver is affected by the same bug, but this is an active work in progress.

[b-rad-NDi]

I haven't updated my media_tree repo yet, but I've updated the mxl692 series in this repo. I do not experience any of the symptoms that I previously did now. I can bang on all four tuners simultaneously and everything is happy. I think this was because of some ridiculously long delays in various functions, which I've reduced dramatically. Like sleeping all over the place for 1000ms originally and now my delays are <=50ms. I see zero errors. Lemme know what you find.

[brad112358]

Thanks, I have applied the updated mxl692 patches, but not the dvbcore patch. As before, the tuners are initially working, but with error messages reported. I'll let it continue to run to see if it fails to tune after some time as before.

Some of the kernel log messages have changed, but I'm still seeing lots of i2c write errors. For example: [ 2175.691954] mxl692 25-0063: firmware: direct-loading firmware dvb-demod-mxl692.fw [ 2189.670406] mxl692 25-0063: FAIL! 6 [ 2218.621518] em28xx 1-2.1:1.0: write to i2c device at 0xc6 failed with unknown error (status=10) [ 2218.621525] mxl692 21-0063: i2c write error! [ 2218.621529] mxl692 21-0063: FAIL! -121 [ 2218.621532] mxl692 21-0063: FAIL! -121 [ 2218.759553] mxl692 21-0063: i2c write error! [ 2218.759562] mxl692 21-0063: FAIL! -121 [ 2218.761574] mxl692 21-0063: FAIL! -110 [ 2218.851541] em28xx 1-2.1:1.0: write to i2c device at 0xc6 failed with unknown error (status=10) [ 2218.851548] mxl692 21-0063: i2c write error! [ 2218.851550] mxl692 21-0063: FAIL! -121 [ 2218.851552] mxl692 21-0063: FAIL! -121 [ 2218.893552] em28xx 1-2.1:1.0: write to i2c device at 0xc6 failed with unknown error (status=10) [ 2218.893560] mxl692 21-0063: i2c write error! [ 2218.893563] mxl692 21-0063: FAIL! -121 [ 2218.893566] mxl692 21-0063: FAIL! -121 [ 2219.943677] mxl692 19-0060: i2c write error! [ 2219.943684] mxl692 19-0060: FAIL! -121 [ 2219.945695] mxl692 19-0060: FAIL! -110 [ 2220.137702] em28xx 1-2.1:1.0: write to i2c device at 0xc0 failed with unknown error (status=22)

Let me know if you want full kernel logs.

[brad112358]

The tuners didn't work very long, I verified they were all 4 working when I sent the previous message, but when I checked just now, one tuner was still working, but at least two of them couldn't get a lock on any channel. Let me know if you want the full kernel logs. Thanks.

[b-rad-NDi]

What platform are you running on? I don't see any of these after letting a device run for an extended time. I mean, you're even failing just loading the firmware...which if that doesn't work, that tuner will just not work at all thereafter.

[brad112358]

As I said in the initial report, stock Debian kernel source (4.19.98 based). What makes you think the firmware loading failed?

[brad112358]

I only included messages from one line before the first sign of trouble which may have confused you. If you examine the time stamps, you will see that the trouble began well after the firmware was loaded. Probably when mythtv started actually using the tuners. I will attach the section of the kernel log starting when the tuner was plugged in and just before I started the mythtv service and tested all 4 tuners (which generated the initial errors) and ending after I noticed some tuners were not able to get a lock a few hours later. kern.log

[b-rad-NDi]

You mentioned kernel. You didn't mention amd64/armhf/etc.

For your errors to be meaningul you need to enable debugfs and then turn on function name printing so I know where the errors are coming from.

[b-rad-NDi]

... that would be options +pfl in case you were wondering.

Also, have you tried using the media_build system to build all the mainline tip drivers? You would have to patch in the mxl692 modifications, but it's fairly simple. That would show at least if this is a 4.19 specific issue, or it affects mainline tip as well.

[brad112358]

You mentioned kernel. You didn't mention amd64/armhf/etc.

Sorry. amd64.

[b-rad-NDi]

Let me know if you need any help testing media_build. It is easy to stuff in the mxl692 modifications. I just need to know if this is a 4.19 issue or that it also affects mainline media tree.

[brad112358]

OK. I finally found some time to work on this again. I grabbed media_build, patched for mxl692 and built and installed like this: git clone git://linuxtv.org/media_build.git cd media_build/ ./build cat ../../Ubuntu-media-tree-kernel-builder/patches/mainline-extra/tip/90.usb.quadhd.xml692/* | patch -p1 make sudo make install sudo update-initramfs -u sudo reboot.

Unfortunately, the modules it built and installed won't load. I'm getting "v4l2_common: disagrees about version of symbol v4l2_subdev_init", etc.

/lib/modules//build points to the correct headers from my kernel build (I built the kernel as a debian package and installed both the kernel image and the headers packages.)

Not sure what's causing the conflict. Is your media_tree kernel up to date on github? I tried that kernel early on, but ran into some unrelated issues and went back to the stock Debian kernel source. If it has your latest fixes, I could try that again.

[b-rad-NDi]

My media_tree github should be fairly recently refreshed. There is a new branch for mxl692. No functional differences, just excessive checkpatch work.

Unsure about the issue you're encountering. Sounds like a mismatch somewhere. I don't use the "build" script because it's not necessary. Instead I just issue the make targets directly:

make release DIR=<path to installed kernel build dir>
make -C linux/ download
make -C linux/ untar
<apply mxl692 patches here if necessary>
make -C v4l/

Since I'm typically building for embedded targets that's as far as I go, but i'm sure installing is probably something like

make -C v4l/ install

[brad112358]

Thanks for the shortcut hint; It would be faster not to build twice, but the result should be the same. I tried your media_tree from github yesterday after diffing it with the patch and concluding the differences were mostly cosmetic.

Unfortunately, it produces a kernel bug report and processes hang resulting in an unusable system. (backtrace below) Also, unfortunately, my 30 day return window on the QuadHD has expired. I'm sorry I haven't had more time to work on it. The next couple of weeks should be less busy for me so I will email and see if they want to give us more time to debug this.

I do have one other thought. Is it possible the reason you don't see the problems I see is application use patterns? I would think MythTV would be a popular use case for 4 tuners on Linux. Have you tried testing with MythTV? It shouldn't be hard to install on Ubuntu. I know it's more trouble to setup than other things you might use for testing, but there are good guides online. If you install it and start the backend and frontend and use the arrow and enter keys (m is menu) to go to advanced->Manage Recordings-> Schedule Recordings -> Program Guide to select several upcoming programs to record at once, it should reproduce my use case fairly well.

[b-rad-NDi]

I don't see any backtrace?

[shspvr]

LoL no MythTV is not a popular choice option as there are better option like Emby Server and setup NextPVR as M3U tuner which what I have setup under PoP!_OS 20.04 as my test rig box or you could just used NextPVR that way it is and there are few other option like Kaffeine TV, MeTV, SageTV, VDR.

[brad112358]

Sorry. I got interrupted and didn't notice I hadn't pasted the backtrace. [ 6.010766] kernel BUG at lib/list_debug.c:47! [ 6.012790] invalid opcode: 0000 [#1] SMP NOPTI [ 6.014827] CPU: 4 PID: 409 Comm: systemd-udevd Tainted: G E 5.6.0-rc1+ #6 [ 6.016870] Hardware name: Micro-Star International Co., Ltd MS-7C02/B450 TOMAHAWK (MS-7C02), BIOS 1.D0 11/07/2019 [ 6.018963] RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x4c [ 6.021063] Code: cc ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 98 f8 b0 a1 e8 1c e0 cc ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 28 f9 b0 a1 e8 08 e0 cc ff <0f> 0b 48 c7 c7 d8 f9 b0 a1 e8 fa df cc ff 0f 0b 48 89 f2 48 89 fe [ 6.023317] RSP: 0018:ffffb45240613ca8 EFLAGS: 00010246 [ 6.025580] RAX: 000000000000004e RBX: ffff98abf5e450c0 RCX: 0000000000000000 [ 6.027873] RDX: 0000000000000000 RSI: ffff98abfe9199a8 RDI: ffff98abfe9199a8 [ 6.030180] RBP: ffff98abf5e45000 R08: 000000000000048c R09: 0000000000aaaaaa [ 6.032479] R10: 0000000000000000 R11: ffffb4524b190420 R12: 0000000000000000 [ 6.034768] R13: ffffffffc1098000 R14: 000000000000005e R15: ffffffffa1cdab00 [ 6.037062] FS: 00007fa9531a5d40(0000) GS:ffff98abfe900000(0000) knlGS:0000000000000000 [ 6.039380] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.041705] CR2: 00007f00a800b028 CR3: 00000007ee21e000 CR4: 00000000003406e0 [ 6.044054] Call Trace: [ 6.046391] device_links_driver_bound+0x50/0x210 [ 6.048728] driver_bound+0x5f/0xf0 [ 6.051056] really_probe+0x211/0x3e0 [ 6.053355] ? driver_allows_async_probing+0x50/0x50 [ 6.055639] driver_probe_device+0xb4/0x100 [ 6.057928] ? driver_allows_async_probing+0x50/0x50 [ 6.060222] bus_for_each_drv+0x79/0xc0 [ 6.062518] device_attach+0xd4/0x160 [ 6.064811] bus_probe_device+0x87/0xa0 [ 6.067098] device_add+0x698/0x7b0 [ 6.069371] ? device_del+0x308/0x3f0 [ 6.071648] snd_hdac_device_register+0x11/0x50 [snd_hda_core] [ 6.073956] snd_hda_codec_configure+0x45/0x170 [snd_hda_codec] [ 6.076273] reconfig_store+0x4f/0x90 [snd_hda_codec] [ 6.078592] kernfs_fop_write+0xce/0x1b0 [ 6.080896] vfs_write+0xa5/0x1a0 [ 6.083199] ksys_write+0x59/0xd0 [ 6.085498] do_syscall_64+0x52/0x180 [ 6.087785] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 6.090075] RIP: 0033:0x7fa953986504 [ 6.092347] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d 05 f9 61 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53 [ 6.094781] RSP: 002b:00007fff03e8dfc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 6.097233] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fa953986504 [ 6.099698] RDX: 0000000000000001 RSI: 0000563f4c52a560 RDI: 0000000000000006 [ 6.102173] RBP: 0000563f4c52a560 R08: 00007fa9531a5d40 R09: 0000563f4c52d430 [ 6.104659] R10: 0000563f4c509970 R11: 0000000000000246 R12: 0000563f4c509970 [ 6.107144] R13: 0000000000000001 R14: 00007fa953a53760 R15: 0000000000000001 [ 6.109634] Modules linked in: nf_tables_set(E) nf_tables(E) nfnetlink(E) bnep(E) binfmt_misc(E) edac_mce_amd(E) kvm_amd(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) btusb(E) ledtrig_audio(E) btrtl(E) ghash_clmulni_intel(E) btbcm(E) btintel(E) snd_hda_codec_hdmi(E) uvcvideo(E) snd_hda_intel(E) videobuf2_vmalloc(E) snd_usb_audio(E+) snd_intel_dspcfg(E) videobuf2_memops(E) em28xx(E+) bluetooth(E) videobuf2_v4l2(E) snd_usbmidi_lib(E) tveeprom(E) aesni_intel(E) snd_hda_codec(E) crypto_simd(E) videobuf2_common(E) pl2303(E) snd_rawmidi(E) snd_seq_device(E) snd_hda_core(E) snd_hwdep(E) cryptd(E) drbg(E) snd_pcm(E) glue_helper(E) pcspkr(E) wmi_bmof(E) serio_raw(E) k10temp(E) sp5100_tco(E) snd_timer(E) ccp(E) usblp(E) videodev(E) rng_core(E) usbserial(E) joydev(E) mc(E) snd(E) ansi_cprng(E) soundcore(E) ecdh_generic(E) sg(E) ecc(E) rfkill(E) evdev(E) acpi_cpufreq(E) parport_pc(E) ppdev(E) lp(E) parport(E) nfsd(E) auth_rpcgss(E) [ 6.109677] nfs_acl(E) lockd(E) grace(E) sunrpc(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) ses(E) enclosure(E) scsi_transport_sas(E) sd_mod(E) t10_pi(E) sr_mod(E) cdrom(E) hid_generic(E) usbhid(E) hid(E) uas(E) usb_storage(E) radeon(E) i2c_algo_bit(E) ttm(E) ahci(E) drm_kms_helper(E) libahci(E) xhci_pci(E) cec(E) crc32c_intel(E) xhci_hcd(E) r8169(E) i2c_piix4(E) libata(E) drm(E) realtek(E) libphy(E) scsi_mod(E) usbcore(E) wmi(E) gpio_amdpt(E) gpio_generic(E) button(E) [ 6.133604] ---[ end trace be8e5077af24c2ec ]--- [ 6.137356] r8169 0000:22:00.0 enp34s0: Link is Down [ 6.137568] RIP: 0010:list_del_entry_valid.cold.1+0x12/0x4c [ 6.142656] Code: cc ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 98 f8 b0 a1 e8 1c e0 cc ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 28 f9 b0 a1 e8 08 e0 cc ff <0f> 0b 48 c7 c7 d8 f9 b0 a1 e8 fa df cc ff 0f 0b 48 89 f2 48 89 fe [ 6.145989] RSP: 0018:ffffb45240613ca8 EFLAGS: 00010246 [ 6.149290] RAX: 000000000000004e RBX: ffff98abf5e450c0 RCX: 0000000000000000 [ 6.152584] RDX: 0000000000000000 RSI: ffff98abfe9199a8 RDI: ffff98abfe9199a8 [ 6.155837] RBP: ffff98abf5e45000 R08: 000000000000048c R09: 0000000000aaaaaa [ 6.159011] R10: 0000000000000000 R11: ffffb4524b190420 R12: 0000000000000000 [ 6.162215] R13: ffffffffc1098000 R14: 000000000000005e R15: ffffffffa1cdab00 [ 6.165393] FS: 00007fa9531a5d40(0000) GS:ffff98abfe900000(0000) knlGS:0000000000000000 [ 6.168674] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.171986] CR2: 00007f00a800b028 CR3: 00000007ee21e000 CR4: 00000000003406e0

[b-rad-NDi]

Looks like some audio module is very unhappy.

Arguments about popularity aside, Plex/Emby/NextPVR are the most popular probably by a magnitude or more. I have had reports passed to me about mythtv triggering various errors in an assortment of drivers over the years. How/why it does cause instability I do not know, but because of that I only recommend running the absolute latest code base for mythtv and nothing distribution provided.

[shspvr]

Looks like some audio module is very unhappy.

Arguments about popularity aside, Plex/Emby/NextPVR are the most popular probably by a magnitude or more. I have had reports passed to me about mythtv triggering various errors in an assortment of drivers over the years. How/why it does cause instability I do not know, but because of that I only recommend running the absolute latest code base for mythtv and nothing distribution provided.

Ops I forgot about Plex it good option too but it doesn't have the features I want for recording as it toss everything in Movie or TV Show and has no dedicated OTA recording only folder separating my DVD or Blu-ray library, Those app are much easy to get configuration on first try and get up and running vs MythTV.

[brad112358]

I've run MythTV reliably for more than 15 years with several brands of v4l and dvb tuners, some of which I can no longer use because newer motherboards don't have PCI. It's not perfect, and has not always been trivial to keep everything working, especially through distribution upgrades, but overall, I have been quite happy with it. I've read about the alternatives mentioned here (some of which aren't PVR systems or open source) and haven't found a reason to switch so I'm not likely to switch right now.

Two different versions of the Hauppage two tuner USB devices work reliably with MythTV on my current system. If the application causes a driver to misbehave, I think that's a driver issue.

Do you still want me to try to rule out a kernel version problem by getting a newer kernel working? I suppose I can disable the intel hda sound support or blacklist the module for testing purposes.

[b-rad-NDi]

You need to find a way to run a mainline kernel to ensure the problem resides there. It makes it very hard for me to help you otherwise.

Are you sure that the device has enough power? Power issues can cause the exact issues you're encountering and this device takes up considerably more power than any other bus powered tuners hauppauge makes.

[b-rad-NDi]

Also for further debug you must enable entirely dynamic debug using options +pfl

[b-rad-NDi]

Also, small note, if you're not running Ubuntu this really isn't the best place to file a ticket. Please file future issues on the media_tree repo that is not Ubuntu specific.

[b-rad-NDi]

It doesn't appear like it's sucking too much juice, but my inline meter suggests it's peaking at 0.8A

[b-rad-NDi]

Wow...ok. Since you're using ancient software to trigger this I reverted to using ancient command line utilities in the theory they would be guilty as they do things in the same antiquated ways. azap was immediately able to trigger a bug on close. Something in the order of operations software doing things the "v3" way breaks powermode. I'm not sure if this is a dvb core issue related to v3 or what. Software that does things the "new v5" way are weirdly unaffected.

I have it addressed locally by moving the powermode check from set_frontend to just after the warm label in init. I'm trying to suss out why behaviour is so radically different from "old style" to "new style" dvb operations, but this fixes azap immediately.

[b-rad-NDi]

now to just suss out "v3 signal strength" always being 0.

[b-rad-NDi]

@brad112358 the patch is in my usb.mxl692.b branch

[brad112358]

OK. Sounds like I'm a little behind as I didn't see all of your comments from yesterday until just now, but I will send this along as I hope it will at least tell you if the problem you found is the same one I'm seeing...

I got your media_tree kernel as of commit aa71fa138489939a77c5ad26256e695666db388c to boot without the kernel BUG report and turned on debugging with +pfl as you requested. You can find the resulting (large) kernel logs here: https://drive.google.com/drive/folders/1c0NqY_3ncfD0k44fjyme3_r_fRkkGFZn?usp=sharing Please let me know when you have finished downloading them so I can free up the space.

The first log file includes from boot to confirming the tuning problem was happening after which I mounted debugfs and enabled debugging and allowed it to run for a few seconds to gather details related to the i2c write errors. I can send more of this log if you need it.

Then, after several minutes, I stopped the MythTV backend service and unplugged the tuner from the USB port and plugged it back in. The second, much larger log file captures the kernel messages (still with +pfl) as the device was initialized and a few seconds later, MythTV was restarted and the i2c errors started again. I hope this file will show everything that happens leading up to the errors.

Regarding power, in the past, I've sometimes connected it to a powered USB3 hub. In the case I provided logs for, I connected directly to a USB3 port on the back of the motherboard. I've always used the USB-C cable it came with.

Sorry I reported my bug in the wrong place. You mentioned this previously, but since I started with the patch here, it didn't make sense to me to report it elsewhere, nor, does it make sense to me to move this thread now.

I'm not sure why you are characterizing my version of MythTV as ancient, it was released in march of this year. I'll admit the 4.19 kernel is ancient, its just the Debian way. I often end up running a newer kernel.org kernel. If MythTV is not using the API in the best way, perhaps you would be kind enough to help those of us out who are still stuck in the dark ages and file a bug there? I think MythTV is still worth maintaining and I'm sure the developers who are still enhancing it would agree.

What should I try next? Could the errors I see be explained by the bug you just fixed? I'd like to try your latest changes. I've refreshed my copies of your repositories, but I don't seem to see it on github yet. Where do I find your usb.mxl692.b branch?

[b-rad-NDi]

it's on github since yesterday, i didn't give the correct name but if you just look at the branches it's obvious. hmmm...sh*t wait, I must not have pushed that commit. I'll push it now.

I didn't mean ancient version of mythtv, just that the software from what i understand still does everything the "old" way. It should work just fine, but as you've noted, and what I found with azap, "old" style "v3" operations immediately broke things.

This ticket should stay open, but all future issues should go to my media_tree, as that is where my actual kernel development happens and it's sync'd to my tree at linuxtv.org

[b-rad-NDi]

Yikes, i definitely do not want 700MB+ of logs lol. I'll look at the 38MB one, but you can stop entirely everything the moment you encounter failures. Everything after is just noise.

I grabbed the small one you, but I don't think it'll be informative if you only enabled dynamic debug after the failure.

If you could run the latest code including commit 7892310503 and then get a log from device connection to mere seconds after meltdown (hopefully no meltdown anymore) that's what I want.

[brad112358]

By failures, you mean any error, like the i2c errors? Strange thing is, they don't always cause trouble with tuning.

[b-rad-NDi]

well technically there shouldn't be any i2c errors of any sort. It would be informative to know where they're coming from if they're innocuous though.

[brad112358]

I can truncate more of the log before and after the first reported error if you want to see it. I already truncated a lot, the exercise of turning on all that dynamic logging for everything generated 10GB of logs. I included so much because, since I don't know if there is much correlation between reported errors and tuning failures in MythTv, I thought you might want to see everything from the start. Like you said, it's likely to be more interesting than to see what's going on after the first error has already happened.
I think I'll hand apply your power mode change (thanks for pushing it) to the 5.4.47 stock kernel.org kernel which I switched to today (on top of the mxl692 patches from your Ubuntu-media-tree-kernel-builder repository). Let me know if this won't be helpful and I'll try to get the media-tree kernel to boot again (It seems to be a matter of chance whether the sound driver bug shows up or not). Thanks!

[b-rad-NDi]

if you just apply the patches from the "b" branch including the "v3" fix I think it's ok. Dynamic debug can be noisy and tuning can help, but it's most informative just catching right up to the point of critical failure. Everything after that is probably repetitive.

[brad112358]

I must have missed some symbol name changes when I tried to manually apply the V3 fix so I ended up just copying the mxl692*.? files from the "b" branch into my 5.4.47 kernel. Unfortunately, I still saw tuning problems in my first test (without the extra debug) so I turned on the dynamic debug and replugged the tuners. I'm not sure if I captured an actual tuning failure with the dynamic debug on, but I did see errors reported. It takes a few minutes to reproduce any errors so the resulting log is very large again. At least this time I compressed it so download will be faster. Please look at the kernel_3.log.gz file using the link I sent previously. Thanks!

[b-rad-NDi]

omg lol. Now I see why your logs are so huge. I didn't mean to enable +pfl kernel wide hehehe. I only meant the drivers that were involved.

mxl692.c drivers/media/usb/em28xx/ drives/media/dvb-core/

etc.

[b-rad-NDi]

maybe not dvb-core since it is very noisy

[b-rad-NDi]

I can see a point of failure starting in the kernel 3 log. There's only <2k lines in the log that are pertinent. I might take a look if I'm bored, but I don't work on the weekends so no promise.

[brad112358]

I wondered about that, but you didn't specify more than "+pfl". I considered narrowing the focus of the dynamic logging when the first logs I tried were so large, but then I noticed what looked like failure messages from the USB subsystem that seemed to appear just before the i2c errors and I thought they might be interesting and since you didn't specify any files or modules, I figured you must want it all. I guess I should have asked.

[b-rad-NDi]

The usb errors could be insightful. I'll let you know what i find after i fully grok the log. Hopefully it's enough for me to get an idea of the root cause.

[brad112358]

Thanks for your patience with me. I've done some kernel driver development at work over the (many) years, but not as much lately and I started long before these facilities were available and haven't played with debugfs much. I look forward to what you might find next week. have a good weekend!

[b-rad-NDi]

Ok. Unfortunately dev_err does not abide by dynamic debug rules. I'll need you to do a search&replace changing all instances of dev_err to dev_dbg. I forgot that only dev_dbg pays heed to the dyndebug options, argh.

It seems you encounter a couple non-critical failures, and then one critical failure which causes the device to timeout on the next command. We need to isolate these parts.

[b-rad-NDi]

It seems like read_status or more particularly the ucb/ber function is what's dying first.