Robert Rust <[email protected]> wrote: >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
Ok. That confirms the CX23418 interrupts either aren't happening at all or the kernel is getting them. Easiest things to check are: A. that you have the cx23418 apu and cpu firmware files under /lib/firmware (or wherever) and that they are correct (or at least bigger than 0 bytes) B. Move the hvr1600 to a different pci slot. While you have the case open, remove all your legacy pci cards and blow the dust out of all the slots. Reinstall all the cards and then retest. C. Move the hvr1600 back to the system in which it was working, and verify that it still works. Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
