Gerhard, I'm copying the list so that others may follow your progress...
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. > 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. > 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. > 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. 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 _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
