OK...There is enough confusing posts below that I think it's time for a top post and a summary of where we've been and where we are.
Original Problem ---------------- I started with a Dell Optiplex 240 with a Hauppauge HVR-1600, an nVidia GeForce 6200, 385MB RAM, Mythbuntu 8.04, latest cx18 drivers, etc. When loading the cx18 driver got the dreaded: tveeprom 1-0050: Huh, no eeprom present (err=-121)? tveeprom 1-0050: Encountered bad packet header [86]. Corrupt or not a Hauppauge eeprom. cx18-0: Invalid EEPROM Did all the usual... - Changed vmalloc to 256M and 512M with no improvement - Started cx18 with buffers zeroed (enc_mpg_buffers enc_ts_buffers enc_yuv_buffers enc_vbi_buffers enc_pcm_buffers) with no improvement. - Ran the typical debugs with no particularly interesting results expect for some I2C debug that showed writes and subsequent reads not matching. ul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setscl: Wrote CX18_REG_I2C_2_WR = 0x21c0b Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setscl: Readback CX18_REG_I2C_2_WR = 0x7 Jul 20 09:54:54 localhost kernel: cx18-0 warning: cx18_setscl: On exit readback value (0x7) and written value (0x21c0b) upper bytes differ Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setsda: On entry CX18_REG_I2C_2_WR = 0x7 Jul 20 09:54:54 localhost kernel: cx18-0 warning: cx18_setsda: On entry read value (0x7) and previously written value (0x21c0b) upper bytes differ. Using previous value as it should be correct. Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setsda: Wrote CX18_REG_I2C_2_WR = 0x21c0b Jul 20 09:54:54 localhost kernel: cx180 i2c: cx18_setsda: Readback CX18_REG_I2C_2_WR = 0x7 Jul 20 09:54:54 localhost kernel: cx18-0 warning: cx18_setsda: On exit readback value (0x7) and written value (0x21c0b) upper bytes differ Readbacks from the I2C control registers almost always return 0xf or 0x7 depending on the register read. These are in fact the *exact* values that Gerhard's log show. Some things I tried ------------------- - I added RAM. Moved RAM from 384MB to 1024MB. No improvement. VMALLOC Before (384MB DRAM) VmallocTotal: 638968 kB VmallocUsed: 45460 kB VmallocChunk: 586228 kB With (1024 MB DRAM) VmallocTotal: 241656 kB VmallocUsed: 4152 kB VmallocChunk: 172500 kB - There was a concern that the card was defective: I installed the card in a WinXP box and the card initialized correctly and the Hauppauge software allowed me to play digital but not analog stations. Still not sure why.,,Probably a dumb operator problem! I installed the card in a AMD dual core box with 2GB RAM, nVidia GeForce 7400, Fedora 9 and a self-built MythTV 0.21. Card initialized with CX18 drivers and, after much learning and adjusting, I was able to use the card with MythTV for both analog and digital stations. The card is not defective. - I re-installed in the original box now upgraded with 1025MB RAM and installed most recent cx18 drivers. Still no luck. I then booted to single user mode and began to remove modules one at a time and tried to restart cx18. (The concern was that some other program was writing into the cx18 driver's memory space causing the mismatch between the writes and reads. Again...No luck. I removed almost every modules with no improvement. - Timings...While I didn't say this earlier I tried multiple timing options in cx18-cards.c and cx18-i2c.c with no improvement. I also fooled with the PCI latency timings trying everything from 00 to FF. Again no impact. - Change OS on the original box. Installed Fedora 9 on the original box with no improvement. What Next? ---------- - Install Win2K on the original box and see if a significant shift in OS makes a difference. I'll start that tonight...Results tomorrow. - I'm stuck!!!! Any other ideas from anyone. Is there more data I can collect? Quoting "Gerhard R. Wittreich" <[EMAIL PROTECTED]>: >> Gerhard, >> >> I'm copying the list so that others may follow your progress... > > Ooops...I missed that. Sorry > >> >> >> On Mon, 2008-07-21 at 11:04 -0400, Gerhard R. Wittreich wrote: >>> >> > All the values being read back are wrong. In fact, the values >>> read back >>> >> > are always either 0xf or 0x7 depending on which CX23418 I2C control >>> >> > register, RD or WR, is being read. >>> >> > >>> >> > You have a PCI bus problem, a problem with your CX23418 chip, or the >>> >> > driver just isn't initializing the CX23418 properly. >>> > >>> > After sleeping on it, I have a hypothesis on another type of failure >>> > mode: a kernel or kernel module bug is corrupting the CX23418 register >>> > space that has been mapped into virtual memory. >> >>> > >>> > So how do we test that hypothesis: that any code in kernel space could >>> > be corrupting registers in the CX23418 address mapping? >>> > >>> > 1. One way would be to reduce the amount of kernel code (e.g. unload >>> > modules) until we find the offending code. Boot to single user mode and >>> > start "rmmod" or "modprobe -r" as any modules as you safely can: sound >>> > modules, ethernet modules, video card modules (if it's safe), USB >>> > modules, etc. You'll have to leave you disk controller modules in >>> > place. Then, when you've got as few modules loaded as possible, load >>> > the cx18 module. >>> > >>> > 2. Another way would be to use a different build of kernel code. That's >>> > most easily done with a different Linux distro or OS (NB that testing >>> > with Windows will verify your hardware, but not offer much else in the >>> > way of insght.) >>> > >>> >>> I'll give it a try tonight especially in light of the other successes >>> I've had....See below. >> >> OK. >> > > I focused my testing on the Dual Core AMD box to prove if the card was > functioning. Should get to this tonight. > >> >> >> >> >>> The two PCI slot riser card is part of a cage that contain the two PCI >>> cards. To install and remove a PCI card I pull out the entire cage >>> which pulls the riser from its slot. Therefore, I have done this many >>> times with, predictably, no effect. >> >> OK - likely not a bad slot connector. >> >> >>> >> > 2. Try the card in a different motherboard if you can, to rule out the >>> >> > possibility of a bad card >>> >> >>> >> I have two possible options. I could install Win2k on this machine >>> >> and see if everything works. >>> > >>> > If that is a low effort you should do that to eliminate the possibility >>> > of a bad CX23418 or HVR-1600. We want to eliminate unknowns. >>> > >>> > >>> OK...I ran both tests on Sunday. >>> >>> 1. Installation into my WinXP box was successful. NO apparent >>> problems or error messages during install. The analog tuner worked >>> well immediately but I was not able to tune anything on the digital >>> tuner. Not clear if there was a config problem or a signal problem on >>> the second floor. >> >> OK. Your card works to some degree. The analog tuner was on the second >> I2C bus which always appeared to work under Linux. The digital tuning >> devices are commanded via the first I2C bus, so it is unfortunate that >> you could do any digital tuning here. It doesn't let us completely >> eliminate the card (yet). >> >> >> >>> 2. Installation on the Fedora 9 AMD box was also successful. Both >>> halves of the card initialized normally. >> >> OK. That's a very good sign. It indicates that your HVR-1600 card is >> likely OK and not defective in some way. Pending more testing, we'll >> declared that variable eliminated. >> >> >>> I decided to install MythTV >>> to do a more complete test. After a number of rounds of dumb errors >>> (like troubleshooting a MySQL permission problem for two hours when >>> the real issue was a missing qt-mysql install!!) MythTV is now >>> working. Unfortunately, I am getting no signal for either the analog >>> or digital tuners. I connected to an long unused cable jack in the >>> kids room which I have not yet had a chance to test to be sure it is >>> live. >> >> For very weak signals you'll get snowy analog first before you get a >> good digital lock. If you haven't got analog, you've got a really poor >> signal, or something else is wrong with the software/hardware setup. >> > > Turns out the cable was not terminated in the distribution > panel...Fixed that. Now I can detect 75+ channels on both the analog > and digital tuners. Although this is fewer digital stations than my > LCD w/ digital tuner in the next room can find...Not sure why. MythTV > displays the digital images with occasional pixelation and audio pops. > I cannot get any image to display from the analog tuner even thought > MythTV detects active stations...This is a MythTV problem, not yours. > I did a capture on the analog tuner (cat /dev/video0 >test.mpg) and > was able to view a very clear analog video stream. I also noticed > fairly high CPU usage. That was a bit surprising. Given a very good > graphics card (nVidia 7000 series) and with hardware encoding/decoding > on the HVR-1600 I had expected the CPU usage to be very low. Is there > some aspect of the HVR-1600 that is not yet enabled by the drivers > that woould account for the high CPU usage? > > I would have to conclude that this card is working even if MythTV is not. > > BTW....I'm no stranger to building software packages and I am finding > MythTV unusually complex and vague. Maybe it's just me but.... Oh > well. > >> >>> I'll get that done this evening. Nonetheless, here is the >>> dmesg and lspci -vv outputs. I tried adding a debug=321 on the cx18 >>> but it appeared to have no effect...Was that option available only on >>> the build from your archive? >> >> No it's always available. My repository had extra (excessive!) debug >> messages built into it so I could see what was going on when those flags >> (256+64+1 = 321) were enabled. "/sbin/modinfo cx18" to see the possible >> debug flags. >> >> > I still see no difference in the dmesg results with debug=321 or not. > On the original box this clearly gave very detailed results. Do I > need to pursue this on this box or should we shift focus back to the > original box? Glad to pursue this if you think you can get useful > information. > >> >> >>> dmesg + tveeprom debug >>> ----------------------- >>> >>> cx18: Start initialization, version 1.0.0 >>> cx18-0: Initializing card #0 >>> cx18-0: Autodetected Hauppauge card >>> ACPI: PCI Interrupt 0000:01:05.0[A] -> Link [APC1] -> GSI 16 (level, >>> low) -> IRQ 16 >>> cx18-0: cx23418 revision 01010000 (B) >>> tveeprom 2-0050: full 256-byte eeprom dump: >>> tveeprom 2-0050: 00: 00 70 00 44 74 00 00 00 84 09 00 04 20 77 00 40 >>> tveeprom 2-0050: 10: ef 4b 0e f0 73 05 26 00 84 08 00 06 39 21 01 00 >>> tveeprom 2-0050: 20: 92 68 8d 72 07 70 73 09 1f 36 73 0a 08 70 73 0b >>> tveeprom 2-0050: 30: 4f 30 72 0f 03 72 10 01 72 11 00 79 9f 00 00 00 >>> tveeprom 2-0050: 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> tveeprom 2-0050: 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> tveeprom 2-0050: 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> tveeprom 2-0050: 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> tveeprom 2-0050: 80: 00 00 00 00 84 09 00 04 20 77 00 40 ef 4b 0e f0 >>> tveeprom 2-0050: 90: 73 05 26 00 84 08 00 06 39 21 01 00 92 68 8d 72 >>> tveeprom 2-0050: a0: 07 70 73 09 1f 36 73 0a 08 70 73 0b 4f 30 72 0f >>> tveeprom 2-0050: b0: 03 72 10 01 72 11 00 79 9f 00 00 00 00 00 00 00 >>> tveeprom 2-0050: c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> tveeprom 2-0050: d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> tveeprom 2-0050: e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> tveeprom 2-0050: f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> tveeprom 2-0050: Tag [04] + 8 bytes: 20 77 00 40 ef 4b 0e f0 >>> tveeprom 2-0050: Tag [05] + 2 bytes: 26 00 >>> tveeprom 2-0050: Tag [06] + 7 bytes: 39 21 01 00 92 68 8d >>> tveeprom 2-0050: Tag [07] + 1 bytes: 70 >>> tveeprom 2-0050: Tag [09] + 2 bytes: 1f 36 >>> tveeprom 2-0050: Tag [0a] + 2 bytes: 08 70 >>> tveeprom 2-0050: Tag [0b] + 2 bytes: 4f 30 >>> tveeprom 2-0050: Tag [0f] + 1 bytes: 03 >>> tveeprom 2-0050: Tag [10] + 1 bytes: 01 >>> tveeprom 2-0050: Not sure what to do with tag [10] >>> tveeprom 2-0050: Tag [11] + 1 bytes: 00 >>> tveeprom 2-0050: Not sure what to do with tag [11] >>> tveeprom 2-0050: Hauppauge model 74041, rev C6B2, serial# 936943 >>> tveeprom 2-0050: MAC address is 00-0D-FE-0E-4B-EF >>> tveeprom 2-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) >>> tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08) >>> tveeprom 2-0050: audio processor is CX23418 (idx 38) >>> tveeprom 2-0050: decoder processor is CX23418 (idx 31) >>> tveeprom 2-0050: has no radio, has IR receiver, has IR transmitter >> >> I have this model of card (74041) and have never had an I2C bus problem >> with it in my machines: both AMD Athlon X2 64 bit with different AMD >> chipsets running Fedora 7 and Fedora 9. >> >> >>> cx18-0: Autodetected Hauppauge HVR-1600 >>> cx18-0: VBI is not yet supported >>> tuner 3-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) >>> cs5345 2-004c: chip found @ 0x98 (cx18 i2c driver #0-0) >>> tuner-simple 3-0061: creating new instance >>> tuner-simple 3-0061: type set to 50 (TCL 2002N) >>> cx18-0: Disabled encoder IDX device >>> cx18-0: Registered device video0 for encoder MPEG (2 MB) >>> DVB: registering new adapter (cx18) >>> MXL5005S: Attached at address 0x63 >>> DVB: registering frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... >>> cx18-0: DVB Frontend registered >>> cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes) >>> cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) >>> cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) >>> cx18-0: loaded v4l-cx23418-dig.fw firmware (16382 bytes) >>> cx18-0: Registered device video32 for encoder YUV (2 MB) >>> cx18-0: Registered device video24 for encoder PCM audio (1 MB) >>> cx18-0: Initialized card #0: Hauppauge HVR-1600 >>> cx18: End initialization >> >> All normal. Looks good. >> >>> lspci -vv >>> ---------------------- >>> 00:00.0 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a1) >>> Subsystem: Elitegroup Computer Systems Unknown device 2602 >>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >>> Stepping- SERR- FastB2B- DisINTx- >>> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- >>> <TAbort- <MAbort- >SERR- <PERR- INTx- >>> Latency: 0 >> [snip] >> >> What surpirses me is almost all of the latency timers are set to 0. I'm >> not up to speed on PCIe so maybe that's OK. I would expect problems on >> a straight PCI bus when trying to access more than 1 device for large >> transfers. The good news your PCI devices have a decent latency timer >> to give them plenty of time on the bus: 64 bus cycles * ~4 bytes/bus >> cycle = ~256 bytes per burst transfer max. (A bus cycle is 30.3 >> nanoseconds). >> >> >> >>> >> I also have another, newer (Dual core >>> >> AMD, 2GB RAM) box running Fedora 9. >>> > >>> > That's what I use right now. It's 64 bit. What I noticed about the 64 >>> > mappings is that the vmalloc space is way, way, above the kernel static >>> > mappings, and the default vmalloc size is just huge >>> > >>> > $ cat /proc/meminfo | grep Vmalloc >>> > VmallocTotal: 34359738367 kB <---- 32,768 GB ! >>> > VmallocUsed: 18268 kB >>> > VmallocChunk: 34359719959 kB >>> > >>> >>> Yes...Same here >>> >>> [EMAIL PROTECTED] ~]# cat /proc/meminfo | grep Vmalloc >>> VmallocTotal: 34359738367 kB >>> VmallocUsed: 176008 kB >>> VmallocChunk: 34359561751 kB >>> >>> versus on the original box.. >>> >>> [EMAIL PROTECTED]:~# cat /proc/meminfo |grep Vmalloc >>> VmallocTotal: 638968 kB >>> VmallocUsed: 45460 kB >>> VmallocChunk: 586228 kB >>> >>> Would more memory be a solution? Only 384MB there now...I could >>> replace it with 1GB. >> >> Given that one can get memory on sale cheap (I got 2 GB of OCZ DDR2 800 >> for $18 a few weeks ago), it's worth the hours and hours of labor trying >> to hunt down problems on low memory systems. > > I probably should do this but, on the other hadn, maybe I'm asking to > much of this box. The original concept was to build a MythTV box from > an existing spare investing in just a tuner and upgraded video. At > what point do I shift and just build a box for this purpose. I'm torn > between the challenge of making this work (an contributing some useful > knowledge to the open source community) and getting the project done. > I can always donate the upgraded box to someone! > >> >> Your current vmalloc allocation is 624 MB, 'vmalloc=512M' wouldn't help >> you get rid of your -ENOMEM problem. You also have quite a large free >> vmalloc chunk 572 MB, so you might really be low on physical memory for >> kernel stuff (like DMA buffers for transfers from the CX23418 card). >> >> >> >> Just FYI, vmalloc space is not about real physical memory, it's about a >> pool of virtual memory addresses to use for dynamic memory mapping in >> kernel space. >> >> vmalloc addresses are used for at least: >> >> 1. mappings of I/O ports, or registers or I/O memory across the PCI bus >> into the kernels' virtual address space >> >> 2. dynamic remappings of real physical memory to host loadable kernel >> module code >> >> 3. (other things that I can't remember right now.) >> >> There is no free lunch, so what's the cost? The bigger vmalloc space >> you set aside, the more memory page table entries you consume to support >> dynamic mappings (which you may never use). >> >> With only 384 MB of real physical memory, you probably have page table >> entries to spare. >> >> >> I'm no expert in linux memory management, so you may want to consult >> other FAQs or sources. I know about the vmalloc stuff because I was >> forced to learn to overcome some problems of my own. >> >> >> >>> >> It's the kids computer so I'll >>> >> need to fight them for it. I'll try to do one or both of these in the >>> >> next day or two. >>> > >>> > The biggest impediment to getting the HVR-1600 working on your AMD >>> > Fedora 9 machine will likely be your children. I had to build a spare >>> > system to avoid the time conflicts with my wife & kids. >>> > >>> >>> I had to turn over a laptop to them until I finish testing the card in >>> their box! >> >> Yes, it's amazing how my box becomes their box. ;) >> >> >>> >> > 4. Make sure the latency timers for all the PCI devices have >>> reasonable >>> >> > values. >>> >> > >>> >> Not sure I know what is reasonable....Any guidiance? >>> > >>> > The 64 clock cycles are reasonable (until you try to do too much with >>> > your systems at once). The 0 clock cycle ones are always a little >>> > funny, as they're not really 0 but an expression of some setting >>> > dependent minimum - in general they're OK to leave alone. >>> > >>> > I do have some guidance, but since you don't show any bus aborts of >>> > significance, I'll spare you the tutorial. (You can search this list >>> > archive and the linux-dvb and video4linux list archives to find some >>> > tutorial information I gave.) >>> > >>> > >>> >> Can I change >>> >> latency settings? >>> > >>> > Yes. 'man setpci' for more info. Again, I'd leave them alone for now. >>> > >>> >>> Cool....I'll take a look at that. Thanks again for the help. >> >> The PCI and PCIe spec are also archived various places on-line. The >> PCISig website wants to charge you an arm and a leg for the actual >> specs, so to get it from them you have to part with serious $$$$'s. The >> PCISIg website does have develop conference materials which explain the >> concepts and are easier to read than the spec. >> >> Regards, >> Andy >> > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > ivtv-users mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
