> 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
