On Fri, 2008-07-25 at 12:03 -0400, Gerhard R. Wittreich wrote: > Quoting "Andy Walls" <[EMAIL PROTECTED]>: >
> > 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. > >> 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! > > 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. Regards, Andy > --Gerhard _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
