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> http://linuxtv.org/hg/v4l-dvb/rev/f046a0bf05f8 or <http://linuxtv.org/hg/v4l-dvb/rev/922aa9be8cd3> http://linuxtv.org/hg/v4l-dvb/rev/922aa9be8cd3 just to eliminate big v4l2 infrastructure changes being the cause. [ Tony>] Thanks Andy, I went back to f046a0bf05f8 and that seemed to have helped although I'm not certain that was the issue. I have the card working now with MythTV. I changed multiple things at the same time so not sure exactly what the issue was, but it seemed to have worked. Here's what I did just for reference; [ Tony>] - Went back to f046a0bf05f8 build as mentioned; [ Tony>] - Made sure "Enable drivers not supported by this kernel" at compile time was enabled as I'm on 2.6.18-92.1.22.el5.centos.plus kernel, this seemed to helped with the unload soft kernel lockups, although I did have this occur once after still; [ Tony>] - Made sure bttv driver was blacklisted so cx18 gets a chance to load first; [ Tony>] - Made sure I omitted some memory intensive programs at startup, the system usually runs low on memory with only 512MB available, so want to make sure this was not the issue; > - 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> http://thinkspace.ath.cx/stuff/hvr-1600_debug.txt > With more debugging turned on; > <http://thinkspace.ath.cx/stuff/hvr-1600_debug2.txt> 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? [ Tony>] Yes, good catch, I saw this error a few times before but thought it had stopped appearing. > > - 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-04.jpg > <http://thinkspace.ath.cx/stuff/15-116-009-05.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> 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. [ Tony>] Thanks, I moved the card back to a 5V PCI slot and it's working there too. May be good to update the wiki at some point with this info. :-) > - 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> 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> 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. [ Tony>] I didn't try increasing the vmalloc size as it was already at 507896kB and the system only has 512MB total. I tried reducing the buffers as you indicated but it worked in both cases after I had done all the above changes mentioned. I currently have the buffers set to their default values. I have meminfo output here just for reference http://thinkspace.ath.cx/stuff/hvr-1600_meminfo.txt > - 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> 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. [ Tony>] Perhaps, although I think it was most likely something at my end as I'm still unable to get "mplayer /dev/video0" to spit out anything other than a green screen but it works in MythTV. I suspected the card is not tuned correctly my default but I was unable to build the v4l2-apps tools initially with some build problems with Qt header files. I did finally get this to compile correctly after messing around with Qt directories. [ Tony>] I have the "./v4l2-dbg -d /dev/video0 --log-status" output here, http://thinkspace.ath.cx/stuff/hvr-1600_v4l2-dbg.txt Everything seems to be okay as far as I can tell. >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 [ Tony>] Thanks for all your help once more Andy and for your hard work on getting the driver to where it is. Only remaining (known) issue I have is the initial jitter/studder when tuning in to a channel for the very first time, but this is a minor annoyance, as normally my backend runs 24x7 and is rarely restarted. Again the performance of the HVR-1600 is very good with the latest driver and I'm impressed. Picture quality is better than my old Bt878 Avermedia card and CPU utilization on my dual 933Mhz Coppermine PIII backend is <4% on a single CPU while watching live TV. My old Bt878 averaged 60-70% on a single CPU as reference. I'm glad I went with the HVR-1600 vs a more mature older dual card solution in the end, took me all of about 2 days from unwrapping the box to have it operational with MythTV! at least for analog NTSC. :-)) I now have the option to mess around with ATSC/DVB later... > 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
