peter@xxxxxxxxxxxxx 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 >>> anything. >> 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 problem. 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. - Steve _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
