[ivtv-users] PVR-500 sporadically failing: DMA TIMEOUT 00000001 0

Andy Walls awalls at radix.net
Fri Mar 19 18:58:34 CET 2010


On Fri, 2010-03-19 at 01:59 -0700, Pete wrote:
> On Feb 8, 2010, 2:12 PM, cybertron at nemebean wrote:
> > On Mon, 8 Feb 2010 16:49:45 -0500, "Matt S." <skd5aner [at] gmail>
> wrote:
> >> I'm running Ubuntu 9.10 (server): 2.6.31-17-server #54-Ubuntu SMP
> >> Thu Dec 10 18:06:56 UTC 2009 x86_64 GNU/Linux
> >>
> >> The card has been fairly rock solid for several years, but it
> >> seems over the past week or so (following an apt-get
> >> update/apt-get dist-update) that it frequently becomes unusable
> >> after a few hours/days.
> >
> > I've run into the same problem, although I've had it for a bit
> > longer. There's a workaround from a couple of years ago that you
> > can find here:
> > http://ivtvdriver.org/pipermail/ivtv-users/2007-June/006626.html
> 
> I've been having this dreaded problem as well, since about
> 10/2009, and cannot find a kernel/driver just prior to that
> which resolves the issue.  I also switched motherboards around
> that time (to an Asus M3N78-VM, nVidia 8200/AMD-based), and so
> have been trying to figure out whether it is an IRQ hardware
> issue, as this board seems to assign the same (shared) IRQ to
> every PCI and PCIe slot.  No BIOS option to give the PVR-500
> its own IRQ, though it flakes out after a few minutes to a
> couple hours of recording even when the other cards are idle.
> Tried every ACPI switch, increased IRQ latency, all to no avail.
> 
> I turned on debug=0x63, and found that there are some
> warnings that may give further hints:
> [75352.975814] ivtv1:  warn: DMA ERROR 00000003 00000000 00000013 0
> [75523.644223] ivtv1:  warn: DMA ERROR 00000003 00000000 00000013 0
> [80997.874066] ivtv1:  warn: DMA ERROR 00000003 00000000 00000013 0
> [81138.711795] ivtv1:  warn: DMA ERROR 00000003 00000000 00000011 0
> [81139.011347] ivtv1: DMA TIMEOUT 00000001 0
> [81141.397531] ivtv1:  info: close stopping capture
> [81141.397545] ivtv1:  info: Stop Capture
> [81141.490391] ivtv1:  info: Start encoder stream encoder MPG
> [81141.512265] ivtv1:  info: Setup VBI API header 0x0000bd03 pkts 1 
> buffs 4 ln 24 sz 1456
> [81141.512387] ivtv1:  info: Setup VBI start 0x002fea04 frames 4 fpi 1
> [81141.516587] ivtv1:  info: PGM Index at 0x00180150 with 400 elements
> kernel: [81142.401605] ivtv1: DMA TIMEOUT 00000001 0
> etc.

You might want to try debug=0x467 and see if you spot a pattern of
events in common leading up to each "DMA ERROR" warning message.  The
amount of logging of normal activity will be huge hwoever.

> 
> Note that the warning with status 0x13 appears infrequently,
> and doesn't seem to be harmful.  The 0x11 is fatal, as it is
> always followed by the dreaded DMA TIMEOUT exactly 300ms later
> (corresponding to the hardcoded DMA timeout value in ivtv-irq.c).

That's an interesting observation.  That 0x11 or 0x13 is the contents of
the DMA transfer status register.  It is described at 

	linux/Documentation/video4linux/cx2341x/fw-dma.txt

as:

        DMA Transfer Status
        ===================
        
        Register 0x0004 holds the DMA Transfer Status:
        
        Bit
        0   read completed
        1   write completed
        2   DMA read error
        3   DMA write error
        4   Scatter-Gather array error
        
So 0x11 corresponds to the case of an SG array error when the
"write" (what write?) didn't complete.


For the case of an 0x11 status, I wonder if there is anything wrong with
the corrective actions being taken in ivtv-irq.c:ivtv_irq_dma_err() just
after the error message.

	write_reg(read_reg(IVTV_REG_DMASTATUS) & 3, IVTV_REG_DMASTATUS);
        if (!test_bit(IVTV_F_I_UDMA, &itv->i_flags) &&
            itv->cur_dma_stream >= 0 && itv->cur_dma_stream < IVTV_MAX_STREAMS) {
                struct ivtv_stream *s = &itv->streams[itv->cur_dma_stream];

                /* retry */
                if (s->type >= IVTV_DEC_STREAM_TYPE_MPG)
                        ivtv_dma_dec_start(s);
                else
                        ivtv_dma_enc_start(s);
                return;
        }
       
Maybe trying to restart the DMA, when we don't have a "write completed"
status on the SG Array error, is the wrong thing to do.

-Andy

> Interesting that the tuner remains broken even after
> reloading the driver and firmware with rmmod/modprobe, and
> only a reboot makes it operational again.  Wonder if there's
> something more the driver should be doing to reinitialize it?

> --Pete





More information about the ivtv-users mailing list