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
