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.

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.

Maybe we can consolidate our information about this problem there.

Thanks,
-Todd

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

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?

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

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

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

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.

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…