Hello, Let me add a datapoint to the discussion. I have an hp a1450n (you can get details from hp.com). With 0.4.6 (I'm using SuSE 10.0) I have the DMA problem with the Hauppauge 350 for which I'm using the PIO mode in the driver. But, the HD5500 in my box has no problems at all with DMA. It happily records QAM from cable. Marty
Hans Verkuil wrote: > Hi Steven, > > Is it possible to talk this over in the ivtv-dev channel of > irc://irc.freenode.net/ivtv-dev? It is probably easier to discuss this > on that IRC channel, at least initially. > > I can be on that channel between 8 pm and midnight tonight or tomorrow, > my timezone is GMT+2. > > Let me know if and when you can be on IRC. If it's not possible, then we > continue by email. > > Regards, > > Hans > > On Wednesday 09 August 2006 05:18, Steven Ellis wrote: > >> Hi Hans >> >> Hans Verkuil wrote: >> >>> On Tuesday 08 August 2006 23:37, Steven Ellis wrote: >>> >>>> First off can someone setup an account on trac for me so I can >>>> update tickets 48 and 49. >>>> >>> Axel, can you do this? >>> >> Cheers >> >> >>>> Now I have been trying ivtv version 0.4.2-0.4.6, plus I've seen >>>> recent reports of the problem still being present with the 0.6.x >>>> tree. >>>> >>>> Hardware - Asus A8N-VM CSM motherboard, Athlon 64 3000+, Knoppmyth >>>> R5B7 with 2.6.15 kernel, IDE HD and either PVR150 or PVR500 >>>> capture (tried both). I also have a FreeCom USB DVB-T card, and I >>>> run a lot of media over the 100Mb network. >>>> >>>> Reproducing the problem >>>> -------------------------------- >>>> Can almost do this at will now. If I have a capture running whilst >>>> I delete a large previously captured file (about 2G) off an ext3 >>>> local volume the slight system pause during the deletion is enough >>>> to force the problem. >>>> >>>> It also seems to happen quite quickly if I'm playing a video file >>>> across the network via NFS and jump around the video stream very >>>> rapidly. Its like the ethernet i/o is preventing the DMA from the >>>> ivtv card >>>> >>>> Attempts to fix the problem >>>> ---------------------------------- >>>> 1. Turned off Cool and Quiet >>>> This was mentioned in trac ticket 48 as a possible fix. Initially >>>> appeared to reduce occurrences, but I was mistaken. No change >>>> >>>> 2. Try to change the PCI latency of the IDE devices with setpci. >>>> Doesn't work with the IDE devices on my motherboard. It uses and >>>> nforce chipset and the driver won't let you change latency values. >>>> The MythTV Wiki recommends bumping the IDE latency to avoid >>>> issues. >>>> >>>> 3. Check BIOS level timings etc >>>> Doesn't appear to be anything I can tweak in this bios. >>>> >>>> 4. Use PIO mode. >>>> Well I just tried this and my machine isn't fast enough to capture >>>> full D1 PAL in PIO mode. CPU is running 60%+ in ivtv_enc, but I >>>> still get capture issues. >>>> >>>> Possible Next Steps >>>> ------------------------ >>>> 1. Changing the size of the DMA ENC buffers >>>> Any chance increasing the buffer sizes might help matters. >>>> >>> Won't help. >>> >> Ok. Nice to know. >> >> >>>> 2. Enable additional debug information >>>> This is where I need some feedback. What debug options should I >>>> look at enabling. >>>> >>>> >>>> I'd really appreciate any help here. The oddest part is I never >>>> had this problem with the older 0.3.x driver versions. There are >>>> quite a few people on this list and the users list with the >>>> problem. I'm sure with a bit of guidance from Hans we can track it >>>> down. >>>> >>> First of all, this problem can only occur after a DMA error. Some >>> chipsets are more prone to DMA errors than others, so this >>> introduces a hardware component into the problem. Many people don't >>> see this (or only very rarely) because their hardware is better in >>> dealing with DMA. >>> >>> At some point in time Chris Kennedy switched from using the >>> firmware DMA mailbox commands to directly programming DMA registers >>> in the card's memory. The reason is that the card's firmware is >>> simply buggy when dealing with DMA (and from all accounts so is the >>> hardware). This is (if I understand correctly) especially the case >>> when multiple streams (e.g. MPEG encoding and MPEG decoding, or >>> MPEG encoding and VBI) are running simultaneously. >>> >> Ok what version do I need to look at for the old DMA code. I'm more >> than happy to try an retrofit that code into the current 0.4.x tree >> and work through my steps that reproduce the problem. Don't a bit of >> Linux device driver work in the past so i'm not totally poking around >> in the dark (see tw98.sf.net). >> >> >>> Now it seems that when a DMA error occurs the dma_from_device() >>> function doesn't seem to be able to restore the card to the correct >>> configuration before retrying the DMA. The result is that MPEG data >>> is shifted and the stream becomes corrupt. >>> >> Makes a lot of sense based on the nature of the visible artifacts >> >> >>> Several people have looked at it without finding anything special. >>> It is really hard for me to investigate since it so rarely happens >>> on my hardware. >>> >>> An alternative approach (although that would be a temporary >>> solution only) might be to reinstate the original DMA handling and >>> make it possible to select one or the other. It may well be that >>> the original DMA handling is actually better at correcting DMA >>> errors in the case of having just a single stream. >>> >> Yes I agree it would be good to make the two DMA modes selectable. >> >> >>> What makes this an interesting approach is that it may be possible >>> to compare the DMA registers after a DMA error occurred and see if >>> that suggests a solution for our dma_from_device() function. >>> >> How can you do this? >> >> >>> Unfortunately, I myself don't have the time for that, and the great >>> difficulty I have to even reproduce it doesn't make it easier for >>> me. >>> >> Understood. Just need some pointers and a little bit of hand holding. >> >> >>> There are no debugging options that are useful here. It is really a >>> case of very low level printk debugging and hoping you can find out >>> what's wrong. If it was easy this would have been fixed ages ago. >>> >>> I would really appreciate it if you would manage to solve this, but >>> be aware that it is probably a major effort. >>> >> This is really important. My company (www.openmedia.co.nz) has been >> shipping MythTV based PVR units using the Hauppauge cards, and thus >> far most of my customers aren't having the problems. I can reproduce >> this quite easily in my lab thanks to the stress tests I perform. >> Quite happy to apply some engineering time onto this issue so that >> all of the ivtv users can benefit. >> >> Steve >> >> _______________________________________________ >> ivtv-devel mailing list >> [email protected] >> http://ivtvdriver.org/mailman/listinfo/ivtv-devel >> > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel > > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
