View Single Post
Old 08-14-06, 08:02 PM   #27
StevenChamberla
Registered User
 
Join Date: Jul 2006
Posts: 14
Default Re: Crashing when SMP enabled

Quote:
Originally Posted by JaXXoN
Max should stay below 100 for a nanosleep call:
Code:
cyclictest -c 1 -n -p 80 -t 1 -i 1000
Ah, much better, but well above 100. The '-n' option alone stops the number from increasing beyond 1200 or so.
Code:
T: 0 (26423) P:80 I:    1000 C:  240520 Min:       5 Act:     420 Avg:     512 Max:    1189
I left cyclictest running in X and started a compile running. 'jackd' suffered an xrun but the figure for 'Max' did not increase.
Code:
From 'jackd':
**** alsa_pcm: xrun of at least 1.108 msecs
I even tried without X or 'nvidia' module loaded, and managed a max figure of '1014' when running a compile in the background. Switching virtual terminals brings the figure to over 4000 but I believe there are unavoidable latencies invovled with VT switching.

Quote:
Originally Posted by JaXXoN
Did you also applied "idle=poll" as kernel boot option?
Yes, I was using this boot option, as well as 'pci=conf1' and 'noirqbalancer' as suggested earlier. I also used 'noapic' because without APIC the IRQs for my devices are such that the sound card has a higher priority than the disks, video, and network interface.

I tried booting without any of these options and still got a figure of '1184' for max. Again, I ran a compile which caused 'jackd' to xrun but the value in cyclictest did not increase. The compile was running under the 'TS' scheduler; the main 'jackd' thread, as well as the threads 'feeding' JACK, were all running with 'FF' scheduler.

So, am I right in thinking this indicates a problem with the realtime patch? Or rather, there is a latency somewhere which has not been fixed by the realtime patch. If so, I should probably learn how to debug the realtime patch and hopefully find out where the latencies are coming from.
StevenChamberla is offline   Reply With Quote