Quoting "Andy Walls" <[EMAIL PROTECTED]>: > On Thu, 2008-07-24 at 21:54 -0400, Gerhard R. Wittreich wrote: >> 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. > > I'm assuming all the failures above include an I2C bus problems and not > just simply an -ENOMEM. At that point I think it's safe to assume it's > motherboard PCI chipset (which includes the bridges and memory > controller) interaction/errant behavior with respect to the CX23418. >
I did read a few interesting posts regarding linux issue with riser cards. It appears there may be significant latitude in how mfg's implement pci standards and bridging on riser cards. FWIW...Here is a link to an interesting pci riser issue. Unfortunately, this thread also reaches no conclusion/solution. http://kerneltrap.org/mailarchive/linux-kernel/2007/2/18/56447 > > > >> What Next? >> ---------- >> >> - Install Win2K on the original box and see if a significant shift in >> OS makes a difference. > > If, when you install Windows, the card doesn't work, then we know that > getting the card working in that machine will likely be impossible. > > If when you install Windows, things work, all that tells us is that > Windows doesn't set up the Intel motherboard chipset the same as Linux > does, or that it exercises the bus in a manner different than Linux. > That means probably quite a few hours of studying the PCI bus specs, the > datasheets and errata for the Intel 82845 and 82801 chipsets, the state > of the PCI devices registers, and experimentation. (Datasheets and > Errata sheets are available from Intel's website,) > Ran into a bit of a snag. The easiest OS for me to install is Win2K. Unfortunately, as I discovered after I finished the build, the Hauppauge software/driver are not available for Win2K...Just XP. I don't believe it is worth pursuing this route any further. > > >> I'll start that tonight...Results tomorrow. >> >> - I'm stuck!!!! Any other ideas from anyone. Is there more data I >> can collect? > > Out of curiosity, I wonder how many of the c23418's I2C registers are > actually affected? > > Here's the dump of cx18 I2C related registers from my machine: > > > # ./v4l2-dbg -d /dev/video0 -R type=host,chip=0,min=0x2f15000,max=0x2f15023 > ioctl: VIDIOC_DBG_G_REGISTER > > 00 04 08 0C 10 14 > 18 1C > 02f15000: 00021c0b 00000000 0000000c 00000074 00000807 00000000 > 001fac0b 00000000 > 02f15020: 00000000 > > # ./v4l2-dbg -d /dev/video0 -R type=host,chip=0,min=0x2f25100,max=0x2f25123 > ioctl: VIDIOC_DBG_G_REGISTER > > 00 04 08 0C 10 14 > 18 1C > 02f25100: 00021c0b 00000000 0000000c e1587173 00000807 00000000 > 00ada8d7 00000000 > 02f25120: 00000000 > > # ./v4l2-dbg -d /dev/video0 -R type=host,chip=0,min=0x2c71000,max=0x2c71027 > ioctl: VIDIOC_DBG_G_REGISTER > > 00 04 08 0C 10 14 > 18 1C > 02c71000: 00000020 00000004 00000002 00000104 0000ffff 0000ffff > 00000000 00000000 > 02c71020: 00009026 00003185 > I'll give this a try after I rebuild with Mythbuntu tonight or tomorrow. > > > You do have the outside chance of a BIOS update and/or adjustment of > BIOS settings making things work by configuring the motherboard chipset > differently. For example a BIOS update may configure the motherboard > chipset differently to work around Intel's recently published chipset > errata (2004 for the 82801). > I am running the latest Dell BIOS and no updates have been released since 2005. The only other thought was using some additional kernel boot parameters. There are a number of pci boot parameters...Any possibility that one of those might change the pci behavior enough to allow this to work? ie... PCI --- pci=off Don't use PCI pci=conf1 Use conf1 access. pci=conf2 Use conf2 access. pci=rom Assign ROMs. pci=assign-busses Assign busses pci=irqmask=MASK Set PCI interrupt mask to MASK pci=lastbus=NUMBER Scan upto NUMBER busses, no matter what the mptable says. pci=noacpi Don't use ACPI to set up PCI interrupt routing. > > After that I'm at a loss. If it were in front of me along with a PCI > bus analyzer (which I also don't have), I'd have a chance of figuring it > out after God knows how many hours. It would be faster/cheaper to get a > new motherboard and processor or a different digital video capture card. > I had reached that same conclusion but was willing to try a few more things in the hopes that this would improve the cx18 driver/contribute to the open source community. I just ordered a new MB (actually bought a used Dell Optiplex GX280 for $150.) I'll let you know if that works...I expect it will. > > You also have the option of leaving the HVR-1600 card in your AMD > x2/Fedora 9 system and having that as a Myth backend. You could use > this older computer as only a Myth frontend machine. > Yes...A possibility. Once I get the new machine up I will experiment using the new machine as a backend and the old machine as a frontend. > You've done an excellent job at troubleshooting and eliminating > variable. Sorry, it doesn't look like it's something that can be solved > without hours of study, analysis and experimentation. > Thanks for all you help. To bad we didn't solve this one but we gave it a good try. If you think any of the above PCI boot options is worth trying I will still do that. --Gerhard >> 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 >> > > > _______________________________________________ > 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
