[15:46] <ParkerR> b-rad, So emm 4.17.2 (without any of your specific patches) has em28xx crashing on devie disconenct https://gist.github.com/parkerlreed/63fae74aaf28019c7ae50e1d92061de3
[15:46] <ParkerR> *umm
[15:46] <ParkerR> *device
[15:47] <ParkerR> *disconnect
[15:47] <ParkerR> Shit I cant type today lol
[15:48] <ParkerR> I remember an old xc5000 bug I reported where it was freeing a non existant instance and had a similar crash (but froze up the entire system). Wonder if it's possibly related
[15:49] <b-rad> with what device?
[15:49] <b-rad> 4.17.2 contains broken 01595 dualhd support
[15:50] <b-rad> the patch i pushed to fix that didn't make it until 4.18-rc1
[15:50] <ParkerR> It is dual HD
[15:50] <ParkerR> Ahh good to know
[15:51] <ParkerR> b-rad, Thanks!
[15:51] <b-rad> you'll notice it announces ts2, but never actually creates it
[15:51] <b-rad> so the tear down poops itself
[15:51] <b-rad> s/create/register/
[15:51] <ParkerR> Heh here's the xc5000 I was thinking of https://github.com/torvalds/linux/commit/856260a57cdfa5c121c7b7a6e816409bab07885c#diff-c2b7d8fe59e79b9f245c3b677e97d2a1
[15:52] <ParkerR> Also I think this was related https://github.com/torvalds/linux/commit/4961a5323f5d873e2170c5ef4f48538930e6df3e#diff-c2b7d8fe59e79b9f245c3b677e97d2a1
[15:52] <b-rad> i don't think thats, related, but i had to sort out something similar in lgdt3306a and si2157 with my analog stuff
[15:53] <ParkerR> No I meant to the other xc5000 lol
[15:53] <ParkerR> Just reminiscing on older bugs
[15:53] <b-rad> good ole bugs
[15:54] <b-rad> if you build 4.17 yourself my fix is a single line
[15:54] <ParkerR> b-rad, So did 4.17.2 partially pull in the second tuner patches causing that or was the break unrelated?
[15:55] <b-rad> they were merged correctly, but then em28xx had stack reduction retooling and an in the mix an important variable somehow got swapped with hardcode value
[15:55] <ParkerR> Ouch
[15:55] <ParkerR> Oh so the dual tuner is merged in 4.17.2 or 4.18 rc?
[15:55] <b-rad> well technically it's merged in 4.17.2, just totally broken :/
[15:56] <ParkerR> That single line fix or or is there something else in 4.17 killing it?
[15:56] <b-rad> 4.18 rc it's fixed, i just confirmed that this morning for someone else
[15:56] <ParkerR> *it or
[15:56] <ParkerR> Cool cool
[15:56] <ParkerR> I might doa  comile from git
[15:56] <b-rad> nope, the single line fix should be it
[15:57] <ParkerR> b-rad, Congrats on the merge! (Albeit a rocky one it seems lol)
[15:57] <b-rad> c'est la vie :)
[15:57] <b-rad> analog next and that one is still being difficult on ryzen
[15:57] <b-rad> i'm starting to very much dislike ryzen pcie
[15:57] <ParkerR> The DUal HD in particular?
[15:57] <b-rad> quadhd's now
[15:57] <ParkerR> Ahh
[15:58] <b-rad> dualhd does not have analog
[15:58] <b-rad> all our cx231xx stuff does now though
[15:58] <ParkerR> Ahh yeah. I meant in trerms of issues with Ryzen
[15:58] <ParkerR> All PCIe based?
[15:58] <b-rad> usb is fine on ryzen, only pcie is a hassle
[15:58] <ParkerR> Ahh ok
[15:58] <b-rad> cx231xx is usb
[15:58] <b-rad> SoloHD is basically a 955Q without analog
[15:59] <ParkerR> That's weird. Never even thought of newer PCIe implementations breaking stuff
[15:59] <b-rad> ryzen is too fast
[15:59] <ParkerR> TOO AST
[15:59] <ParkerR> &FAST
[15:59] <b-rad> xeon exhibits similar issues
[16:00] <ParkerR> Ahh so the timings arent quite right?
[16:00] <b-rad> those two platforms act a little racey, so it definitely feels timing related
[16:03] <ParkerR> b-rad, And we're off to the races :) https://i.imgur.com/GCEMEOU.png
[17:07] <ParkerR> b-rad, :/ https://gist.github.com/parkerlreed/3bdf0ed6b0bf907d6c7c42e13840f204 So the first issue was when I tried starting a second stream the first died completely. Couldnt restart. Unplugged and I got that. No error message related to the first card ying upon trying to use second
[17:07] <ParkerR> Linux inspiron15 4.18.0-rc1-g81e97f01371f #1 SMP PREEMPT Wed Jun 20 12:06:01 EDT 2018 x86_64 GNU/Linux
[17:08] <ParkerR> *dying
[17:08] <b-rad> hmmmm interesting, i'll add this to my queue
[17:09] <ParkerR> Thanks. Yeah seems odd. Fresh pull from git master
[17:09] <b-rad> i've been heavily testing 01595 lately using the tip drivers from last week, albeit on backported systems, and have not seen that
[17:10] <b-rad> and i specifically test for disconnect oopses because i hate them
[17:10] <ParkerR> So yeah I have 95. Weird
[17:10] <ParkerR> Heh
[17:11] <ParkerR> b-rad, Actually whats the single line fix from 4.17.2 so I can at least check my sources and see if its there
[17:15] <b-rad> https://git.linuxtv.org/media_tree.git/commit/drivers/media/usb/em28xx?id=01affb000e00cfa0a9e9954476ef50962eb8b168
[17:18] <ParkerR> Yep so thats right
[17:18] <ParkerR> I see another dvb->i2c_client_tuner = dvb_module_probe("si2157", NULL, where the i2c is still hardcoded to 0x60. Is that intended?
[17:19] <ParkerR> Line 1245
[17:20] <ParkerR> Err 1247
[17:20] <ParkerR> https://git.linuxtv.org/media_tree.git/tree/drivers/media/usb/em28xx/em28xx-dvb.c?id=01affb000e00cfa0a9e9954476ef50962eb8b168#n1247
[17:20] <b-rad> it's correct, since the dualhd has a second tuner it has another pid besides the default value
[17:20] <b-rad> for the second tuner
[17:21] <ParkerR> Ahh ok
[17:25] <ParkerR> b-rad, Following the loginc https://gist.github.com/parkerlreed/430f95b76dd4e1a3513d36bcc5257868 The first disconenct says #1 for the first but nothing for the second. And the second freeing device seems to be where it crashes. 
[17:25] <ParkerR> *logic
[17:26] <b-rad> well that sure sounds to me like that patch isn't applied
[17:26] <ParkerR> Is there a separate verbose mode I can do for em28xx or do I have to do a whole debug kernel?
[17:26] <b-rad> do you see registration of the second adapter?
[17:26] <ParkerR> Yeah thats the weird part
[17:27] <ParkerR> Umm lemme see
[17:27] <ParkerR> Didnt realize my first paste was cut off, woops https://gist.github.com/parkerlreed/732af6a5827b34df6101b56113798732
[17:28] <ParkerR> [  136.974704] em28xx 1-3:1.0: DVB: registering adapter 1 frontend 0 (LG Electronics LGDT3306A VSB/QAM Frontend)...
[17:28] <b-rad> yeh, looks fine
[17:28] <b-rad> i'll try and repro and fix this up if i can
[17:28] <ParkerR> And my line 1393 is deifnitely addr so I know that patch was there
[17:29] <ParkerR> Cheers
[17:54] <tjader> What do UCB, postBER and preBER mean on dvb-fe-tool -m?
[18:55] <b-rad> @ParkerR, confirming your issue
[18:56] <b-rad> i see oops on unplug
[18:56] <b-rad> i also see crazy amount of i2c errors the moment i do a second w_scan
[18:56] <b-rad> i have another couple em28xx devices i think, i'll try them, but this is abnormal and new to me
[19:02] <ParkerR> b-rad, Ahh damn. Might be what I ran into trying to tune the second tuner
[19:03] <ParkerR> Thanks for looking into it
[19:05] <b-rad> no i2c failures on tuner0 during scan by self, 3 i2c failures on tuner1 scan by self, total shtf when accessing both
[19:07] <ParkerR> Yep. I tried using both in mpv when it shat out
[19:13] <b-rad> same result using media_tree
[19:51] <b-rad> 4.15 with media tree dated april 18 is fine, as is 3.10 and 4.1 using backported drivers from tip media_tree
[20:50] <ParkerR> b-rad, Any luck?
[20:51] <b-rad> my 4.15 build did have the disconnect oops, but both tuners worked
[20:52] <b-rad> looking into now