Thanks Mike. I'm happy to know we have something solid to work from now. If something is broken, I'll usually stumble upon it - it's what I do best :-).
I'll wait to hear from you after you've had time to work on it. Let me know if there's any other info I can provide. -vincent On Tue, Jan 6, 2009 at 10:41 PM, Mike Isely <[email protected]> wrote: > > Uh-oh. See below... > > On Tue, 6 Jan 2009, fivenote wrote: > >> Great... We're getting somewhere... >> >> > lsmod | grep cx25840 >> cx25840 36656 0 >> v4l2_common 24576 7 >> tuner,cx25840,pvrusb2,cx8800,ivtv,cx2341x,bttv >> videodev 49024 8 >> tuner,cx25840,pvrusb2,cx8800,cx88xx,ivtv,bttv,v4l2_common >> i2c_core 31892 13 >> s5h1411,tda18271,tda8290,tuner,cx25840,pvrusb2,cx88xx,ivtv,bttv,i2c_algo_bit,v4l2_common,tveeprom,lirc_i2c >> >> > cat /sys/pvrusb2/*/debuginfo > > The stuff below are reports of various global control / state flags in > the driver: > >> Driver state info: >> driver: <ok> <init> <connected> <no decoder> <mode=analog> > > Note the "<no decoder>" flag. That just confirms the missing decoder > state. > >> pipeline: <idle> <configok> >> worker: <decode:quiescent> <encode:virgin> <encode:waitok> <usb:stop> >> <pathway:ok> >> state: error > > And that "state: error" is the driver realizing it isn't in a viable > state at the moment - because of the <no decoder> flag. This is > definitely a big piece of the puzzle. > > > This is the current state of which inputs are possible (no surprise > here): > >> Hardware supported inputs: television, dtv, composite, s-video > > > This reports current video buffer pipeline information. It's obviously > idle: > >> Bytes streamed=0 URBs: queued=0 idle=0 ready=0 processed=0 failed=0 > > > Here's the interesting part below. It's a list of which V4L I2C modules > are "attached" to the pvrusb2 driver. Each of these modules controls a > particular I2C bus target within the device. What you see for each item > listed is the name of the module (as given by the module itself), its > I2C address (after the "@"), any "handler" that the pvrusb2 driver has > associated with it (listed in parantheses), and a list of particular > classes of commands that the pvrusb2 driver will send to it (in square > brackets - normally that list is everything possible though in a few > cases it might be trimmed): > >> Attached I2C modules: > >> Hauppauge PVR150 @ 0x71 [v4l2_standard v4l2_audiomode v4l2_bcsh v4l2_volume >> v4l2_freq v4l2_crop v4l2_size v4l2_log] > >> cx25840' @ 0x44 [v4l2_standard v4l2_audiomode v4l2_bcsh v4l2_volume >> v4l2_freq v4l2_crop v4l2_size v4l2_log] > > Ouch! It's at this point where we should have seen "(handler: > pvrusb2-cx2584x-v4l)", similar to what you see below for the tuner > module. I smell a big fat rat. > > >> tuner' @ 0x42 (handler: pvrusb2-tuner) [v4l2_standard v4l2_audiomode >> v4l2_bcsh v4l2_volume v4l2_freq v4l2_crop v4l2_size v4l2_log] > > OK, so what this is telling us is that the cx25840 module showed up to > the party and the pvrusb2 "party host" driver failed to recognize it. > Had it been recognized, the pvrusb2 driver would have logically attached > a "handler" to that module - this enables additional specific bits of > communication. In this particular case, since the pvrusb2 driver didn't > spot the cx25840 module, it doesn't know who to send the "stream on" > command to when streaming is started. Not knowing that critical bit > triggers the "no decoder present" warning, sets the "<no decoder>" flag, > which places the driver into an error state, and the stream fails. > > FYI, in case you're curious why there's no "handler" registered for the > "Hauppauge PVR150 @ 0x71" instance, it's because in that case the > pvrusb2 driver need not do anything unique to deal with it - that module > is the linkage to the LIRC IR driver mentioned in the other thread. > > So the root cause is to find out why the pvrusb2 driver failed to > recognize the cx25840 module. This is new broken behavior, and I don't > believe there's anything you can do to accidentally cause this. The > pvrusb2 driver has not changed in several months now and this *was* > working last time I tested. The "big fat rat" I smell is that something > probably changed in v4l-dvb surrounding code which has broken the > pvrusb2 driver. (And I know that the I2C architecture changed a while > back, that might have precipitated this as various modules - e.g. > cx25840 - have been moved forward to the new design. This might get > tricky...) > > Going back to the in-kernel pvrusb2 driver will work around this. Of > course, running that driver is what led you here :-( The standalone > driver probably won't help since the issue that led you to the in-v4l > driver involved tuner problems in v4l-dvb. But now with the tuner > fixed, the analog side is busted because of this new cx25840 problem. > > [...] > >> >> >> Mike, ami I missing "ghandler: pvrusb2-cx2584x-v4l"? > > Yup. Exactly. :-( > > I'll need to investigate this ASAP. This issue is probably only in > v4l-dvb right now, but once it hits the kernel I'm going to get buried. > Unfortunately I have zero time right at this instant to work on it. I > will see what I can do this weekend. Probably on Sunday. Sorry about > this. Stay tuned. > > -Mike > > > -- > > Mike Isely > isely @ pobox (dot) com > PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 > _______________________________________________ > pvrusb2 mailing list > [email protected] > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > -- ~~~~~~~~~~~~~~~~~~~~ VAO - [email protected] ~~~~~~~~~~~~~~~~~~~~ _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
