> >> > 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 > > > Spec violations or misimplementations aren't uncommon. Intel's usually > the best about adhering as far as I can tell though. There errata > sheets show some weird problems though. > > I just looked and the 82801 IO controller hub (which is likely > integrated into your 80845 chipset) is a PCI v2.2 compliant set of > devices. > > I just read the Product Brief for the CX23418 that is available to the > public from Conexant's website. The CX23418 is a PCI v2.3 device. > > I've now got to go back through all the other reports from users to see > what PCI version their chipsets implement. I'll post the results with a > query for anyone who has a CX23418 working with a PCI v2.2 or earlier > chipset. > > Please verify these findings for yourself (and double check my research) > by pulling the 82845 & 82801 datasheets from Intel and the CX23418 > product brief from Conexant. > > *** So I think the root cause is a PCI version incompatibility. *** > > > BTW, the last version of the plain old PCI spec I know of is v3.0. You > can google for "pci 3.0 spec" and perhaps find sites host the PCI bus > and PCI bridge specs. >
Unfortunately, I may have some contrary data. The Windows XP system I used to test the HVR-1600 is a Dell Optiplex GX280. While there is a bit of conflicting data the tech docs for the GX280 show that it is PCI v2.2. The tech docs also refer to the chipset as an Intel "Grantsdale". "Grantsdale" was the codename for the Intel 915G/P and 925X chipsets all of which are PCI v2.3. Since the used Dell I am getting is also a GX280 this should be a good test of your theory. With Linux loaded I will also be able to get the most certain view of the chipset and be able to determine the actual PCI version. The other Fedora 9 box has an nVidia nForce 405 chipset. I could not find any information on the PCI version on the nVidia web page or on the MB mfg's site. Given it's age (<6 months old) I would assume the PCI version to be >2.2. I had one other idea. Is it worth eliminating the riser card as the source of the problem? I could plug the HVR-1600 directly into the riser card's slot or use the only other PCI slot which is buried on the MB with no external slot on the back of the case. I would need to lift the MB in order to get the card into one of those slots. If that info could help you I will gladly give that a try as well. > >> >> 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. > > OK. For the record, I suspect all that would happen is that you would > verify you have a PCI bus hardware compatibility problem. > > > > >> > 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 > [snip] >> I'll give this a try after I rebuild with Mythbuntu tonight or >> tomorrow. > > I just realized you can do this unless you get a '/dev/videoN' node to > show up. So if you can't, no big deal. > > >> > 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? > > I thought of that too, but didn't know what was available off the top of > my head. > >> ie... >> >> PCI >> --- >> pci=off Don't use PCI > > Not useful. > >> pci=conf1 Use conf1 access. >> pci=conf2 Use conf2 access. > > I don't think it will be useful, as the most common case is for any > device to implement configuration access method 0, with the others > usually not being implemented > > >> pci=rom Assign ROMs. > > Only useful if we thought there was a ROM actually responding to where > the CX23418 had it's addressed mapped. This one is probably worth a > try. > >> pci=assign-busses Assign busses > > Not useful. > > >> pci=irqmask=MASK Set PCI interrupt mask to MASK >> pci=lastbus=NUMBER Scan upto NUMBER busses, no matter what the >> mptable says. > > Not useful. > > >> pci=noacpi Don't use ACPI to set up PCI interrupt routing. > > May have an effect, but I doubt it would fix any plain old PCI reads and > writes, which are what we have a problem with. > > >> > >> > 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. > > Check the mobo chipset to make sure it's PCI v2.3 or above! > Not clear but probably v2.2 > > > >> > 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. > > Maybe the "rom" one. I doubt it will fix things. > None of the PCI or ACPI kernel boot parameters had any effect. > Regards, > Andy > >> --Gerhard > > > > _______________________________________________ > 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
