Hi! Already tried disabling cpu speed management. Doesn't change anything for me.
My vacancy ends on sunday so I can resume testing on this on monday and I can answer mails more frequently. I think the first thing I'm going to try is setting up some <=2.6.13 kernels. Until now I just tried 2.6.14 and 2.6.15. Yours, Michael Am 10.08.2006 um 21:15 schrieb Simen Thoresen: > Michael Zanetti wrote: >> Hi Simen, Rey, > > Hi Michael, Rey, > > I've been able to confirm on my own that this issue is not limited > to SMP-kernels; > My 2.6.17.6 kernel is susceptible in both SMP and UP modes. My > CentOS 2.6.9 kernel is not usable in SMP mode (unrelated timer/ > motherboard problems), and on the 2.6.9 UP kernel I had to disable > the cpuspeed service (load-based clock throttling) as loading the > single-CPU powernow-modules dies rather horribly on my X2 kernel. > Still, i did /not/ see the problem with the 2.6.9 kernel, and I > feel the test was running for a sufficient length. > > I saw Kristo (on the list) mentioning that this had been tied to > CPU throttling, so I'm currently back to the 2.6.17 SMP-kernel, > unmodified 0.7.0 ivtv-source but cpuspeed disabled. As it was with > this setup that I first noticed the errors, I think I will do so > again. I've set up a regimen to grab and encode a lot more data tv- > time than I usually do, so I hope the error will show up quickly. > > Michael, Rey, can you confirm that you are running with a speed > management utility, or (possibly) that your kernels are compiled > with support for speed management? > > This should show as the presence of the > /sys/devices/system/cpu/cpu0/cpufreq/ > subtree (I'm not sure if there is a similar /proc) interface. > > If so, perhaps you too could give running without speed managment a > try? > > I'll report back when I have run a while with this, or have seen > errors. > > Yours, > -S > > > > >> Am 05.08.2006 um 12:46 schrieb Simen Thoresen: >>> Hi Michael, Rey, >>> >>> I have not seen any new replies to this, nor anything from any >>> developers. As I wrote in my problem report, I've been an ivtv- >>> user for a while, but only recently subscribed to the list - thus >>> I don't know what to expect from developer interest and such. >>> >>> Still - assuming the developers are reading the list and and are >>> interested in the problem, I thought I'd try to summarise our >>> systems so that we can get similarities or differences sorted out. >>> >>> My system (as previously written) is an Asus A8N-SLI Deluxe >>> motherboard, with an Athlon64 X2 chip, running in i386 mode, with >>> ivtv 0.7.0 on a 2.6.17.6 kernel. >> My system: >> ASUS A8V (VIA-chipset). >> tried kernel 2.6.14 and 2.6.15 (I cannot use >=2.6.16 because of >> missing support from dmraid) >> tried ivtv-0.4.x >> The best results I got with 0.4.0. The system stays up for about 2 >> days. The worst case comes with 0.4.5. ivtv crashes after about 10 >> minutes. >>> >>> This means >>> -NForce4 (I would not thing that mobo brand or chipset features >>> matter too much) >>> -SMP (This may be important. I've run my card with ivtv-0.4.x >>> 'forever' in UP-mode on older kernels without issues) >>> -kernel 2.6.17 + ivtv 0.7.0 >>> >>> >>> Michael; >>> From your mail, I understand you are running an A8V board (That >>> would be a ViA K8T800pro-board, right?). Are you running an X2 >>> CPU in SMP on this? In i386 and not x86-64 mode? >> Yes, it is the A8V with the mentioned chipset. I do not have an X2 >> CPU and tried both, SMP and not SMP. I tried a fresh x86 install >> and a x86-64 install. I still have both of them on my drive so I >> can test them both. >> 2 weeks ago I put my old HD from my PIII mythbox into this PC and >> tested with this. For two days I could run the system without one >> error. Unfortunately I had a disk headcrash and the working system >> is now away (I know I'm too lazy with backups). >>> Also, you're writing that ivtv 'crashes' - are we talking about >>> the same DMA error; >>> warning: ENC: (0) DMA Error 0x0000000b >>> reported some or many times during a capture? >>> The actual error number may be important, altho I don't know what >>> it signifies. >>> >> Right. It is the same Error and also the number matches. The >> message appears just as the System load goes up. For example when >> running one recording and mythcommflag or running 2 recordings and >> watching one at the same time. I couldn't find a certain point of >> CPU load causing the problems. Probably the DMA-access from the >> hard disk and the ivtv-cards at the same time are disturbing each >> other. >>> Altho my errors were a lot less frequent that I have seen others >>> report, they never caused ivtv to stop working, nor impaired >>> system stability. >>> >>> >> My system throws out some DMA errors and then the one: >> ivtv: DMA still pending while stopping capture. >> After this message the card is unusable and I have to reboot the >> system. Unloading and reloading the ivtv module doesn't help. >>> >>> Rey; >>> You write that you have the same setup as I have. Could you >>> please expand on that? >>> Did the patch work for you as well as it does for me? >> Of course the patch works well since DMA for the ivtv-cards is >> totally switched off. Unfortunately its not a solution for me >> since I cannot watch any recordings when both cards are capturing >> because of the CPU load. >>> >>> >>> >>> So - assuming Michael is experiencing the same problem I am, it >>> would seem that his is /not/ a chipset issue (or, if it is, both >>> NForce4 and K8T800pro chipsets are affected), but the common line >>> is that it applies to Athlon64 CPUs, possibly SMP setups. >> I agree with the chipsets but its not the SMP setup. >>> >>> From my own experience from my own setup, I feel pretty confident >>> that the the main change I introduced was the SMP CPU. I see >>> others have reported this issue with other kernels and ivtv- >>> versions, but good information is typically missing. >>> >>> With a little spare time, I will build an UP kernel and give that >>> a spin with an unmodified ivtv-driver. Given that my errors never >>> were very frequent, testing will take time to be conclusive. >> I did some more testing but couldn't find out any setups working >> fine. >> As mentioned above I think it could have to do something with the >> DMA transfers of the hard disks. I am using a SATA I -Raid 0 >> setup. Are you using SATA and/or RAID? >> Hope this helps. Let me know if you need some more information. >> Currently I'm not at home so I cannot do any testing for the next >> week. >> Michael > > -- > Simen Thoresen, Dolphin ICS > _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
