Robert Rust <[email protected]> wrote: >On Wed, Jun 27, 2012 at 4:05 PM, Andy Walls <[email protected]> >wrote: > >> Robert Rust <[email protected]> wrote: >> >> >On Wed, Jun 27, 2012 at 1:38 PM, Devin Heitmueller < >> >[email protected]> wrote: >> > >> >> On Wed, Jun 27, 2012 at 2:27 PM, Peter Schneider >> >> <[email protected]> wrote: >> >> > Sorry to say but I am not likely much more help here. To me it >> >does not >> >> > look promising as there may be a dead card if you get a signal >> >detected >> >> and >> >> > then no actual image. >> >> > >> >> > Thanks, >> >> > Peter >> >> >> >> There are numerous alternatives to it being a dead card. >> >> >> >> Is the firmware installed? Any errors in dmesg? >> >> >> >> Are you interacting with /dev/video0 or /dev/video1? You might be >> >> trying to read the raw video device, which won't work properly in >> >> mplayer without extra arguments. >> >> >> >> Have you tried catting the /dev/video0 to a file and see if it is >> >> non-zero length? >> >> >> >> Note you should be sure the mythbackend is stopped before doing >any >> >of >> >> this. >> >> >> >> Devin >> >> >> >> Firmware is installed. No errors. I've tried both using mplayer >and >> >dumping to a file. The file dump resulted in a 0 byte file (which >is >> >how I >> >ruled out the MythTV software as the problem). I did stop >mythbackend. >> >I've even gone so far as to replicate this problem on a fairly >> >bare-bones >> >Ubuntu 12.04 server install (which wouldn't have any of the MythTV >> >bits). >> > >> >The signal should be good strength as it's coming straight out of >the >> >wall >> >(unity gain distribution amplifier to ensure that). I'll post my >> >"dmesg | >> >grep cx18" below, but have noted that the version listed (1.5.1) is >> >significantly newer than what I had in my old system (1.2.0), which >is >> >why >> >I was experimenting with the Ubuntu 10.0.4 install (I now have 10, >11 >> >and >> >12 side-by-side on the new hardware). >> > >> >[ 6.449510] cx18: Start initialization, version 1.5.1 >> >[ 6.449542] cx18-0: Initializing card 0 >> >[ 6.449543] cx18-0: Autodetected Hauppauge card >> >[ 6.449585] cx18 0000:04:01.0: PCI INT A -> GSI 17 (level, low) >-> >> >IRQ 17 >> >[ 6.449599] cx18-0: Unreasonably low latency timer, setting to 64 >> >(was >> >32) >> >[ 6.461752] cx18-0: cx23418 revision 01010000 (B) >> >[ 6.750896] cx18-0: Autodetected Hauppauge HVR-1600 >> >[ 6.750897] cx18-0: Simultaneous Digital and Analog TV capture >> >supported >> >[ 7.025228] cs5345 17-004c: chip found @ 0x98 (cx18 i2c driver >#0-0) >> >[ 7.073037] cx18-0: Registered device video0 for encoder MPEG (64 >x >> >32.00 kB) >> >[ 7.073040] DVB: registering new adapter (cx18) >> >[ 7.249671] cx18-0: DVB Frontend registered >> >[ 7.249673] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 >kB) >> >[ 7.249701] cx18-0: Registered device video32 for encoder YUV (20 >x >> >101.25 kB) >> >[ 7.249726] cx18-0: Registered device vbi0 for encoder VBI (20 x >> >51984 >> >bytes) >> >[ 7.249749] cx18-0: Registered device video24 for encoder PCM >audio >> >(256 >> >x 4.00 kB) >> >[ 7.249751] cx18-0: Initialized card: Hauppauge HVR-1600 >> >[ 7.249786] cx18: End initialization >> >[ 7.441838] cx18-alsa: module loading... >> >[ 7.946958] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 >> >bytes) >> >[ 8.353145] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 >> >(141200 >> >bytes) >> >[ 8.363961] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) >> >[ 9.786496] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 >> >bytes) >> >[ 9.845990] cx18-0 843: verified load of v4l-cx23418-dig.fw >firmware >> >(16382 bytes) >> >_______________________________________________ >> >ivtv-users mailing list >> >[email protected] >> >http://ivtvdriver.org/mailman/listinfo/ivtv-users >> >> Hi Robert, >> >> Start a capture (cat /dev/video0 > foo.mpg ) and then cat >/proc/interrupts >> . You should see the interrupts handled for the cx18 driver >increasing. >> >> If not, then add a debug=0x1ff to the cx18 module options when >loading the >> module (or via echo 0x1ff > /proc/modules/cx18/parameters/debug) and >try >> another capture. You should get lots of debug in /var/log/messages >which >> might give insight into the problem. >> >> And for the record, top-posting is _not_ preferred. But in an era of >lame >> smartphone email clients it is forgivable. ;) >> >> Regards, >> Andy >> >> >That certainly provided a lot of additional messages, though from what >I've >read, some may be normal, e.g.: >[ 454.856839] cx18-0: irq: sending interrupt SW1: 8 to send >CX18_CPU_DE_SET_MDL >[ 454.868754] cx18-0: warning: failed to be awakened upon RPU >acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 12 msecs >[ 454.868788] cx18-0: api: CX18_CPU_DE_SET_MDL cmd 0x20040005 args >0x00000001 0x00dc0cd0 0x00000001 0x00000004 0x00008000 > >I'm not sure what constitutes a problem. I'd post log output but it's >about 650 lines from when I modprobed with debug to when I ended >capture. >Should I go ahead and send it? > >-Robert >_______________________________________________ >ivtv-users mailing list >[email protected] >http://ivtvdriver.org/mailman/listinfo/ivtv-users
Hi Robert, Sending it to the list if you want. If it bounces, you can send it directly to me. >From the one message set you culled it seems very likely that interrupts from >the CX23418 chip are not being processed by the cx18 driver's IRQ irq handler. This is likely a system level issue. What other drivers share the irq lines with the cx18 driver? See the output of cat /proc/interrupts. Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
