> > Message: 5 > Date: Sat, 17 Jun 2006 11:26:04 -0400 > From: Brian Bustin <[EMAIL PROTECTED]> > Subject: Re: [ivtv-devel] ivtv-devel Digest, Vol 10, Issue 24 > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > >> Date: Sat, 17 Jun 2006 09:52:40 +0200 >> From: Hans Verkuil <[EMAIL PROTECTED]> >> Subject: Re: [ivtv-devel] Potential fix for DMA problems >> To: Discussion list for development of the IVTV driver >> <[email protected]> >> Message-ID: <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset="iso-8859-1" >> >> On Saturday 17 June 2006 02:39, Brian Bustin wrote: >>> I made 3 changes recently that seem to have made all the difference >>> in the world. The system has been up for a little over 17 hours and >>> it seems pretty solid. >>> >>> The three changes that I made were: >>> 1. 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. >> >> Which gcc version do you have? (gcc --version) If you have a recent >> gcc >> I don't think this is the cause of the problem. >> >>> >>> 2. 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. >> >> I don't have that option in my vanilla kernel. Seems to be a patch >> gentoo added. Actually, this sounds like something that can cause >> problems. What does it do? >> >>> 3. I am now using the kernelspace ondemand cpu frequency scaler >>> instead of using cpudyn >> >> I personally am running powernowd and I never had any problems with >> that >> cpu scaler. >> >>> >>> System: >>> Athlon 64 3000+ >>> 1 Gig of Ram >>> ASUS A8N-SLI >>> SATA hard drives using libata >>> 2 PVR-150 >>> 1 HD3000 >>> Gentoo Linux >>> IVTV 0.6.2 >>> kernel: linux-2.6.16-gentoo-r9 >>> MythTV 0.19 >>> >>> There is more information about this on my blog: >>> http://www.morph3ous.net/2006/06/16/solution-to-ivtv-drivers-ivtv0- >>> warning-enc-0-dma-error-0x0000000b/ >>> >>> I hope that this is helpful. >> >> Certainly. Can you also post your INIT IVTV messages from the kernel >> log? >> >> Thanks, >> >> Hans > > I apologize in advance for sending 3 emails. I realized that the > other 2 emails did not get connected with this thread. Must be > because I subscribe to the digests and actually created a new message > with the same subject thinking it would work. > > I have gcc version: > gcc (GCC) 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9) > > The unordered IO mapping gives this information in its help text: > CONFIG_UNORDERED_IO: > > Use unordered stores to access IO memory mappings in device > drivers. > Still very experimental. When a driver works on IA64/ppc64/pa- > risc it should > work with this option, but it makes the drivers behave differently > from i386. Requires that the driver writer used memory barriers > properly. > > Symbol: UNORDERED_IO [=n] > Prompt: Unordered IO mapping access > Defined at arch/x86_64/Kconfig:515 > Depends on: EXPERIMENTAL > Location: > -> Bus options (PCI etc.) > > My IVTV INIT is: > ivtv: ==================== START INIT IVTV ==================== > ivtv: version 0.6.2 (tagged release) loading > ivtv: Linux version: 2.6.16-gentoo-r9 gcc-3.4 > ivtv: In case of problems please include the debug info between > ivtv: the START INIT IVTV and END INIT IVTV lines, along with > ivtv: any module options, when mailing the ivtv-users mailinglist. > ivtv0: Autodetected Hauppauge WinTV PVR-150 card (cx23416 based) > ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 > GSI 21 sharing vector 0xD9 and IRQ 21 > ACPI: PCI Interrupt 0000:05:06.0[A] -> Link [APC1] -> GSI 16 (level, > low) -> IRQ 21 > ivtv0: Unreasonably low latency timer, setting to 64 (was 32) > tveeprom 2-0050: Hauppauge model 26052, rev C199, serial# 8165771 > tveeprom 2-0050: tuner model is TCL 2002N 5H (idx 99, type 50) > tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08) > tveeprom 2-0050: audio processor is CX25843 (idx 37) > tveeprom 2-0050: decoder processor is CX25843 (idx 30) > tveeprom 2-0050: has no radio, has IR remote > tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0) > cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0) > cx25840 2-0044: loaded v4l-cx25840.fw firmware (14264 bytes) > wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0) > ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes) > ivtv0: Encoder revision: 0x02050032 > ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB > total) > ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB > total) > ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB > total) > ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers > (2048KB total) > tuner 2-0061: type set to 50 (TCL 2002N) > ivtv0: Initialized Hauppauge WinTV PVR-150, card #0 > ivtv: ====================== NEXT CARD ====================== > ivtv1: Autodetected Hauppauge WinTV PVR-150 card (cx23416 based) > ACPI: PCI Interrupt 0000:05:08.0[A] -> Link [APC3] -> GSI 18 (level, > low) -> IRQ 20 > ivtv1: Unreasonably low latency timer, setting to 64 (was 32) > tuner 3-0061: chip found @ 0xc2 (ivtv i2c driver #1) > cx25840 3-0044: cx25841-23 found @ 0x88 (ivtv i2c driver #1) > cx25840 3-0044: loaded v4l-cx25840.fw firmware (14264 bytes) > wm8775 3-001b: chip found @ 0x36 (ivtv i2c driver #1) > tveeprom 3-0050: Hauppauge model 26032, rev C199, serial# 7841418 > tveeprom 3-0050: tuner model is TCL 2002N 5H (idx 99, type 50) > tveeprom 3-0050: TV standards NTSC(M) (eeprom 0x08) > tveeprom 3-0050: audio processor is CX25841 (idx 35) > tveeprom 3-0050: decoder processor is CX25841 (idx 28) > tveeprom 3-0050: has no radio, has IR remote > ivtv1: loaded v4l-cx2341x-enc.fw firmware (262144 bytes) > ivtv1: Encoder revision: 0x02050032 > ivtv1: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB > total) > ivtv1: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB > total) > ivtv1: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB > total) > ivtv1: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers > (2048KB total) > tuner 3-0061: type set to 50 (TCL 2002N) > ivtv1: Initialized Hauppauge WinTV PVR-150, card #1 > ivtv: ==================== END INIT IVTV ==================== > > Hope this is helpful. > > Thanks, > Brian > > > > > ------------------------------ > > Message: 6 > Date: Sat, 17 Jun 2006 17:41:40 +0200 > From: Hans Verkuil <[EMAIL PROTECTED]> > Subject: Re: [ivtv-devel] ivtv-devel Digest, Vol 10, Issue 24 > To: Discussion list for development of the IVTV driver > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > On Saturday 17 June 2006 17:26, Brian Bustin wrote: >>> Date: Sat, 17 Jun 2006 09:52:40 +0200 >>> From: Hans Verkuil <[EMAIL PROTECTED]> >>> Subject: Re: [ivtv-devel] Potential fix for DMA problems >>> To: Discussion list for development of the IVTV driver >>> <[email protected]> >>> Message-ID: <[EMAIL PROTECTED]> >>> Content-Type: text/plain; charset="iso-8859-1" >>> >>> On Saturday 17 June 2006 02:39, Brian Bustin wrote: >>>> I made 3 changes recently that seem to have made all the >>>> difference in the world. The system has been up for a little over >>>> 17 hours and it seems pretty solid. >>>> >>>> The three changes that I made were: >>>> 1. 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. >>> >>> Which gcc version do you have? (gcc --version) If you have a recent >>> gcc >>> I don't think this is the cause of the problem. >>> >>>> 2. 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. >>> >>> I don't have that option in my vanilla kernel. Seems to be a patch >>> gentoo added. Actually, this sounds like something that can cause >>> problems. What does it do? >>> >>>> 3. I am now using the kernelspace ondemand cpu frequency scaler >>>> instead of using cpudyn >>> >>> I personally am running powernowd and I never had any problems with >>> that >>> cpu scaler. >>> >>>> System: >>>> Athlon 64 3000+ >>>> 1 Gig of Ram >>>> ASUS A8N-SLI >>>> SATA hard drives using libata >>>> 2 PVR-150 >>>> 1 HD3000 >>>> Gentoo Linux >>>> IVTV 0.6.2 >>>> kernel: linux-2.6.16-gentoo-r9 >>>> MythTV 0.19 >>>> >>>> There is more information about this on my blog: >>>> http://www.morph3ous.net/2006/06/16/solution-to-ivtv-drivers-ivtv0 >>>> - warning-enc-0-dma-error-0x0000000b/ >>>> >>>> I hope that this is helpful. >>> >>> Certainly. Can you also post your INIT IVTV messages from the >>> kernel log? >>> >>> Thanks, >>> >>> Hans >> >> I apologize in advance for sending 3 emails. I realized that the >> other 2 emails did not get connected with this thread. Must be >> because I subscribe to the digests and actually created a new message >> with the same subject thinking it would work. >> >> I have gcc version: >> gcc (GCC) 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9) > > Hmm, it could be that this compiler has problems with size > optimizations. I'm using gcc-4.1.1. > >> >> The unordered IO mapping gives this information in its help text: >> CONFIG_UNORDERED_IO: >> >> Use unordered stores to access IO memory mappings in device >> drivers. Still very experimental. When a driver works on >> IA64/ppc64/pa- risc it should >> work with this option, but it makes the drivers behave >> differently from i386. Requires that the driver writer used memory >> barriers properly. > > Sounds dangerous. > > It would be nice if you can tell which of these two options are the > culprit. If it is the UNORDERED_IO, then I may have to check for > memory > barriers. > > Hans > > > > ------------------------------
Hans, I would be glad to do some tests for you. I'll start testing it all out after the world cup. The system still seems to be doing well. Let me know if this would be the best way to test it. Compile the kernel 2 more times, and save separately in /boot kernel 1: Optimize for size, no unordered IO kernel 2: no optimize for size, unordered IO boot kernel 1, turn cpudyn back on, and disable script that is loading the ondemand governor boot kernel 1, disable cpudyn, reenable script that is loading ondemand governor boot kernel 2, turn cpudyn back on, and disable script that is loading the ondemand governor boot kernel 2, disable cpudyn, reenable script that is loading ondemand governor boot current working kernel and test with cpudyn turned on Would this be a good way to test it? Do you have any other tips that may help me to get you better information? After the world cup is over, I'll test this out. Thanks, Brian _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
