On Wed, 2008-12-24 at 09:38 -0800, Tony Sarathchandra wrote: > > Hello, > I'm attempting to get a brand new HVR-1600 working on CentOS > 5.2 (2.6.18-92.1.22.el5.centos.plus kernel). System is Dell PowerEdge > 2500SC with dual PIII CPUs. Prior to purchasing this card I profusely > read all the issues folks were having on this list and others with the > cx18 driver and decided to risk it, verse going with a PVR-500/350 + > separate HDTV card, and so here I am. I'm reasonably proficient with > Linux but not a sw programmer. > > My current setup is a split MythTV backend/frontend with the backend > on the PE2500, frontend's running Minimyth. I have a AverMedia (Bt878 > based) capture card working reliably with NTSC from my cable provider > (Coax in) on the PE2500 backend. Here's what I've done to date to try > and get this to work and debug the issue. > > - Grabbed the latest V4L distribution (v4l-dvb-94592e006b95) and > compiled as per instructions and installed. Had some initial compile > issues, directories not found etc which I've fixed.
Well, Hans has just got a lot of v4l2 infrastructure changes pulled in just recently. I have not had time to test. You may want to go back in time a little to: http://linuxtv.org/hg/v4l-dvb/rev/f046a0bf05f8 or http://linuxtv.org/hg/v4l-dvb/rev/922aa9be8cd3 just to eliminate big v4l2 infrastructure changes being the cause. > - Downloaded the HVR firmware to /lib/firmware which seems to load > correctly. > > - Following a reboot everything with respect to the cx18 driver seems > to load fine, I have some debug captures of this here; > > http://thinkspace.ath.cx/stuff/hvr-1600_debug.txt > With more debugging turned on; > http://thinkspace.ath.cx/stuff/hvr-1600_debug2.txt > The bttv driver (/dev/video0) and associated modules for that are > loaded prior to the cx18 module which becomes /dev/video1 This does not look fine: cx18-0: i2c hardware 0x00000004 (cs5345) not found for cmd 0x4008646d! The CS5345 does baseband audio digitzation and multiplexing for SVideo and Composite inputs, so you don't need it for Tuner inputs, but it indicates something is wrong. I2C or V4L infrastructure related maybe? > > - The issues is after everything seemly going fine, I get no signal > from the /dev/video1. Testing via xawtv, mplayer and mythtv all reveal > a blank red or green screen. Almost as if the input on the HVR-1600 is > set to composite 1 or 2 but it not as far as I can tell! (Refer to the output of /sbin/modinfo cx18 ) Debug with "high volume" "dma" "api" and "irq" debugging. Make sure interrupts are happening and buffers are going back and forth between driver and firmware. If you debug the "file" operations, you can also see if the application is reading buffers. > - Switching the coax cable to connect to the ATSC, I'm able to tune in > successfully to some QAM-256 channels, so the driver is working to > some degree. Here some photos of the card, it’s the MCE version with > the built in FM tuner. > > http://thinkspace.ath.cx/stuff/15-116-009-04.jpg > http://thinkspace.ath.cx/stuff/15-116-009-05.jpg > > - After having read of the I2C bus issues I placed the card in a 3.3V > 64bit PCI slot that should be PCI 2.3 compliant. The PE2500 has both > 5V and 3.3V 64bit PCI slots. Have some hardware details here, card > seems to be detected fine. > > http://thinkspace.ath.cx/stuff/HVR-1600_details.txt The I2C stuff should be fixed. I2C problems were really a symptom of PCI bus errors. Now the cx18 driver checks and retries writes (up to 10 times) to the CX23418 until it's sure the proper values were written to the CX23418 registers or memory across the PCI bus. > - After having read here that for the PVR-500 sometimes the bttv > drivers causes tuner detection to not work (Tuner not detected), and > since the cx18 is based on this code, I tried blacklisting the bttv > and snd_bt87x drivers at startup, and this did end up giving me an > error during cx18 load. > > http://www.mythtv.org/wiki/index.php/Hauppauge_PVR-500 > > - Here is the current cx18 dmesg error with debug=32, > http://thinkspace.ath.cx/stuff/hvr-1600_debug3.txt Your vmalloc memory address space fragmented (or was leaked) with driver unloads and reloads. The cx18 driver doesn't leak vmalloc space (anymore!), but it does need one for 64 MB segment for PCI MMIO mapping, and the another several hundred for buffers of 4 to 32 kB of real memory for captures. You should up your available vmalloc address space with a 'vmalloc=xxxM' kernel command line. Make it about 128M larger than what /proc/meminfo reports for your total vmalloc space. Alternately you can use the 'enc_yuv_bufs=0 enc_idx_bufs=0 enc_pcm_bufs=0' cx18 module options to temporarily reduce the buffer needs for streams you aren't using. > - Also modprobe -r of the cx18 module at any points ends up with a > kernel soft lockup as below which is only recoverable via a reboot. > > http://thinkspace.ath.cx/stuff/Kernel_lockup_bug.txt > Was there some problem with the build process perhaps? Perhaps. It could also be problems with the new infrastructure changes. In which case Hans would be interested if you can narrow it down to that or not. >From what I can read in the lockup messages, the cx18 driver was trying to unload and when calling v4l2 and i2c infrastructure functions, something hung up for 10 seconds. (Maybe waiting on a lock that something in your kernel never released?) Regards, Andy > I'm kind of running out of ideas on what else I can do to further > diagnose this issue, any help or pointers would be greatly > appreciated. > > Many thanks, > > Tony _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
