Re: realtime-preempt-2.6.12-final-V0.7.51-01 compile error and more problems

[William Weston <weston@sysex.net>]

On Wed, 6 Jul 2005, Carlo Scarfoglio wrote:

> Compilation stops at this point:
> 
> make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
>    CHK     include/linux/compile.h
>    CHK     usr/initramfs_list
>    CC      net/ipv4/netfilter/ip_conntrack_proto_tcp.o
> net/ipv4/netfilter/ip_conntrack_proto_tcp.c: In function 
> `tcp_print_conntrack':
> net/ipv4/netfilter/ip_conntrack_proto_tcp.c:333: error: `tcp_lock' 
> undeclared (first use in this function)
> net/ipv4/netfilter/ip_conntrack_proto_tcp.c:333: error: (Each undeclared 
> identifier is reported only once
> net/ipv4/netfilter/ip_conntrack_proto_tcp.c:333: error: for each 
> function it appears in.)
> net/ipv4/netfilter/ip_conntrack_proto_tcp.c:333: warning: type defaults 
> to `int' in declaration of `type name'
> etc. etc..
> 
> Most likely it depends on the redefinition of DECLARE_RWLOCK in lockhelp.h

Same here...

> More problems....
> 
> Patch 7.50-48 has been the first rt kernel that compiled and booted 
> cleanly on my system.

-50-43 is the most recent out of the -50 series that's compiled and
operated cleanly on my Athlon box.  So far, it appears to be rock-solid.  
I'd recommend giving it a try if you haven't already.

> I'm testing the rt kernels because I want to use jack as my system sound 
> mixer/router
> and to record lp's with my ice1712-based sound card. I have no rt 
> requrements, of course,
> but I want to get rid of xruns. Kernel 2.6.12 vanilla is quite good 
> already (a big improvement
> over previous kernels) but still ...

Audio without xruns is an RT requirement, IMHO  ;-}

> Patch 7.50-48 been running for two days now and seems pretty stable but:
> 
> 1) My logs are filled with Apic errors all like this
> 
> Jul  5 04:30:01 linux kernel: APIC error on CPU0: 02(02)
> 
> every 2 seconds, or minute, at random. I've never seen these messages 
> before with vanilla kernels,
> so it's a bit weird.

Have you tried disabling CONFIG_X86_IOAPIC_FAST?  This is new in the
realtime-preempt patches.  It's currently stable on 3 out of the 4 boxes
I'm testing RT on.  On the fourth (P4 with an SIS chipset), it didn't seem
to make any difference.  I finally had to switch from APIC to PIC (in
BIOS) to get the APIC errors on CPU0 to go away.

> 2) Whenever I play an mp3 or watch a movie (through jack) I get 
> thousands of times these errors in the logs
> 
> Jul  5 20:45:56 linux kernel: `IRQ 8'[828] is being piggy. 
> need_resched=0, cpu=0
> Jul  5 20:45:56 linux kernel: Read missed before next interrupt
> Jul  5 20:45:56 linux kernel: wow!  That was a 12 millisec bump
> Jul  5 20:45:56 linux kernel: bug in rtc_read(): called in state S_IDLE!
> Jul  5 20:45:56 linux kernel: `IRQ 8'[828] is being piggy. 
> need_resched=0, cpu=0
> Jul  5 20:45:56 linux kernel: Read missed before next interrupt
> Jul  5 20:45:56 linux kernel: wow!  That was a 3 millisec bump
> Jul  5 20:45:56 linux kernel: bug in rtc_read(): called in state S_IDLE!
> 
> This is a known issue, RTC  interrupts are missed. I have noticed it 
> many times when ntp is
> running. It stops working after a few minutes of playing when the the 
> error exceeds 500 PPM.
> But I thought that ntp compared external reference clocks to the system 
> timer, so the system
> was missing int 0, not int 8.  My mobo has a crappy timer anyway. I had 
> to reduce the tick to 9934
> in order to allow ntp to run.

Is the RTC the only thing on IRQ 8?  The last time I saw the 'IRQ 8 is 
being piggy' messages on my Athlon box was when the RTC was sharing IRQ 8 
with either the video or the USB.

> 3) I had to disable polling of the cpu temperature by kacpid because 
> whenever it did the sound
> stopped for 1-3 seconds. The polling took longer and longer after a few 
> hours of uptime.
> The nice thing is, it caused no xruns. Kernel 2.6.12 vanilla has the 
> same problem, though.
> 
> 4) Xruns occur every 10-60 minutes even when the system is practically 
> idle (no playback
> or recording). When copying large files (between sata disks on two 
> sil3112 controllers)
> xruns frequency is much higher.  When sound is used xruns occur every 2 
> or 20 minutes.

Do these xruns coincide with the RTC 'Read missed before next interrupt'
messages?

Have you tried running JACK with a larger buffer period size?  Some cards
are perfectly happy with -p64, while others need -p128 or -p256 to be xrun
free for an extended time.  In the past, I've seen a difference between
running with 2 and 3 buffer periods (-n2 or -n3).

Also, have you tried bumping up JACK's RT priority?  If JACK is running at 
a lower priority than the IRQ threads for your SATA, then disk activity 
will most likely cause additional xruns.  I've had good luck running JACK 
with '-R -P60', which sets it's realtime priority above all the IRQ 
threads.

You may also want to run the IRQ threads for your audio hardware at a 
slightly higher RT priority than the rest of the IRQ threads.

> This is a nForce2-mobo (Abit NF7-S V 2.0), Athlon 2800, 1 GB Ram, 
> Terratec DMX6Fire,
> nVidia 4200 video card, 2 sil3112 sata controllers with 3 disks,etc. 
> SuSE 9.1 with KDE 3.4 and
> uptodate jack, xmms, mplayer, sound libraries and recording apps.
> 
> If more details are needed or I can perform some tests, feel free to ask.

If you haven't tried this out yet, jack_test4.1 should be a big help for 
system tuning:

http://www.joq.us/jack/tests/jack_test4.1.tar.gz

Edit jack_test4_run.sh to change settings for JACK priority, number of 
test clients, etc.  On your system, you should be able to run with 28 or 
more clients without any xruns.


Best Regards,
--ww