Update: The author of IVTV has just released a patch that may resolve these problems once and for all
I think that I may have found a solution to this problem. The problem is detailed in this post. I made 3 recent changes to my system, and I am not sure which has led to everything working. (I made some other changes that I will not detail here at the moment; however, they did not resolve the problem. These are the only large changes that I have made in the past week.) The system has only been up for 7 hours 30 minutes with these changes; however, it has been rock solid.
The first 2 changes are changes in the kernel settings:
- In General Settings I removed Optimize for size
- I had not realized that this option was selected in the first place. It very clearly notes that it may cause problems with certain compilers.
- In Bus Options and then PCI Support I removed Unordered IO Mapping
- I had also not realized that this was selected. The help text clearly notes that it is experimental code, and will only work properly for drivers that have been coded for specific platforms.
The final change was for Cool N’ Quiet. I had been using the userspace program Cpudyn to change the frequency of my processor. I thought that it might be better to do this all in kernelspace. The different governors were already compiled into my kernel, so I added the following to my /etc/conf.d/local.start (I believe this is a Gentoo-specific location):
echo "--------------------------------" echo "Enabling Cool N' Quiet using kernel ondemand governor" echo "*** No longer using cpudyn userspace program***" echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "Setting ondemand governor to increase cpu speed for niced processes" echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load echo "--------------------------------"
Then I made sure to disable cpudyn from coming up on system startup by issuing this command: rc-update del cpudyn (Gentoo-specific command).
I learned the information about Cool N’ Quiet from the HOWTO: PowerNow! page on Gentoo-wiki.com.I hope that you have found this information useful and that it works for you. Please leave a comment to let me know whether this did or did not work for you.
UPDATE:
The machine has now been up for slightly more than 17 hours. There are 10 successful recordings. I am able to watch TV with both tuners.
The dmesg output has two ivtv0 warning: ENC: (0) DMA Error 0x0000000b errors. I would prefer not to have any; however, normally there would have been a lot more at this point. I also would normally have the ivtv0 warning: ENC: REG_DMAXFER 2 wait failed error. That error usually indicates that at least one of the tuners is no longer functioning properly.
This looks to be a fix for the problem that I was encountering. I have tried to post this information at http://ivtvdriver.org/trac/ticket/48; however, it won’t seem to let me.
If you have any idea which of the changes made this drastic difference, please let me know. My bet is on using the kernelspace support for Cool N’ Quiet instead of the userspace cpudyn program.
I’m experiencing this as well. Over the past few days I’ve dug into the code, but I haven’t uncovered anything yet… just ruled some things out. I made a post to the mailing-list… but it doesn’t seem to be showing up.
In my experience with this bug, getting the DMA error may or may not cause an observable problem. It’s pretty much russian roulette. However, if you stress your system to the max, I’ve found this causes the error to occur very quickly, several times, and within at the most 15 minutes you’ll see video corruption. Again… it’s russian roulette, so you can always get lucky several times in a row. You might want to test your system by starting a transcode or two, and recording on one tuner and watching on the other. My guess is that what you’ve found isn’t really a fix, you’ve just been lucky.
Mr. Lewis,
You’re right, it may just be luck at the moment. I’d like to hope not, but I honestly do not know.
The good news is that so far the system has been up for almost 21 hours. I still only have the 2 errors. Both tuners seem to be working still. I have never gone this long without at least one of the tuners ceasing to function. I have my fingers crossed that it will continue to work.
Last time I thought I had found a solution by enabling AHCI. I then thought it had gotten at least a little better after changing the PCI latency settings of various cards. In the end AHCI had no effect, and the latency settings may have helped only slightly.
This is the longest that the system has been running properly. I hope it is not just luck, as I would like to help the community narrow down the cause of this error. I unfortunately am not skilled enough to read C code at the moment. One of these days…
I have been seeing the same exact issues with my KT800 MSI motherboard. I made the following changes, which so far have seemed to have resolved the problem.
I changed my bios setting to match those recommended on NVIDIA’s website.
http://nvidia.custhelp.com/cgi-bin/nvidia.cfg/php/enduser/std_adp.php?p_faqid=805&p_created=1141634762&p_sid=u9RQCPai&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTcmcF9wcm9kcz0wJnBfY2F0cz0wJnBfcHY9JnBfY3Y9JnBfc2VhcmNoX3R5cGU9YW5zd2Vycy5zZWFyY2hfZm5sJnBfcGFnZT0xJnBfc2VhcmNoX3RleHQ9Qmlvcw**&p_li=&p_topview=1
I the only one that applied to my motherboard was PCI Latency Timer=128.
That got rid of the hangs and corrupted video but I was still getting the
ivtv0 warning: ENC: (0) DMA Error 0×0000000b
Error every once in a while.
I downloaded the latest firmware from ivtv sites. Copied it over the atrpms firmware. And powered down my PC. Once I powered up, it seems to have gone away, at least for now. I will update if I see it again.
This really looks like a DMA conflict of some kind occuring at the hardware level. It had gotten so bad that it messed up the all DMA to my systems. Making my harddrive screw up so that it was corrupting my filesystems and generating write errors in dmesg output. I shut the system down. Download the maxtor diagnostic iso. Ran the Adv. Diags. they reported no problems with the drive. Boot up the system again and the dma errors were completely gone. Everything was happy including me, since I though I had a bad drive.
Also cool and quite is disabled in my bios.
Okay, never mind a complete waste of time. All that does is reduce the likely hood of have a DMA that can corrupt the file. It does not get rid of them. I will keep working on it. This seems to be hardware related.
Not sure if this is a fix or not. but I have captured serveral movies now and have not recieved the dreaded
vtv0 warning: ENC: (0) DMA Error 0×0000000b
error messages. i am getting the following when the recording ends:
ivtv0 warning: ENC: EOS took 476 ms to occur. However, this does not seem to be a problem as far as the recording is concerned, ever thing looks good.
I am running the 2.6.16 kernel on FC5 using the 6.3 drivers. Edited /etc/grub.conf and added the following option to the kernel boot parameters:
pci=routeirq
Would like to know if this helps anyone else or if this seems to be a solution.
Jimmy,
I’ve been having some minor problems now, but it’s much improved since making the changes that I posted here in the blog. I am going to try the pci=routeirq kernel boot parameter to see if it helps.
Gentoo has ivtv-0.6.3 and a slightly newer version of the MythTV 0.19 ebuild. I am going to update those first, give it a couple of days, and then try with pci=routeirq.
I really appreciate all your contributions here.
Brian
I’m also running a AMD64 Gentoo Mythtv Box with 2 tuners and am seeing this error in my dmesg. I’ve upgraded to 2.6.16 and ivtv 0.6.3 last weekend and just starting seeing this. I’ll try to pci=routeirq later this week. Also, my box has been up for about 2 days and I think only one or two recorded programs.
Also, I noticed some system lockups when doing a channel scan in the mythtv-setup which really worries me. I’m going to monitor the box closely over the next couple of weeks to ensure there is no lockups under normal recording operation.
Let me know if you need any further information from me to help debug this problem.
-Todd
Hi. I’m having the same same problems. Just tried the pci=routeirq kernel option. Doesn’t help. 15 minutes after the reboot I got the first DMA error.
Is everyone here running his system in 64 Bit mode? I’m thinking about recompiling everything for 32Bit. Anyone knows if this is worth a try?
dreadhead
Hi!
I’ve put the old HD from my old MythTV installation (32Bit) into this PC and tested this for 3 days. It was running perfectly undtil I the HD crashed
So I thougt this is the solution to our Problem and installed a fresh 32 Bit install to the new HD. Unfortunately also here I got the errors and the crashes.
But I think, since old installation was running 3 Days whitout 1 DMA-Error this is not a Hardware-related thing.
I will keep on trying…
Anyone of you has new informations about this?
I did a fresh install of FC5 64bit.
I switched to using the firmware and drivers as provide off of atrpms.
Seems to have settled down quite a bit. The weird part is that I did try to compile from source to install the drivers that way. Boy, did I ever have problems with that.
Other, weirdness if I boot into windoze, and do a warm boot back into linux the card will quite working. I have to shutdown and power down to get back into linux with a working pvr-250.
Got the same DMA issues on my box. Usually happens if I delete a very large file during a recording, like an old 2h video of around 4GB. Once it happens I need to reboot to fix it.
I’ve been playing with various different firmware versions as some appear to work a bit better meaning it becomes a lot harder to cause the problem. Hope to send a report to the IVTV mailing list soon.
Oh i’m running a 32Bit Athlon 64 3000+ with Knoppmyth
I seem to be hitting this problem everytime I record now. I’ve created a wiki page on the offical ivtv wiki:
http://ivtvdriver.org/index.php/DMA
Maybe we can consolidate our information about this problem there.
Thanks,
-Todd
I believe there has been work with the 7.1 drivers to resolve this DMA issue. As well as the 8 drivers. I have been useing the 7.1 for a while and have not seen a the problem manifest. But I have not been doing a lot of video capture work recently either.
I started having this problem /after/ trying to upgrade to the latest ivtv (0.7.1) under Gentoo (AMD64) From the looks of things, the 0.7.1 upgrade also came with a new package for the firmware.
Long story short, when I shut down for 30 seconds and then rebooted, the problem went away (after having to reboot it every day for a week because the encoder stopped responding) Anyway, it is such a frustrating problem, and I seem to have licked it, so give it a try if you run into this one.
Looks like the 8.1 drivers are out looking at the change log below. there appears to have be serveral things that were broken that could relate to a lot of the problems we all have been seeing.
0.8.1 stable release
- vbi test tool accepts -d1 as a shortcut for /dev/video1
- added videodev2.h in utils since distros often are sloppy
in updating this file in a new kernel release.
- some usability improvements to v4l2-ctl. Please note! Some
options have new names.
- workaround VIDIOC_INT_S_REGISTER kernel bug (wrong ioctl value
in the v4l2-common.h header, this is fixed in 2.6.19).
- saa717x fixes for Japanese cards.
- reported pix format was V4L2_PIX_FMT_UYVY instead of V4L2_PIX_FMT_HM12.
- added missing VIDIOC_ENUM_FMT ioctl.
- added new IVTV_IOC_STOP ioctl (thanks to Martin Dauskardt )
- added new IVTV_IOC_PAUSE_BLACK ioctl (thanks to Martin Dauskardt )
Similar to IVTV_IOC_PAUSE, but it turns the output black when paused.
- Fix encoder pause/resume: these two were swapped.
- Firmware loading has been made more robust
Thanks to Robert Hardy .
- Firmware loading once again supports ppc.
- Fix nasty bug when loading the init mpeg file
Thanks to Robert Hardy .
- Enabling of newi2c support now depends on the presence of an IR-blaster.
- No longer turn the digitizer off and on when changing channels, this
caused the tinny audio!
- Fix VIDIOC_STREAMOFF support.
- Detection of Hauppauge cards is now fully based on the tveeprom,
PCI IDs are ignored. Other cards still use the PCI ID for detection.
- The detection of the first or second unit of a PVR500 is now done based
on the PCI ‘slot’ used on the PVR500 card. The first unit has slot 8,
the second has slot 9.
- Added IR-blaster detection, with thanks to Hauppauge’s Steven Toth for
providing this information.
- Fix initial PAL/SECAM/NTSC tuner defaults.
- Fix driver cleanup in case an error occurs.
- Fix VIDIOC_INT_S_AUDIO_ROUTING ioctl.
- Ripped out dynamic buffer allocation: it never worked right and gave
some people a lot of grief.
- Make i2c errors (missing i2c devices) more readable.
The failures to load the firmware on a reboot could be related to one of the following:
- Fix nasty bug when loading the init mpeg file
- Firmware loading has been made more robust
I for one have seen a lot of the errors related to this one.
- Ripped out dynamic buffer allocation: it never worked right and gave some people a lot of grief
So far so good with these drivers but I just upgraded to the 8.1 version. If you do upgrade remember to power off and wait about 30-40 sec before powering back on to give the card’s memory time to completely clear.
Good Luck.