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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
