[lkml]   [2005]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: realtime-preempt-2.6.12-final-V0.7.51-01 compile error and more problems
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'

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

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:

Edit 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,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-07-06 03:18    [W:0.196 / U:0.172 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site