awalls at radix
Oct 15, 2008, 6:17 PM
Post #2 of 13
(2520 views)
Permalink
|
On Wed, 2008-10-15 at 20:24 +0100, . . wrote:
> My basic problem is that recordings stop in mythtv before they should
> and mythbackend freezes, and at the end of this message is my hardware
> via lspci. I'm using 2 cards(HVR-1600 PVR-150) on a motherboard with
> VIA KM266Pro northbridge and a VIA 8235 southbridge. The manual says
> it's PCI revision 2.2.
>
> Before the 1st fix(mmio_ndelay) the HVR-1600 card worked. How well it
> worked, I don't remember because other issues were being resolved and
> I was updating the driver so often. After the 1st fix I had to use a
> value of 303 to get the card to init and work. Again I think I
> remember being able to record off of both the QAM and NTSC tuner w/o
> any issues. However, once the 2nd fix was implemented(retry_mmio)
> until now I've been experiencing the issue mentioned previously. When
> using both the QAM and NTSC tuner on the HVR-1600 card, one or the
> other will stop recording before it should and mythbackend will become
> unresponsive and must be restarted. In dmesg I get a lot of these:
> CX18_CPU_DE_SET_MDL busy
> and intermixed in-between them are a few of these:
> CX18_CPU_DE_SET_MDL failed
I can confirm I get the 'mb CX18_CPU_DE_SET_MDL busy' symptom when using
MythTV (Digital) Picture in (Analog) Picture with the HVR-1600 and a
recent cx18 driver in my more modern system:
cx18-0: mb CX18_CPU_DE_SET_MDL busy
cx18-0: mb CX18_CPU_DE_SET_MDL busy
cx18-0: mb CX18_CPU_DE_SET_MDL busy
cx18-0: mb CX18_CPU_DE_SET_MDL busy
cx18-0: mb CX18_CPU_DE_SET_MDL busy
cx18-0: mb CX18_CPU_DE_SET_MDL busy
And here are some stats on the retries of accesses to the CX23418 on my
running system:
$ su - root
# echo 3 > /sys/module/cx18/parameters/debug
# v4l2-ctl -d /dev/video0 --log-status
cx18-0: Stream encoder MPEG: status 0x0118, 3% of 2016 KiB (63 buffers) in use
cx18-0: Stream encoder YUV: status 0x0000, 0% of 2048 KiB (16 buffers) in use
cx18-0: Stream encoder VBI: status 0x0000, 0% of 989 KiB (27 buffers) in use
cx18-0: Stream encoder PCM audio: status 0x0000, 0% of 1008 KiB (63 buffers) in use
cx18-0: Read MPEG/VBI: 538073088/0 bytes
cx18-0 info: retried_write[0] = 8094974
cx18-0 info: retried_write[1] = 883
cx18-0 info: retried_write[2] = 882
cx18-0 info: retried_write[3] = 540
cx18-0 info: retried_write[4] = 270
cx18-0 info: retried_write[5] = 304
cx18-0 info: retried_write[6] = 355
cx18-0 info: retried_write[7] = 355
cx18-0 info: retried_write[8] = 321
cx18-0 info: retried_write[9] = 358
cx18-0 info: retried_write[10] = 2455412
cx18-0 info: retried_read[0] = 27696703
cx18-0 info: retried_read[1] = 0
cx18-0 info: retried_read[2] = 0
cx18-0 info: retried_read[3] = 0
cx18-0 info: retried_read[4] = 0
cx18-0 info: retried_read[5] = 0
cx18-0 info: retried_read[6] = 0
cx18-0 info: retried_read[7] = 0
cx18-0 info: retried_read[8] = 0
cx18-0 info: retried_read[9] = 0
cx18-0 info: retried_read[10] = 570
So thank you for bringing the 'DE_SET_MDL busy' issue to my attention.
I do not have data points as to whether or not it was happening before
the mmio_ndelay and retry_mmio fix. My position right now is that the
retry_mmio fix needs to stay (it helps), but this 'busy' issue needs to
be fixed.
To give buffers back to the CX23418 MPEG encoder for use, we issue a
CX18_CPU_DE_SET_MDL command to the CX23418 to tell it that it may use
the buffer again. Under various conditions of the CX23418 not letting
us give the buffer to it, we log the busy or failed message.
Once we give up trying to give a particular buffer back to the CX23418,
we never try again (that's a problem). There are only 63 buffers for
the MPEG stream. Once you dwindle down to 0 buffers for the MPEG
encoder to use, it will certainly stop responding.
As I write this email MythTV just went dark.
It looks like my CX23418 MPEG stream gave up after my system couldn't
return about 27 buffers. Debugging shows the TS stream is still going.
In the window of time bracketing when my MPEG stream stopped, my debug
logging shows that only *1* read completely failed (retried_read[10]
went from 570 to 571) while about 6 million reads succeeded on the first
try (retried_read[0]):
Oct 15 19:59:17 palomino kernel: cx18-0 info: retried_read[0] = 27696703
Oct 15 19:59:17 palomino kernel: cx18-0 info: retried_read[10] = 570
Oct 15 20:14:04 palomino kernel: cx18-0 info: retried_read[0] = 33403071
Oct 15 20:14:04 palomino kernel: cx18-0 info: retried_read[10] = 571
Oct 15 20:14:28 palomino kernel: cx18-0 info: retried_read[0] = 33582817
Oct 15 20:14:28 palomino kernel: cx18-0 info: retried_read[10] = 571
In my experience, PCI bus read failures of the CX23418 are a rare event
(570/[27696703+570] = 0.002%). That failed read could have been a
critical failure in driver-CX23418 buffer hand-off.
In that same window of time, there are many completely failed writes
(retried_write[10]):
Oct 15 19:59:17 palomino kernel: cx18-0 info: retried_write[0] = 8094974
Oct 15 19:59:17 palomino kernel: cx18-0 info: retried_write[10] = 2455412
Oct 15 20:14:04 palomino kernel: cx18-0 info: retried_write[0] = 9299978
Oct 15 20:14:04 palomino kernel: cx18-0 info: retried_write[10] = 2880730
Oct 15 20:14:28 palomino kernel: cx18-0 info: retried_write[0] = 9357999
Oct 15 20:14:28 palomino kernel: cx18-0 info: retried_write[10] = 2891039
Complete write failures are much more common events, so I never worried
about them as much.
I have to do more investigation.
> To try to fix this I've done a lot of things: enable open on demand,
> disable active eit, change the tuning delay from 0 to 300 in
> mythtv-setup, increased vmalloc from 192 to 256, increase pci latency
> of both cards from 64 to 128, tried many various combinations of
> retry_mmio on and off, and different values for mmio_ndelay. I don't
> know what else to do, any ideas?
To approximate previous behavior before either fix was introduced use:
retry_mmio=0 mmio_ndelay=0
To get the behavior before retry_mmio was introduced use
retry_mmio=0 mmio_ndelay=(number)
The setting for getting the most reliable communications between CPU and
CX23418 should be:
retry_mmio=1 mmio_ndelay=0
As a workaround you may be stuck with avoiding simultaneous analog &
digital capture from the HVR-1600 card until I find some sort of
resolution. Sorry.
> Also, where can I find out information on what options are available
> for the cx18 module and what they do, I'm aware of these, but not sure
> what they do and if others are available: enc_mpg_buffers,
> enc_ts_buffers , enc_yuv_buffers, enc_vbi_buffers, enc_pcm_buffers
$/sbin/modinfo cx18
Regards,
Andy
_______________________________________________
ivtv-users mailing list
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users
|
