On Wed, Jun 27, 2012 at 5:07 PM, Robert Rust <[email protected]> wrote:
> On Wed, Jun 27, 2012 at 5:01 PM, Andy Walls <[email protected]>wrote: > >> 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 >> >> From cat /proc/interrupts ... > 17: 155 0 0 0 IR-IO-APIC-fasteoi > snd_hda_intel, cx18-0 > > Looks like the sound driver (motherboard on-board audio)? > > -Robert > I've now disabled the motherboard audio and blacklisted the driver. Still no luck dumping to a file and no updates to the /proc/interrupts line when doing so: 17: 0 0 0 0 IR-IO-APIC-fasteoi cx18-0 :(
_______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
