On Mon, 2008-07-28 at 13:05 -0400, Gerhard R. Wittreich wrote: > > > > 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.
I don't think it would help me really. It may eliminate whether or not one specific bridge chip's interaction were causing a problem. If it were, then it is theoretically possible to start tweaking things and hope for the best. I'm not sure it would help you either. If the HVR-1600 works in that configuration, what then? Will you be able to close the case still and connect cables to the 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 Let me know please when you find out. > >> 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. Not surprising but it was worth a try. Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
