[linux-dvb] Lockups with cx2388x cards
stoth at linuxtv.org
Fri Jan 11 16:58:03 CET 2008
peter at naiadhome.com wrote:
> Steven Toth wrote:
>> Peter Martin wrote:
>>> I have a couple of Hauppauge cards (Nova-T using the cx2388x and a Nova
>>> Plus, again using an cx2388x) in an industrial motherboard (an Axiomtek
>>> ATX6022-14G) which is causing me some grief. After a short time I am
>>> getting both cards locking up (no DMA) at the same time.
>> Does it happen with only a single card active in the system?
> Yes it does. If I start streaming from one card, it runs for a few minutes, then I get the timeout. I am then unable to start streaming from the other card after this. I will try a single card in the motherboard later.
Obviously, it goes without saying that many people have been using the
basic cx2388x based products for years without any serious issue, so
this sounds like it's environment specific.
What other products are on the same PCI bus? Maybe something else is
grabbing the bus for extended periods (or just a flaky PCI
implementation on the controller side).
It would also be good to try other products with similar operating
characteristics (IE. another DVB-T/S product s with a different bridge
part). If the problem is fundamentally a host DMA controller issue then
the system should exhibit unusual behavior across multiple different
products (that have the same DMA resource requirements).
>> Have you tried the cards on other motherboards and do they operate
>> successfully without error?
> Both these cards work fine in other motherboards, indeed they work with up to 5 cards for extended periods.
OK, that's normal.
>>> In order to get these cards working at all in this configuration, I have
>>> re-arranged the SRAM and increased the FIFO size in cx88-core.c to
>>> 0x4800 bytes, and disabled all the other channels (video, audio etc),
>>> which has cured the FIFO overflow errors I was getting ( general errors:
>>> 0x00000100), but the cards still lock up. The cards can run from between
>>> 5 seconds and 30 minutes before the lockup. I also get the lockups with
>>> the stock code, so I am happy that my SRAM chganges have not broken
>> IIRC, the fifo is pretty small (resulting in potential short latency
>> issues). This could be compounded with a busy DMA bus and short fifo's
>> both competing for the same DMA queue resource. I suspect increasing the
>> fifo really just masks the real DMA contension issue.
> Sounds plausible. Since the failure of one card affects the other card(s) then I suspect you are right and there is a common DMA problem here. Any suggestions as to how I can look for this, I am a relative newbie to debugging PC systems at this level. FWIW, the PCI bridge is a Pericom P17C 8150B.
I'll push the issue around internally with the engineers and see what we
can come up with. I've seen one similar (ish) issue in the past with an
ATI chipset where the cx2388x and ATI PCI controller didn't like to
co-operate much, and that turned out to be an ATI issue in a
pre-production motherboard from an OEM we partner with.
>> What else is happening DMA wise in your system?
> Not a lot of other DMA activity. A bit of disk IO for logging, and and < 100Kbps for ethernet, but this is all being done on the controlling SBC anyway which is behind the Pericom bridge.
This is a reach but I'm going to mention it anyway. Try to find the
kernel driver responsible for your DMA controller. See what diagnostic
features that offers and see if enabling any of those help pinpoint the
Second. Can you run windows on this motherboard and repro the issue? If
you can that would help tremendously. That would most likely escalate
the issue internally resulting in a rapid windows fix, and shortly after
I'd generate a Linux patch.
More information about the linux-dvb