Mailing List Archive

cx18 - Hauppauge 1600 not loading
Hi, I have a Hauppage WinTV-HVR-1600 (Digital + Analog tuners with IR
receiver). The card appeared
to work fine until my last kernel update (upgraded to 2.6.32.9). Since
then, I have also
upgraded the v4l-dvb modules to v4l-dvb-e50bb36f881c. Unfortunately,
still no success.

Now I only get the following output during boot:
cx18: Start initialization, version 1.4.0
cx18: End initialization

After some digging, I found that
http://pci-ids.ucw.cz/read/PC/0070/7444 lists the
Hauppage 1600 as:
Hauppauge's HVR-1600 board, PCI ID 14f1:5b7a, Subsystem 0070:7444

Unfortunately, this is NOT what my card returns, output from my lspci
is below and clearly
shows the ID as 597a NOT 5b7a. Could this be why the card isn't
working anymore or
should I be looking for the problem somewhere else (hardware failure etc.)?

Any help would be appreciated,
Many thanks,
Peter


lspci verbose output below
----------------------------------------------------------------------------------
00:0a.0 Multimedia video controller: Conexant Systems, Inc. Device 597a
Subsystem: Hauppauge computer works Inc. Device 7444
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR+ INTx-
Latency: 32 (500ns min, 50000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 10
Region 0: Memory at c8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [44] Vital Product Data
pcilib: sysfs_read_vpd: read failed: Connection timed out
Not readable
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: cx18 - Hauppauge 1600 not loading [ In reply to ]
I had a similar issue, what I did was remove the card and reinsert it
(reseating) and it seemed to work fine.

On Fri, Mar 12, 2010 at 8:49 PM, Peter Klimas <peter.klimas@gmail.com>wrote:

> Hi, I have a Hauppage WinTV-HVR-1600 (Digital + Analog tuners with IR
> receiver). The card appeared
> to work fine until my last kernel update (upgraded to 2.6.32.9). Since
> then, I have also
> upgraded the v4l-dvb modules to v4l-dvb-e50bb36f881c. Unfortunately,
> still no success.
>
> Now I only get the following output during boot:
> cx18: Start initialization, version 1.4.0
> cx18: End initialization
>
> After some digging, I found that
> http://pci-ids.ucw.cz/read/PC/0070/7444 lists the
> Hauppage 1600 as:
> Hauppauge's HVR-1600 board, PCI ID 14f1:5b7a, Subsystem 0070:7444
>
> Unfortunately, this is NOT what my card returns, output from my lspci
> is below and clearly
> shows the ID as 597a NOT 5b7a. Could this be why the card isn't
> working anymore or
> should I be looking for the problem somewhere else (hardware failure etc.)?
>
> Any help would be appreciated,
> Many thanks,
> Peter
>
>
> lspci verbose output below
>
> ----------------------------------------------------------------------------------
> 00:0a.0 Multimedia video controller: Conexant Systems, Inc. Device 597a
> Subsystem: Hauppauge computer works Inc. Device 7444
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR+ INTx-
> Latency: 32 (500ns min, 50000ns max), Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 10
> Region 0: Memory at c8000000 (32-bit, non-prefetchable) [size=64M]
> Capabilities: [44] Vital Product Data
> pcilib: sysfs_read_vpd: read failed: Connection timed out
> Not readable
> Capabilities: [4c] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>



--
Darren Blaber
Re: cx18 - Hauppauge 1600 not loading [ In reply to ]
On Fri, 2010-03-12 at 20:49 -0500, Peter Klimas wrote:
> Hi, I have a Hauppage WinTV-HVR-1600 (Digital + Analog tuners with IR
> receiver). The card appeared
> to work fine until my last kernel update (upgraded to 2.6.32.9). Since
> then, I have also
> upgraded the v4l-dvb modules to v4l-dvb-e50bb36f881c. Unfortunately,
> still no success.
>
> Now I only get the following output during boot:
> cx18: Start initialization, version 1.4.0
> cx18: End initialization
>
> After some digging, I found that
> http://pci-ids.ucw.cz/read/PC/0070/7444 lists the
> Hauppage 1600 as:
> Hauppauge's HVR-1600 board, PCI ID 14f1:5b7a, Subsystem 0070:7444
>
> Unfortunately, this is NOT what my card returns, output from my lspci
> is below and clearly
> shows the ID as 597a NOT 5b7a. Could this be why the card isn't
> working anymore or
> should I be looking for the problem somewhere else (hardware failure etc.)?

You have a PCI bus signal problem.

1. Take out all your PCI cards
2. Blow the dust out of all the PCI slots.
3. Reinsert all the cards.

(Of course, be sure to take appropriate precautions when handling the
boards, as the chips can are sensitive to static electricity.)

After that, things hsould be fine.

The PCI bus uses "reflected wave swithcing", which means that one
bad/dusty/oxidized PCI board connection can affect the other boards.

Regards,
Andy

> Any help would be appreciated,
> Many thanks,
> Peter
>
>
> lspci verbose output below
> ----------------------------------------------------------------------------------
> 00:0a.0 Multimedia video controller: Conexant Systems, Inc. Device 597a
> Subsystem: Hauppauge computer works Inc. Device 7444
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR+ INTx-
> Latency: 32 (500ns min, 50000ns max), Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 10
> Region 0: Memory at c8000000 (32-bit, non-prefetchable) [size=64M]
> Capabilities: [44] Vital Product Data
> pcilib: sysfs_read_vpd: read failed: Connection timed out
> Not readable
> Capabilities: [4c] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: cx18 - Hauppauge 1600 not loading [ In reply to ]
Andy Walls wrote:
> The PCI bus uses "reflected wave swithcing", which means that one
> bad/dusty/oxidized PCI board connection can affect the other boards.

Yikes - I never realized that, but then I never really thought about it,
either. Wouldn't that also mean that a lot of issues become dependent
on how many slots there are and how many slots are populated, etc? In
other words, plugging more cards in might make a system flakier - or
more stable, same for moving a card from one slot to another. (And
that's not just moving it to another IRQ.)

Dale
(In a past life, I was a Rambus licensee, speaking of signal
propagation. I specifically did voltage reference and regulation,
temperature sensor, and CAD tools. But I was aware of the rest of the
design, and particularly marveled at the I/O and DLL designs. Now that
I write it, the I/O and DLL simply ARE the crux of Rambus, along with a
protocol to make it all work together, and a few bits and pieces. The
array was our design that we were bolting on.)

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: cx18 - Hauppauge 1600 not loading [ In reply to ]
Darren,

You were absolutely correct. Re-seating the card solved the problem.
Many thanks for the quick response!

Peter

On 12 March 2010 22:30, Darren <dmbtech@gmail.com> wrote:
> I had a similar issue, what I did was remove the card and reinsert it
> (reseating) and it seemed to work fine.
>
> On Fri, Mar 12, 2010 at 8:49 PM, Peter Klimas <peter.klimas@gmail.com>
> wrote:
>>
>> Hi, I have a Hauppage WinTV-HVR-1600 (Digital + Analog tuners with IR
>> receiver). The card appeared
>> to work fine until my last kernel update (upgraded to 2.6.32.9). Since
>> then, I have also
>> upgraded the v4l-dvb modules to v4l-dvb-e50bb36f881c. Unfortunately,
>> still no success.
>>
>> Now I only get the following output during boot:
>> cx18:  Start initialization, version 1.4.0
>> cx18:  End initialization
>>
>> After some digging, I found that
>> http://pci-ids.ucw.cz/read/PC/0070/7444 lists the
>> Hauppage 1600 as:
>> Hauppauge's HVR-1600 board, PCI ID 14f1:5b7a, Subsystem 0070:7444
>>
>> Unfortunately, this is NOT what my card returns, output from my lspci
>> is below and clearly
>> shows the ID as 597a NOT 5b7a. Could this be why the card isn't
>> working anymore or
>> should I be looking for the problem somewhere else (hardware failure
>> etc.)?
>>
>> Any help would be appreciated,
>> Many thanks,
>> Peter
>>
>>
>> lspci verbose output below
>>
>> ----------------------------------------------------------------------------------
>> 00:0a.0 Multimedia video controller: Conexant Systems, Inc. Device 597a
>>        Subsystem: Hauppauge computer works Inc. Device 7444
>>        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
>> Stepping- SERR+ FastB2B- DisINTx-
>>        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR+ INTx-
>>        Latency: 32 (500ns min, 50000ns max), Cache Line Size: 32 bytes
>>        Interrupt: pin A routed to IRQ 10
>>        Region 0: Memory at c8000000 (32-bit, non-prefetchable) [size=64M]
>>        Capabilities: [44] Vital Product Data
>> pcilib: sysfs_read_vpd: read failed: Connection timed out
>>                Not readable
>>        Capabilities: [4c] Power Management version 2
>>                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>
>> _______________________________________________
>> ivtv-users mailing list
>> ivtv-users@ivtvdriver.org
>> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
>
>
> --
> Darren Blaber
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: cx18 - Hauppauge 1600 not loading [ In reply to ]
On Sat, 2010-03-13 at 12:46 -0500, Dale Pontius wrote:
> Andy Walls wrote:
> > The PCI bus uses "reflected wave swithcing", which means that one
> > bad/dusty/oxidized PCI board connection can affect the other boards.
>
> Yikes - I never realized that, but then I never really thought about it,
> either. Wouldn't that also mean that a lot of issues become dependent
> on how many slots there are and how many slots are populated, etc? In
> other words, plugging more cards in might make a system flakier - or
> more stable, same for moving a card from one slot to another. (And
> that's not just moving it to another IRQ.)

Yup. But in practice an arrangement of physical slots for a single PCI
bus segment can only have 5 physcial slots. Southbridge chips can have
a large number of devices integrated in silicon though.

The idea was to not deal with termination of the PCI bus "transmission
lines" and rely on the reflected waves coming back to give you the
proper signal levels. Fun, huh?

The PCI local-bus specification is a very interesting read.

At the PCI SIG (.org) website, the freely available developers' material
and briefs from years back may provide a nice tutorial with pictures and
rationale. Copies of the spec's themselves are costly.


> Dale
> (In a past life, I was a Rambus licensee, speaking of signal
> propagation. I specifically did voltage reference and regulation,
> temperature sensor, and CAD tools. But I was aware of the rest of the
> design, and particularly marveled at the I/O and DLL designs. Now that
> I write it, the I/O and DLL simply ARE the crux of Rambus, along with a
> protocol to make it all work together, and a few bits and pieces. The
> array was our design that we were bolting on.)

Neat. Didn't the owners of the Rambus patents recently try to sue every
memory manufacturer on Earth?

BTW, if you do a little digging on patents by Rockwell-Collins and
Conexant you can find patents and papers that somewhat explain DLLs and
SRCs that are most likely used in the CX25843 and CX23418.

For example, I suspect Fritz Rothacher's thesis work directly impacted
the CX25843 design:

http://www.guest.iis.ee.ethz.ch/~rota/

since he is later listed on some Conexant patents.

Regards,
Andy



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users