This is definitely looking like a hardware failure on this board. I swaped the old motherboard back in, and the device didn't show up. Is there any way to restore the EEPROM, or should I see if I can RMA this? I still have not been able to find the eeprom file to actually pull the 256 bytes of configuration data. Anyone have any idea where I should look?
On 10/16/06, Joshua Prismon <joshua.prismon@xxxxxxxxx> wrote: > It worked on a different motherboard (an ASUS A8N-SLI deluxe with a > socket 939 AMD64). I replaced the motherboard with a Intel 965P, and > it stopped working. It does not work with a vanilla kernel. > > I also noted that the device went away with this motherboard. The 965P > motherboards are fairly new, and this may be a larger linux problem. > > Right now I am playing around with PCI addressing modes to see if > there is a problem in the ACPI layer. > > On 10/16/06, Steven Toth <stoth@xxxxxxxxxxxxx> wrote: > > Joshua Prismon wrote: > > > I am still getting the hang of this code, so it's very very possible > > > that I am missing something basic here. > > > > > > I don't think the problem is in the request_aquire function. In fact > > > that doesn't even appear to be every called. The DVB driver registered > > > correctly with the cx88-mpeg driver ( cx8802_register_driver). That > > > driver registers with the pci_driver. > > > > > > That PCI probe doesn't appear to be actually called. When > > > cx8802_register_driver starts looping through devices (after the dvb > > > driver is registered), it doesn't find any devices at all. The > > > devlist should be (if I read the code correctly) populated by the > > > cx8802_probe function. > > > > > > As a quick test, I added the following lines to the > > > pci_register_driver to see what the system actually sees in the PCI > > > tables: > > > > > > /* > > > .vendor = 0x14f1, > > > .device = 0x8802, > > > */ > > > > > > dev = pci_find_device(0x14f1, 0x8802, dev); > > > > > > > > > > <cut> > > > > > 05:00.0 0400: 14f1:8800 (rev 05) > > > Subsystem: 7063:3000 > > > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > > > ParErr- Stepping- SERR- FastB2B- > > > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium > > > > > >> TAbort- <TAbort- <MAbort- >SERR- <PERR- > > >> > > > Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes > > > Interrupt: pin A routed to IRQ 21 > > > Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=16M] > > > Capabilities: [44] Vital Product Data > > > Capabilities: [4c] Power Management version 2 > > > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > > > PME(D0-,D1-,D2-,D3hot-,D3cold-) > > > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > > > > > > 05:00.4 0480: 14f1:8804 (rev 05) > > > Subsystem: 7063:3000 > > > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > > > ParErr- Stepping- SERR- FastB2B- > > > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium > > > > > I don't see the mpeg PCI function enabled. In other words I don't see > > the 14f1:8802 device. Why is this missing? I expected to see an entire > > entry for this. > > > > The cx8802.ko (cx88-mpeg.c) driver registers against 14f1:8802 and so if > > that isn't registered then DVB is never going to work, because the > > kernel will never probe it. > > > > Are you completely sure the DVB device works under other kernels? > > > > Can you tell me which vanilla kernel from www.kernel.org this DVB > > product is working correctly with? > > > > Steve > > > > > > >
_______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
