[linux-dvb] HD3000 (cx88) and GA-965P-DS3 Problem.

Steven Toth stoth at hauppauge.com
Tue Oct 17 04:43:33 CEST 2006


See below.

Joshua Prismon 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 at hauppauge.com> 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?
>>
>>     
cc'ing the linux-dvb list back _IN_ to the thread.

modprobe eeprom.ko

^^^ This should create a /sys/bus/i2c/drive/eeprom/?-0050/eeprom or 
something like this.

hexdump the eeprom file, it's 256 bytes long. The first byte of the file 
indicates which PCI devices are enabled by the 88x bridge chip. If the 
eeprom has become corrupt this will effect which PCI devices are enabled 
when the board is powered up.

What does the entire eeprom content look like? (make sure you get the 
byte ordering the right way around in hexdump else it assumes word 
format and all the bytes get switched).

Steve






More information about the linux-dvb mailing list