Mailing List Archive

PVR-500 sporadically failing: DMA TIMEOUT 00000001 0
I have a PVR-500 which is sporadically failing to tune, and the only
way I can get it to restore itself into a working state is by
power-cycling the machine.

When I look at dmesg, I'm flooded with:
[423390.332526] ivtv1: DMA TIMEOUT 00000001 0
[423393.262527] ivtv1: DMA TIMEOUT 00000001 0
[423396.202536] ivtv1: DMA TIMEOUT 00000001 0
[423399.132526] ivtv1: DMA TIMEOUT 00000001 0
[423402.072524] ivtv1: DMA TIMEOUT 00000001 0
[423405.012532] ivtv1: DMA TIMEOUT 00000001 0
[423407.980026] ivtv1: DMA TIMEOUT 00000001 0
[423410.912530] ivtv1: DMA TIMEOUT 00000001 0
[423413.852531] ivtv1: DMA TIMEOUT 00000001 0
[423416.822530] ivtv1: DMA TIMEOUT 00000001 0
[423419.792532] ivtv1: DMA TIMEOUT 00000001 0
[423422.722525] ivtv1: DMA TIMEOUT 00000001 0
[423425.660026] ivtv1: DMA TIMEOUT 00000001 0


Looking through some of the archives, I enabled ivtv-ctrl -D584 and
now I get a bit of info of the card, followed by this repeating
section:
[423612.950535] ivtv1: ioctl: V4L2_ENC_CMD_START
[423613.282924] ivtv1 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0
[423613.852524] ivtv1: DMA TIMEOUT 00000001 0
[423615.801458] ivtv1: ioctl: V4L2_ENC_CMD_STOP
[423615.900035] ivtv1 encoder MPG: VIDIOC_ENCODER_CMD cmd=1, flags=0
[423615.900052] ivtv1: ioctl: V4L2_ENC_CMD_START
[423616.232541] ivtv1 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0
[423616.822524] ivtv1: DMA TIMEOUT 00000001 0
[423618.749941] ivtv1: ioctl: V4L2_ENC_CMD_STOP
[423618.852528] ivtv1 encoder MPG: VIDIOC_ENCODER_CMD cmd=1, flags=0

For more detailed dmesg output: http://mythtv.pastebin.ca/1790617


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.

Any ideas on what to do or how to troubleshoot?

Thanks!
Matt

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: PVR-500 sporadically failing: DMA TIMEOUT 00000001 0 [ In reply to ]
On Mon, 8 Feb 2010 16:49:45 -0500, "Matt S." <skd5aner@gmail.com> 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.
>
> Any ideas on what to do or how to troubleshoot?

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

In my case that has been okay because I'm not particularly CPU limited on
my backend, but on an older system the extra CPU usage might be too much.
It also means I have to remember to recompile and reinstall the driver
every time there is a kernel update (also on Ubuntu 9.10). However, I've
been too busy fighting with Myth .22 to pursue problems that aren't
immediately causing me grief, which is why I haven't mentioned it until
now.

I had assumed it was my HVR-1600 that was causing this since, like yours,
my PVR-150 has been rock solid pretty much since I got it, but it's
possible that was the culprit in my case as well. I'll have to check next
time it happens.

-Ben

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: PVR-500 sporadically failing: DMA TIMEOUT 00000001 0 [ In reply to ]
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.

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).

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?

Switching from DMA to PIO using the patch you refer to seems to
work so far, but is clearly a last resort. When one program is
recording, the CPU runs at full speed (unthrottled); when both
PVR-500 tuners are recording, the load avg shoots up to 10.
Especially bad in a combined mythtv front/backend where heat
and fan noise need to be minimized.

If PIO turns out to be the only long-term solution, that switch
should probably be made into a per-card modprobe parameter, so
we don't have to keep maintaining our own custom kernel builds.

--Pete

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: PVR-500 sporadically failing: DMA TIMEOUT 00000001 0 [ In reply to ]
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



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