Re: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00
> > i have released the -V0.7.44-00 Real-Time Preemption patch, which can be > downloaded from the usual place: > >http://redhat.com/~mingo/realtime-preempt/ > I'm having plenty of this on boot, on my SMP/HT desktop (P4/x86), while running RT-V0.7.44-01 (SMP+PREEMPT_RT): BUG: kstopmachine: RT task yield()-ing! See sample dmesg and .config on attach. OTOH, on my laptop (P4/UP), all seems to be clear fine. Is this something to be affraid of? :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED]Linux version 2.6.12-rc2-RT-V0.7.44-01.0smp ([EMAIL PROTECTED]) (gcc version 3.3.4 (pre 3.3.5 20040809)) #1 SMP Tue Apr 5 19:21:11 WEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - 3ff3 (usable) BIOS-e820: 3ff3 - 3ff4 (ACPI data) BIOS-e820: 3ff4 - 3fff (ACPI NVS) BIOS-e820: 3fff - 4000 (reserved) BIOS-e820: ffb8 - 0001 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000ff780 On node 0 totalpages: 261936 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:16 HighMem zone: 32560 pages, LIFO batch:7 DMI 2.3 present. ACPI: RSDP (v002 ACPIAM) @ 0x000f9e60 ACPI: XSDT (v001 A M I OEMXSDT 0x08000320 MSFT 0x0097) @ 0x3ff30100 ACPI: FADT (v003 A M I OEMFACP 0x08000320 MSFT 0x0097) @ 0x3ff30290 ACPI: MADT (v001 A M I OEMAPIC 0x08000320 MSFT 0x0097) @ 0x3ff30390 ACPI: OEMB (v001 A M I OEMBIOS 0x08000320 MSFT 0x0097) @ 0x3ff40040 ACPI: DSDT (v001 P4P81 P4P81086 0x0086 INTL 0x02002026) @ 0x ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:2 APIC version 20 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:bfb8) Real-Time Preemption Support (c) Ingo Molnar Built 1 zonelists Kernel command line: root=/dev/hda2 mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 3360.970 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1035212k/1047744k available (1872k kernel code, 12144k reserved, 598k data, 176k init, 130240k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 6668.28 BogoMIPS (lpj=3334144) Security Framework v1.0.0 initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 4400 CPU: After vendor identify, caps: bfebfbff 4400 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebfbff 0080 4400 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09 Booting processor 1/1 eip 2000 Initializing CPU#1 Calibrating delay loop... 6717.44 BogoMIPS (lpj=3358720) CPU: After generic identify, caps: bfebfbff 4400 CPU: After vendor identify, caps: bfebfbff 4400 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebfbff 0080 4400 CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09 Total of 2 processors activated (13385.72 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=-1 checking TSC synchronization across 2 CPUs: passed. spawn_desched_task() desched cpu_callback 3/ ksoftirqd started up. softirq RT prio: 24. desched cpu_callback 2/ desched thread 0 started up. desched cpu_callback 3/0001 desched cpu_callback 2/0001 ksoftirqd started up. softirq RT prio: 24. Brought up 2 CPUs desched thread 1 started up. CPU0 attaching sched-domain: domain 0
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00
> Our first victim!! :-) > No kidding!? > On Tue, 2005-04-05 at 20:06 +0100, Rui Nuno Capela wrote: >> > >> I'm having plenty of this on boot, on my SMP/HT desktop (P4/x86), while >> running RT-V0.7.44-01 (SMP+PREEMPT_RT): >> >> BUG: kstopmachine: RT task yield()-ing! >> >> See sample dmesg and .config on attach. >> >> OTOH, on my laptop (P4/UP), all seems to be clear fine. >> > > The kstopmachine is only run on SMP environments, so it won't show up on > your UP machine. > > >> Is this something to be affraid of? :) >> > > If your box is still running, then no. But it's now a chore to remove > the yield from this algorithm, since yields have a possibility to > deadlock the system. Although in this particular case, it may not be a > problem, since the threads that are being waited on are created for > other CPUs. But I haven't looked too much into what stop_machine is > doing so I can very well be wrong. > > Thank you for reporting it, we want to weed out all the yields that a RT > task may call. > Now, I'm sure my fears were reasonable. With RT-V0.7.44-02 SMP a can't even reach an usable system state. This weird BUG: kstopmachine: RT task yield()-ing! is flooding the init process to death. Completely. Hard-reset is the only viable solution to a fast scrolling console dump, which seems to be in a terrible, nasty and endless loop. I'm not afraid anymore. RT-0.7.44-02 is useless on my P4 SMP/HT desktop machine. ;) Bye. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] config-2.6.12-rc2-RT-V0.7.44-02.0smp.gz Description: GNU Zip compressed data
Re: realtime-preempt-2.6.12-final-V0.7.51-11 glitches [no more]
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote: > >> OTOH, I'll take this chance to show you something that is annoying me >> for quite some time. Just look to the attached chart where I've marked >> the spot with an arrow and a question mark. Its just one example of a >> strange behavior/phenomenon while running the jack_test4.2 test on >> PREEMPT_RT kernels: the CPU usage, which stays normally around 50%, >> suddenly jumps to 60% steady, starting at random points in time but >> always some time after the test has been started. Note that this >> randomness surely adds to the the slight differences found on the >> above results. > > how long does this condition persist? Firstly, please upgrade to the > -51-16 kernel, previous kernels had a condition where interrupt storms > (or repeat interrupts) could occur. (Your irqs/sec values dont suggest > such a condition, but it could still occur.) > > Then could you enable profiling (CONFIG_PROFILING=y and profile=1 boot > parameter), and create a script like this to capture a kernel profile > for a fixed amount of time: > > #!/bin/bash > > readprofile -r # reset profile > sleep 10 > readprofile -n -m /home/mingo/System.map | sort -n > > and start it manually when the anomaly triggers. Also start it during a > 'normal' period of the test. The output should give us a rough idea of > what is happening. This type of profiling is very low-overhead so it > wont disturb the condition. > > Note that you can increase the frequency and the quality of profiling by > enabling the NMI watchdog (LOCAL_APIC in the .config and nmi_watchdog=2 > boot option), in the -RT kernel it will automatically switch the > profiling tick to occur from NMI context. Such tracing will also show > overhead occuring in irqs-off functions. > After several trials, with CONFIG_PROFILING=y and profile=1 nmi_watchdog=2 as boot parameters, I'm almost convinced I'm doing something wrong :) - `readprofile` always just outputs one line: 0 total 0. - `readprofile -a` gives the whole kernel symbol list, all with zero times. Is there anything else I can check around here? -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: realtime-preempt-2.6.12-final-V0.7.51-11 glitches [no more]
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote: > >> After several trials, with CONFIG_PROFILING=y and profile=1 >> nmi_watchdog=2 as boot parameters, I'm almost convinced I'm doing >> something wrong :) >> >> - `readprofile` always just outputs one line: >> >> 0 total0. >> >> - `readprofile -a` gives the whole kernel symbol list, all with zero >> times. >> >> Is there anything else I can check around here? > > it means that the NMI watchdog was not activated - i.e. the 'NMI' counts > in /proc/interrupts do not increase. Do you have LOCAL_APIC enabled in > the .config? If yes and if nmi_watchdog=1 does not work either then it's > probably not possible to activate the NMI watchdog on your box. In that > case try nmi_watchdog=0, that should activate normal profiling. (unless > i've broken it via the profile-via-NMI changes ...) > I've tried whether having nmi_watchdog has any influence, to no distinguishable result; readprofile always says zero times. And I'm sure I have LOCAL_APIC=y (see attached config.gz) -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: realtime-preempt-2.6.12-final-V0.7.51-11 glitches [no more]
> I've tried whether having nmi_watchdog has any influence, to no > distinguishable result; readprofile always says zero times. And > I'm sure I have LOCAL_APIC=y (see attached config.gz) Damn, forgot the attachement. Here it goes. Sorry. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] config-2.6.12-RT-V0.7.51-26.0.gz Description: GNU Zip compressed data
realtime-preempt-2.6.12-final-V0.7.51-11 glitches
Hi all, These are one of my latest consolidated results while using (my) jack_test4.2 suite, against a couple of 2.6.12 kernels patched for PREEMPT_RT, on my [EMAIL PROTECTED]/UP laptop. See anything funny? As it seems, the kernel latency performance is in some unfortunate regression, and I'm experiencing this unsatisfactory behavior ever since the latest RT-V0.7.50-xx patch series. -- - - RT-V0.7.51-11 RT-V0.7.49-01 -- - - Total seconds ran . . . . . . : 900 900 Number of clients . . . . . . : 1414 Ports per client . . . . . . :4 4 Frames per buffer . . . . . . : 6464 Number of runs . . . . . . . :1 1 -- - - Failure Rate . . . . . . . . : (0.0 )(0.0) /hour XRUN Rate . . . . . . . . . . : 373.3 0.0 /hour Delay Rate (>spare time) . . : 220.0 0.0 /hour Delay Rate (>1000 usecs) . . :0.0 0.0 /hour Delay Maximum . . . . . . . . : 7853 295 usecs Cycle Maximum . . . . . . . . : 852 943 usecs Average DSP Load. . . . . . . : 41.8 44.4 % Average CPU System Load . . . :6.8 16.3 % Average CPU User Load . . . . : 28.8 30.1 % Average CPU Nice Load . . . . :0.0 0.0 % Average CPU I/O Wait Load . . :0.0 0.1 % Average CPU IRQ Load . . . . :0.0 0.0 % Average CPU Soft-IRQ Load . . :0.0 0.0 % Average Interrupt Rate . . . : 1679.31680.4 /sec Average Context-Switch Rate . :12508.6 14463.2 /sec -- - - JFYI respective kernel configs are also attached. Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] jack_test4.2.tar.gz Description: application/gzip-compressed config-2.6.12-RT-V0.7.49-01.0.gz Description: Binary data config-2.6.12-RT-V0.7.51-11.0.gz Description: Binary data
realtime-preempt-2.6.12-final-V0.7.51-11 glitches [2]
> Hi all, > > These are one of my latest consolidated results while using (my) > jack_test4.2 suite, against a couple of 2.6.12 kernels patched for > PREEMPT_RT, on my [EMAIL PROTECTED]/UP laptop. > > See anything funny? > > As it seems, the kernel latency performance is in some unfortunate > regression, and I'm experiencing this unsatisfactory behavior ever since > the latest RT-V0.7.50-xx patch series. > > -- - - > RT-V0.7.51-11 RT-V0.7.49-01 > -- - - > Total seconds ran . . . . . . : 900 900 > Number of clients . . . . . . : 1414 > Ports per client . . . . . . :4 4 > Frames per buffer . . . . . . : 6464 > Number of runs . . . . . . . :1 1 > -- - - > Failure Rate . . . . . . . . : (0.0 )(0.0) /hour > XRUN Rate . . . . . . . . . . : 373.3 0.0 /hour > Delay Rate (>spare time) . . : 220.0 0.0 /hour > Delay Rate (>1000 usecs) . . :0.0 0.0 /hour > Delay Maximum . . . . . . . . : 7853 295 usecs > Cycle Maximum . . . . . . . . : 852 943 usecs > Average DSP Load. . . . . . . : 41.8 44.4 % > Average CPU System Load . . . :6.8 16.3 % > Average CPU User Load . . . . : 28.8 30.1 % > Average CPU Nice Load . . . . :0.0 0.0 % > Average CPU I/O Wait Load . . :0.0 0.1 % > Average CPU IRQ Load . . . . :0.0 0.0 % > Average CPU Soft-IRQ Load . . :0.0 0.0 % > Average Interrupt Rate . . . : 1679.31680.4 /sec > Average Context-Switch Rate . :12508.6 14463.2 /sec > -- - - > > JFYI respective kernel configs are also attached. > Sorry, my last post failed on packing those configs away. Here it goes again, hopefully. Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] config-2.6.12-RT-V0.7.49-01.0.gz Description: application/gzip-compressed config-2.6.12-RT-V0.7.51-11.0.gz Description: application/gzip-compressed
Re: realtime-preempt-2.6.12-final-V0.7.51-11 glitches
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote: > >> Hi all, >> >> These are one of my latest consolidated results while using (my) >> jack_test4.2 suite, against a couple of 2.6.12 kernels patched for >> PREEMPT_RT, on my [EMAIL PROTECTED]/UP laptop. >> >> See anything funny? > > hm, you dont seem to have PREEMPT_RT enabled in your .config - it's set > to PREEMPT_DESKTOP (config-2.6.12-RT-V0.7.51-11.0). OTOH, your 49-01 > config has PREEMPT_RT enabled. So it's not an apples to apples > comparison. Just to make sure, could you check 51-11 with PREEMPT_RT > enabled too? > Damn. You're right... grrr! I gotta spank myself later... I've been running PREEMPT_DESKTOP all along since V0.7.5x . Anyway, all that seems to show some pretty figures on the distinction between PREEMPT_DESKTOP and PREEMPT_RT performance :) > i have just done a jack_test4.1 run, and indeed larger latencies seem to > have crept in. (But i forgot to chrt the sound IRQ above the network > IRQ, so i'll retest.) > I will do my homework too ;) -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
realtime-preempt-2.6.12-final-V0.7.51-11 glitches [no more]
OK. Just for the heads up, here goes todays summary results regarding my jack_test4.2 test suite against 2.6.12 kernels configured with PREEMPT_RT, but... now with 99.9% certainty :) -- - - RT-V0.7.51-13 RT-V0.7.49-01 -- - - Total seconds ran . . . . . . : 900 900 Number of clients . . . . . . : 1414 Ports per client . . . . . . :4 4 Frames per buffer . . . . . . : 6464 Number of runs . . . . . . . :1 1 -- - - Failure Rate . . . . . . . . : (0.0 )(0.0) /hour XRUN Rate . . . . . . . . . . :0.0 0.0 /hour Delay Rate (>spare time) . . :0.0 0.0 /hour Delay Rate (>1000 usecs) . . :0.0 0.0 /hour Delay Maximum . . . . . . . . : 333 295 usecs Cycle Maximum . . . . . . . . : 970 943 usecs Average DSP Load. . . . . . . : 45.7 44.4 % Average CPU System Load . . . : 15.6 16.3 % Average CPU User Load . . . . : 32.0 30.1 % Average CPU Nice Load . . . . :0.0 0.0 % Average CPU I/O Wait Load . . :0.0 0.1 % Average CPU IRQ Load . . . . :0.0 0.0 % Average CPU Soft-IRQ Load . . :0.0 0.0 % Average Interrupt Rate . . . : 1678.61680.4 /sec Average Context-Switch Rate . :14446.4 14463.2 /sec -- - - Just for the forgiveness sake, my mistake was useful after all, where one can incidentally assert the significantly lower performance of PREEMPT_DESKTOP for audio work, when PREEMPT_RT is a clear winner. As it was already, for quite some time. No more worries ;) Thanks, -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: realtime-preempt-2.6.12-final-V0.7.51-11 glitches [no more]
>> -- - - >> RT-V0.7.51-13 RT-V0.7.49-01 >> -- - - > >> Delay Maximum . . . . . . . . : 333 295 usecs >> Cycle Maximum . . . . . . . . : 970 943 usecs >> Average DSP Load. . . . . . . : 45.7 44.4 % >> Average CPU System Load . . . : 15.6 16.3 % >> Average CPU User Load . . . . : 32.0 30.1 % > > i'm wondering - is this slight increase in CPU utilization (and > latencies) due to natural fluctuations, or is it a genuine overhead > increase? > I'm pretty confortable in saying that both results are almost equivalent, the slight differences probably due to environmental effects. All tests were conducted from a regular user konsole screen, under KDE 3.3 and perfectly functional X.org desktop session. Runlevel 5 with network down however. Oh, gkrellm is also on screen :) OTOH, I'll take this chance to show you something that is annoying me for quite some time. Just look to the attached chart where I've marked the spot with an arrow and a question mark. Its just one example of a strange behavior/phenomenon while running the jack_test4.2 test on PREEMPT_RT kernels: the CPU usage, which stays normally around 50%, suddenly jumps to 60% steady, starting at random points in time but always some time after the test has been started. Note that this randomness surely adds to the the slight differences found on the above results. First suspicions gone to cpu frequency/throttling, but I have it disabled on every kernel I build. Denormals? Don't think so, as jack_test_client is specially coded to treat floats as zero if below 1E-6. Any hints? -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] jack_test4-2.6.12-RT-V0.7.51-13.0-200507080917.png Description: PNG image
Re: realtime-preempt-2.6.12-final-V0.7.51-11 glitches [no more]
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote: > >> OTOH, I'll take this chance to show you something that is annoying me >> for quite some time. Just look to the attached chart where I've marked >> the spot with an arrow and a question mark. Its just one example of a >> strange behavior/phenomenon while running the jack_test4.2 test on >> PREEMPT_RT kernels: the CPU usage, which stays normally around 50%, >> suddenly jumps to 60% steady, starting at random points in time but >> always some time after the test has been started. Note that this >> randomness surely adds to the the slight differences found on the >> above results. > > how long does this condition persist? On all of my extensive tests, it persists on all of the remaining jack_test4 time span, doesn't matter how long it is. I'll look later into your profiling and tracing instructions. Many thanks for the directions. Seeya. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: [patch] drivers/ide/pci/alim15x3.c SMP fix
Ingo Molnar wrote: is this the right way to fix the UP assumption below? Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Index: linux/drivers/ide/pci/alim15x3.c > [snip] OK. The reported boot WARNING seems to be over now. Tested on the offended laptop ([EMAIL PROTECTED]/UP, PCI chipset: ALi M1533) with 2.6.13-rt3, where the suggested patch on drivers/ide/pci/alim15x3.c seems to fix the burp. All seems to be working fine, still ;) Thanks. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: [patch] drivers/ide/pci/alim15x3.c SMP fix
Ingo Molnar wrote: Rui Nuno Capela wrote: OK. The reported boot WARNING seems to be over now. Tested on the offended laptop ([EMAIL PROTECTED]/UP, PCI chipset: ALi M1533) with 2.6.13-rt3, where the suggested patch on drivers/ide/pci/alim15x3.c seems to fix the burp. All seems to be working fine, still ;) just to make sure the original point gets across: the warning is only in the -rt tree, and it pinpoints potential SMP bugs. Does your box do hyperthreading? Nope. The [EMAIL PROTECTED] is from pre-HT age, and the kernel is being built for UP. Bye now. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
2.6.11-rc4-RT-V0.7.39-02 kernel BUG
Hi,
I'm back :) just shortly, to report an annoying kernel crash that
sometimes I'm experiencing at boot time on my laptop ([EMAIL PROTECTED]/UP),
running 2.6.11-rc4-RT-V0.7.39-02 (PREEMPT_RT=y, config attached).
This BUG is happening in some probabilistic fashion, like 1 on each 3
boots, rendering the whole USB subsystem completely unusable as the most
notable consequence.
Taken from dmesg (integral output is attached):
BUG: Unable to handle kernel paging request at virtual address 0811eb68
printing eip:
c0127927
*pde = 1e41d067
*pte =
Oops: [#1]
PREEMPT
Modules linked in: natsemi crc32 ohci1394 ieee1394 loop subfs evdev
ohci_hcd usbcore video thermal processor fan button battery ac
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010082 (2.6.11-rc4-RT-V0.7.39-02.0)
EIP is at change_owner+0x1a/0x5a
eax: de65c550 ebx: de65c550 ecx: 0811eb68 edx: df180550
esi: df0c3cc8 edi: df180a48 ebp: df0c3cc8 esp: de59ded0
ds: 007b es: 007b ss: 0068 preempt: 0004
Process IRQ 10 (pid: 1439, threadinfo=de59c000 task=df406000)
Stack: de65c550 df0c3cc8 df03ff70 df180550 c0127b5c de65c550 df0c3cc8
c0127d31
df03ff70 0286 de59c000 de558000 0001
0001
c01283f5 e00d4400 e00c2cb0 0001 de55a4d4 e00b0bf6 0001
0017
Call Trace:
[] set_new_owner+0x17/0x2b (20)
[] __up_mutex+0xa4/0x193 (12)
[] up+0x35/0x3d (36)
[] highlevel_host_reset+0x3b/0x49 [ieee1394] (8)
[] ohci_irq_handler+0x576/0x713 [ohci1394] (12)
[] __sched_text_start+0x5a/0x5d7 (28)
[] __do_IRQ+0xca/0x180 (4)
[] handle_IRQ_event+0x5c/0xc8 (36)
[] do_hardirq+0x61/0x112 (48)
[] do_sched_setscheduler+0x73/0xa0 (4)
[] do_irqd+0x0/0x96 (20)
[] do_irqd+0x66/0x96 (4)
[] kthread+0x94/0xc8 (28)
[] kthread+0x0/0xc8 (16)
[] kernel_thread_helper+0x5/0xb (16)
Code: 8b 6c 24 18 83 c4 1c c3 b8 da ff ff ff c3 90 90 c3 55 39 ca 89 c5 57
89 c8 56 53 74 49 8b 8a f8 04 00 00 8d ba f8 04 00 00 39 cf <8b> 19 74 37
8d b0 f8 04 00 00 eb 08 89 d9 8b 1b 39 cf 74 27 39
<6>note: IRQ 10[1439] exited with preempt_count 3
BUG: scheduling while atomic: IRQ 10/0x0003/1439
caller is do_exit+0x1da/0x34d
[] __sched_text_start+0x48e/0x5d7 (8)
[] exit_notify+0x60b/0x8f4 (24)
[] vprintk+0x101/0x142 (24)
[] do_exit+0x1da/0x34d (32)
[] do_trap+0x0/0xfe (40)
[] do_page_fault+0x0/0x524 (48)
[] do_page_fault+0x0/0x524 (12)
[] do_page_fault+0x346/0x524 (4)
[] preempt_schedule+0x50/0x6b (80)
[] try_to_wake_up+0x104/0x106 (20)
[] dma_trm_reset+0x36/0x11e [ohci1394] (24)
[] __wake_up_common+0x35/0x55 (16)
[] do_page_fault+0x0/0x524 (60)
[] error_code+0x2b/0x30 (8)
[] change_owner+0x1a/0x5a (44)
[] set_new_owner+0x17/0x2b (28)
[] __up_mutex+0xa4/0x193 (12)
[] up+0x35/0x3d (36)
[] highlevel_host_reset+0x3b/0x49 [ieee1394] (8)
[] ohci_irq_handler+0x576/0x713 [ohci1394] (12)
[] __sched_text_start+0x5a/0x5d7 (28)
[] __do_IRQ+0xca/0x180 (4)
[] handle_IRQ_event+0x5c/0xc8 (36)
[] do_hardirq+0x61/0x112 (48)
[] do_sched_setscheduler+0x73/0xa0 (4)
[] do_irqd+0x0/0x96 (20)
[] do_irqd+0x66/0x96 (4)
[] kthread+0x94/0xc8 (28)
[] kthread+0x0/0xc8 (16)
[] kernel_thread_helper+0x5/0xb (16)
prev->state: 2 != TASK_RUNNING??
IRQ 10/1439: BUG in __schedule at kernel/sched.c:3028
[] __sched_text_start+0x3fd/0x5d7 (8)
[] do_exit+0x1da/0x34d (80)
[] do_trap+0x0/0xfe (40)
[] do_page_fault+0x0/0x524 (48)
[] do_page_fault+0x0/0x524 (12)
[] do_page_fault+0x346/0x524 (4)
[] preempt_schedule+0x50/0x6b (80)
[] try_to_wake_up+0x104/0x106 (20)
[] dma_trm_reset+0x36/0x11e [ohci1394] (24)
[] __wake_up_common+0x35/0x55 (16)
[] do_page_fault+0x0/0x524 (60)
[] error_code+0x2b/0x30 (8)
[] change_owner+0x1a/0x5a (44)
[] set_new_owner+0x17/0x2b (28)
[] __up_mutex+0xa4/0x193 (12)
[] up+0x35/0x3d (36)
[] highlevel_host_reset+0x3b/0x49 [ieee1394] (8)
[] ohci_irq_handler+0x576/0x713 [ohci1394] (12)
[] __sched_text_start+0x5a/0x5d7 (28)
[] __do_IRQ+0xca/0x180 (4)
[] handle_IRQ_event+0x5c/0xc8 (36)
[] do_hardirq+0x61/0x112 (48)
[] do_sched_setscheduler+0x73/0xa0 (4)
[] do_irqd+0x0/0x96 (20)
[] do_irqd+0x66/0x96 (4)
[] kthread+0x94/0xc8 (28)
[] kthread+0x0/0xc8 (16)
[] kernel_thread_helper+0x5/0xb (16)
Please, feel free to ask me for anything else, if relevant to get rid of
this casual crash behavior. I'm already running the RT patch/kernel 100%
of the time, on all my boxes, althought I have no record of this happening
on my other [EMAIL PROTECTED]/HT(SMP) box.
Cheers.
--
rncbc aka Rui Nuno Capela
[EMAIL PROTECTED]
Linux version 2.6.11-rc4-RT-V0.7.39-02.0 ([EMAIL PROTECTED]) (gcc version 3.4.1
(Mandrakelinux 10.1 3.4.1-4mdk)) #1 Tue Feb 15 09:37:36 WET 2005
BIOS-provided physical RAM map:
BIOS-e820: - 0009f800 (usable)
BIOS-e820: 0009f800 - 000a (reserved)
BIOS-e820: 000dc000 - 0010 (reserved)
BIOS-e820: 0010 - 1f77 (usable)
BIOS-e820: 1f77 - 1
Re: 2.6.11-rc4-RT-V0.7.39-02 kernel BUG
Matthias-Christian wrote: > > Hi! > The first bug is in the usbb ohci module (report it to > http://buzilla.kernel.org and its Maintainers). The second one is caused > by the first one. > Done. Bugzilla bug #4247: http://bugzilla.kernel.org/show_bug.cgi?id=4247 Bye. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.11-rc4-RT-V0.7.39-02 kernel BUG
> Matthias-Christian wrote: >> >> Hi! >> The first bug is in the usbb ohci module (report it to >> http://buzilla.kernel.org and its Maintainers). The second one is >> caused by the first one. >> > > Done. > > Bugzilla bug #4247: > http://bugzilla.kernel.org/show_bug.cgi?id=4247 > And this was the response: [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |REJECTED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-24 11:11 --- As you are using Ingo's patches, please post this to him, in an email, not on here. Now what? -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.11-rc4-RT-V0.7.39-02 kernel BUG
> Matthias-Christian wrote: >> >> Hi! >> The first bug is in the usbb ohci module (report it to >> http://buzilla.kernel.org and its Maintainers). The second one is >> caused by the first one. >> > > Done. > > Bugzilla bug #4247: > http://bugzilla.kernel.org/show_bug.cgi?id=4247 > And this was the response: [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |REJECTED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-24 11:11 --- As you are using Ingo's patches, please post this to him, in an email, not on here. Now what? -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
> > i have released the -V0.7.43-00 Real-Time Preemption patch, which can be > downloaded from the usual place: > RT-V0.7.43-00 is failing to build here: . . . CC kernel/rcupdate.o CC kernel/intermodule.o kernel/intermodule.c:179: warning: `inter_module_register' is deprecated (declar ed at kernel/intermodule.c:38) kernel/intermodule.c:180: warning: `inter_module_unregister' is deprecated (decl ared at kernel/intermodule.c:79) kernel/intermodule.c:182: warning: `inter_module_put' is deprecated (declared at kernel/intermodule.c:160) CC kernel/extable.o CC kernel/params.o CC kernel/posix-timers.o CC kernel/kthread.o CC kernel/wait.o CC kernel/kfifo.o CC kernel/sys_ni.o CC kernel/posix-cpu-timers.o CC kernel/rt.o kernel/rt.c:1435: error: `up_read' undeclared here (not in a function) kernel/rt.c:1435: error: initializer element is not constant kernel/rt.c:1435: error: (near initialization for `__ksymtab_up_read.value') kernel/rt.c:1435: error: __ksymtab_up_read causes a section type conflict make[1]: *** [kernel/rt.o] Error 1 make: *** [kernel] Error 2 Bye. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
> > thx - i've uploaded -43-01 which should fix this. > Now it's dying-on-the-beach: . . . if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.12-rc1-RT-V0.7.43-01.0; fi WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/usb/storage/usb-storage.ko needs unknown symbol __compat_down_failed_interruptible WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/usb/storage/usb-storage.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/parport/parport.ko needs unknown symbol __compat_down_failed_interruptible WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/parport/parport.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/net/ppp_async.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/net/ppp_async.ko needs unknown symbol __compat_down_failed WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_down_failed_trylock WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_down_failed_interruptible WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_down_failed make: *** [_modinst_post] Error 1 Bye. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
> * Rui Nuno Capela wrote: > >> > thx - i've uploaded -43-01 which should fix this. >> > >> >> Now it's dying-on-the-beach: > >> needs unknown symbol __compat_down_failed_interruptible > > ok - does -43-02 work any better? > Nope. Same error output as last report. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
> >> >> needs unknown symbol __compat_down_failed_interruptible >> >> Nope. Same error output as last report. > > does -43-04 work for you? > RT-V0.7.43-05 is now working for me. No quirks so far, on the UP laptop. Building now for the SMP/HT desktop. Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
>> Jack O'Quin wrote: >>> Outstanding. How do you get rid of that checkerboard grey >>> background in the graphs? >> >>> Con Kolivas <[EMAIL PROTECTED]> writes: >> Funny; that's the script you sent me so... beats me? > > It's just one of the many things I don't understand about graphics. > > If I look at those png's locally (with gimp or gqview) they have a > dark grey checkerboard background. If I look at them on the web (with > galeon), the background is white. Go figure. Maybe the file has no > background? I dunno. > The PNGs are being generated with transparent background. The checkered background is just being added as a visual helper artifact (or sort of) on some graphics viewers (notably the ones which names start with "g" :). It's in jack_test3_plot.sh where the explicit option to render it transparent is. Just look for "transparent" and get rid of it, if you like :) BTW, as joq has already hinted, I have almost ready here a new test suite (jack_test4), which features an actual (i.e.audible) audio chain instead of just CPU eaters, as on the jack_test3 set. Right now I'm merging the corrections joq handed to me yesterday, and will post it here later toiday. Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
OK. Here goes my fresh and newly jack_test4.1 test suite. It might be still rough, as usual ;) (Jack: this post is an new edited version of the same I sent you last weekend; sorry for the noise:) The main difference against jack_test3.2 goes into the specific test client (jack_test4_client.c). That is, the client chain now tries to resemble a real audio chain. The first client runs as a signal generator, pumping ou a pure sinusoidal 1Khz tone into all its ouput ports. The second and all following clients connect their input ports to the outputs of the preceding one. Each one of these clients work exactly as before, mixing all input into each output. Finally the last client of the chain, connects its output ports to the available terminal/physical inputs (e.g. alsa_pcm). This way the tone signal feeding can actually be heard on your speakers--but please take care of the effective output volume for not to hurt your precious ears :) The tone signal is specially in phase-sync along all client nodes, provided a sync pulse is propagated along the chain, but suppressed on that last node (the one which feeds the speakers). Each client, other than the first generator one, compares every single input frame against a self-generated one, checking for any extraneous noise/artifact. This difference is detected and exposed as a "Delta Maximum" value on the summary results--it should be always 0.0, if not something really bad has occurred during the test. A fifth argument to the jack_test4_run.sh main script is also featured, giving the number of consecutive runs the whole test-chain-cycle is performed for the same jackd service session. The sixth argument is now the number of extra playback ports to be acquainted by jackd. Now the bad news . This new test-suite exposes a very nasty jackd behavior, which was rarely seen with the previous jack_test3.2 but now is pretty reproducible, at least on my laptop ([EMAIL PROTECTED]/UP) under Ingo's 2.6.11-rc1-RT-V0.7.35-01 (PREEMPT_RT). This phenomenon, so to speak, shows up as a sudden full increase of DSP/CPU load after a few minutes running jackd while perfectly normal and stable until that moment. Once that occurs, and it does now everytime I run jack_test4_run.sh with default parameters (14 clients, 4x4 ports), you end under a horrible XRUN storm--see attached chart--you can even hear it perfectly as the 1KHz audible tone burps and stutters, resembling radioactivity morse pulses. So it seems that this showstopper is an issue only under extreme loads, and is probably relative to the hardware you're running into. On my other [EMAIL PROTECTED]/HT desktop I could not reproduce this. Instead, I hit a rather older issue, which comes like the magic 14 client limit. As it seems, I now find trouble when starting more than 14 connected clients, as the jack_watchdog kills everything in sight beyhond that point. This wasn't happening with the jack_test3.2 suite, suspectedly because those clients weren't being connected to each other. Please check this out, and would you try at least to reproduce the naughty behavior such as the pictured on the attached chart? Now back on-topic :) Just some last lines about the iso2 patch. I know some of you will laught at me, but I've just gave it a try on merging it with Ingo's realtime-preempt. After some changes to Con's original (2.6.11-rc1-iso2.diff) I've reached a clean build, and the attached patch is the proof, which applies in the following sequence: linux-2.6.11-rc1.tar.bz2 + realtime-preempt-2.6.11-rc1-V0.7.35-01 + linux-2.6.11-rc1-RT-V0.7.35-iso2.patch.gz But... even though it booted fine, the resulting kernel just crashes immediately as soon as one remembers to run jackd -R :( If just someone finds this interesting... ;) So no joy no fun, eheheh. Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] jack_test4.1.tar.gz Description: application/gzip-compressed <> linux-2.6.11-rc1-RT-V0.7.35-iso2.patch.gz Description: application/gzip-compressed
Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
Jack O'Quin wrote: > > [...] Looking at the graph, it appears that your DSP load is hovering > above 70% most of the time. This happens to be the default threshold > for revoking realtime privileges. Perhaps that is the problem. Try > running it with the threshold set to 90%. (I don't recall exactly > how, but I think there's a /proc/sys/kernel control somewhere.) > It would be nice to know which one really is :) Here are what I have here: # grep . /proc/sys/kernel /proc/sys/kernel/bootloader_type:2 /proc/sys/kernel/cad_pid:1 /proc/sys/kernel/cap-bound:-257 /proc/sys/kernel/core_pattern:core /proc/sys/kernel/core_uses_pid:1 /proc/sys/kernel/ctrl-alt-del:0 /proc/sys/kernel/debug_direct_keyboard:0 /proc/sys/kernel/domainname:(none) /proc/sys/kernel/hostname:lambda /proc/sys/kernel/hotplug:/sbin/hotplug /proc/sys/kernel/kernel_preemption:1 /proc/sys/kernel/modprobe:/sbin/modprobe /proc/sys/kernel/msgmax:8192 /proc/sys/kernel/msgmnb:16384 /proc/sys/kernel/msgmni:16 /proc/sys/kernel/ngroups_max:65536 /proc/sys/kernel/osrelease:2.6.11-rc1-RT-V0.7.35-01.0 /proc/sys/kernel/ostype:Linux /proc/sys/kernel/overflowgid:65534 /proc/sys/kernel/overflowuid:65534 /proc/sys/kernel/panic:0 /proc/sys/kernel/panic_on_oops:0 /proc/sys/kernel/pid_max:32768 /proc/sys/kernel/printk:3 4 1 7 /proc/sys/kernel/printk_ratelimit:5 /proc/sys/kernel/printk_ratelimit_burst:10 /proc/sys/kernel/prof_pid:-1 /proc/sys/kernel/sem:25032000 32 128 /proc/sys/kernel/shmall:2097152 /proc/sys/kernel/shmmax:33554432 /proc/sys/kernel/shmmni:4096 /proc/sys/kernel/sysrq:1 /proc/sys/kernel/tainted:0 /proc/sys/kernel/threads-max:8055 /proc/sys/kernel/unknown_nmi_panic:0 /proc/sys/kernel/version:#1 Mon Jan 17 15:15:21 WET 2005 My eyes can't find anything related, but you know how intuitive these things are ;) > > [...] The old problem with more than 14 clients has been > fixed. I routinely run 30 or 40 without trouble. > Yes, but that is with (old) jack_test3 where clients were stand-alone, without being connected to anyother. With (new) jack_test4, each client gets all its inputs connected to all the output ports of the preceding one. In my experience, with this (new) setup you achieve a much greater workload with a lesser number of running clients. If seems funny, but highly suspicious, that in both of my machines, a [EMAIL PROTECTED]/UP laptop and a [EMAIL PROTECTED]/SMP desktop, the limit is somewhat the same: jackd stops responding as soon the 15th client enters the chain. Currently on jackd 0.99.47 (cvs), but I'm quite sure that was occurring before. > Perhaps we're running out of some port resource? > Probably. That was what I thought and then worked around by increasing the maximum number of ports jackd preallocates (-p/--port-max option), but I guess it is not enough. It was on jack_test3, but it isn't for jack_test4. Go figure ;) Bye now. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
Jack O'Quin wrote:
>
> If you grep your log file for 'client failure:', you'll probably find
> that JACK has reacted to the deteriorating situation by shutting down
> some of its clients. The number of 'client failure:' messages is
> *not* the number of clients shut down, there is some repetition (not
> sure why). This will give the actual number...
>
> $ grep '^client failure:' ${LOGFILE} | cut -f4 -d' ' | sort -u | wc -l
>
> It would help if the test script reported this value.
>
I will include it on the next jack_test4.2 :)
If you remember of anything else, please ask.
Cheers.
--
rncbc aka Rui Nuno Capela
[EMAIL PROTECTED]
P.S. I'm under a terrible cold|flu right now #( that's why I didn't had
the time or patience to test all these new kernel iso/rt_cpu_limit
goodies. So sorry.
-
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/
Re: 2.6.23-rt4 (was 2.6.23-rt1 trouble)
> On Mon, October 15, 2007 11:49, Rui Nuno Capela wrote: >> >> I am experiencing some highly annoying but intermitent freezing on a >> pentium4 2.80G HT/SMT box, when doing normal desktop work with 2.6.23-rt1. >> >> >> The same crippling behavior does not occur on a Core 2 Due T7200 2.0G >> SMP, so I suspect it's something due specific to the SMT scheduling >> support (Hyper-Threading). But can't tell for sure, obviously :) >> > > I was wrong. After several trials the same behavior also occurs on the > Core2 Duo T7200. It just took longer to show its nasty. > > >> The symptoms are noticeable primarily as some X/GUI intermitent freezing, >> sometimes only one application, then several and ultimately the whole X >> desktop becomes completely unresponsive. It looks like scheduling >> problems. There is this hint that switching to a spare console terminal >> (via Ctrl+Alt+Fn) might cause later recovery. But its just a question of >> some more time for it just happens again and again, one after another, >> several applications becoming temporarily frozen and just by luck the >> system gets back to normal, probably due to some incidental shake-up :) >> but there are other times that nothing seems to help with no alternative >> to the power-reset switch. >> >> I could not find any evidence on dmesg or in the system logs, of any >> apparent trouble. No BUGs, no oops, no panics, no nothing. It just >> freezes, this and that, now and then. It just makes it all unworkable >> and obviously subject to ditching. >> >> Again, this only happens on this P4/HT box. On a Core2 Duo laptop, with >> same 2.6.23-rt1 with the very same kernel configuration, it does not show >> any illness and is running quite fine. >> > > False. It used to run fine, until the creeps happen first time :( > > >> Remember one report I had about a similar freezing behavior? Now it's >> happening the other way around: the core2 is OK, the pentium4 is KO. >> > > Now it applies to all 2.6.23-rt1 images I could test upon. > > >> One naive suspicion goes like the new rcu-preempt code is to blame, since >> I don't remember having this or any other trouble with 2.6.23-rc8-rt1. >> > > Not be sure anymore, but this seems to be still a valid assumption. > just to let you know that still the same trouble persists with 2.6.23.1-rt4 .config can be found here: http://www.rncbc.org/datahub/config-2.6.23.1-rt4.0 cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.23-rt4 (was 2.6.23-rt1 trouble)
Steven Rostedt wrote: > -- > > On Sat, 27 Oct 2007, Rui Nuno Capela wrote: > >>> On Mon, October 15, 2007 11:49, Rui Nuno Capela wrote: >>>> I am experiencing some highly annoying but intermitent freezing on a >>>> pentium4 2.80G HT/SMT box, when doing normal desktop work with 2.6.23-rt1. >>>> >>>> >>>> The same crippling behavior does not occur on a Core 2 Due T7200 2.0G >>>> SMP, so I suspect it's something due specific to the SMT scheduling >>>> support (Hyper-Threading). But can't tell for sure, obviously :) >>>> >>> I was wrong. After several trials the same behavior also occurs on the >>> Core2 Duo T7200. It just took longer to show its nasty. >>> >>> >>>> The symptoms are noticeable primarily as some X/GUI intermitent freezing, >>>> sometimes only one application, then several and ultimately the whole X >>>> desktop becomes completely unresponsive. It looks like scheduling > > When things start to freeze, could you capture the output of a sysrq-t. > yes, you can find a complete serial console capture here, where it holds the final SysRq-T output: http://www.rncbc.org/datahub/console-2.6.23.1-rt4.1-1.log the corresponding .config is also there: http://www.rncbc.org/datahub/config-2.6.23.1-rt4.1 the reason this is a new kernel build, following a shot in the dark from nick mainsbridge, which let out the ntfs module build (CONFIG_NTFS_FS is not set) suggesting that would mitigate similar freezes. in deed the general feel is that it seems to run longer and less prone to those incidents, but that is just a gut feeling, nothing more. hope this be any useful. > >>>> problems. There is this hint that switching to a spare console terminal >>>> (via Ctrl+Alt+Fn) might cause later recovery. But its just a question of >>>> some more time for it just happens again and again, one after another, >>>> several applications becoming temporarily frozen and just by luck the >>>> system gets back to normal, probably due to some incidental shake-up :) >>>> but there are other times that nothing seems to help with no alternative >>>> to the power-reset switch. >>>> >>>> I could not find any evidence on dmesg or in the system logs, of any >>>> apparent trouble. No BUGs, no oops, no panics, no nothing. It just >>>> freezes, this and that, now and then. It just makes it all unworkable >>>> and obviously subject to ditching. >>>> >>>> Again, this only happens on this P4/HT box. On a Core2 Duo laptop, with >>>> same 2.6.23-rt1 with the very same kernel configuration, it does not show >>>> any illness and is running quite fine. >>>> >>> False. It used to run fine, until the creeps happen first time :( >>> >>> >>>> Remember one report I had about a similar freezing behavior? Now it's >>>> happening the other way around: the core2 is OK, the pentium4 is KO. >>>> >>> Now it applies to all 2.6.23-rt1 images I could test upon. >>> >>> >>>> One naive suspicion goes like the new rcu-preempt code is to blame, since >>>> I don't remember having this or any other trouble with 2.6.23-rc8-rt1. >>>> >>> Not be sure anymore, but this seems to be still a valid assumption. >>> >> just to let you know that still the same trouble persists with 2.6.23.1-rt4 >> >> .config can be found here: >>http://www.rncbc.org/datahub/config-2.6.23.1-rt4.0 >> > > I have a P4HT laptop (unfortunately with no serial). I use it as one of my > main machines, so it will suck for me when it freezes ;-). I'll take your > config and try it out. > > I'll most likely do this on Monday since process Wife has the highest > priority over the weekend ;-) > that is also true here :) otoh, as reported before, the freezes are not exclusive to P4HT, which is the main box I'm been reporting here (the one which has a good old serial port anyway), but also applies to my other laptop, an core2 duo t7200. bye -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.23.1-rt5 (was 2.6.23-rt1 trouble)
Rui Nuno Capela wrote: > Steven Rostedt wrote: >> >> When things start to freeze, could you capture the output of a sysrq-t. >> > > yes, you can find a complete serial console capture here, where it holds > the final SysRq-T output: > http://www.rncbc.org/datahub/console-2.6.23.1-rt4.1-1.log > > the corresponding .config is also there: > http://www.rncbc.org/datahub/config-2.6.23.1-rt4.1 > > the reason this is a new kernel build, following a shot in the dark from > nick mainsbridge, which let out the ntfs module build (CONFIG_NTFS_FS is > not set) suggesting that would mitigate similar freezes. > > in deed the general feel is that it seems to run longer and less prone > to those incidents, but that is just a gut feeling, nothing more. > > hope this be any useful. > >> I have a P4HT laptop (unfortunately with no serial). I use it as one of my >> main machines, so it will suck for me when it freezes ;-). I'll take your >> config and try it out. >> >> I'll most likely do this on Monday since process Wife has the highest >> priority over the weekend ;-) >> > > that is also true here :) > > otoh, as reported before, the freezes are not exclusive to P4HT, which > is the main box I'm been reporting here (the one which has a good old > serial port anyway), but also applies to my other laptop, an core2 duo > t7200. > still in trouble with 2.6.23.1-rt5 :( .config: http://www.rncbc.org/datahub/config-2.6.23.1-rt5.0 serial console capture: http://www.rncbc.org/datahub/console-2.6.23.1-rt5.0-1.log one thing about SysRq-T: while in the middle of a freeze it just doesn't dump anything, just the 'SysRq : Show State' line. you can see that several times on the console output above. only when it is somewhat recovering, as said, by making some last resort measures like SysRq-E as in 'SysRq: terminate All Tasks' for instance, then SysRq-T will dump something. my guess is that this later dump will be moot :/ back to production with 2.6.22.1-rt9 ;) -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.23.1-rt5 (was 2.6.23-rt1 trouble)
Steven Rostedt wrote: > -- > On Tue, 30 Oct 2007, Rui Nuno Capela wrote: > >> still in trouble with 2.6.23.1-rt5 :( >> >> .config: >> http://www.rncbc.org/datahub/config-2.6.23.1-rt5.0 >> >> serial console capture: >> http://www.rncbc.org/datahub/console-2.6.23.1-rt5.0-1.log > > "NVRM: loading NVIDIA UNIX x86 Kernel Module 100.14.19 Wed Sep 12 > 14:12:24 PDT 2007" > > Is that the nVidia module? Showing a date of Sept 12th also makes this > look suspicious. > > If this is the case, could you run without that module to see if we get > the same freezes. > yes, running without the *cough* nvidia module is under way. but do you remember that on my other laptop the freezes also happen and on that one there's no single proprietary modules in it? (same .config btw) problem is, like most modern laptops, it doesn't come bundled with a serial port so that can't give you a serial console evidence ... thanks for the reminder, anyway ;) > Thanks, > > -- Steve > >> one thing about SysRq-T: while in the middle of a freeze it just doesn't >> dump anything, just the 'SysRq : Show State' line. you can see that >> several times on the console output above. >> >> only when it is somewhat recovering, as said, by making some last resort >> measures like SysRq-E as in 'SysRq: terminate All Tasks' for instance, >> then SysRq-T will dump something. my guess is that this later dump will >> be moot :/ >> >> back to production with 2.6.22.1-rt9 ;) bye now -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.23.1-rt5 (was 2.6.23-rt1 trouble)
Steven Rostedt wrote: > -- >> yes, running without the *cough* nvidia module is under way. but do you >> remember that on my other laptop the freezes also happen and on that one >> there's no single proprietary modules in it? (same .config btw) problem >> is, like most modern laptops, it doesn't come bundled with a serial port >> so that can't give you a serial console evidence ... >> >> thanks for the reminder, anyway ;) >> > > hmm, it could also be a separate issue. This other laptop is the one that > took a while to freeze. Correct? > yes, it seems that was the case, but not sure if still applies. the moment of the freezes are rather random, sometimes in the (tainted) desktop one it takes a while too before it starts to hiccup. > Was it only on X apps? Or could it possible be something we could do via a > command line and then we could see vga output (if any). > most of the time, yes, it's on X applications. if I get into a tty (eg. via Alt-Ctrl-F1) it seems to eventually recover from the intermitent frozen state easier, but its just a matter of time to have it also dead on the console, sooner or later. once it starts freezing the first time I know the whole system is, how should i say? doomed ... never saw a bug, oops or panik message. it just drops dead, until SysRq-B gets hit in despair :) cheers -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
2.6.22.1-rt4 lockups
Hi, As with -rt3, I was able to capture one more crash trace, via serial console, with nmi_watchdog=1. Yes, current 2.6.22.1-rt4 is still locking-up on my ix86 SMT/SMP boxes. I'll have to wait for some hours of uptime and normal desktop use and then it just locks-up without warning. Last couple of occurrences were all while browsing with firefox (2.0.0.5) or using openoffice.org (2.0.4) but in rare and non-deterministic fashion I must say. It looks very similar to the previous ones I've reported before for -rt3, but I am no expert in these things. ... Oops: [#1] PREEMPT SMP Modules linked in: tun appletalk ax25 ipx p8023 snd_rtctimer snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_seq_midi snd_seq_midi_event snd_seq w83627hf hwmon_vid hwmon eeprom button battery ac loop dm_mod wacom usbhid hid ff_memless ohci1394 ieee1394 nvidia(P) snd_cs46xx gameport firewire_ohci snd_ice1712 snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_cs8427 snd_i2c snd_mpu401_uart snd_rawmidi snd_seq_device firewire_core sk98lin snd_intel8x0 crc_itu_t snd_ac97_codec ac97_bus ide_cd snd_pcm cdrom snd_timer uhci_hcd ehci_hcd i2c_i801 snd rtc_cmos shpchp iTCO_wdt i2c_core usbcore rtc_core pci_hotplug soundcore intel_agp rtc_lib agpgart snd_page_alloc ext3 mbcache jbd edd fan piix thermal processor ide_disk ide_core CPU:0 EIP:0060:[<>]Tainted: P VLI EFLAGS: 00213006 (2.6.22.1-rt4.0 #1) EIP is at _stext+0x3feff000/0x20 eax: c1812a80 ebx: c03bb540 ecx: 0001 edx: c038e3c0 esi: c038e3c0 edi: 0001 ebp: f6fe1d6c esp: f6fe1d50 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 preempt:0003 Process Xorg (pid: 4101, ti=f6fe1000 task=f754ec30 task.ti=f6fe1000) Stack: c011a94c 04882eab 0ca9 c1812a80 c1812a80 04882eab 0ca9 f6fe1d90 c011b4af 04882eab 0ca9 0001 c038e3c0 c038e3c0 f6fe1df4 c011e09d f6fe1dfc c011de3b 001f c1812a80 001f Call Trace: [] show_trace_log_lvl+0x1a/0x30 [] show_stack_log_lvl+0xb6/0xe0 [] show_registers+0x201/0x330 [] die+0x118/0x260 [] do_page_fault+0x193/0x600 [] error_code+0x72/0x78 [] activate_task+0x4f/0xb0 [] try_to_wake_up+0x2bd/0x420 [] wake_up_process_mutex+0x19/0x20 [] wakeup_next_waiter+0xec/0x1a0 [] rt_spin_lock_slowunlock+0x4c/0x70 [] rt_spin_unlock+0x26/0x30 [] put_zone_pcp+0x14/0x20 [] get_page_from_freelist+0x145/0x380 [] __alloc_pages+0x54/0x2d0 [] __handle_mm_fault+0x7dd/0x9a0 [] do_page_fault+0x2f8/0x600 [] error_code+0x72/0x78 === Code: Bad EIP value. EIP: [<>] _stext+0x3feff000/0x20 SS:ESP 0068:f6fe1d50 NMI watchdog detected lockup on CPU#1 (5000/5000) ... Complete serial console capture: http://www.rncbc.org/datahub/console-2.6.22.1-rt4.0-1.log .config evidence: http://www.rncbc.org/datahub/config-2.6.22.1-rt4.0 Cheers. -- rncbc aka Rui Nuno Capela - 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/
Re: 2.6.22.1-rt4 lockups
Hi again, Sorry to bother, but got another one. Please advise whether these dumps are any useful or are just garbage. ... Oops: [#1] PREEMPT SMP Modules linked in: appletalk ax25 ipx p8023 snd_rtctimer snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_seq_midi snd_seq_midi_event snd_seq w83627hf hwmon_vid hwmon button eeprom battery ac loop dm_mod ohci1394 ieee1394 snd_ice1712 snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_cs8427 nvidia(P) snd_i2c wacom usbhid hid ff_memless firewire_ohci snd_cs46xx snd_mpu401_uart gameport snd_rawmidi firewire_core crc_itu_t snd_seq_device sk98lin snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd intel_agp soundcore ide_cd ehci_hcd uhci_hcd cdrom iTCO_wdt shpchp snd_page_alloc agpgart usbcore i2c_i801 pci_hotplug i2c_core rtc_cmos rtc_core rtc_lib ext3 mbcache jbd edd fan piix thermal processor ide_disk ide_core CPU:0 EIP:0060:[<>]Tainted: P VLI EFLAGS: 00010003 (2.6.22.1-rt4.0 #1) EIP is at _stext+0x3feff000/0x20 eax: c1812a80 ebx: c03bb540 ecx: 0001 edx: c038e3c0 esi: c038e3c0 edi: 0001 ebp: c64a9d6c esp: c64a9d50 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 preempt:0003 Process thunderbird-bin (pid: 12848, ti=c64a9000 task=e4514db0 task.ti=c64a9000) Stack: c011a94c d1027dbe 1dc1 c1812a80 c1812a80 d1027dbe 1dc1 c64a9d90 c011b4af d1027dbe 1dc1 0001 c038e3c0 c038e3c0 c64a9df4 c011e09d 001f c1812a80 c64a9e20 Call Trace: [] show_trace_log_lvl+0x1a/0x30 [] show_stack_log_lvl+0xb6/0xe0 [] show_registers+0x201/0x330 [] die+0x118/0x260 [] do_page_fault+0x193/0x600 [] error_code+0x72/0x78 [] activate_task+0x4f/0xb0 [] try_to_wake_up+0x2bd/0x420 [] wake_up_process_mutex+0x19/0x20 [] wakeup_next_waiter+0xec/0x1a0 [] rt_spin_lock_slowunlock+0x4c/0x70 [] rt_spin_unlock+0x26/0x30 [] put_zone_pcp+0x14/0x20 [] get_page_from_freelist+0x145/0x380 [] __alloc_pages+0x54/0x2d0 [] __handle_mm_fault+0x7dd/0x9a0 [] do_page_fault+0x2f8/0x600 [] error_code+0x72/0x78 === Code: Bad EIP value. EIP: [<>] _stext+0x3feff000/0x20 SS:ESP 0068:c64a9d50 NMI watchdog detected lockup on CPU#1 (5000/5000) Pid: 2882, comm:klogd EIP: 0060:[] CPU: 1 EIP is at __spin_lock+0x19/0x20 EFLAGS: 0082Tainted: P(2.6.22.1-rt4.0 #1) EAX: c1812a80 EBX: c1812a80 ECX: 0001 EDX: f6c57000 ESI: c0403a80 EDI: dff03230 EBP: f6c57d1c DS: 007b ES: 007b FS: 00d8 CR0: 8005003b CR2: ae41a000 CR3: 3730e000 CR4: 06d0 [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x20 [] show_regs+0x183/0x190 [] nmi_watchdog_tick+0x1f0/0x290 [] do_nmi+0x77/0x260 [] nmi_stack_correct+0x26/0x2b [] task_rq_lock+0x37/0x70 [] try_to_wake_up+0x27/0x420 [] default_wake_function+0x18/0x20 [] __wake_up_common+0x39/0x60 [] __wake_up_sync+0x3b/0x50 [] sock_def_readable+0x79/0x80 [] unix_dgram_sendmsg+0x450/0x500 [] sock_aio_write+0x114/0x130 [] do_sync_write+0xd0/0x110 [] vfs_write+0x14d/0x160 [] sys_write+0x3d/0x70 [] sysenter_past_esp+0x5f/0x85 === NMI watchdog detected lockup on CPU#0 (0/5000) Pid: 12848, comm: thunderbird-bin EIP: 0060:[] CPU: 0 EIP is at __spin_lock+0x19/0x20 EFLAGS: 0082Tainted: P(2.6.22.1-rt4.0 #1) EAX: c1812a80 EBX: c1812a80 ECX: EDX: c040d000 ESI: c0403a80 EDI: f74cf8f0 EBP: c040df50 DS: 007b ES: 007b FS: 00d8 CR0: 8005003b CR2: ffd5 CR3: 0c391000 CR4: 06d0 [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x20 [] show_regs+0x183/0x190 [] nmi_watchdog_tick+0x1f0/0x290 [] do_nmi+0x77/0x260 [] nmi_stack_correct+0x26/0x2b [] task_rq_lock+0x37/0x70 [] try_to_wake_up+0x27/0x420 [] wake_up_process+0x19/0x20 [] redirect_hardirq+0x47/0x60 [] handle_fasteoi_irq+0x6b/0x100 [] do_IRQ+0x94/0x100 [] common_interrupt+0x23/0x28 [] do_exit+0x88/0x890 [] die+0x257/0x260 [] do_page_fault+0x193/0x600 [] error_code+0x72/0x78 [] activate_task+0x4f/0xb0 [] try_to_wake_up+0x2bd/0x420 [] wake_up_process_mutex+0x19/0x20 [] wakeup_next_waiter+0xec/0x1a0 [] rt_spin_lock_slowunlock+0x4c/0x70 [] rt_spin_unlock+0x26/0x30 [] put_zone_pcp+0x14/0x20 [] get_page_from_freelist+0x145/0x380 [] __alloc_pages+0x54/0x2d0 [] __handle_mm_fault+0x7dd/0x9a0 [] do_page_fault+0x2f8/0x600 [] error_code+0x72/0x78 === ... Complete serial console capture: http://www.rncbc.org/datahub/console-2.6.22.1-rt4.0-2.log .config evidence: http://www.rncbc.org/datahub/config-2.6.22.1-rt4.0 Bye now -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: v2.6.22.1-rt5
Ingo Molnar wrote: > we are pleased to announce the v2.6.22.1-rt5 kernel (collected and > assembled by Thomas), which can be downloaded from the usual place: > > http://redhat.com/~mingo/realtime-preempt/ > > more info about the -rt patchset can be found in the RT wiki: > > http://rt.wiki.kernel.org > > Changes since -rt4: > > - MM fix: PCP pages locking (Peter Zijlstra) > > - yield() fix: remove stale RCU-unlock (Daniel Walker) > > - dont do check_pgt_cache() in idle (found by Daniel Walker) > > - moved 8 patches, created 6 new patches out of larger patches to >make the -rt queue more bisectable (Daniel Walker) > > - cleanup (Daniel Walker) > > - fix the latency tracer under paravirt > > to build a 2.6.22.1-rt5 tree, the following patches should be applied: > > http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.1.tar.bz2 > http://redhat.com/~mingo/realtime-preempt/patch-2.6.22.1-rt5 > > Ingo > - Maybe I was too quick, but `make all` on is failing here: ... In file included from arch/i386/mm/pgtable.c:16: include/linux/quicklist.h: In function ‘quicklist_alloc’: include/linux/quicklist.h:50: warning: unused variable ‘q’ include/linux/quicklist.h: In function ‘__quicklist_free’: include/linux/quicklist.h:79: error: ‘per_cpu__quicklist’ undeclared (first use in this function) include/linux/quicklist.h:79: error: (Each undeclared identifier is reported only once include/linux/quicklist.h:79: error: for each function it appears in.) include/linux/quicklist.h:79: warning: type defaults to ‘int’ in declaration of ‘type name’ include/linux/quicklist.h:79: error: invalid type argument of ‘unary *’ make[1]: *** [arch/i386/mm/pgtable.o] Error 1 make: *** [arch/i386/mm] Error 2 ... .config is from previous -rt4: http://www.rncbc.org/datahub/config-2.6.22.1-rt4.0 Bye now. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
2.6.23-rt1 trouble
On Fri, October 12, 2007 03:04, Steven Rostedt wrote: > We are pleased to announce the 2.6.23-rt1 tree, which can be > downloaded from the location: > > http://www.kernel.org/pub/linux/kernel/projects/rt/ > > Changes since 2.6.23-rc9-rt2 > > - updated to 2.6.23 > > - spin_trylock_irqsave macro fix (Sébastien Dugué) > > - move rcu_preempt_boost init earlier (Steven Rostedt) > > - rt task send IPI condition update (Mike Kravetz) > I am experiencing some highly annoying but intermitent freezing on a pentium4 2.80G HT/SMT box, when doing normal desktop work with 2.6.23-rt1. The same crippling behavior does not occur on a Core 2 Due T7200 2.0G SMP, so I suspect it's something due specific to the SMT scheduling support (Hyper-Threading). But can't tell for sure, obviously :) The symptoms are noticeable primarily as some X/GUI intermitent freezing, sometimes only one application, then several and ultimately the whole X desktop becomes completely unresponsive. It looks like scheduling problems. There is this hint that switching to a spare console terminal (via Ctrl+Alt+Fn) might cause later recovery. But its just a question of some more time for it just happens again and again, one after another, several applications becoming temporarily frozen and just by luck the system gets back to normal, probably due to some incidental shake-up :) but there are other times that nothing seems to help with no alternative to the power-reset switch. I could not find any evidence on dmesg or in the system logs, of any apparent trouble. No BUGs, no oops, no panics, no nothing. It just freezes, this and that, now and then. It just makes it all unworkable and obviously subject to ditching. Again, this only happens on this P4/HT box. On a Core2 Duo laptop, with same 2.6.23-rt1 with the very same kernel configuration, it does not show any illness and is running quite fine. Remember one report I had about a similar freezing behavior? Now it's happening the other way around: the core2 is OK, the pentium4 is KO. One naive suspicion goes like the new rcu-preempt code is to blame, since I don't remember having this or any other trouble with 2.6.23-rc8-rt1. Until now this post looks like more of a rant than a proper bug report, I know. Question is how I can help myself in figuring this all out? Advice on debugging, tracing or statistical collection would be really appreciated, as will for any hint in pin pointing the issue, of course. Help? -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.23-rt1 trouble
On Mon, October 15, 2007 11:49, Rui Nuno Capela wrote: > On Fri, October 12, 2007 03:04, Steven Rostedt wrote: > >> We are pleased to announce the 2.6.23-rt1 tree, which can be >> downloaded from the location: >> >> http://www.kernel.org/pub/linux/kernel/projects/rt/ >> >> Changes since 2.6.23-rc9-rt2 >> >> - updated to 2.6.23 >> >> - spin_trylock_irqsave macro fix (Sébastien Dugué) >> >> - move rcu_preempt_boost init earlier (Steven Rostedt) >> >> - rt task send IPI condition update (Mike Kravetz) >> > > I am experiencing some highly annoying but intermitent freezing on a > pentium4 2.80G HT/SMT box, when doing normal desktop work with 2.6.23-rt1. > > > The same crippling behavior does not occur on a Core 2 Due T7200 2.0G > SMP, so I suspect it's something due specific to the SMT scheduling > support (Hyper-Threading). But can't tell for sure, obviously :) > I was wrong. After several trials the same behavior also occurs on the Core2 Duo T7200. It just took longer to show its nasty. > The symptoms are noticeable primarily as some X/GUI intermitent freezing, > sometimes only one application, then several and ultimately the whole X > desktop becomes completely unresponsive. It looks like scheduling > problems. There is this hint that switching to a spare console terminal > (via Ctrl+Alt+Fn) might cause later recovery. But its just a question of > some more time for it just happens again and again, one after another, > several applications becoming temporarily frozen and just by luck the > system gets back to normal, probably due to some incidental shake-up :) > but there are other times that nothing seems to help with no alternative > to the power-reset switch. > > I could not find any evidence on dmesg or in the system logs, of any > apparent trouble. No BUGs, no oops, no panics, no nothing. It just > freezes, this and that, now and then. It just makes it all unworkable > and obviously subject to ditching. > > Again, this only happens on this P4/HT box. On a Core2 Duo laptop, with > same 2.6.23-rt1 with the very same kernel configuration, it does not show > any illness and is running quite fine. > False. It used to run fine, until the creeps happen first time :( > Remember one report I had about a similar freezing behavior? Now it's > happening the other way around: the core2 is OK, the pentium4 is KO. > Now it applies to all 2.6.23-rt1 images I could test upon. > One naive suspicion goes like the new rcu-preempt code is to blame, since > I don't remember having this or any other trouble with 2.6.23-rc8-rt1. > Not be sure anymore, but this seems to be still a valid assumption. Just in case someone might try in reproducing this showstopper, the kernel .config is available from here: http://www.rncbc.org/datahub/config-2.6.23-rt1.0 dmesg output as right after init: http://www.rncbc.org/datahub/dmesg-2.6.23-rt1.0 which can't really tell where to look :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: Two 2.6.20-rc5-rt2 issues
On Tue, January 16, 2007 11:56, Ingo Molnar wrote: > > * Rui Nuno Capela <[EMAIL PROTECTED]> wrote: > >> First one is about building for UP (CONFIG_SMP not set) on my old P4 >> laptop. As it seems, all my build attempts failed at the final link >> stage, with undefined references to paravirt_enable. After disabling >> CONFIG_PARAVIRT I get a similar failure, but this time for a couple >> kvm* symbols. [...] > > ok, i think i have managed to fix both bugs. I have released -rt3, > please re-check whether it works any better. If it still doesnt then > please send me the exact .config that fails. > Building this already with -rt5, still gives: ... LD arch/i386/boot/compressed/vmlinux OBJCOPY arch/i386/boot/vmlinux.bin BUILD arch/i386/boot/bzImage Root device is (3, 2) Boot sector 512 bytes. Setup is 7407 bytes. System is 1427 kB Kernel: arch/i386/boot/bzImage is ready (#1) WARNING: "profile_hits" [drivers/kvm/kvm-intel.ko] undefined! WARNING: "profile_hits" [drivers/kvm/kvm-amd.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 ... .config as .gz is attached. > >> Second one is already about running SMP, on a Dual Core2 T7200, for >> which the build goes fine but run-time is haunted by a crippling BUG: > >> Call Trace: >> [] __switch_to+0xcc/0x176 >> [] wake_up_process+0x19/0x1b >> [] acpi_ec_gpe_handler+0x1f/0x53 >> [] acpi_ev_gpe_dispatch+0x64/0x163 >> [] acpi_ev_gpe_detect+0x94/0xd7 >> > > hm, this is a -rt specific thing that i hoped to have worked around but > apparently not. The ACPI code uses a waitqueue in its idle routine > (argh!) which cannot by done sanely on PREEMPT_RT. In -rt3 i've added > a more conservative (but still ugly and incorrect) hack - could you try > it, does -rt3 work any better? > Yes it does. No BUG has been spotted on -rt3, yet. Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] config.gz Description: GNU Zip compressed data
Re: Two 2.6.20-rc5-rt2 issues
On Wed, January 17, 2007 06:31, Ingo Molnar wrote:
>
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
>
>> Building this already with -rt5, still gives:
>> ...
>> LD arch/i386/boot/compressed/vmlinux
>> OBJCOPY arch/i386/boot/vmlinux.bin
>> BUILD arch/i386/boot/bzImage
>> Root device is (3, 2)
>> Boot sector 512 bytes.
>> Setup is 7407 bytes.
>> System is 1427 kB
>> Kernel: arch/i386/boot/bzImage is ready (#1)
>> WARNING: "profile_hits" [drivers/kvm/kvm-intel.ko] undefined!
>> WARNING: "profile_hits" [drivers/kvm/kvm-amd.ko] undefined!
>>
>
> ok - in my test-config i didnt have KVM modular - the patch below should
> fix this problem.
>
> Ingo
>
>
> Index: linux/kernel/profile.c
> ===
> --- linux.orig/kernel/profile.c
> +++ linux/kernel/profile.c
> @@ -332,7 +332,6 @@ out:
> local_irq_restore(flags); put_cpu(); }
> -EXPORT_SYMBOL_GPL(profile_hits);
>
>
> static int __devinit profile_cpu_callback(struct notifier_block *info,
> unsigned long action, void *__cpu) @@ -402,6 +401,8 @@ void
> profile_hits(int type, void *__pc, }
> #endif /* !CONFIG_SMP */
>
>
> +EXPORT_SYMBOL_GPL(profile_hits);
> +
> void __profile_tick(int type, struct pt_regs *regs) {
> if (type == CPU_PROFILING && timer_hook)
>
OK, now it builds alright.
Both issues seem to be fixed now, thanks.
Bye.
--
rncbc aka Rui Nuno Capela
[EMAIL PROTECTED]
-
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/
2.6.20-rt5 Oops on boot
ty Framework v1.0.0 initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff
4400
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 3080 4400
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Compat vDSO mapped to e000.
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 9k freed
ACPI: Core revision 20060707
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
Booting processor 1/1 eip 2000
CPU 1 irqstacks, hard=c03ee000 soft=c03ec000
Initializing CPU#1
Calibrating delay using timer specific routine.. 6720.94 BogoMIPS
(lpj=3360473)
CPU: After generic identify, caps: bfebfbff
4400
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 3080 4400
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
Total of 2 processors activated (13444.92 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Brought up 2 CPUs
BUG: unable to handle kernel NULL pointer dereference at virtual address
001c
printing eip:
c011783d
*pde =
stopped custom tracer.
Oops: [#1]
PREEMPT SMP
Modules linked in:
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.20-rt5.1 #1)
EIP is at try_to_wake_up+0x11/0x395
eax: ebx: ecx: edx: dfc87ccc
esi: edi: c18a4700 ebp: dfc87cdc esp: dfc87c90
ds: 007b es: 007b ss: 0068 preempt: 0001
Process swapper (pid: 1, ti=dfc87000 task=dfca1670 task.ti=dfc87000)
Stack: 0046 001f 0008 c18a3d80 dfca1670 dfc87cc0
dfc87cb8
0046 dfca1670 0001 dfc87cc4 c0136f34 dfc87cd0 c012dbc8
dfc87cf4
c18a3d80 c18a4700 dfc87ce8 c0117c64 dfc87d3c
c01180e6
Call Trace:
[] wake_up_process+0x19/0x1b
[] set_cpus_allowed+0x6c/0x92
[] measure_one+0x34/0x165
[] build_sched_domains+0x6e2/0xce4
[] arch_init_sched_domains+0x1b/0x1d
[] sched_init_smp+0x10/0x47
[] init+0xd0/0x335
[] kernel_thread_helper+0x7/0x10
===
Code: 5d f0 89 4f 44 89 5f 48 8b 55 e8 89 f8 e8 99 e1 ff ff 83 c4 0c 5b
5e 5f 5d c3 55 89 e5 57 56 89 c6 53 83 ec 40 89 55 bc 8d 55 f0 <83> 78
1c 63 b8 00 00 00 00 0f 4f c1 89 45 b8 89 f0 e8 ca e1 ff
EIP: [] try_to_wake_up+0x11/0x395 SS:ESP 0068:dfc87c90
<0>Kernel panic - not syncing: Attempted to kill init!
[] dump_trace+0x63/0x1e5
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] panic+0x50/0xf3
[] do_exit+0x9b/0x771
[] die+0x211/0x237
[] do_page_fault+0x3f3/0x4bf
[] error_code+0x7c/0x84
[] try_to_wake_up+0x11/0x395
[] wake_up_process+0x19/0x1b
[] set_cpus_allowed+0x6c/0x92
[] measure_one+0x34/0x165
[] build_sched_domains+0x6e2/0xce4
[] arch_init_sched_domains+0x1b/0x1d
[] sched_init_smp+0x10/0x47
[] init+0xd0/0x335
[] kernel_thread_helper+0x7/0x10
===
--EOF--
Hope it helps.
--
rncbc aka Rui Nuno Capela
[EMAIL PROTECTED]
-
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/
Re: 2.6.20-rt5 Oops on boot
Andrew Burgess wrote: > > Ditto for me on an ASUS AMD64 x2, just hangs, I have no > serial console. 2.6.20-rc5-rt7 booted ok (the last one I > tried). Both using SMP. > Yep. The last one I've tried and pretty stable for the record, is 2.6.20-rt3. Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.20-rt5 Oops on boot [-rt8 OK]
Rui Nuno Capela (me) wrote: > > I have terrible news: 2.6.20-rt5 does not boot at all on a couple > machines I was brave enough to try -- a [EMAIL PROTECTED] SMP/HT desktop, and > a > Core2 Duo [EMAIL PROTECTED] laptop. For the first case I could capture the > following dump via serial console: > ... News are that 2.6.20-rt8 got it all back to business :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
2.6.20-rc6-rt1 timekeeping_is_continuous question
Hi, I'm having the following traces on every boot; are they of any concern, or should I just ignore and carry on? (machine is an Intel Core2 Duo T7200 2.0Ghz laptop) Linux version 2.6.20-rc6-rt1.0 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP PREEMPT Thu Jan 25 10:02:28 WET 2007 [...] Total of 2 processors activated (7985.17 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 timekeeping_is_continuous(jiffies): 0 [] dump_trace+0x63/0x1ec [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] timekeeping_is_continuous+0x58/0x60 [] tick_check_oneshot_change+0x3e/0x111 [] hrtimer_run_queues+0x40/0x26a [] run_timer_softirq+0x785/0x975 [] ksoftirqd+0xfd/0x1a2 [] kthread+0xb5/0xde [] kernel_thread_helper+0x7/0x10 === checking TSC synchronization [CPU#0 -> CPU#1]: passed. Brought up 2 CPUs timekeeping_is_continuous(jiffies): 0 [] dump_trace+0x63/0x1ec [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] timekeeping_is_continuous+0x58/0x60 [] tick_check_oneshot_change+0x3e/0x111 [] hrtimer_run_queues+0x40/0x26a [] run_timer_softirq+0x785/0x975 [] ksoftirqd+0xfd/0x1a2 [] kthread+0xb5/0xde [] kernel_thread_helper+0x7/0x10 === migration_cost=34 Booting paravirtualized kernel on bare hardware [...] Time: tsc clocksource has been installed. timekeeping_is_continuous(tsc): 0 [] dump_trace+0x63/0x1ec [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] timekeeping_is_continuous+0x58/0x60 [] tick_check_oneshot_change+0x3e/0x111 [] hrtimer_run_queues+0x40/0x26a [] run_timer_softirq+0x785/0x975 [] ksoftirqd+0xfd/0x1a2 [] kthread+0xb5/0xde [] kernel_thread_helper+0x7/0x10 === timekeeping_is_continuous(tsc): 0 [] dump_trace+0x63/0x1ec [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] timekeeping_is_continuous+0x58/0x60 [] tick_check_oneshot_change+0x3e/0x111 [] hrtimer_run_queues+0x40/0x26a [] run_timer_softirq+0x785/0x975 [] ksoftirqd+0xfd/0x1a2 [] kthread+0xb5/0xde [] kernel_thread_helper+0x7/0x10 === Write protecting the kernel read-only data: 794k timekeeping_is_continuous(tsc): 1 timekeeping_is_continuous(tsc): 1 [] dump_trace+0x63/0x1ec [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] timekeeping_is_continuous+0x58/0x60 [] tick_check_oneshot_change+0x3e/0x111 [] hrtimer_run_queues+0x40/0x26a [] run_timer_softirq+0x785/0x975 [] ksoftirqd+0xfd/0x1a2 [] kthread+0xb5/0xde [] kernel_thread_helper+0x7/0x10 === Switched to high resolution mode on CPU 1 [] dump_trace+0x63/0x1ec [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] timekeeping_is_continuous+0x58/0x60 [] tick_check_oneshot_change+0x3e/0x111 [] hrtimer_run_queues+0x40/0x26a [] run_timer_softirq+0x785/0x975 [] ksoftirqd+0xfd/0x1a2 [] kthread+0xb5/0xde [] kernel_thread_helper+0x7/0x10 === Switched to high resolution mode on CPU 0 [...] Bye. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
2.6.20-rc6-rt4 register_cpu_notification undefined
Hi, Just to let you know that this my simple patch solves the 'register_cpu_notifier' being undefined when SMP is set but not HOTPLUG_CPU. Dunno if its the right thing, tho. Cheers -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] linux-2.6.20-rc6-rt4-cpu.patch Description: Binary data
2.6.19-rt11 boot failure
toption+0x0/0x222 === Code: 11 fd ff eb ec eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 55 89 e5 83 ec 18 89 5d f8 8b 4d 0c e8 92 0e fd ff 81 c3 37 45 01 00 <89> 75 fc 8b 83 d8 ff ff ff 8b 30 8b 46 04 c7 00 14 00 63 10 8b EIP: [] 0xf000fea7 SS:ESP 0068:c03a1f0c <0>Kernel panic - not syncing: Fatal exception in interrupt [] panic+0x50/0xf1 [] die+0x2a2/0x2d6 [] do_page_fault+0x440/0x513 [] __alloc_pages+0x55/0x284 [] do_page_fault+0x0/0x513 [] error_code+0x39/0x40 [] __kmalloc+0x8a/0x95 [] timer_interrupt+0x46/0x4c [] handle_IRQ_event+0x41/0xb7 [] handle_level_irq+0xa4/0xee [] do_IRQ+0xcd/0xf6 [] common_interrupt+0x1a/0x20 [] __spin_unlock_irqrestore+0xf/0x23 [] setup_irq+0x14a/0x1cf [] start_kernel+0x227/0x3c4 [] unknown_bootoption+0x0/0x222 ======= Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.19-rt11 boot failure
Thomas Gleixner wrote: > On Sat, 2006-12-09 at 21:28 +0000, Rui Nuno Capela wrote: >> Hi all, >> >> Sorry for the interrupt, but all my 2.6.19-rt11 builds very fail early on >> boot. It doesn't matter if its UP or SMP. This is a sample of what I could >> capture on one case via serial console: > > Can you please disable CONFIG_HPET_TIMER ? > Yes, sorry :) now it boots and runs apparently fine. I always had HPET_TIMER enabled until now. Ok, last time I tried was on 2.6.19-rt6. Somehow I've failed to know or simply missed whether HPET it's supposed to be off on PREEMPT_RT kernels. Maybe some simple heads-up would be welcome :) Notice that lately I have both HIGH_RES_TIMERS and NO_HZ enabled. Is there any sense on having those options mutually exclusive with HPET_TIMER ? Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.21-rt2..8 troubles
Thomas Gleixner wrote: > On Fri, 2007-06-08 at 19:21 +0100, Rui Nuno Capela wrote: >> Just built from linux-2.6.22-rc4.tar.bz2, with patch-2.6.22-rc4-hrt5. >> All's working apparentely nice on this offending machine (laptop, intel >> core2 T7200). In fact, I'm writing this very reply under it and through >> ipw3945 wifi module--which never was so pragmatic on -rt2..9 ;) >> >> Nevertheless, this is not preempt-realtime (-rt) is it? And I it never >> complained about vanilla. >> >> Is this good news though? > > Well, the patch carries the same high resolution timer fixes as -rt, so > I just wanted to exclude those. Thanks for testing. > > I'm spinning -rt10 with a couple of fixes. Should be out sometimes > tomorrow. If the problem persists, we need to dig deeper. > Uhoh. I'm sorry to tell, but the problem is still creeping on 2.6.21.4-rt11 and -rt12 :( So sorry. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.21-rt2..8 troubles
Daniel Walker wrote: > On Mon, 2007-06-11 at 21:45 +0200, Thomas Gleixner wrote: >> On Mon, 2007-06-11 at 20:36 +0100, Rui Nuno Capela wrote: >>>> I'm spinning -rt10 with a couple of fixes. Should be out sometimes >>>> tomorrow. If the problem persists, we need to dig deeper. >>>> >>> Uhoh. I'm sorry to tell, but the problem is still creeping on >>> 2.6.21.4-rt11 and -rt12 :( >>> >>> So sorry. >> Hmm. Does it happen, when you boot with maxcpus=1 on the kernel >> commandline ? > > I think 2.6.21-rt2 had some apic updates also, (along with hpet updates) > so testing with "noapic" on the command line might be helpful too .. > Thomas, Yes, "maxcpus=1" seems to keep it running, but then I render my Core2 just half-baked ;) Daniel, No, "noapic" does not seem to help any better. HTH -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.21-rt2..8 troubles
Thomas Gleixner wrote: > On Mon, 2007-06-11 at 21:50 +0100, Rui Nuno Capela wrote: >> Thomas, >> >> Yes, "maxcpus=1" seems to keep it running, but then I render my Core2 >> just half-baked ;) > > Yes, I know :( > > /me goes into desperate mode > > Is this a DELL laptop ? > Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL PROTECTED] Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already know :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.21-rt2..8 troubles
On Tue, June 12, 2007 00:08, Thomas Gleixner wrote: > On Mon, 2007-06-11 at 15:34 -0700, Daniel Walker wrote: > >> On Mon, 2007-06-11 at 23:42 +0200, Thomas Gleixner wrote: >> >>> On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: >>> >>>> Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo >>>> [EMAIL PROTECTED] >>>> >>> >>> Yeah, there are Dell ones which have similar or worse symptoms. >>> >>> >>>> Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you >>>> already know :) >>> >>> Ok. I go back and figure out which differences we have between >>> 2.6.21-rt>8 and the -hrt queue. >>> >> >> Are you sure it's strictly and HRT issue? I didn't see a >> !CONFIG_HIGH_RES_TIMERS test .. >> > > The main difference between -rt1 and -rt2 was the update of -hrt, which > not only affects CONFIG_HIGH_RES_TIMERS. There are enough > CONFIG_HIGH_RES_TIMERS=n related changes to clock events and friends as > well. > In deed, FWIW and IIRC, I can confirm that the show-stopper problem was still present when tried with CONFIG_HIGH_RES_TIMERS not set (=N). Bye now. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.21-rt2..8 troubles
Hi, I'm back but with good news this time :)... On Tue, June 12, 2007 11:10, Rui Nuno Capela wrote: > On Tue, June 12, 2007 00:08, Thomas Gleixner wrote: >> On Mon, 2007-06-11 at 15:34 -0700, Daniel Walker wrote: >>> On Mon, 2007-06-11 at 23:42 +0200, Thomas Gleixner wrote: >>>> On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: >>>> >>>>> Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo >>>>> [EMAIL PROTECTED] >>>>> >>>> Yeah, there are Dell ones which have similar or worse symptoms. >>>> >>>>> Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you >>>>> already know :) >>>> >>>> Ok. I go back and figure out which differences we have between >>>> 2.6.21-rt>8 and the -hrt queue. >>> >>> Are you sure it's strictly and HRT issue? I didn't see a >>> !CONFIG_HIGH_RES_TIMERS test .. >> >> The main difference between -rt1 and -rt2 was the update of -hrt, which >> not only affects CONFIG_HIGH_RES_TIMERS. There are enough >> CONFIG_HIGH_RES_TIMERS=n related changes to clock events and friends as >> well. > > In deed, FWIW and IIRC, I can confirm that the show-stopper problem was > still present when tried with CONFIG_HIGH_RES_TIMERS not set (=N). > Although I'm still with my fingers crossed, I can tell that 2.6.21.5-rt19 (and -rt20) does behave far better now on the very same box. I've more than 8 hours up and running now, without a single glimpse of the bad symptoms, which used to show in a matter of minutes if not earlier during init time. Congratulations, -rt is usable again here and that just makes me happier :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: v2.6.21.5-rt19
Hi, On Wed, July 4, 2007 21:49, Thomas Gleixner wrote: > I'm pleased to announce the v2.6.21.5-rt19 kernel on behalf of Ingo. > > > It can be downloaded from the usual place: > > http://people.redhat.com/mingo/realtime-preempt/ > > More info about the -rt patch set can be found in the RT wiki: > > http://rt.wiki.kernel.org > > Changes since 2.6.21.5-rt18: > > - Fixed a nasty and hard to track down slowness / boot problem on SMP > machines with CONFIG_NOHZ enabled. The problem was caused by the timer > wheel base lock held during the get_next_timer_interrupt() call in the > idle path, which eventually led to a bogus PI boosting of the idle task > and in consequence a stale wrong scheduler selection for the affected idle > task. > > Kudos to Carsten Emde, who patiently and meticulously isolated the > problem and provided the traces, which allowed to identify the root cause. > > Problem solution: Prevent idle task boosting > > - back port of the ntp / clock_was_set fix > > - integration of the processor_idle fix from Venki Pallipadi, which > resolves boot issues on some platforms > > - ep93xx clock events fix from Manfred Gruber > Maybe someone remember me whining about troubles with 2.6.21-rt2..18 on my Core2 T7200 laptop (fujitsu-siemens amilo i1520). Althought I'm still with my fingers crossed, I can tell the good news are that 2.6.21.5-rt19 (and -rt20) does behave far better now on the very same box. I've more than 8 hours up and running now, without a single glimpse of the bad symptoms, which used to show in a matter of minutes if not earlier during init time. Congratulations. I'm not sure whether this problem can be closed for good, though, just because you mention the slowness fix applies to CONFIG_NOHZ=Y and I'm quite sure my badness surged either way. But at least -rt is usable again here and that just makes me happier :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
2.6.21-rt2..8 troubles
Hi Ingo et al. It's been quite a while, since last time I've complained about the -rt kernel patch series. This time I'm afraid I have a nasty specialty I've been trying to figure out and isolate but to no definitive results. Fact is, since 2.6.21-rt2 and still on latest -rt8, that I'm facing troubled behavior while running on a Core2 T7200 laptop (SMP). Somehow, soon or later, the whole system starts crawling to death. It just slows down to some kind of Big Freeze, with no evidence over the console whatsoever, so that I'm ultimately left with a brick on my hands. This behavior is consistent and occurs every time after a while. It surely does not occur on 2.6.21-rt1 and earlier. Even stranger, it does not occur on another but older [EMAIL PROTECTED] desktop (HT/SMP) where a very identical system image is deployed (openSUSE 10.2 i386, gcc 4.1.2, KDE 3.5.7) I wish I could give you more details, but the fact is I don't know where to look. The machine just freezes silently, again and again, with all kernels from -rt2 to -rt8 inclusive, with no traceable evidence, at least to my knowledge. The only symptom that I can come about is that, from some moment on and ever since, the system cannot start any new process anymore, or otherwise takes forever to realize and launch any new started process thread. A sample dmesg output: http://www.rncbc.org/datahub/dmesg-2.6.21-rt5.0 The corresponding .config: http://www.rncbc.org/datahub/config-2.6.21-rt5.0 Again, there's no logged evidence of the problem, which is as nasty as repeatable after each boot. Unfortunately, it's not quite deterministically reproducible, this behavior of turning into an unresponsive brick ;) It's just a matter of time, or so I think. That's why I have no clues. Is there anything I can do better to help myself figuring out this issue? As this is a modern laptop such things like a serial console are unavailable, but it would be nice to track things up over netconsole perhaps? I just need some bright and nice directions now ;) Hope someone finds this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
Re: 2.6.21-rt2..8 troubles
Thomas Gleixner wrote: > On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote: >> Is there anything I can do better to help myself figuring out this >> issue? As this is a modern laptop such things like a serial console are >> unavailable, but it would be nice to track things up over netconsole >> perhaps? >> >> I just need some bright and nice directions now ;) Hope someone finds >> this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :) > > Can you boot with "hpet=disable" on the command line ? > Nope. It doesn't seem to have significant effect. Same time-bomb behavior: after an indeterminate period of uptime, the systems stops responding and cannot spawn new processes (current running ones still live on, strange). > If that does not help, please provide the output of /proc/timer_list. > This is with my latest iteration: http://www.rncbc.org/datahub/config-2.6.21.1-rt8.0 Normal boot on which it behaves as badly as reported: http://www.rncbc.org/datahub/dmesg-2.6.21.1-rt8.0 # cat /proc/timer_list Timer List Version: v0.3 HRTIMER_MAX_CLOCK_BASES: 2 now at 131736771907 nsecs cpu: 0 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180213690448299114 nsecs active timers: clock 1: .index: 1 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: , tick_sched_timer, S:01 # expires at 13173700 nsecs [in 228093 nsecs] #1: , it_real_fn, S:01 # expires at 131751277843 nsecs [in 14505936 nsecs] #2: , hrtimer_wakeup, S:01 # expires at 131802703679 nsecs [in 65931772 nsecs] #3: , hrtimer_wakeup, S:01 # expires at 131802705006 nsecs [in 65933099 nsecs] #4: , hrtimer_wakeup, S:01 # expires at 132412838830 nsecs [in 676066923 nsecs] #5: , it_real_fn, S:01 # expires at 137026607454 nsecs [in 5289835547 nsecs] #6: , hrtimer_wakeup, S:01 # expires at 141381493725 nsecs [in 9644721818 nsecs] #7: , hrtimer_wakeup, S:01 # expires at 170796028701 nsecs [in 39059256794 nsecs] .expires_next : 13173700 nsecs .hres_active: 1 .nr_events : 40634 .nohz_mode : 2 .idle_tick : 13172400 nsecs .tick_stopped : 0 .idle_jiffies : 4294799020 .idle_calls : 178848 .idle_sleeps: 133212 .idle_entrytime : 131736069830 nsecs .idle_sleeptime : 100895567465 nsecs .last_jiffies : 4294799033 .next_jiffies : 4294799039 .idle_expires : 13173600 nsecs jiffies: 4294799033 cpu: 1 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180213690448299114 nsecs active timers: clock 1: .index: 1 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: , hrtimer_wakeup, S:01 # expires at 131737067173 nsecs [in 295266 nsecs] #1: , tick_sched_timer, S:01 # expires at 13173725 nsecs [in 478093 nsecs] #2: , hrtimer_wakeup, S:01 # expires at 139151071745 nsecs [in 7414299838 nsecs] #3: , hrtimer_wakeup, S:01 # expires at 139151133755 nsecs [in 7414361848 nsecs] #4: , hrtimer_wakeup, S:01 # expires at 139151154005 nsecs [in 7414382098 nsecs] .expires_next : 131737067173 nsecs .hres_active: 1 .nr_events : 31510 .nohz_mode : 2 .idle_tick : 13173425 nsecs .tick_stopped : 0 .idle_jiffies : 4294799030 .idle_calls : 151213 .idle_sleeps: 107018 .idle_entrytime : 131735193036 nsecs .idle_sleeptime : 108256832194 nsecs .last_jiffies : 4294799032 .next_jiffies : 4294799040 .idle_expires : 13174300 nsecs jiffies: 4294799033 Tick Device: mode: 1 Clock Event Device: hpet max_delta_ns: 2147483647 min_delta_ns: 3352 mult: 61496110 shift: 32 mode: 3 next_event: 13173700 nsecs set_next_event: hpet_legacy_next_event set_mode: hpet_legacy_set_mode event_handler: tick_handle_oneshot_broadcast tick_broadcast_mask: 0003 tick_broadcast_oneshot_mask: 0001 Tick Device: mode: 1 Clock Event Device: lapic max_delta_ns: 806914928 min_delta_ns: 1442 mult: 44650051 shift: 32 mode: 1 next_event: 13173700 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt Tick Device: mode: 1 Clock Event Device: lapic max_delta_ns: 806914928 min_delta_ns: 1442 mult: 44650051 shift: 32 mode: 3 next_event: 131737067173 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt -- Alternate boot with hpet=disabled as suggested, but no better results: http://www.rncbc.org/datahub/dmesg-2.6.21.1-rt8.0-hpet_disabled # cat /proc/timer_list Timer List Version: v0.3 HRTIMER_MAX_CLOCK_BASES: 2 now at 269529706096 nsecs cpu: 0 clock 0: .index: 0 .resolution: 1 nse
2.6.22.1-rt3 lockups
+0x3d/0x70 [] sysenter_past_esp+0x5f/0x85 === NMI watchdog detected lockup on CPU#0 (0/5000) ... Here are the complete console captures: http://www.rncbc.org/datahub/console-2.6.22.1-rt3.0-1.log http://www.rncbc.org/datahub/console-2.6.22.1-rt3.0-2.log http://www.rncbc.org/datahub/console-2.6.22.1-rt3.0-3.log .config evidence: http://www.rncbc.org/datahub/config-2.6.22.1-rt3.0 Cheers. -- rncbc aka Rui Nuno Capela - 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/
Re: 2.6.21-rt2..8 troubles
Rui Nuno Capela wrote: > Thomas Gleixner wrote: >> On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote: >>> Is there anything I can do better to help myself figuring out this >>> issue? As this is a modern laptop such things like a serial console are >>> unavailable, but it would be nice to track things up over netconsole >>> perhaps? >>> >>> I just need some bright and nice directions now ;) Hope someone finds >>> this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :) >> Can you boot with "hpet=disable" on the command line ? >> > > Nope. It doesn't seem to have significant effect. Same time-bomb > behavior: after an indeterminate period of uptime, the systems stops > responding and cannot spawn new processes (current running ones still > live on, strange). > >> If that does not help, please provide the output of /proc/timer_list. >> > > This is with my latest iteration: > http://www.rncbc.org/datahub/config-2.6.21.1-rt8.0 > > Normal boot on which it behaves as badly as reported: > http://www.rncbc.org/datahub/dmesg-2.6.21.1-rt8.0 > > # cat /proc/timer_list > Timer List Version: v0.3 > HRTIMER_MAX_CLOCK_BASES: 2 > now at 131736771907 nsecs > > cpu: 0 > clock 0: > .index: 0 > .resolution: 1 nsecs > .get_time: ktime_get_real > .offset: 1180213690448299114 nsecs > active timers: > clock 1: > .index: 1 > .resolution: 1 nsecs > .get_time: ktime_get > .offset: 0 nsecs > active timers: > #0: , tick_sched_timer, S:01 > # expires at 13173700 nsecs [in 228093 nsecs] > #1: , it_real_fn, S:01 > # expires at 131751277843 nsecs [in 14505936 nsecs] > #2: , hrtimer_wakeup, S:01 > # expires at 131802703679 nsecs [in 65931772 nsecs] > #3: , hrtimer_wakeup, S:01 > # expires at 131802705006 nsecs [in 65933099 nsecs] > #4: , hrtimer_wakeup, S:01 > # expires at 132412838830 nsecs [in 676066923 nsecs] > #5: , it_real_fn, S:01 > # expires at 137026607454 nsecs [in 5289835547 nsecs] > #6: , hrtimer_wakeup, S:01 > # expires at 141381493725 nsecs [in 9644721818 nsecs] > #7: , hrtimer_wakeup, S:01 > # expires at 170796028701 nsecs [in 39059256794 nsecs] > .expires_next : 13173700 nsecs > .hres_active: 1 > .nr_events : 40634 > .nohz_mode : 2 > .idle_tick : 13172400 nsecs > .tick_stopped : 0 > .idle_jiffies : 4294799020 > .idle_calls : 178848 > .idle_sleeps: 133212 > .idle_entrytime : 131736069830 nsecs > .idle_sleeptime : 100895567465 nsecs > .last_jiffies : 4294799033 > .next_jiffies : 4294799039 > .idle_expires : 13173600 nsecs > jiffies: 4294799033 > > cpu: 1 > clock 0: > .index: 0 > .resolution: 1 nsecs > .get_time: ktime_get_real > .offset: 1180213690448299114 nsecs > active timers: > clock 1: > .index: 1 > .resolution: 1 nsecs > .get_time: ktime_get > .offset: 0 nsecs > active timers: > #0: , hrtimer_wakeup, S:01 > # expires at 131737067173 nsecs [in 295266 nsecs] > #1: , tick_sched_timer, S:01 > # expires at 13173725 nsecs [in 478093 nsecs] > #2: , hrtimer_wakeup, S:01 > # expires at 139151071745 nsecs [in 7414299838 nsecs] > #3: , hrtimer_wakeup, S:01 > # expires at 139151133755 nsecs [in 7414361848 nsecs] > #4: , hrtimer_wakeup, S:01 > # expires at 139151154005 nsecs [in 7414382098 nsecs] > .expires_next : 131737067173 nsecs > .hres_active: 1 > .nr_events : 31510 > .nohz_mode : 2 > .idle_tick : 13173425 nsecs > .tick_stopped : 0 > .idle_jiffies : 4294799030 > .idle_calls : 151213 > .idle_sleeps: 107018 > .idle_entrytime : 131735193036 nsecs > .idle_sleeptime : 108256832194 nsecs > .last_jiffies : 4294799032 > .next_jiffies : 4294799040 > .idle_expires : 13174300 nsecs > jiffies: 4294799033 > > > Tick Device: mode: 1 > Clock Event Device: hpet > max_delta_ns: 2147483647 > min_delta_ns: 3352 > mult: 61496110 > shift: 32 > mode: 3 > next_event: 13173700 nsecs > set_next_event: hpet_legacy_next_event > set_mode: hpet_legacy_set_mode > event_handler: tick_handle_oneshot_broadcast > tick_broadcast_mask: 0003 > tick_broadcast_oneshot_mask: 0001 > > > Tick Device: mode: 1 > Clock Event Device: lapic > max_delta_ns: 806914928 > min_delta_ns: 1442 > mult: 44650051 > shift: 32 > mode: 1 > next_event: 13173700 nsecs > set_nex
Re: 2.6.21-rt2..8 troubles
Hi Thomas, On Fri, June 8, 2007 16:47, Thomas Gleixner wrote: > On Wed, 2007-06-06 at 01:44 +0100, Rui Nuno Capela wrote: > >> Just for the heads-up, I'm still suffering from this same illness, and >> it seems even worse (big freeze happens earlier) on 2.6.21.3-rt9. >> >> There's no way around. On one box it works flawlessly (desktop, >> [EMAIL PROTECTED]) while on the patient one (laptop, core2 T7200) it bricks >> silently. > > Sorry for responding late. To have some idea where the breakage comes > from, can you please try > > http://www.tglx.de/projects/hrtimers/2.6.22-rc4/patch-2.6.22-rc4-hrt5.pat > ch > > whether it has the same behaviour. > Just built from linux-2.6.22-rc4.tar.bz2, with patch-2.6.22-rc4-hrt5. All's working apparentely nice on this offending machine (laptop, intel core2 T7200). In fact, I'm writing this very reply under it and through ipw3945 wifi module--which never was so pragmatic on -rt2..9 ;) Nevertheless, this is not preempt-realtime (-rt) is it? And I it never complained about vanilla. Is this good news though? -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
2.6.21-rc5-rt6 make errors
Hi, Just tried to build 2.6.21-rc5-rt6 and it is failing on build time. ... kernel/sched.c: In function ‘__schedule’: kernel/sched.c:3830: error: ‘print_functions’ undeclared (first use in this function) kernel/sched.c:3830: error: (Each undeclared identifier is reported only once kernel/sched.c:3830: error: for each function it appears in.) ... arch/i386/kernel/apic.c: In function ‘smp_apic_timer_interrupt’: arch/i386/kernel/apic.c:589: error: invalid lvalue in assignment arch/i386/kernel/apic.c:608: error: invalid lvalue in assignment ... Just to let you know that -rt5 was doing fine with very same .config . Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
2.6.21-rc5-rt10 troubles
Ingo et al. I'm afraid having no good news (once again). After building 2.6.21-rc5-rt8 and recently on -rt10 I've found some trouble running on a Core2 T7200 laptop (SMP). Somehow, specially after starting jackd, the whole system starts crawling to death. It just slows down to some kind of Big Freeze, with no evidence over the console whatsoever, so that I'm ultimately left with a brick on my hands. This behavior is consistent and occurs every time after jackd is started. It does not seem to occur on -rt5 and earlier. I wish I could give you more details, but fact is I don't know where to look. The machine just freezes silently. Bye now. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - 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/
