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 [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
