i have released the -V0.7.41-10 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
this release fixes two bugs:
- one affecting SMP systems & RCU (the missing smp_mb()s)
- the other one in net/xfrm/xfrm_policy.c, affecting systems where
network interfaces (or pseudo-interfaces) are frequently
created/destroyed
i've also added a new debugging feature which is activated if
RT_DEADLOCK_DETECT is enabled: the checking of active locks in freed
memory.
This catches a dangerous category of bugs which the upstream kernel can
silently ignore (because there locks are quite 'passive'), while the -RT
kernel will often go down in flames sometime later (it has lists within
the lock, etc.). This mechanism found the xfrm_policy.c bug:
BUG: events/0/4, active lock [e94a8cdc(e94a8cd0-e94a90dc)] freed!
[<c0103e31>] dump_stack+0x1e/0x20 (20)
[<c0136fa2>] check_no_locks_freed+0x158/0x210 (60)
[<c01477e9>] kfree+0x59/0x15a (48)
[<c03638db>] xfrm_policy_gc_task+0x6f/0x7e (28)
[<c012f3c7>] worker_thread+0x1c1/0x26c (132)
[<c01333e9>] kthread+0x95/0xbd (48)
[<c01012c9>] kernel_thread_helper+0x5/0xb (1039269908)
so i'd expect more such bugs to be found. If you had stability problems
under PREEMPT_RT (hangs, crashes), please enable RT_DEADLOCK_DETECT and
try to reproduce the problem and send me the resulting log messages.
to create a -V0.7.41-10 tree from scratch, the patching order is:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc1.bz2
http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc1-V0.7.41-10
Ingo
* Lee Revell <[email protected]> wrote:
> On Fri, 2005-03-25 at 15:59 +0100, Ingo Molnar wrote:
> > i have released the -V0.7.41-10 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
>
> I get zillions of "return type defaults to int" warnings trying to
> compile this with PREEMPT_DESKTOP.
i've uploaded -41-11 which should fix it.
Ingo
On Fri, 2005-03-25 at 15:59 +0100, Ingo Molnar wrote:
> i have released the -V0.7.41-10 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
I get zillions of "return type defaults to int" warnings trying to
compile this with PREEMPT_DESKTOP.
Lee
On Fri, 2005-03-25 at 23:39 +0100, Ingo Molnar wrote:
> * Lee Revell <[email protected]> wrote:
>
> > On Fri, 2005-03-25 at 15:59 +0100, Ingo Molnar wrote:
> > > i have released the -V0.7.41-10 Real-Time Preemption patch, which can be
> > > downloaded from the usual place:
> > >
> > > http://redhat.com/~mingo/realtime-preempt/
> >
> > I get zillions of "return type defaults to int" warnings trying to
> > compile this with PREEMPT_DESKTOP.
>
> i've uploaded -41-11 which should fix it.
>
OK. Any idea about those get_swap_page latencies? I set the swappiness
to 100 on both machines, but I only see those on the slower machine.
Running for several days with PREEMPT_DESKTOP, on the Athlon XP the
worst latency I am seeing is ~150 usecs! But on the C3 its about 4ms:
( ksoftirqd/0-2 |#0): new 16 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 32 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 77 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 86 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 110 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 121 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 131 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 136 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 143 us maximum-latency wakeup.
( IRQ 11-1445 |#0): new 172 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 594 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 1164 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 1255 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 1429 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 1557 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 1680 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 1722 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 1944 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 2027 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 2082 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 2107 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 2112 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 2322 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 2339 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 2426 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 2517 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 2707 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 2817 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 2874 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 3053 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 3149 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 3225 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 3250 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 3316 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 3636 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 3668 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 3819 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 3953 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 3964 us maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 4104 us maximum-latency wakeup.
The traces look like this:
preemption latency trace v1.1.4 on 2.6.12-rc1-RT-V0.7.41-08
--------------------------------------------------------------------
latency: 4104 us, #124/124, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-----------------
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-----------------
_------=> CPU#
/ _-----=> irqs-off
| / _----=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
|||| /
||||| delay
cmd pid ||||| time | caller
\ / ||||| \ | /
(T1/#0) kswapd0 66 0 9 00000002 00000000 [0061867425992692] 0.000ms (+914240.345ms): <6177736b> (<00306470>)
(T1/#2) kswapd0 66 0 9 00000002 00000002 [0061867425993150] 0.000ms (+0.000ms): __trace_start_sched_wakeup+0x96/0xc0 <c012f806> (try_to_wake_up+0x84/0x140 <c010f9e4>)
(T1/#3) kswapd0 66 0 9 00000000 00000003 [0061867425993646] 0.001ms (+0.001ms): wake_up_process+0x1c/0x30 <c010fabc> (do_softirq+0x4b/0x60 <c01047bb>)
(T6/#4) kswapd0-66 0dn.2 2us!< (1)
(T2/#5) kswapd0-66 0dnh2 975us : do_IRQ+0x2d/0x80 <c010467d> (c014e3c6 0 0)
(T1/#6) kswapd0 66 0 5 00000001 00000006 [0061867426579669] 0.976ms (+0.003ms): mask_and_ack_8259A+0xb/0x110 <c010818b> (__do_IRQ+0x8b/0x160 <c01364ab>)
(T1/#7) kswapd0 66 0 5 00000001 00000007 [0061867426581623] 0.979ms (+0.000ms): redirect_hardirq+0x8/0x90 <c0136288> (__do_IRQ+0xbc/0x160 <c01364dc>)
(T1/#8) kswapd0 66 0 5 00000000 00000008 [0061867426582099] 0.980ms (+0.000ms): handle_IRQ_event+0xe/0xf0 <c013631e> (__do_IRQ+0xea/0x160 <c013650a>)
(T1/#9) kswapd0 66 0 5 00000000 00000009 [0061867426582486] 0.981ms (+0.000ms): timer_interrupt+0xb/0x100 <c0106fcb> (handle_IRQ_event+0x61/0xf0 <c0136371>)
(T1/#10) kswapd0 66 0 5 00000001 0000000a [0061867426583035] 0.982ms (+0.004ms): mark_offset_tsc+0xe/0x370 <c010c81e> (timer_interrupt+0x24/0x100 <c0106fe4>)
(T1/#11) kswapd0 66 0 5 00000001 0000000b [0061867426585820] 0.986ms (+0.000ms): do_timer+0x8/0x20 <c011e718> (timer_interrupt+0x2a/0x100 <c0106fea>)
(T1/#12) kswapd0 66 0 5 00000001 0000000c [0061867426586179] 0.987ms (+0.000ms): update_process_times+0xa/0x100 <c011e17a> (timer_interrupt+0x44/0x100 <c0107004>)
(T1/#13) kswapd0 66 0 5 00000001 0000000d [0061867426586521] 0.988ms (+0.000ms): account_system_time+0xa/0xb0 <c011013a> (update_process_times+0xed/0x100 <c011e25d>)
(T1/#14) kswapd0 66 0 5 00000001 0000000e [0061867426586854] 0.988ms (+0.000ms): acct_update_integrals+0xa/0x60 <c013609a> (account_system_time+0x40/0xb0 <c0110170>)
(T1/#15) kswapd0 66 0 5 00000001 0000000f [0061867426587131] 0.989ms (+0.000ms): update_mem_hiwater+0x8/0x50 <c0147b68> (update_process_times+0xed/0x100 <c011e25d>)
(T1/#16) kswapd0 66 0 5 00000001 00000010 [0061867426587472] 0.989ms (+0.000ms): run_local_timers+0x8/0x20 <c011e298> (update_process_times+0x2d/0x100 <c011e19d>)
(T1/#17) kswapd0 66 0 5 00000001 00000011 [0061867426587879] 0.990ms (+0.000ms): raise_softirq+0xa/0x70 <c011a21a> (update_process_times+0x2d/0x100 <c011e19d>)
(T1/#18) kswapd0 66 0 5 00000001 00000012 [0061867426588355] 0.991ms (+0.000ms): rcu_check_callbacks+0x8/0xc0 <c0126e18> (update_process_times+0x68/0x100 <c011e1d8>)
(T1/#19) kswapd0 66 0 5 00000001 00000013 [0061867426588691] 0.991ms (+0.000ms): idle_cpu+0x8/0x20 <c0110c28> (rcu_check_callbacks+0x66/0xc0 <c0126e76>)
(T1/#20) kswapd0 66 0 5 00000001 00000014 [0061867426589168] 0.992ms (+0.000ms): scheduler_tick+0xc/0x3e0 <c011024c> (update_process_times+0x6f/0x100 <c011e1df>)
(T1/#21) kswapd0 66 0 5 00000001 00000015 [0061867426589501] 0.993ms (+0.001ms): sched_clock+0xe/0xe0 <c010c57e> (scheduler_tick+0x1d/0x3e0 <c011025d>)
(T1/#22) kswapd0 66 0 5 00000001 00000016 [0061867426590397] 0.994ms (+0.000ms): run_posix_cpu_timers+0xe/0x1b0 <c012d04e> (timer_interrupt+0x44/0x100 <c0107004>)
(T1/#23) kswapd0 66 0 5 00000001 00000017 [0061867426590838] 0.995ms (+0.001ms): profile_hit+0x9/0x50 <c0115a79> (timer_interrupt+0x4e/0x100 <c010700e>)
(T1/#24) kswapd0 66 0 5 00000001 00000018 [0061867426591522] 0.996ms (+0.000ms): note_interrupt+0xb/0x90 <c0136e0b> (__do_IRQ+0x148/0x160 <c0136568>)
(T1/#25) kswapd0 66 0 5 00000001 00000019 [0061867426591895] 0.997ms (+0.000ms): end_8259A_irq+0x8/0x40 <c0107f58> (__do_IRQ+0x110/0x160 <c0136530>)
(T1/#26) kswapd0 66 0 5 00000001 0000001a [0061867426592237] 0.997ms (+0.002ms): enable_8259A_irq+0xb/0x80 <c010803b> (__do_IRQ+0x110/0x160 <c0136530>)
(T1/#27) kswapd0 66 0 7 00000002 0000001b [0061867426593509] 0.999ms (+0.000ms): irq_exit+0x8/0x50 <c011a1c8> (do_IRQ+0x60/0x80 <c01046b0>)
(T1/#28) kswapd0 66 0 3 00000003 0000001c [0061867426593976] 1.000ms (+0.000ms): do_softirq+0xb/0x60 <c010477b> (irq_exit+0x45/0x50 <c011a205>)
(T1/#29) kswapd0 66 0 9 00000000 0000001d [0061867426594452] 1.001ms (+0.001ms): __do_softirq+0xa/0x90 <c011a05a> (do_softirq+0x4b/0x60 <c01047bb>)
(T6/#30) kswapd0-66 0dn.2 1002us!< (1)
(T2/#31) kswapd0-66 0dnh2 1973us : do_IRQ+0x2d/0x80 <c010467d> (c014e3cc 0 0)
(T1/#32) kswapd0 66 0 5 00000001 00000020 [0061867427179407] 1.974ms (+0.002ms): mask_and_ack_8259A+0xb/0x110 <c010818b> (__do_IRQ+0x8b/0x160 <c01364ab>)
(T1/#33) kswapd0 66 0 5 00000001 00000021 [0061867427181188] 1.977ms (+0.000ms): redirect_hardirq+0x8/0x90 <c0136288> (__do_IRQ+0xbc/0x160 <c01364dc>)
(T1/#34) kswapd0 66 0 5 00000000 00000022 [0061867427181652] 1.978ms (+0.000ms): handle_IRQ_event+0xe/0xf0 <c013631e> (__do_IRQ+0xea/0x160 <c013650a>)
(T1/#35) kswapd0 66 0 5 00000000 00000023 [0061867427182012] 1.978ms (+0.000ms): timer_interrupt+0xb/0x100 <c0106fcb> (handle_IRQ_event+0x61/0xf0 <c0136371>)
(T1/#36) kswapd0 66 0 5 00000001 00000024 [0061867427182448] 1.979ms (+0.004ms): mark_offset_tsc+0xe/0x370 <c010c81e> (timer_interrupt+0x24/0x100 <c0106fe4>)
(T1/#37) kswapd0 66 0 5 00000001 00000025 [0061867427185275] 1.984ms (+0.000ms): do_timer+0x8/0x20 <c011e718> (timer_interrupt+0x2a/0x100 <c0106fea>)
(T1/#38) kswapd0 66 0 5 00000001 00000026 [0061867427185625] 1.984ms (+0.000ms): update_process_times+0xa/0x100 <c011e17a> (timer_interrupt+0x44/0x100 <c0107004>)
(T1/#39) kswapd0 66 0 5 00000001 00000027 [0061867427185972] 1.985ms (+0.000ms): account_system_time+0xa/0xb0 <c011013a> (update_process_times+0xed/0x100 <c011e25d>)
(T1/#40) kswapd0 66 0 5 00000001 00000028 [0061867427186355] 1.986ms (+0.000ms): acct_update_integrals+0xa/0x60 <c013609a> (account_system_time+0x40/0xb0 <c0110170>)
(T1/#41) kswapd0 66 0 5 00000001 00000029 [0061867427186720] 1.986ms (+0.000ms): update_mem_hiwater+0x8/0x50 <c0147b68> (update_process_times+0xed/0x100 <c011e25d>)
(T1/#42) kswapd0 66 0 5 00000001 0000002a [0061867427187061] 1.987ms (+0.000ms): run_local_timers+0x8/0x20 <c011e298> (update_process_times+0x2d/0x100 <c011e19d>)
(T1/#43) kswapd0 66 0 5 00000001 0000002b [0061867427187394] 1.987ms (+0.000ms): raise_softirq+0xa/0x70 <c011a21a> (update_process_times+0x2d/0x100 <c011e19d>)
(T1/#44) kswapd0 66 0 5 00000001 0000002c [0061867427187844] 1.988ms (+0.000ms): rcu_check_callbacks+0x8/0xc0 <c0126e18> (update_process_times+0x68/0x100 <c011e1d8>)
(T1/#45) kswapd0 66 0 5 00000001 0000002d [0061867427188177] 1.989ms (+0.000ms): idle_cpu+0x8/0x20 <c0110c28> (rcu_check_callbacks+0x66/0xc0 <c0126e76>)
(T1/#46) kswapd0 66 0 5 00000001 0000002e [0061867427188595] 1.989ms (+0.000ms): scheduler_tick+0xc/0x3e0 <c011024c> (update_process_times+0x6f/0x100 <c011e1df>)
(T1/#47) kswapd0 66 0 5 00000001 0000002f [0061867427189086] 1.990ms (+0.001ms): sched_clock+0xe/0xe0 <c010c57e> (scheduler_tick+0x1d/0x3e0 <c011025d>)
(T1/#48) kswapd0 66 0 5 00000001 00000030 [0061867427189936] 1.992ms (+0.000ms): run_posix_cpu_timers+0xe/0x1b0 <c012d04e> (timer_interrupt+0x44/0x100 <c0107004>)
(T1/#49) kswapd0 66 0 5 00000001 00000031 [0061867427190359] 1.992ms (+0.001ms): profile_hit+0x9/0x50 <c0115a79> (timer_interrupt+0x4e/0x100 <c010700e>)
(T1/#50) kswapd0 66 0 5 00000001 00000032 [0061867427191007] 1.993ms (+0.000ms): note_interrupt+0xb/0x90 <c0136e0b> (__do_IRQ+0x148/0x160 <c0136568>)
(T1/#51) kswapd0 66 0 5 00000001 00000033 [0061867427191376] 1.994ms (+0.000ms): end_8259A_irq+0x8/0x40 <c0107f58> (__do_IRQ+0x110/0x160 <c0136530>)
(T1/#52) kswapd0 66 0 5 00000001 00000034 [0061867427191718] 1.995ms (+0.002ms): enable_8259A_irq+0xb/0x80 <c010803b> (__do_IRQ+0x110/0x160 <c0136530>)
(T1/#53) kswapd0 66 0 7 00000002 00000035 [0061867427192985] 1.997ms (+0.000ms): irq_exit+0x8/0x50 <c011a1c8> (do_IRQ+0x60/0x80 <c01046b0>)
(T1/#55) kswapd0 66 0 9 00000000 00000037 [0061867427194001] 1.998ms (+0.000ms): __do_softirq+0xa/0x90 <c011a05a> (do_softirq+0x4b/0x60 <c01047bb>)
(T6/#56) kswapd0-66 0dn.2 1999us!< (1)
(T2/#57) kswapd0-66 0dnh2 2971us : do_IRQ+0x2d/0x80 <c010467d> (c014e3cf 0 0)
(T1/#58) kswapd0 66 0 5 00000001 0000003a [0061867427779204] 2.972ms (+0.002ms): mask_and_ack_8259A+0xb/0x110 <c010818b> (__do_IRQ+0x8b/0x160 <c01364ab>)
(T1/#59) kswapd0 66 0 5 00000001 0000003b [0061867427780963] 2.975ms (+0.000ms): redirect_hardirq+0x8/0x90 <c0136288> (__do_IRQ+0xbc/0x160 <c01364dc>)
(T1/#60) kswapd0 66 0 5 00000000 0000003c [0061867427781443] 2.976ms (+0.000ms): handle_IRQ_event+0xe/0xf0 <c013631e> (__do_IRQ+0xea/0x160 <c013650a>)
(T1/#61) kswapd0 66 0 5 00000000 0000003d [0061867427781830] 2.976ms (+0.000ms): timer_interrupt+0xb/0x100 <c0106fcb> (handle_IRQ_event+0x61/0xf0 <c0136371>)
(T1/#62) kswapd0 66 0 5 00000001 0000003e [0061867427782271] 2.977ms (+0.004ms): mark_offset_tsc+0xe/0x370 <c010c81e> (timer_interrupt+0x24/0x100 <c0106fe4>)
(T1/#63) kswapd0 66 0 5 00000001 0000003f [0061867427785062] 2.982ms (+0.000ms): do_timer+0x8/0x20 <c011e718> (timer_interrupt+0x2a/0x100 <c0106fea>)
(T1/#64) kswapd0 66 0 5 00000001 00000040 [0061867427785408] 2.982ms (+0.000ms): update_process_times+0xa/0x100 <c011e17a> (timer_interrupt+0x44/0x100 <c0107004>)
(T1/#65) kswapd0 66 0 5 00000001 00000041 [0061867427785750] 2.983ms (+0.000ms): account_system_time+0xa/0xb0 <c011013a> (update_process_times+0xed/0x100 <c011e25d>)
(T1/#66) kswapd0 66 0 5 00000001 00000042 [0061867427786129] 2.984ms (+0.000ms): acct_update_integrals+0xa/0x60 <c013609a> (account_system_time+0x40/0xb0 <c0110170>)
(T1/#67) kswapd0 66 0 5 00000001 00000043 [0061867427786489] 2.984ms (+0.000ms): update_mem_hiwater+0x8/0x50 <c0147b68> (update_process_times+0xed/0x100 <c011e25d>)
(T1/#68) kswapd0 66 0 5 00000001 00000044 [0061867427786839] 2.985ms (+0.000ms): run_local_timers+0x8/0x20 <c011e298> (update_process_times+0x2d/0x100 <c011e19d>)
(T1/#69) kswapd0 66 0 5 00000001 00000045 [0061867427787172] 2.985ms (+0.000ms): raise_softirq+0xa/0x70 <c011a21a> (update_process_times+0x2d/0x100 <c011e19d>)
(T1/#70) kswapd0 66 0 5 00000001 00000046 [0061867427787626] 2.986ms (+0.000ms): rcu_check_callbacks+0x8/0xc0 <c0126e18> (update_process_times+0x68/0x100 <c011e1d8>)
(T1/#71) kswapd0 66 0 5 00000001 00000047 [0061867427787964] 2.987ms (+0.000ms): idle_cpu+0x8/0x20 <c0110c28> (rcu_check_callbacks+0x66/0xc0 <c0126e76>)
(T1/#72) kswapd0 66 0 5 00000001 00000048 [0061867427788378] 2.987ms (+0.000ms): scheduler_tick+0xc/0x3e0 <c011024c> (update_process_times+0x6f/0x100 <c011e1df>)
(T1/#73) kswapd0 66 0 5 00000001 00000049 [0061867427788711] 2.988ms (+0.001ms): sched_clock+0xe/0xe0 <c010c57e> (scheduler_tick+0x1d/0x3e0 <c011025d>)
(T1/#74) kswapd0 66 0 5 00000001 0000004a [0061867427789557] 2.989ms (+0.000ms): run_posix_cpu_timers+0xe/0x1b0 <c012d04e> (timer_interrupt+0x44/0x100 <c0107004>)
(T1/#75) kswapd0 66 0 5 00000001 0000004b [0061867427789989] 2.990ms (+0.001ms): profile_hit+0x9/0x50 <c0115a79> (timer_interrupt+0x4e/0x100 <c010700e>)
(T1/#76) kswapd0 66 0 5 00000001 0000004c [0061867427790659] 2.991ms (+0.000ms): note_interrupt+0xb/0x90 <c0136e0b> (__do_IRQ+0x148/0x160 <c0136568>)
(T1/#77) kswapd0 66 0 5 00000001 0000004d [0061867427791033] 2.992ms (+0.000ms): end_8259A_irq+0x8/0x40 <c0107f58> (__do_IRQ+0x110/0x160 <c0136530>)
(T1/#78) kswapd0 66 0 5 00000001 0000004e [0061867427791433] 2.992ms (+0.002ms): enable_8259A_irq+0xb/0x80 <c010803b> (__do_IRQ+0x110/0x160 <c0136530>)
(T1/#79) kswapd0 66 0 7 00000002 0000004f [0061867427792705] 2.995ms (+0.000ms): irq_exit+0x8/0x50 <c011a1c8> (do_IRQ+0x60/0x80 <c01046b0>)
(T1/#80) kswapd0 66 0 3 00000003 00000050 [0061867427793238] 2.995ms (+0.000ms): do_softirq+0xb/0x60 <c010477b> (irq_exit+0x45/0x50 <c011a205>)
(T1/#81) kswapd0 66 0 9 00000000 00000051 [0061867427793742] 2.996ms (+0.000ms): __do_softirq+0xa/0x90 <c011a05a> (do_softirq+0x4b/0x60 <c01047bb>)
(T6/#82) kswapd0-66 0dn.2 2997us!< (1)
(T2/#83) kswapd0-66 0dnh2 3969us : do_IRQ+0x2d/0x80 <c010467d> (c014e3c6 0 0)
(T1/#84) kswapd0 66 0 5 00000001 00000054 [0061867428379021] 3.970ms (+0.003ms): mask_and_ack_8259A+0xb/0x110 <c010818b> (__do_IRQ+0x8b/0x160 <c01364ab>)
(T1/#85) kswapd0 66 0 5 00000001 00000055 [0061867428380861] 3.973ms (+0.000ms): redirect_hardirq+0x8/0x90 <c0136288> (__do_IRQ+0xbc/0x160 <c01364dc>)
(T1/#86) kswapd0 66 0 5 00000000 00000056 [0061867428381320] 3.974ms (+0.000ms): handle_IRQ_event+0xe/0xf0 <c013631e> (__do_IRQ+0xea/0x160 <c013650a>)
(T1/#87) kswapd0 66 0 5 00000000 00000057 [0061867428381680] 3.975ms (+0.000ms): timer_interrupt+0xb/0x100 <c0106fcb> (handle_IRQ_event+0x61/0xf0 <c0136371>)
(T1/#88) kswapd0 66 0 5 00000001 00000058 [0061867428382121] 3.975ms (+0.004ms): mark_offset_tsc+0xe/0x370 <c010c81e> (timer_interrupt+0x24/0x100 <c0106fe4>)
(T1/#89) kswapd0 66 0 5 00000001 00000059 [0061867428385025] 3.980ms (+0.000ms): do_timer+0x8/0x20 <c011e718> (timer_interrupt+0x2a/0x100 <c0106fea>)
(T1/#90) kswapd0 66 0 5 00000001 0000005a [0061867428385375] 3.981ms (+0.000ms): update_process_times+0xa/0x100 <c011e17a> (timer_interrupt+0x44/0x100 <c0107004>)
(T1/#91) kswapd0 66 0 5 00000001 0000005b [0061867428385721] 3.981ms (+0.000ms): account_system_time+0xa/0xb0 <c011013a> (update_process_times+0xed/0x100 <c011e25d>)
(T1/#92) kswapd0 66 0 5 00000001 0000005c [0061867428386105] 3.982ms (+0.000ms): acct_update_integrals+0xa/0x60 <c013609a> (account_system_time+0x40/0xb0 <c0110170>)
(T1/#93) kswapd0 66 0 5 00000001 0000005d [0061867428386469] 3.982ms (+0.000ms): update_mem_hiwater+0x8/0x50 <c0147b68> (update_process_times+0xed/0x100 <c011e25d>)
(T1/#94) kswapd0 66 0 5 00000001 0000005e [0061867428386810] 3.983ms (+0.000ms): run_local_timers+0x8/0x20 <c011e298> (update_process_times+0x2d/0x100 <c011e19d>)
(T1/#95) kswapd0 66 0 5 00000001 0000005f [0061867428387139] 3.984ms (+0.000ms): raise_softirq+0xa/0x70 <c011a21a> (update_process_times+0x2d/0x100 <c011e19d>)
(T1/#96) kswapd0 66 0 5 00000001 00000060 [0061867428387622] 3.984ms (+0.000ms): rcu_check_callbacks+0x8/0xc0 <c0126e18> (update_process_times+0x68/0x100 <c011e1d8>)
(T1/#97) kswapd0 66 0 5 00000001 00000061 [0061867428387958] 3.985ms (+0.000ms): idle_cpu+0x8/0x20 <c0110c28> (rcu_check_callbacks+0x66/0xc0 <c0126e76>)
(T1/#98) kswapd0 66 0 5 00000001 00000062 [0061867428388453] 3.986ms (+0.000ms): scheduler_tick+0xc/0x3e0 <c011024c> (update_process_times+0x6f/0x100 <c011e1df>)
(T1/#99) kswapd0 66 0 5 00000001 00000063 [0061867428388781] 3.986ms (+0.001ms): sched_clock+0xe/0xe0 <c010c57e> (scheduler_tick+0x1d/0x3e0 <c011025d>)
(T1/#100) kswapd0 66 0 5 00000001 00000064 [0061867428389637] 3.988ms (+0.000ms): run_posix_cpu_timers+0xe/0x1b0 <c012d04e> (timer_interrupt+0x44/0x100 <c0107004>)
(T1/#101) kswapd0 66 0 5 00000001 00000065 [0061867428390064] 3.988ms (+0.001ms): profile_hit+0x9/0x50 <c0115a79> (timer_interrupt+0x4e/0x100 <c010700e>)
(T1/#102) kswapd0 66 0 5 00000001 00000066 [0061867428390703] 3.990ms (+0.000ms): note_interrupt+0xb/0x90 <c0136e0b> (__do_IRQ+0x148/0x160 <c0136568>)
(T1/#103) kswapd0 66 0 5 00000001 00000067 [0061867428391076] 3.990ms (+0.000ms): end_8259A_irq+0x8/0x40 <c0107f58> (__do_IRQ+0x110/0x160 <c0136530>)
(T1/#104) kswapd0 66 0 5 00000001 00000068 [0061867428391423] 3.991ms (+0.002ms): enable_8259A_irq+0xb/0x80 <c010803b> (__do_IRQ+0x110/0x160 <c0136530>)
(T1/#105) kswapd0 66 0 7 00000002 00000069 [0061867428392667] 3.993ms (+0.000ms): irq_exit+0x8/0x50 <c011a1c8> (do_IRQ+0x60/0x80 <c01046b0>)
(T1/#106) kswapd0 66 0 3 00000003 0000006a [0061867428393139] 3.994ms (+0.000ms): do_softirq+0xb/0x60 <c010477b> (irq_exit+0x45/0x50 <c011a205>)
(T1/#107) kswapd0 66 0 9 00000000 0000006b [0061867428393628] 3.994ms (+0.000ms): __do_softirq+0xa/0x90 <c011a05a> (do_softirq+0x4b/0x60 <c01047bb>)
(T6/#108) kswapd0-66 0dn.2 3995us+< (1)
(T1/#109) kswapd0 66 0 2 00000001 0000006d [0061867428448564] 4.086ms (+0.001ms): preempt_schedule+0xa/0x70 <c02a837a> (get_swap_page+0x208/0x290 <c014e488>)
(T1/#110) kswapd0 66 0 2 00000000 0000006e [0061867428449351] 4.087ms (+0.000ms): preempt_schedule+0xa/0x70 <c02a837a> (get_swap_page+0xc4/0x290 <c014e344>)
(T1/#111) kswapd0 66 0 3 00000000 0000006f [0061867428449864] 4.088ms (+0.000ms): __schedule+0xe/0x710 <c02a7b5e> (preempt_schedule+0x4f/0x70 <c02a83bf>)
(T1/#112) kswapd0 66 0 3 00000000 00000070 [0061867428450437] 4.089ms (+0.000ms): profile_hit+0x9/0x50 <c0115a79> (__schedule+0x3a/0x710 <c02a7b8a>)
(T1/#113) kswapd0 66 0 3 00000001 00000071 [0061867428450904] 4.090ms (+0.002ms): sched_clock+0xe/0xe0 <c010c57e> (__schedule+0x68/0x710 <c02a7bb8>)
(T1/#114) kswapd0 66 0 3 00000002 00000072 [0061867428452321] 4.092ms (+0.000ms): dequeue_task+0xa/0x50 <c010f5ba> (__schedule+0x1ca/0x710 <c02a7d1a>)
(T1/#115) kswapd0 66 0 3 00000002 00000073 [0061867428452788] 4.093ms (+0.000ms): recalc_task_prio+0xc/0x1a0 <c010f71c> (__schedule+0x1e4/0x710 <c02a7d34>)
(T1/#116) kswapd0 66 0 3 00000002 00000074 [0061867428453289] 4.094ms (+0.000ms): effective_prio+0x8/0x50 <c010f6c8> (recalc_task_prio+0xa6/0x1a0 <c010f7b6>)
(T1/#117) kswapd0 66 0 3 00000002 00000075 [0061867428453667] 4.094ms (+0.001ms): enqueue_task+0xa/0x80 <c010f60a> (__schedule+0x1eb/0x710 <c02a7d3b>)
(T4/#118) [ => kswapd0 ] 4.095ms (+0.002ms)
(T1/#119) <...> 2 0 1 00000002 00000077 [0061867428455634] 4.098ms (+0.001ms): __switch_to+0xb/0x1a0 <c01013bb> (__schedule+0x329/0x710 <c02a7e79>)
(T3/#120) <...>-2 0d..2 4100us : __schedule+0x356/0x710 <c02a7ea6> <kswapd0-66> (74 69):
(T1/#121) <...> 2 0 1 00000001 00000079 [0061867428457287] 4.100ms (+0.000ms): trace_stop_sched_switched+0xa/0x150 <c012f83a> (__schedule+0x38d/0x710 <c02a7edd>)
(T3/#122) <...>-2 0d..1 4101us : trace_stop_sched_switched+0x42/0x150 <c012f872> <<...>-2> (69 0):
(T1/#123) <...> 2 0 1 00000001 0000007b [0061867428458566] 4.102ms (+0.000ms): trace_stop_sched_switched+0xfe/0x150 <c012f92e> (__schedule+0x38d/0x710 <c02a7edd>)
vim:ft=help
Lee
* Lee Revell <[email protected]> wrote:
> Running for several days with PREEMPT_DESKTOP, on the Athlon XP the
> worst latency I am seeing is ~150 usecs! But on the C3 its about 4ms:
could you run a bit with tracing disabled (in the .config) on the C3?
(but wakeup timing still enabled) It may very well be tracing overhead
that makes those latencies that high. Also, we'd thus have some hard
data on how much overhead tracing is in such a situation, on that CPU.
Ingo
On Fri, 2005-03-25 at 15:59 +0100, Ingo Molnar wrote:
> i have released the -V0.7.41-10 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
Ingo,
-15 has a typo that prevents building with my config.
Lee
--- include/linux/mm.h~ 2005-03-29 17:28:57.000000000 -0500
+++ include/linux/mm.h 2005-03-29 17:30:05.000000000 -0500
@@ -845,7 +845,7 @@
#else
static inline int check_no_locks_freed(const void *from, const void *to)
{
- return 0
+ return 0;
}
#endif
On Sun, 2005-03-27 at 10:58 +0200, Ingo Molnar wrote:
> * Lee Revell <[email protected]> wrote:
>
> > Running for several days with PREEMPT_DESKTOP, on the Athlon XP the
> > worst latency I am seeing is ~150 usecs! But on the C3 its about 4ms:
>
> could you run a bit with tracing disabled (in the .config) on the C3?
> (but wakeup timing still enabled) It may very well be tracing overhead
> that makes those latencies that high. Also, we'd thus have some hard
> data on how much overhead tracing is in such a situation, on that CPU.
>
I have not left it to run overnight yet with the swappiness set to 100,
which triggers the biggest latencies as my entire desktop is swapped
out, but so far it looks like the problem was tracing overhead. With
timing enabled but tracing disabled the longest latency on the C3 so far
is 270 usecs.
An important giveaway is that with tracing enabled the same code path
only triggers ~200 usec latencies on the K7 but ~2ms on the C3. Since
the longest latency with PREEMPT_DESKTOP is normally more a function of
memory bandwidth than processor speed, and the machines differ much more
in the latter, this agrees with the theory that the overhead is the
problem.
Lee
* Lee Revell <[email protected]> wrote:
> > could you run a bit with tracing disabled (in the .config) on the C3?
> > (but wakeup timing still enabled) It may very well be tracing overhead
> > that makes those latencies that high. Also, we'd thus have some hard
> > data on how much overhead tracing is in such a situation, on that CPU.
>
> I have not left it to run overnight yet with the swappiness set to
> 100, which triggers the biggest latencies as my entire desktop is
> swapped out, but so far it looks like the problem was tracing
> overhead. With timing enabled but tracing disabled the longest
> latency on the C3 so far is 270 usecs.
>
> An important giveaway is that with tracing enabled the same code path
> only triggers ~200 usec latencies on the K7 but ~2ms on the C3. Since
> the longest latency with PREEMPT_DESKTOP is normally more a function
> of memory bandwidth than processor speed, and the machines differ much
> more in the latter, this agrees with the theory that the overhead is
> the problem.
besides cycle overhead, function tracing increases cache footprint - and
with a CPU that has smaller caches (such as the C3) it can tip a loop
over the edge, and can make it cache-trashing, while it would fit into
the cache before. In such a situation the difference can be dramatic.
(on CPUs with larger caches similar artifacts can happen too, but it
needs a 'fatter' loop, which are apparently rarer.)
Ingo
* Lee Revell <[email protected]> wrote:
> On Fri, 2005-03-25 at 15:59 +0100, Ingo Molnar wrote:
> > i have released the -V0.7.41-10 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
>
> Ingo,
>
> -15 has a typo that prevents building with my config.
>
> Lee
>
> --- include/linux/mm.h~ 2005-03-29 17:28:57.000000000 -0500
> +++ include/linux/mm.h 2005-03-29 17:30:05.000000000 -0500
> @@ -845,7 +845,7 @@
> #else
> static inline int check_no_locks_freed(const void *from, const void *to)
> {
> - return 0
> + return 0;
thanks - applied this to 41-20.
Ingo
i have released the -V0.7.41-25 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
this release tries to stabilize things some more. In particular i've
changed 'nocheck' semaphores to not be included in any PI or debugging
logic. This makes them pretty much stateless and compatible. XFS seems
to be working much better with this approach, and maybe some of the
other problematic subsystems (USB/firewire) will improve too.
there's also a latency tracer fix which should cure some of the
'truncated traces' problems.
i've also included Trond Myklebust's NFS client patch which should
reduce latencies in that area (on PREEMPT_DESKTOP/VOLUNTARY kernels -
under PREEMPT_RT the whole NFS code was fully preemptable already).
It's experimental so be careful if you are using NFS.
to create a -V0.7.41-25 tree from scratch, the patching order is:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc1.bz2
http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc1-V0.7.41-25
Ingo
> i have released the -V0.7.41-25 Real-Time Preemption patch,
> which can be
> downloaded from the usual place:
1. Does not compile without RT_DEADLOCK_DETECT:
kernel/rt.c: In function `change_owner':
kernel/rt.c:556: error: structure has no member named `debug'
kernel/rt.c: In function `pi_setprio':
kernel/rt.c:576: error: structure has no member named `debug'
kernel/rt.c: In function `task_blocks_on_lock':
kernel/rt.c:677: error: structure has no member named `debug'
kernel/rt.c:687: error: structure has no member named `debug'
kernel/rt.c: In function `__up_mutex':
kernel/rt.c:1223: error: structure has no member named `debug'
2. My problem (see my LKML mails yesterday) is not yet solved:
The latency tracer shows latencies of at most 40 microseconds,
but my test program at rtprio 99 sometimes did not get any CPU
for milliseconds...
--
Klaus Kusche
Entwicklung Software - Steuerung
Software Development - Control
KEBA AG
A-4041 Linz
Gewerbepark Urfahr
Tel +43 / 732 / 7090-3120
Fax +43 / 732 / 7090-8919
E-Mail: [email protected]
http://www.keba.com
* kus Kusche Klaus <[email protected]> wrote:
> > i have released the -V0.7.41-25 Real-Time Preemption patch,
> > which can be
> > downloaded from the usual place:
>
> 1. Does not compile without RT_DEADLOCK_DETECT:
> kernel/rt.c: In function `change_owner':
> kernel/rt.c:556: error: structure has no member named `debug'
ok - i fixed this in -42-01.
> 2. My problem (see my LKML mails yesterday) is not yet solved: The
> latency tracer shows latencies of at most 40 microseconds, but my test
> program at rtprio 99 sometimes did not get any CPU for milliseconds...
(please Cc: me on PREEMPT_RT related mails - i might not notice lkml
mails.) I'll reply to your lkml mail in a separate thread.
Ingo
i have released the -V0.7.43-00 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
this release too is a step towards more robustness. I found a bug that
caused an infinite recursion and subsequent spontaneous reboot. The bug
was once again related to lock->debug locks, so i decided to get rid of
them altogether: from now on every lock in the -RT domain is debugged.
To be able to use code that relies on incompatible properties of stock
Linux semaphores (and rwsems), i've added a new compile-time
semaphore-type mechanism that enables the easy switching from RT
semaphores to stock semaphores. I've done this conversion for all
subsystems that needed it - e.g. XFS, firewire, USB and SCSI. XFS seems
to be working much better with this approach - BYMMV.
but an unavoidable side-effect is that the whole codebase got turned
upside down once again, so be careful and expect a few rough edges. In
particular keep an eye on new compile-time warnings related to
semaphores - code that gives a warning might build but it will almost
certainly not work.
to create a -V0.7.43-00 tree from scratch, the patching order is:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc1.bz2
http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc1-V0.7.43-00
Ingo
>
> 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]
* Rui Nuno Capela <[email protected]> wrote:
> > 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:
> 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
thx - i've uploaded -43-01 which should fix this.
Ingo
>
> 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]
* Rui Nuno Capela <[email protected]> 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?
Ingo
> * 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]
* Rui Nuno Capela <[email protected]> wrote:
> >> needs unknown symbol __compat_down_failed_interruptible
>
> Nope. Same error output as last report.
does -43-04 work for you?
Ingo
On Friday 01 April 2005 05:47, Ingo Molnar wrote:
>i have released the -V0.7.43-00 Real-Time Preemption patch, which
> can be downloaded from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
>this release too is a step towards more robustness. I found a bug
> that caused an infinite recursion and subsequent spontaneous
> reboot. The bug was once again related to lock->debug locks, so i
> decided to get rid of them altogether: from now on every lock in
> the -RT domain is debugged.
>
>To be able to use code that relies on incompatible properties of
> stock Linux semaphores (and rwsems), i've added a new compile-time
> semaphore-type mechanism that enables the easy switching from RT
> semaphores to stock semaphores. I've done this conversion for all
> subsystems that needed it - e.g. XFS, firewire, USB and SCSI. XFS
> seems to be working much better with this approach - BYMMV.
>
>but an unavoidable side-effect is that the whole codebase got turned
>upside down once again, so be careful and expect a few rough edges.
> In particular keep an eye on new compile-time warnings related to
> semaphores - code that gives a warning might build but it will
> almost certainly not work.
>
>to create a -V0.7.43-00 tree from scratch, the patching order is:
>
> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
I use the .gz, more reliable unpacks
> http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc1.bz
>2
Again I use the .gz
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-r
>c1-V0.7.43-00
>
> Ingo
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts output:
-------------------
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file lib/rwsem-spinlock.c
Hunk #5 FAILED at 133.
Hunk #6 FAILED at 160.
Hunk #7 FAILED at 179.
Hunk #8 FAILED at 194.
Hunk #9 FAILED at 204.
Hunk #10 FAILED at 231.
Hunk #11 FAILED at 250.
Hunk #12 FAILED at 265.
Hunk #13 FAILED at 274.
Hunk #14 FAILED at 293.
Hunk #15 FAILED at 314.
11 out of 15 hunks FAILED -- saving rejects to file
lib/rwsem-spinlock.c.rej
-----------
I doubt it would run, so I haven't built it. Should I?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
* K.R. Foley <[email protected]> wrote:
> >This one didn't go in cleanly Ingo. From my build-src scripts output:
> >-------------------
> >Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
> Adding the attached patch on top of the above should resolve the
> failures, at least in the patching. Still working on building it.
i fixed these things up in -43-05 ... i hope :-|
Ingo
Gene Heskett wrote:
<snip>
> It was up to 43-04 by the time I got there.
>
> This one didn't go in cleanly Ingo. From my build-src scripts output:
> -------------------
> Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
> [...]
> patching file lib/rwsem-spinlock.c
> Hunk #5 FAILED at 133.
> Hunk #6 FAILED at 160.
> Hunk #7 FAILED at 179.
> Hunk #8 FAILED at 194.
> Hunk #9 FAILED at 204.
> Hunk #10 FAILED at 231.
> Hunk #11 FAILED at 250.
> Hunk #12 FAILED at 265.
> Hunk #13 FAILED at 274.
> Hunk #14 FAILED at 293.
> Hunk #15 FAILED at 314.
> 11 out of 15 hunks FAILED -- saving rejects to file
> lib/rwsem-spinlock.c.rej
> -----------
> I doubt it would run, so I haven't built it. Should I?
>
Adding the attached patch on top of the above should resolve the
failures, at least in the patching. Still working on building it.
--
kr
On Friday 01 April 2005 13:27, K.R. Foley wrote:
>Gene Heskett wrote:
><snip>
>
>> It was up to 43-04 by the time I got there.
>>
>> This one didn't go in cleanly Ingo. From my build-src scripts
>> output: -------------------
>> Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
>> [...]
>> patching file lib/rwsem-spinlock.c
>> Hunk #5 FAILED at 133.
>> Hunk #6 FAILED at 160.
>> Hunk #7 FAILED at 179.
>> Hunk #8 FAILED at 194.
>> Hunk #9 FAILED at 204.
>> Hunk #10 FAILED at 231.
>> Hunk #11 FAILED at 250.
>> Hunk #12 FAILED at 265.
>> Hunk #13 FAILED at 274.
>> Hunk #14 FAILED at 293.
>> Hunk #15 FAILED at 314.
>> 11 out of 15 hunks FAILED -- saving rejects to file
>> lib/rwsem-spinlock.c.rej
>> -----------
>> I doubt it would run, so I haven't built it. Should I?
>
>Adding the attached patch on top of the above should resolve the
>failures, at least in the patching. Still working on building it.
I assume you mean apply before the 43-04 patch?
I'll give it a go later today, right now I've got dirt to move in the
yard.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Friday 01 April 2005 13:29, Ingo Molnar wrote:
>* K.R. Foley <[email protected]> wrote:
>> >This one didn't go in cleanly Ingo. From my build-src scripts
>> > output: -------------------
>> >Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
>>
>> Adding the attached patch on top of the above should resolve the
>> failures, at least in the patching. Still working on building it.
>
>i fixed these things up in -43-05 ... i hope :-|
>
> Ingo
Ok, I'll try that later today too. Got dirt to move in the yard,
decent weather for a change & the old farts gotta get his
exersize :-)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Gene Heskett wrote:
> On Friday 01 April 2005 13:27, K.R. Foley wrote:
>
>>Gene Heskett wrote:
>><snip>
>>
>>>It was up to 43-04 by the time I got there.
>>>
>>>This one didn't go in cleanly Ingo. From my build-src scripts
>>>output: -------------------
>>>Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
>>>[...]
>>>patching file lib/rwsem-spinlock.c
>>>Hunk #5 FAILED at 133.
>>>Hunk #6 FAILED at 160.
>>>Hunk #7 FAILED at 179.
>>>Hunk #8 FAILED at 194.
>>>Hunk #9 FAILED at 204.
>>>Hunk #10 FAILED at 231.
>>>Hunk #11 FAILED at 250.
>>>Hunk #12 FAILED at 265.
>>>Hunk #13 FAILED at 274.
>>>Hunk #14 FAILED at 293.
>>>Hunk #15 FAILED at 314.
>>>11 out of 15 hunks FAILED -- saving rejects to file
>>>lib/rwsem-spinlock.c.rej
>>>-----------
>>>I doubt it would run, so I haven't built it. Should I?
>>
>>Adding the attached patch on top of the above should resolve the
>>failures, at least in the patching. Still working on building it.
>
>
> I assume you mean apply before the 43-04 patch?
No actually I meant to apply it after the 43-04 patch. However, Ingo has
a new patch that should cover this also.
>
> I'll give it a go later today, right now I've got dirt to move in the
> yard.
>
--
kr
>
>> >> 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]
On Friday 01 April 2005 14:22, K.R. Foley wrote:
>Gene Heskett wrote:
>> On Friday 01 April 2005 13:27, K.R. Foley wrote:
>>>Gene Heskett wrote:
>>><snip>
>>>
>>>>It was up to 43-04 by the time I got there.
>>>>
>>>>This one didn't go in cleanly Ingo. From my build-src scripts
>>>>output: -------------------
>>>>Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
>>>>[...]
>>>>patching file lib/rwsem-spinlock.c
>>>>Hunk #5 FAILED at 133.
>>>>Hunk #6 FAILED at 160.
>>>>Hunk #7 FAILED at 179.
>>>>Hunk #8 FAILED at 194.
>>>>Hunk #9 FAILED at 204.
>>>>Hunk #10 FAILED at 231.
>>>>Hunk #11 FAILED at 250.
>>>>Hunk #12 FAILED at 265.
>>>>Hunk #13 FAILED at 274.
>>>>Hunk #14 FAILED at 293.
>>>>Hunk #15 FAILED at 314.
>>>>11 out of 15 hunks FAILED -- saving rejects to file
>>>>lib/rwsem-spinlock.c.rej
>>>>-----------
>>>>I doubt it would run, so I haven't built it. Should I?
>>>
>>>Adding the attached patch on top of the above should resolve the
>>>failures, at least in the patching. Still working on building it.
>>
>> I assume you mean apply before the 43-04 patch?
>
>No actually I meant to apply it after the 43-04 patch. However, Ingo
> has a new patch that should cover this also.
>
>> I'll give it a go later today, right now I've got dirt to move in
>> the yard.
3 hrs later, rained out, or in as the case may be. 43-05 is building
now, with lots of traceing turned on to see what sorts of grins I
might get out of it.
No one has commented about the loss of video in the tvtime/pcHDTV-3000
card situation, am I on my own, basicly reverting to the
pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?
------
2 friggin hours later, I'm finally rebooted. I start heyu in my
rc.local file by launching a series of scripts to set that all up,
and my cm-11a interface decided, for the first time in a couple
of years, to not talk to the 'heyu setclock' command. Boot hung,
but not of course until I'd used up half the boots per fsck on
100GB of disks. Grrrrroooowwff.
Anyway, now lets see what works.
tvtime doesn't, even if I re-install the drivers from the pcHDTV-2.0
archive. No video, just a blue screen, sound so-so.
kino works
xsane works
spcagui works
But, I did get some odd stuff in the logs while doing this as I had
a lot of traceing stuff turned on over and above the defaults:
Warning, this IS lengthy
---------------------------
Apr 1 18:05:13 coyote gconfd (root-5947): starting (version 2.6.0), pid 5947 user 'root'
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at position 0
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address "xml:readwrite:/root/.gconf" to a writable config source at position 1
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at position 2
Apr 1 18:05:19 coyote ieee1394.agent[6002]: ... no drivers for IEEE1394 product 0x/0x/0x
Apr 1 18:05:20 coyote kernel: ieee1394: raw1394: /dev/raw1394 device initialized
Apr 1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394 product 0x/0x/0x
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: ==========================================
Apr 1 18:05:24 coyote kernel: [ BUG: lock recursion deadlock detected! |
Apr 1 18:05:24 coyote kernel: ------------------------------------------
Apr 1 18:05:24 coyote kernel: already locked: [e4d17228] {(struct semaphore *)(&fi->complete_sem)}
Apr 1 18:05:24 coyote kernel: .. held by: kino: 6082 [e13ecbb0, 118]
Apr 1 18:05:24 coyote kernel: ... acquired at: raw1394_read+0x104/0x110 [raw1394]
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: ------------------------------
Apr 1 18:05:24 coyote kernel: | showing all locks held by: | (kino/6082 [e13ecbb0, 118]):
Apr 1 18:05:24 coyote kernel: ------------------------------
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: #001: [e4d17228] {(struct semaphore *)(&fi->complete_sem)}
Apr 1 18:05:24 coyote kernel: ... acquired at: raw1394_read+0x104/0x110 [raw1394]
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: -{current task's backtrace}----------------->
Apr 1 18:05:24 coyote kernel: [<c0103353>] dump_stack+0x23/0x30 (20)
Apr 1 18:05:24 coyote kernel: [<c013093e>] check_deadlock+0x2fe/0x320 (44)
Apr 1 18:05:24 coyote kernel: [<c01313b7>] task_blocks_on_lock+0x37/0xf0 (36)
Apr 1 18:05:24 coyote kernel: [<c0374987>] __down_interruptible+0x257/0x4f0 (88)
Apr 1 18:05:24 coyote kernel: [<c0132cba>] rt_down_interruptible+0xba/0x1f0 (48)
Apr 1 18:05:24 coyote kernel: [<f8c9d8f4>] raw1394_read+0x104/0x110 [raw1394] (32)
Apr 1 18:05:24 coyote kernel: [<c015d45d>] vfs_read+0xcd/0x140 (36)
Apr 1 18:05:24 coyote kernel: [<c015d750>] sys_read+0x50/0x80 (44)
Apr 1 18:05:24 coyote kernel: [<c0102cf8>] sysenter_past_esp+0x61/0x89 (-4028)
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: showing all tasks:
Apr 1 18:05:24 coyote kernel: S init: 1 [c190d670, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S ksoftirqd/0: 2 [c190d0e0, 105] (not blocked)
Apr 1 18:05:24 coyote kernel: S desched/0: 3 [c190cb50, 105] (not blocked)
Apr 1 18:05:24 coyote kernel: S events/0: 4 [c190c5c0, 98] (not blocked)
Apr 1 18:05:24 coyote kernel: S khelper: 5 [c190c030, 112] (not blocked)
Apr 1 18:05:24 coyote kernel: S kthread: 10 [c192d690, 110] (not blocked)
Apr 1 18:05:24 coyote kernel: S kacpid: 19 [c192d100, 120] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 9: 20 [c192cb70, 50] (not blocked)
Apr 1 18:05:24 coyote kernel: S kblockd/0: 147 [c192c5e0, 110] (not blocked)
Apr 1 18:05:24 coyote kernel: S khubd: 160 [c192c050, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S pdflush: 220 [c1b796b0, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S pdflush: 221 [c1b79120, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S aio/0: 223 [c1b78600, 112] (not blocked)
Apr 1 18:05:24 coyote kernel: S kswapd0: 222 [c1b78b90, 125] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 8: 808 [f7c3f6d0, 51] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 0: 820 [f7c3f140, 52] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 6: 840 [f7c3ebb0, 53] (not blocked)
Apr 1 18:05:24 coyote kernel: S kseriod: 812 [c1b78070, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 14: 859 [f7c3e620, 54] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 15: 861 [f7c3e090, 55] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 12: 883 [f7cae0b0, 56] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 11: 888 [f7ccd710, 57] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 5: 892 [f7ccd180, 58] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 1: 944 [f7d35240, 59] (not blocked)
Apr 1 18:05:24 coyote kernel: S kjournald: 949 [f7d2a700, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S kjournald: 1432 [f7e477f0, 120] (not blocked)
Apr 1 18:05:24 coyote kernel: S kjournald: 1433 [f7f13930, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S kjournald: 1434 [f7d34cb0, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S kjournald: 1435 [f7d1c150, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S kjournald: 1436 [f7d1d200, 120] (not blocked)
Apr 1 18:05:24 coyote kernel: S kjournald: 1437 [f7d1c6e0, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S kjournald: 1438 [f7d2b7b0, 120] (not blocked)
Apr 1 18:05:24 coyote kernel: S khpsbpkt: 1496 [f7d2b220, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S knodemgrd_0: 1557 [f7fc8940, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 4: 1614 [f7d2ac90, 60] (not blocked)
Apr 1 18:05:24 coyote kernel: S IRQ 3: 1615 [f7f8c920, 61] (not blocked)
Apr 1 18:05:24 coyote kernel: S syslogd: 1921 [f7e46cd0, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S klogd: 1925 [f7d357d0, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S portmap: 1936 [f7caf6f0, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S rpc.statd: 1955 [f7f8ceb0, 121] (not blocked)
Apr 1 18:05:24 coyote kernel: S nscd: 1992 [f7e46740, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S nscd: 1993 [f7fc83b0, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S nscd: 1994 [f7caf160, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S nscd: 1995 [f7fc99f0, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S nscd: 1996 [f7fc8ed0, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S nscd: 1997 [f7fc9460, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S ntpd: 2012 [f7caebd0, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S mount.smbfs: 2022 [f7cccbf0, 119] (not blocked)
Apr 1 18:05:24 coyote kernel: S smbiod: 2024 [f7ccc0d0, 115] (not blocked)
Apr 1 18:05:24 coyote kernel: S mount.smbfs: 2027 [f7d2a170, 121] (not blocked)
Apr 1 18:05:24 coyote kernel: S identd: 2037 [f7d34190, 123] (not blocked)
Apr 1 18:05:24 coyote kernel: S identd: 2044 [f7cae640, 124] (not blocked)
Apr 1 18:05:24 coyote kernel: S identd: 2045 [f7f26e30, 123] (not blocked)
Apr 1 18:05:24 coyote kernel: S identd: 2046 [f7f27950, 123] (not blocked)
Apr 1 18:05:24 coyote kernel: S smartd: 2054 [f7d34720, 122] (not blocked)
Apr 1 18:05:24 coyote kernel: S arpwatch: 2063 [f7f268a0, 116] (not blocked)
Apr 1 18:05:24 coyote kernel: S sshd: 2074 [f7e461b0, 120] (not blocked)
Apr 1 18:05:24 coyote kernel: S xinetd: 2089 [f7e47260, 117] (not blocked)
Apr 1 18:05:24 coyote kernel: S rpc.rquotad: 2102 [f7f273c0, 119] (not blocked)
Apr 1 18:05:24 coyote kernel: S nfsd: 2106 [f7f8c390, 120] (not blocked)
Apr 1 18:05:24 coyote kernel: S nfsd: 2107 [f7f8d9d0, 119] (not blocked)
Apr 1 18:05:24 coyote kernel: S nfsd: 2108 [f7f12880, 119] (not blocked)
Apr 1 18:05:24 coyote kernel: S nfsd: 2109 [f7f133a0, 119] (not blocked)
Apr 1 18:05:24 coyote kernel: S nfsd: 2110 [f7f12e10, 119] (not blocked)
Apr 1 18:05:24 coyote kernel: S nfsd: 2111 [f7d1d790, 120] (not blocked)
Apr 1 18:05:24 coyote kernel: S nfsd: 2112 [f7d1cc70, 120] (not blocked)
Apr 1 18:05:24 coyote kernel: S nfsd: 2113 [f6db7a30, 120] (not blocked)
Apr 1 18:05:24 coyote kernel: S lockd: 2117 [f6db74a0, 122] (not blocked)
Apr 1 18:05:24 coyote kernel: S rpciod/0: 2118 [f6db6f10, 111] (not blocked)
Apr 1 18:05:24 coyote kernel: S rpc.mountd: 2119 [f6db6980, 121] (not blocked)
Apr 1 18:05:24 coyote kernel: S rpc.rstatd: 2148 [f7f26310, 122] (not blocked)
Apr 1 18:05:24 coyote kernel: S S61xprint: 2261 [f6df4410, 121] (not blocked)
Apr 1 18:05:24 coyote kernel: S S61xprint: 2264 [f6e7f0e0, 124] (not blocked)
Apr 1 18:05:24 coyote kernel: S S61xprint: 2267 [f6df5a50, 120] (not blocked)
Apr 1 18:05:24 coyote kernel: S Apr 1 18:05:13 coyote gconfd (root-5947): starting (version 2.6.0), pid 5947 user 'root'
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at position 0
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address "xml:readwrite:/root/.gconf" to a writable config source at position 1
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at position 2
Apr 1 18:05:19 coyote ieee1394.agent[6002]: ... no drivers for IEEE1394 product 0x/0x/0x
Apr 1 18:05:20 coyote kernel: ieee1394: raw1394: /dev/raw1394 device initialized
Apr 1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394 product 0x/0x/0x
[...]
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: ==========================================
Apr 1 18:05:24 coyote kernel: [ BUG: lock recursion deadlock detected! |
Apr 1 18:05:24 coyote kernel: ------------------------------------------
[...snip copy]
[...snip copy]
Apr 1 18:05:26 coyote kernel: #042: [c045fa00] {tasklist_lock}
Apr 1 18:05:26 coyote kernel: .. held by: kino: 6082 [e13ecbb0, 118]
Apr 1 18:05:26 coyote kernel: ... acquired at: show_all_locks+0x30/0x130
Apr 1 18:05:26 coyote kernel: =============================================
Apr 1 18:05:26 coyote kernel:
Apr 1 18:05:26 coyote kernel: [ turning off deadlock detection. Please report this trace. ]
Apr 1 18:05:26 coyote kernel:
Apr 1 18:05:43 coyote gconfd (root-5947): GConf server is not in use, shutting down.
Apr 1 18:05:43 coyote gconfd (root-5947): Exiting
Apr 1 18:08:33 coyote kernel: /usr/src/spca-stf/spca5xx-20050206/drivers/usb/spca50x.c: USB SPCA5XX camera found.Type Labtec Webcam Pro Zc0302 + Hdcs2020
Apr 1 18:08:33 coyote kernel: /usr/src/spca-stf/spca5xx-20050206/drivers/usb/spca50x.c: [spca50x_probe:7258] Camera type JPEG
Apr 1 18:08:33 coyote kernel: usbcore: registered new driver spca50x
Apr 1 18:08:33 coyote kernel: /usr/src/spca-stf/spca5xx-20050206/drivers/usb/spca50x.c: spca5xx driver 56.02.06 registered
Apr 1 18:08:33 coyote kernel: /usr/src/spca-stf/spca5xx-20050206/drivers/usb/zc3xx.h: [zc3xx_init:231] Find Sensor HDCS2020
Apr 1 18:08:33 coyote kernel: /usr/src/spca-stf/spca5xx-20050206/drivers/usb/spca50x.c: init isoc: usb_submit_urb(0) ret -28
Apr 1 18:08:47 coyote kernel: ohci_hcd 0000:00:02.1: bad entry 37ce6440
[e9d36d08] {(struct semaphore *)(&tty->atomic_write)}
--------------------------------
There are several sets of duplicate entries above, and to took
the liberty of clipping some of them back out, almost as if
the logging got stuck in a loop.
But, I only started kino once. And switched it to capture mode after
starting, once, and shut it down once.
And, as far as getting video from the camera and displaying it on screen,
that was fine ANAICT.
Make of this what you can. It certainly looks unusual to me.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote:
> No one has commented about the loss of video in the tvtime/pcHDTV-3000
> card situation, am I on my own, basicly reverting to the
> pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?
You didn't really give much of a clue as to where to start looking.
If you report a bug of the "hardware foo stopped working with kernel
bar" type, and that's all the information you provide, the bug report is
useless to anyone who does not have the exact same hardware.
Lee
On Friday 01 April 2005 20:45, Lee Revell wrote:
>On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote:
>> No one has commented about the loss of video in the
>> tvtime/pcHDTV-3000 card situation, am I on my own, basicly
>> reverting to the
>> pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?
>
>You didn't really give much of a clue as to where to start looking.
>
>If you report a bug of the "hardware foo stopped working with kernel
>bar" type, and that's all the information you provide, the bug
> report is useless to anyone who does not have the exact same
> hardware.
>
>Lee
I did, in a previous incarnation of this thread 2-3 days ago, post the
lsmod output and a section of the log showing (I believe) rampant dma
failures. It also didn't generate any comments.
FWIW, I have reinstalled the tarballs version of the drivers, but that
was of no use, so its definitely something in the RT patch itself I
believe. 2.6.12-rc1 works great. By default.
As far as my being able to fix that, I'm afraid I'll have to plead
NDI. The last time I dealt with dma, was on an rca 1802 cpu, which
had its own builtin dma controller that took care of everything but
the pointer reload for the next 6 byte fetch, and which I used for 6
bytes per field of video to feed a homebrewed character generator I
made out of ttl chips, to generate the academy leader on a
commercial. The year was 1978. A bit far back up the log for even
me, altho I may still have a copy of the machine code I wrote that
ran it at KRCR-TV in Redding CA for a decade that I know of, maybe
longer.
That is neither here nor there now of course, just shining a light
back up the calendar about 27 years for illustration.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
* Gene Heskett <[email protected]> wrote:
> Apr 1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394 product 0x/0x/0x
> Apr 1 18:05:24 coyote kernel:
> Apr 1 18:05:24 coyote kernel: ==========================================
> Apr 1 18:05:24 coyote kernel: [ BUG: lock recursion deadlock detected! |
> Apr 1 18:05:24 coyote kernel: ------------------------------------------
> Apr 1 18:05:24 coyote kernel: already locked: [e4d17228] {(struct semaphore *)(&fi->complete_sem)}
> Apr 1 18:05:24 coyote kernel: .. held by: kino: 6082 [e13ecbb0, 118]
> Apr 1 18:05:24 coyote kernel: ... acquired at: raw1394_read+0x104/0x110 [raw1394]
hm - does the patch below help? (or -43-06 which has the same patch)
Ingo
--- linux/drivers/ieee1394/raw1394-private.h.orig
+++ linux/drivers/ieee1394/raw1394-private.h
@@ -29,7 +29,7 @@ struct file_info {
struct list_head req_pending;
struct list_head req_complete;
- struct semaphore complete_sem;
+ struct compat_semaphore complete_sem;
spinlock_t reqlists_lock;
wait_queue_head_t poll_wait_complete;
Hi Ingo,
I've discovered a problem with basically all "yields" in the kernel. But
that's not why I'm writing you this. To see if your kernel has the same
problems as mine, I wrote a modified test that caused me the problems,
and ran it on your kernel. But too my surprise, this test caused other
problems. This modified test causes my kernel the same types of problems
too.
Attached is the test I ran. The list.h is just my version of the kernels
list functions for userspace. It's used in the test program.
What the test program does, is spawn 5 processes, each with a different
priority. Starting with 10 and going to 14. All are SCHED_FIFO. Each of
these processes just do a scan of all directories starting with the root
directory '/' and going down. I usually run this with a directory NFS
mounted too, but I don't think this was a problem.
Here's the bug I get:
Slab corruption: start=cfc45938, len=276
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<c0142b1d>](mempool_free+0x9d/0xb0)
050: 68 9a 3e c0 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Prev obj: start=cfc45818, len=276
Redzone: 0x170fc2a5/0x170fc2a5.
Last user: [<c01426a8>](mempool_create+0xe8/0x120)
000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
010: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
Next obj: start=cfc45a58, len=276
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<00000000>](0x0)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
BUG at kernel/timer.c:419!
------------[ cut here ]------------
kernel BUG at kernel/timer.c:419!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in:
CPU: 0
EIP: 0060:[<c012142d>] Not tainted VLI
EFLAGS: 00010282 (2.6.12-rc1-RT-V0.7.43-06)
EIP is at cascade+0x6d/0x80
eax: 0000001e ebx: c03e9a90 ecx: 00000000 edx: c0118720
esi: c03e9a68 edi: c03e9a90 ebp: c1273f44 esp: c1273f2c
ds: 007b es: 007b ss: 0068 preempt: 00000001
Process ksoftirqd/0 (pid: 2, threadinfo=c1272000 task=cffed260)
Stack: c0387e66 c0389ef9 000001a3 00000000 c03e9878 c1273f60 c1273f78 c0121bae
c03e9080 c03e98f0 0000002f 00000000 c1272000 c1273f60 c1273f60 c0112643
00000005 c1272000 00000000 c1273fa0 c011d45a c04f3e28 c1272000 cffeff00
Call Trace:
[<c0103bef>] show_stack+0x8f/0xb0 (28)
[<c0103daa>] show_registers+0x16a/0x1d0 (56)
[<c0103fc6>] die+0xf6/0x190 (64)
[<c01044e1>] do_invalid_op+0xc1/0xd0 (204)
[<c010381b>] error_code+0x2b/0x30 (84)
[<c0121bae>] run_timer_softirq+0x2ae/0x420 (52)
[<c011d45a>] ___do_softirq+0x9a/0x100 (40)
[<c011d579>] _do_softirq+0x29/0x30 (8)
[<c011da41>] ksoftirqd+0xb1/0x130 (20)
[<c012de1a>] kthread+0xaa/0xb0 (48)
[<c0100e35>] kernel_thread_helper+0x5/0x10 (1054392340)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c0103f13>] .... die+0x43/0x190
.....[<c01044e1>] .. ( <= do_invalid_op+0xc1/0xd0)
.. [<c0137b8d>] .... print_traces+0x1d/0x60
.....[<c0103bef>] .. ( <= show_stack+0x8f/0xb0)
Code: 76 04 8b 45 10 83 c4 0c 5b 5e 5f 5d c3 c7 04 24 66 7e 38 c0 b8 a3 01 00 00 89 44 24 08 b8 f9 9e 38 c0 89 44 24 04 e8 d3 6e ff ff <0f> 0b a3 01 f9 9e 38 c0 eb b3 89 f6 8d bc 27 00 00 00 00 55 89
BUG: ksoftirqd/0/2, lock held at task exit time!
[c03e9080] {&base->lock}
.. held by: ksoftirqd/0: 2 [cffed260, 106]
... acquired at: run_timer_softirq+0x243/0x420
-- Steve
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
> Here's the bug I get:
>
FYI
For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
Grub option), and the system just locked up hard. I just was curious if
this was from a different change. But at least in the latest it shows
output, and not just a hard lockup.
Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06.
-- Steve
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
> What the test program does, is spawn 5 processes, each with a different
> priority. Starting with 10 and going to 14. All are SCHED_FIFO. Each of
> these processes just do a scan of all directories starting with the root
> directory '/' and going down. I usually run this with a directory NFS
> mounted too, but I don't think this was a problem.
My knowledge of the kernel is still pretty limited, but it looks to me
like something corrupted the timer list.
Have you tried kdb? Last time I checked it worked great with
PREEMPT_RT.
Lee
On Sat, 2005-04-02 at 15:06 -0500, Steven Rostedt wrote:
> On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
>
> > Here's the bug I get:
> >
>
> FYI
>
> For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
> Grub option), and the system just locked up hard. I just was curious if
> this was from a different change. But at least in the latest it shows
> output, and not just a hard lockup.
I had the same results yesterday, while punishing the swap by building
the kernel with make -j64 over NFS. It thrashed wildly for 20 minutes
or so then eventually all disk activity stopped. Of course that stupid
cow continued bouncing up and down...
It wasn't clear from your last mail whether you were using NFS. If so I
would be suspicious given the NFS changes in the new RT patches. I'll
try to reproduce the problem on a local fs.
Lee
* Steven Rostedt <[email protected]> wrote:
> On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
>
> > Here's the bug I get:
> >
>
> FYI
>
> For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
> Grub option), and the system just locked up hard. I just was curious
> if this was from a different change. But at least in the latest it
> shows output, and not just a hard lockup.
>
> Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06.
ok, so it's not the recent NFS changes.
Ingo
* Lee Revell <[email protected]> wrote:
> It wasn't clear from your last mail whether you were using NFS. If so
> I would be suspicious given the NFS changes in the new RT patches.
> I'll try to reproduce the problem on a local fs.
also, try to undo the fs/nfs/*.c and include/linux/*nfs*.h changes,
those are latency breakers, so not strictly necessary.
Ingo
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[email protected]> wrote:
>
> > On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
> >
> > > Here's the bug I get:
> > >
> >
> > FYI
> >
> > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
> > Grub option), and the system just locked up hard. I just was curious
> > if this was from a different change. But at least in the latest it
> > shows output, and not just a hard lockup.
> >
> > Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06.
>
> ok, so it's not the recent NFS changes.
>
I may need to take this back. I forgot to open the serial, so it wasn't
accepting input. So it would just appear dead. And the console was
fighting against the RT tasks, so it too would seem to be dead. I've
reran the test on the latest, but this time I didn't have the NFS
mounted, and it's still running.
-- Steve
On Sat, 2005-04-02 at 15:44 -0500, Steven Rostedt wrote:
> On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
> > >
> > > FYI
> > >
> > > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
> > > Grub option), and the system just locked up hard. I just was curious
> > > if this was from a different change. But at least in the latest it
> > > shows output, and not just a hard lockup.
> > >
> > > Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06.
> >
> > ok, so it's not the recent NFS changes.
> >
>
> I may need to take this back. I forgot to open the serial, so it wasn't
> accepting input. So it would just appear dead. And the console was
> fighting against the RT tasks, so it too would seem to be dead. I've
> reran the test on the latest, but this time I didn't have the NFS
> mounted, and it's still running.
>
I tried the 2.6.12-rc1-RT-V0.7.43-06 kernel again, and I still have the
serial, to do sysrq. The console is using X which locks (even all the
ctrl-alt-X functions) and the ssh session that I run the test stops
after the processes try to grab the locks. It doesn't reply to ping. But
the sysrq from the serial shows constantly:
s test3_rt: 2269 [cf304690, 89] (not blocked)
s test3_rt: 2270 [cf304050, 88] (not blocked)
s test3_rt: 2271 [cef86cb0, 87] (not blocked)
s test3_rt: 2272 [cef86670, 86] (not blocked)
R test3_rt: 2273 [cf28a050, 85] (not blocked)
So it seems that it's in a deadlock somewhere. Since the 43-06 gets much
further, this seems to be another problem. I'm not going to look at this
problem anymore, since it doesn't show up in the lastest.
I'll run a few more tests to see if I can narrow things down on 43-06.
-- Steve
On Saturday 02 April 2005 15:34, Ingo Molnar wrote:
>* Lee Revell <[email protected]> wrote:
>> It wasn't clear from your last mail whether you were using NFS.
>> If so I would be suspicious given the NFS changes in the new RT
>> patches. I'll try to reproduce the problem on a local fs.
>
>also, try to undo the fs/nfs/*.c and include/linux/*nfs*.h changes,
>those are latency breakers, so not strictly necessary.
>
> Ingo
Hi Ingo;
I just got done rebooting to 43-06, had problems with my heyu
startup scripts again, but I finally found a missing & in one
of them, and I can have it recycle itself from the cli like it
used to again.
So far, with *all* the 'logit' switches turned on and in full
preempt mode, there's nothing unusual in the log.
Here goes tvtime from a cli:
Audio only, blue screen video, this in the log:
---------------
Apr 2 17:12:48 coyote kernel: cx88[0]: video y / packed - dma channel status dump
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: initial risc: 0x06b46000
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt base : 0x00180440
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt size : 0x0000000c
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq base : 0x00180400
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq size : 0x00000010
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: risc pc : 0x00000000
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq wr ptr : 0x00000000
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq rd ptr : 0x00000000
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt current : 0x00000000
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: pci target : 0x00000000
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: line / byte : 0x00000000
Apr 2 17:12:48 coyote kernel: cx88[0]: risc0: 0x00000000 [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc1: 0x00000000 [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc2: 0x00000000 [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc3: 0x00000000 [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 0: 0x80008000 [ sync resync count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 1: 0x1c000500 [ write sol eol count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 2: 0x06922000 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 3: 0x1c000500 [ write sol eol count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 4: 0x06922a00 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 5: 0x1c000500 [ write sol eol count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 6: 0x2dc68400 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 7: 0x18000200 [ write sol count=512 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 8: 0x2dc68e00 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 9: 0x14000300 [ write eol count=768 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq a: 0x2dc69000 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq b: 0x1c000500 [ write sol eol count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq c: 0x2dc69800 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq d: 0x0031c040 [ INVALID 21 20 cnt0 resync 14 count=64 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq e: 0x00000000 [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq f: 0x00000011 [ INVALID count=17 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: fifo: 0x00180c00 -> 0x183400
Apr 2 17:12:48 coyote kernel: cx88[0]: ctrl: 0x00180400 -> 0x180460
Apr 2 17:12:48 coyote kernel: cx88[0]: ptr1_reg: 0x00182118
Apr 2 17:12:48 coyote kernel: cx88[0]: ptr2_reg: 0x00180488
Apr 2 17:12:48 coyote kernel: cx88[0]: cnt1_reg: 0x00000082
Apr 2 17:12:48 coyote kernel: cx88[0]: cnt2_reg: 0x00000000
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5940/0] timeout - dma=0x00000000
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5d40/1] timeout - dma=0x00000000
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d417d960/2] timeout - dma=0x00000000
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5540/3] timeout - dma=0x06b46000
Apr 2 17:12:49 coyote kernel: cx88[0]: video y / packed - dma channel status dump
[...]
followed by many repeats of the above as I let it run about
5-6 seconds. On exit, this:
Apr 2 17:12:57 coyote kernel: rtc latency histogram of {tvtime/5717, 232 samples}:
Apr 2 17:12:57 coyote kernel: 20 4
Apr 2 17:12:57 coyote kernel: 21 81
Apr 2 17:12:57 coyote kernel: 22 64
Apr 2 17:12:57 coyote kernel: 23 32
Apr 2 17:12:57 coyote kernel: 24 13
Apr 2 17:12:57 coyote kernel: 25 2
Apr 2 17:12:57 coyote kernel: 26 8
Apr 2 17:12:57 coyote kernel: 27 2
Apr 2 17:12:57 coyote kernel: 28 3
Apr 2 17:12:57 coyote kernel: 29 1
Apr 2 17:12:57 coyote kernel: 30 1
Apr 2 17:12:57 coyote kernel: 32 2
Apr 2 17:12:57 coyote kernel: 33 2
Apr 2 17:12:57 coyote kernel: 34 1
Apr 2 17:12:57 coyote kernel: 35 1
Apr 2 17:12:57 coyote kernel: 37 1
Apr 2 17:12:57 coyote kernel: 9999 14
------------
dma timeouts. I don't get these, and I do get good video under 2.6.12-rc1
re-installing the pcHDTV-2.0 stuff doesn't help.
The rest of the stuff I usually check..
xsane ok
kino ok, only errors logged was because I started it before
turning the camera on :(
spcagui ok once spca50x was reinstalled, a few lines in the log:
-------------------
Apr 2 17:21:54 coyote kernel: /usr/src/spca-stf/spca5xx-20050206/drivers/usb/spca50x.c: USB SPCA5XX camera found. Type Labtec Webcam Pro Zc0302 + Hdcs2020
Apr 2 17:21:54 coyote kernel: /usr/src/spca-stf/spca5xx-20050206/drivers/usb/spca50x.c: [spca50x_probe:7258] Camera type JPEG
Apr 2 17:21:54 coyote kernel: usbcore: registered new driver spca50x
Apr 2 17:21:54 coyote kernel: /usr/src/spca-stf/spca5xx-20050206/drivers/usb/spca50x.c: spca5xx driver 56.02.06 registered
Apr 2 17:21:54 coyote kernel: /usr/src/spca-stf/spca5xx-20050206/drivers/usb/zc3xx.h: [zc3xx_init:231] Find Sensor HDCS2020
Apr 2 17:21:55 coyote kernel: /usr/src/spca-stf/spca5xx-20050206/drivers/usb/spca50x.c: init isoc: usb_submit_urb(0) ret -28
Apr 2 17:22:08 coyote kernel: ohci_hcd 0000:00:02.1: bad entry 37ce6580
-------------------
That last item was when I clicked the Q button I believe.
But it worked, albeit with a pretty decent cpu hit, 25% or so.
That cpu hit is nothing new, its the jpeg decoder I'm told.
This "feels good" so far, but I'd sure like to get tvtime working again.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
> > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
> > Grub option), and the system just locked up hard. I just was curious
> > if this was from a different change. But at least in the latest it
> > shows output, and not just a hard lockup.
> >
> > Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06.
>
> ok, so it's not the recent NFS changes.
Here's an interesting trace I got today. It looks either the emu10k1 or
USB irq handler left IRQ 10 disabled. This isn't a tracer bug because
you can clearly see this leads to an xrun. Since I've been hacking the
emu10k1 driver quite a bit, I suspect this is the problem.
This trace also shows that my trigger callback for the emu10k1
multichannel device needs optimizing; it takes 300 usecs to stop all 16
voices, not acceptable for an ALSA irq handler which uses SA_INTERRUPT.
I think I can improve this significantly by reordering the register
settings and eliminating some function call overhead.
Lee
On Sat, 2005-04-02 at 17:09 -0500, Steven Rostedt wrote:
> On Sat, 2005-04-02 at 15:44 -0500, Steven Rostedt wrote:
> > On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
> I tried the 2.6.12-rc1-RT-V0.7.43-06 kernel again, and I still have the
> serial, to do sysrq. The console is using X which locks (even all the
> ctrl-alt-X functions) and the ssh session that I run the test stops
> after the processes try to grab the locks. It doesn't reply to ping. But
> the sysrq from the serial shows constantly:
>
> s test3_rt: 2269 [cf304690, 89] (not blocked)
> s test3_rt: 2270 [cf304050, 88] (not blocked)
> s test3_rt: 2271 [cef86cb0, 87] (not blocked)
> s test3_rt: 2272 [cef86670, 86] (not blocked)
> R test3_rt: 2273 [cf28a050, 85] (not blocked)
>
>
> So it seems that it's in a deadlock somewhere. Since the 43-06 gets much
> further, this seems to be another problem. I'm not going to look at this
> problem anymore, since it doesn't show up in the lastest.
>
> I'll run a few more tests to see if I can narrow things down on 43-06.
Once again I spoke too soon. I got the same lockup with 43-06, it just
took a little more to do so. All I did differently was to put the test
into a while loop on the command line:
while : ; do test3_rs ; done
On the second iteration, it locked up in the same place as 36-02. But
this is a different issue than what I showed with a NFS mounted system.
That was a BUG where as this has something in a spinning loop somewhere.
The attached is the gzipped minicom capture. After the system locked
up, I was still able to get the serial input and do a few task dumps. I
did several and it clearly shows that the system is locked. What you
constantly see is:
R test3_rt: 2263 [cbd6b9b0, 116] (not blocked)
S test3_rt: 2264 [cc06d8d0, 89] (not blocked)
S test3_rt: 2265 [cc06c090, 88] (not blocked)
R test3_rt: 2266 [cc06ccb0, 87] (not blocked)
D test3_rt: 2267 [cc1286c0, 86] blocked on: [ce127650] {(struct
semaphore *)(&inode->i_sem)}
.. held by: test3_rt: 2268 [ce822760, 85]
... acquired at: vfs_readdir+0x53/0xa0
D test3_rt: 2268 [ce822760, 85] (not blocked)
Process 2263 started the run and has just released the semaphore, it was
preempted before getting to the wait and although still running, it is
not really part of the picture.
Process 2267 is blocked on 2268 which is sleeping at
fs/jbd/transaction.c:636 which is in do_get_write_access waiting (I
believe) for a transaction to finish. Probably for kjournald to run,
since it is also in the running state.
But the problem seems to be with 2266 where as it's trace shows:
test3_rt [cc06ccb0]R C0371AD6 [on rq] 6824 2266 2263 2267 2265 (NOTLB)
cadebc48 00000046 c04eea30 c0371ad6 00000000 00000001 00000016 c0371aa1
c0102d00 00000000 00000000 11de7305 071e89c0 00000071 cc06ccb0 cc06cde8
ffffffff cc06ccb0 cfae68d4 cadebc5c c0371ad6 10000000 cabc71ac cfae68d4
Call Trace:
[<c0371ad6>] preempt_schedule_irq+0x46/0x70 (20)
[<c0102d00>] need_resched+0x20/0x24 (-7260)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c03710df>] .... __schedule+0x4f/0x840
.....[<c0371ad6>] .. ( <= preempt_schedule_irq+0x46/0x70)
.. [<c0371179>] .... __schedule+0xe9/0x840
.....[<c0371ad6>] .. ( <= preempt_schedule_irq+0x46/0x70)
Which is not very helpful.
So it is probably stuck in some spinning "yield" loop, which was the
reason I was writing this test to begin with! It's most likely also
waiting for kjournald to do some work, and is starving it in a schedule
or yield loop never actually going to sleep letting kjournald do the
real work.
-- Steve
* Steven Rostedt <[email protected]> wrote:
> So it is probably stuck in some spinning "yield" loop, which was the
> reason I was writing this test to begin with! It's most likely also
> waiting for kjournald to do some work, and is starving it in a
> schedule or yield loop never actually going to sleep letting kjournald
> do the real work.
actually, what priorities do the yielding tasks have? sched_yield() does
not guarantee that the CPU will be given up, of if a highest-prio
SCHED_FIFO task is in a yield() loop it will livelock the system.
Ingo
On Mon, 2005-04-04 at 22:00 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[email protected]> wrote:
>
> > So it is probably stuck in some spinning "yield" loop, which was the
> > reason I was writing this test to begin with! It's most likely also
> > waiting for kjournald to do some work, and is starving it in a
> > schedule or yield loop never actually going to sleep letting kjournald
> > do the real work.
>
> actually, what priorities do the yielding tasks have? sched_yield() does
> not guarantee that the CPU will be given up, of if a highest-prio
> SCHED_FIFO task is in a yield() loop it will livelock the system.
>
What scares me is the code in fs/inode.c with that
__wait_on_freeing_inode. Look at the code in find_inode and
find_inode_fast. Here you will see that they really are busy loops with
a yield in them, if the inode they are waiting on is I_FREEING or
I_CLEAR and the process doing this hasn't set I_LOCK. I haven't looked
much at this, but my kernel has livelocked on it.
My custom kernel plays with dynamic priorities. That is tasks jump
around in their priorities based on different situations not part of the
normal linux kernel. So my kernel can find these cases easier since a
path where a process gets bumped up to a high priority happens more
often and causes preemption more often than the normal RT kernel. But
this situation can probably occur in the RT kernel and maybe even the
mainline kernel, since it only needs to have a RT FIFO task get blocked
here, and a lower priority task needing to run to change the state.
Currently my fix is in yield to lower the priority of the task calling
yield and raise it after the schedule. This is NOT a proper fix. It's
just a hack so I can get by it and test other parts.
-- Steve
* Steven Rostedt <[email protected]> wrote:
> > actually, what priorities do the yielding tasks have? sched_yield() does
> > not guarantee that the CPU will be given up, of if a highest-prio
> > SCHED_FIFO task is in a yield() loop it will livelock the system.
>
> What scares me is the code in fs/inode.c with that
> __wait_on_freeing_inode. Look at the code in find_inode and
> find_inode_fast. Here you will see that they really are busy loops
> with a yield in them, if the inode they are waiting on is I_FREEING or
> I_CLEAR and the process doing this hasn't set I_LOCK. I haven't
> looked much at this, but my kernel has livelocked on it.
ok, makes sense.
> Currently my fix is in yield to lower the priority of the task calling
> yield and raise it after the schedule. This is NOT a proper fix. It's
> just a hack so I can get by it and test other parts.
yeah, yield() is a quite RT-incompatible concept, which could livelock
an upstream kernel just as much - if the task in question is SCHED_FIFO.
Almost all yield() uses should be eliminated from the upstream kernel,
step by step.
Ingo
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
> > Currently my fix is in yield to lower the priority of the task calling
> > yield and raise it after the schedule. This is NOT a proper fix. It's
> > just a hack so I can get by it and test other parts.
>
> yeah, yield() is a quite RT-incompatible concept, which could livelock
> an upstream kernel just as much - if the task in question is SCHED_FIFO.
> Almost all yield() uses should be eliminated from the upstream kernel,
> step by step.
Now the question is, who will fix it? Preferably the maintainers, but I
don't know how much of a priority this is to them. I don't have the time
now to look at this and understand enough about the code to be able to
make a proper fix, and I'm sure you have other things to do too.
-- Steve
On Mon, 4 Apr 2005, Steven Rostedt wrote:
> On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
>
> > > Currently my fix is in yield to lower the priority of the task calling
> > > yield and raise it after the schedule. This is NOT a proper fix. It's
> > > just a hack so I can get by it and test other parts.
> >
> > yeah, yield() is a quite RT-incompatible concept, which could livelock
> > an upstream kernel just as much - if the task in question is SCHED_FIFO.
> > Almost all yield() uses should be eliminated from the upstream kernel,
> > step by step.
>
> Now the question is, who will fix it? Preferably the maintainers, but I
> don't know how much of a priority this is to them. I don't have the time
> now to look at this and understand enough about the code to be able to
> make a proper fix, and I'm sure you have other things to do too.
I'm sure a lot of the yield() users could be converted to
schedule_timeout(), some of the users i saw were for low memory conditions
where we want other tasks to make progress and complete so that we a bit
more free memory.
On Mon, 2005-04-04 at 16:51 -0600, Zwane Mwaikambo wrote:
> I'm sure a lot of the yield() users could be converted to
> schedule_timeout(), some of the users i saw were for low memory conditions
> where we want other tasks to make progress and complete so that we a bit
> more free memory.
>
I've stated earlier that I was locked up in fs/inode.c with the
__wait_on_freeing_inode. Can this be switched to a schedule_timeout?
Of course schedule_timeout is not too good with RT as well. Although you
can prevent a live_deadlock, but we bring up the problem of priority
inversion again. The process needing to run can still be starved by
another higher priority process that is lower in priority as the one
doing the waiting.
The schedule_timeout should stop the livelock. But what is the effect of
switching to it?
-- Steve
On Mon, 4 Apr 2005, Steven Rostedt wrote:
> On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
>
> > > Currently my fix is in yield to lower the priority of the task calling
> > > yield and raise it after the schedule. This is NOT a proper fix. It's
> > > just a hack so I can get by it and test other parts.
> >
> > yeah, yield() is a quite RT-incompatible concept, which could livelock
> > an upstream kernel just as much - if the task in question is SCHED_FIFO.
> > Almost all yield() uses should be eliminated from the upstream kernel,
> > step by step.
>
> Now the question is, who will fix it? Preferably the maintainers, but I
> don't know how much of a priority this is to them. I don't have the time
> now to look at this and understand enough about the code to be able to
> make a proper fix, and I'm sure you have other things to do too.
How about adding a
if(rt_task(current)) {
WARN_ON(1);
mutex_setprio(current, MAX_PRIO-1)
}
?
to find all calls to yields from rt-tasks. That will force the user (aka
the real-time developer) to either stop calling the subsystems still using
yield from his RT-tasks, or fix those subsystems.
Esben
>
> -- Steve
>
On Mon, 4 Apr 2005, Zwane Mwaikambo wrote:
> On Mon, 4 Apr 2005, Steven Rostedt wrote:
>
> > On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
> >
> > > > Currently my fix is in yield to lower the priority of the task calling
> > > > yield and raise it after the schedule. This is NOT a proper fix. It's
> > > > just a hack so I can get by it and test other parts.
> > >
> > > yeah, yield() is a quite RT-incompatible concept, which could livelock
> > > an upstream kernel just as much - if the task in question is SCHED_FIFO.
> > > Almost all yield() uses should be eliminated from the upstream kernel,
> > > step by step.
> >
> > Now the question is, who will fix it? Preferably the maintainers, but I
> > don't know how much of a priority this is to them. I don't have the time
> > now to look at this and understand enough about the code to be able to
> > make a proper fix, and I'm sure you have other things to do too.
>
> I'm sure a lot of the yield() users could be converted to
> schedule_timeout(), some of the users i saw were for low memory conditions
> where we want other tasks to make progress and complete so that we a bit
> more free memory.
>
Easy, but damn ugly. Completions are the right answer. The memory system
needs a queue system where tasks can sleep (with a timeout) until the
right amount of memory is available instead of half busy-looping.
Esben
* Esben Nielsen <[email protected]> wrote:
> > Now the question is, who will fix it? Preferably the maintainers, but I
> > don't know how much of a priority this is to them. I don't have the time
> > now to look at this and understand enough about the code to be able to
> > make a proper fix, and I'm sure you have other things to do too.
>
> How about adding a
> if(rt_task(current)) {
> WARN_ON(1);
> mutex_setprio(current, MAX_PRIO-1)
> }
> ?
>
> to find all calls to yields from rt-tasks. That will force the user
> (aka the real-time developer) to either stop calling the subsystems
> still using yield from his RT-tasks, or fix those subsystems.
i've added this to the -43-08 patch, so that we can see the scope of the
problem. But any yield() use could become a problem due to priority
inheritance. (which might eventually be expanded to userspace locking
too)
Ingo
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/
this is a merge of -43-08 to 2.6.12-rc2.
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc2.bz2
http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc2-V0.7.44-00
Ingo
On Tue, 5 Apr 2005, Esben Nielsen wrote:
> > I'm sure a lot of the yield() users could be converted to
> > schedule_timeout(), some of the users i saw were for low memory conditions
> > where we want other tasks to make progress and complete so that we a bit
> > more free memory.
> >
>
> Easy, but damn ugly. Completions are the right answer. The memory system
> needs a queue system where tasks can sleep (with a timeout) until the
> right amount of memory is available instead of half busy-looping.
I agree entirely, that would definitely be a better way to go eventually.
On Tue, 5 Apr 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[email protected]> wrote:
>
> > > Now the question is, who will fix it? Preferably the maintainers, but I
> > > don't know how much of a priority this is to them. I don't have the time
> > > now to look at this and understand enough about the code to be able to
> > > make a proper fix, and I'm sure you have other things to do too.
> >
> > How about adding a
> > if(rt_task(current)) {
> > WARN_ON(1);
> > mutex_setprio(current, MAX_PRIO-1)
> > }
> > ?
> >
> > to find all calls to yields from rt-tasks. That will force the user
> > (aka the real-time developer) to either stop calling the subsystems
> > still using yield from his RT-tasks, or fix those subsystems.
>
> i've added this to the -43-08 patch, so that we can see the scope of the
> problem. But any yield() use could become a problem due to priority
> inheritance. (which might eventually be expanded to userspace locking
> too)
>
Any calls to non-deterministic subsystems breaks the real-time properties.
yield() is certainly not the only problem. Code waiting for RCU-completion
or whatever is bad too. Calling code like that from RT-tasks or calling
them while having locks shared with RT-tasks is just bad. Anyone knowing
about RT development _has_ to know that. Putting warnings and traces into
the kernel is a nice feature.
Static code analyzes would also help quite a bit. What about having a new
attribute "nonrt" for functions and locks? yield() and syncronize_kernel() are
certain candidates. Any function having nonrt operations are marked
nonrt. Any lock becomes held while doing a nonrt operation is marked
nonrt. Taking a nonrt lock is a nonrt operation. (Might end up marking the
whole kernel nonrt....)
Esben
> Ingo
At 01:57 AM 4/5/2005 -0600, Zwane Mwaikambo wrote:
>On Tue, 5 Apr 2005, Esben Nielsen wrote:
>
> > > I'm sure a lot of the yield() users could be converted to
> > > schedule_timeout(), some of the users i saw were for low memory
> conditions
> > > where we want other tasks to make progress and complete so that we a bit
> > > more free memory.
> > >
> >
> > Easy, but damn ugly. Completions are the right answer. The memory system
> > needs a queue system where tasks can sleep (with a timeout) until the
> > right amount of memory is available instead of half busy-looping.
>
>I agree entirely, that would definitely be a better way to go eventually.
I wouldn't bet on it. There used to be a queue - minus the
timeout. Throughput improved markedly with it's removal.
That said, yield()s in the kernel can be quite evil. I once instrumented
semaphores, and under hefty load, frequently found tasks waiting for a
semaphore held by someone in the expired array. When you've got a busy
cpu, that wait can be _extremely_ painful. The yield()s in mm/*.c are long
gone (thank god), but after a quick grep/peek, I can imagine the one in
free_more_memory() causing some throughput grief in a cpu intense
environment, and the one in __wait_on_freeing_inode() would punt you into
the dungeon while you're holding the inode lock... that looks like it could
be pretty unpleasant.
-Mike
>
> 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:xxxx 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]
Our first victim!! :-)
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:xxxx 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.
-- Steve
> 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:xxxx 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:xxxx 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]
On Fri, 2005-04-08 at 16:22 +0100, Rui Nuno Capela wrote:
> > Our first victim!! :-)
> >
>
> No kidding!?
>
V0.7.44-02 does not even compile for me. It appears to be full of merge
errors.
I get these errors with "make oldconfig":
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf -o arch/i386/Kconfig
lib/Kconfig.RT:160:warning: choice values currently only support a single prompt
lib/Kconfig.RT:173:warning: choice values currently only support a single prompt
lib/Kconfig.RT:190:warning: choice values currently only support a single prompt
lib/Kconfig.RT:211:warning: choice values currently only support a single prompt
lib/Kconfig.RT:7:warning: choice values currently only support a single prompt
lib/Kconfig.RT:20:warning: choice values currently only support a single prompt
lib/Kconfig.RT:37:warning: choice values currently only support a single prompt
lib/Kconfig.RT:58:warning: choice values currently only support a single prompt
#
# using defaults found in .config
Then, looks like mcount-wrapper.S is two copies of the same file. To
have any chance of building this patch was required:
--- arch/i386/kernel/mcount-wrapper.S~ 2005-04-07 19:02:33.000000000 -0400
+++ arch/i386/kernel/mcount-wrapper.S 2005-04-07 19:52:24.000000000 -0400
@@ -25,30 +25,3 @@
out:
ret
-/*
- * linux/arch/i386/mcount-wrapper.S
- *
- * Copyright (C) 2004 Ingo Molnar
- */
-
-.globl mcount
-mcount:
-
- cmpl $0, mcount_enabled
- jz out
-
- push %ebp
- mov %esp, %ebp
- pushl %eax
- pushl %ecx
- pushl %edx
-
- call __mcount
-
- popl %edx
- popl %ecx
- popl %eax
- popl %ebp
-out:
- ret
-
And it still bombs out here. This is where I gave up:
CC kernel/rt.o
kernel/rt.c:1931: error: redefinition of `pi_lock'
kernel/rt.c:55: error: `pi_lock' previously defined here
kernel/rt.c:2037: error: redefinition of `zap_rt_locks'
kernel/rt.c:161: error: `zap_rt_locks' previously defined here
kernel/rt.c:2382: error: redefinition of `check_pi_list_present'
kernel/rt.c:555: error: `check_pi_list_present' previously defined here
kernel/rt.c:2387: error: redefinition of `check_pi_list_empty'
kernel/rt.c:560: error: `check_pi_list_empty' previously defined here
kernel/rt.c:2398: error: redefinition of `change_owner'
kernel/rt.c:571: error: `change_owner' previously defined here
kernel/rt.c:2420: error: redefinition of `pi_setprio'
kernel/rt.c:593: error: `pi_setprio' previously defined here
[etc]
Lee
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc2-RT-V0.7.44-02
# Thu Apr 7 05:56:40 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_CPUSETS=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODE is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=8
# CONFIG_SCHED_SMT is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT_DESKTOP is not set
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_BKL=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ASM_SEMAPHORES=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
#
# Firmware Drivers
#
CONFIG_EDD=m
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_IRQBALANCE=y
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_SECCOMP is not set
#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set
#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set
CONFIG_ACPI_BOOT=y
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
CONFIG_ISAPNP=y
# CONFIG_PNPBIOS is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_BLK_DEV_ATIIXP is not set
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_TRIFLEX=y
CONFIG_BLK_DEV_CY82C693=y
# CONFIG_BLK_DEV_CS5520 is not set
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT34X=y
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_BLK_DEV_HPT366=y
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
CONFIG_BLK_DEV_PDC202XX_OLD=y
# CONFIG_PDC202XX_BURST is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
# CONFIG_PDC202XX_FORCE is not set
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIIMAGE=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=m
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
#
# SCSI low-level drivers
#
CONFIG_BLK_DEV_3W_XXXX_RAID=m
# CONFIG_SCSI_3W_9XXX is not set
CONFIG_SCSI_7000FASST=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_ENABLE_RD_STRM is not set
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_DPT_I2O is not set
CONFIG_SCSI_IN2000=m
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_DTC3280=m
CONFIG_SCSI_EATA=m
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
# CONFIG_SCSI_EATA_LINKED_COMMANDS is not set
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_GENERIC_NCR5380=m
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_GENERIC_NCR53C400 is not set
CONFIG_SCSI_IPS=m
# CONFIG_SCSI_INITIO is not set
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_NCR53C406A=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
# CONFIG_SCSI_IPR is not set
CONFIG_SCSI_PAS16=m
CONFIG_SCSI_PSI240I=m
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_FC=m
# CONFIG_SCSI_QLOGIC_FC_FIRMWARE is not set
CONFIG_SCSI_QLOGIC_1280=m
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
CONFIG_SCSI_SYM53C416=m
# CONFIG_SCSI_DC395x is not set
CONFIG_SCSI_DC390T=m
CONFIG_SCSI_T128=m
CONFIG_SCSI_U14_34F=m
# CONFIG_SCSI_U14_34F_TAGGED_QUEUE is not set
# CONFIG_SCSI_U14_34F_LINKED_COMMANDS is not set
CONFIG_SCSI_U14_34F_MAX_TAGS=8
CONFIG_SCSI_ULTRASTOR=m
CONFIG_SCSI_NSP32=m
CONFIG_SCSI_DEBUG=m
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
# CONFIG_MD_RAID10 is not set
CONFIG_MD_RAID5=m
# CONFIG_MD_RAID6 is not set
CONFIG_MD_MULTIPATH=m
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_CRYPT is not set
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Networking support
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m
CONFIG_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set
#
# IP: Virtual Server Configuration
#
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=16
#
# IPVS transport protocol load balancing support
#
# CONFIG_IP_VS_PROTO_TCP is not set
# CONFIG_IP_VS_PROTO_UDP is not set
# CONFIG_IP_VS_PROTO_ESP is not set
# CONFIG_IP_VS_PROTO_AH is not set
#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
# CONFIG_IP_VS_SED is not set
# CONFIG_IP_VS_NQ is not set
#
# IPVS application helper
#
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
# CONFIG_IP_NF_MATCH_IPRANGE is not set
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
# CONFIG_IP_NF_MATCH_PHYSDEV is not set
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_REALM is not set
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
# CONFIG_IP_NF_TARGET_NETMAP is not set
# CONFIG_IP_NF_TARGET_SAME is not set
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
# CONFIG_IP_NF_TARGET_CLASSIFY is not set
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
#
# Bridge: Netfilter Configuration
#
# CONFIG_BRIDGE_NF_EBTABLES is not set
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
CONFIG_ATM=y
CONFIG_ATM_CLIP=y
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
CONFIG_ATM_BR2684=m
CONFIG_ATM_BR2684_IPFILTER=y
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=y
CONFIG_LTPC=m
CONFIG_COPS=m
CONFIG_COPS_DAYNA=y
CONFIG_COPS_TANGENT=y
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
CONFIG_NET_DIVERT=y
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_ATM is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
# CONFIG_CLS_U32_MARK is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_NET_SB1000 is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL1=m
CONFIG_EL2=m
CONFIG_ELPLUS=m
CONFIG_EL16=m
CONFIG_EL3=m
CONFIG_3C515=m
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
CONFIG_LANCE=m
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=m
CONFIG_ULTRA=m
CONFIG_SMC9194=m
CONFIG_NET_VENDOR_RACAL=y
CONFIG_NI52=m
CONFIG_NI65=m
#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
# CONFIG_TULIP_NAPI is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
CONFIG_AT1700=m
CONFIG_DEPCA=m
CONFIG_HP100=m
CONFIG_NET_ISA=y
CONFIG_E2100=m
CONFIG_EWRK3=m
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
CONFIG_HPLAN_PLUS=m
CONFIG_HPLAN=m
CONFIG_LP486E=m
CONFIG_ETH16I=m
CONFIG_NE2000=m
# CONFIG_ZNET is not set
# CONFIG_SEEQ8005 is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_AMD8111_ETH=m
# CONFIG_AMD8111E_NAPI is not set
CONFIG_ADAPTEC_STARFIRE=m
# CONFIG_ADAPTEC_STARFIRE_NAPI is not set
CONFIG_AC3200=m
CONFIG_APRICOT=m
CONFIG_B44=m
# CONFIG_FORCEDETH is not set
CONFIG_CS89x0=m
CONFIG_DGRS=m
# CONFIG_EEPRO100 is not set
CONFIG_E100=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m
#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=m
CONFIG_E1000_NAPI=y
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
# CONFIG_R8169_NAPI is not set
# CONFIG_R8169_VLAN is not set
CONFIG_SK98LIN=m
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=m
#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# ATM drivers
#
# CONFIG_ATM_TCP is not set
# CONFIG_ATM_LANAI is not set
# CONFIG_ATM_ENI is not set
# CONFIG_ATM_FIRESTREAM is not set
# CONFIG_ATM_ZATM is not set
# CONFIG_ATM_NICSTAR is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
# CONFIG_ATM_HORIZON is not set
# CONFIG_ATM_IA is not set
# CONFIG_ATM_FORE200E_MAYBE is not set
# CONFIG_ATM_HE is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
# CONFIG_PPP_BSDCOMP is not set
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NET_FC=y
CONFIG_SHAPER=m
CONFIG_NETCONSOLE=m
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=m
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_N_HDLC is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_STALDRV is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=m
CONFIG_RTC=y
CONFIG_RTC_HISTOGRAM=y
CONFIG_BLOCKER=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
#
# I2C support
#
# CONFIG_I2C is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Misc devices
#
# CONFIG_IBM_ASM is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SOFT_CURSOR=y
# CONFIG_FB_MACMODES is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
CONFIG_FB_CIRRUS=m
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_HGA=m
# CONFIG_FB_HGA_ACCEL is not set
CONFIG_FB_NVIDIA=y
# CONFIG_FB_NVIDIA_I2C is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE is not set
#
# Logo configuration
#
# CONFIG_LOGO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Sound
#
CONFIG_SOUND=m
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
#
# Generic devices
#
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
#
# ISA devices
#
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_HDA_INTEL is not set
#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
#
# Open Sound System
#
CONFIG_SOUND_PRIME=m
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_CMPCI is not set
# CONFIG_SOUND_EMU10K1 is not set
CONFIG_SOUND_FUSION=m
# CONFIG_SOUND_CS4281 is not set
# CONFIG_SOUND_ES1370 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ESSSOLO1 is not set
# CONFIG_SOUND_MAESTRO is not set
# CONFIG_SOUND_MAESTRO3 is not set
# CONFIG_SOUND_ICH is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
# CONFIG_SOUND_VIA82CXXX is not set
# CONFIG_SOUND_OSS is not set
# CONFIG_SOUND_ALI5455 is not set
# CONFIG_SOUND_FORTE is not set
# CONFIG_SOUND_RME96XX is not set
# CONFIG_SOUND_AD1980 is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
# CONFIG_USB_STORAGE is not set
#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
#
# Video4Linux support is needed for USB Multimedia device support
#
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set
#
# USB port drivers
#
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_TEST is not set
#
# USB ATM/DSL drivers
#
# CONFIG_USB_ATM is not set
# CONFIG_USB_SPEEDTOUCH is not set
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_REISERFS_FS_XATTR is not set
CONFIG_JFS_FS=m
# CONFIG_JFS_POSIX_ACL is not set
# CONFIG_JFS_SECURITY is not set
CONFIG_JFS_DEBUG=y
# CONFIG_JFS_STATISTICS is not set
CONFIG_FS_POSIX_ACL=y
#
# XFS support
#
# CONFIG_XFS_FS is not set
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_CIFS is not set
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_CODA_FS=m
# CONFIG_CODA_FS_OLD_API is not set
CONFIG_AFS_FS=m
CONFIG_RXRPC=m
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
# CONFIG_EFI_PARTITION is not set
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_WAKEUP_TIMING=y
CONFIG_PREEMPT_TRACE=y
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
CONFIG_LATENCY_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_RT_DEADLOCK_DETECT=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
# CONFIG_CRYPTO_TWOFISH is not set
CONFIG_CRYPTO_SERPENT=m
# CONFIG_CRYPTO_AES_586 is not set
CONFIG_CRYPTO_CAST5=m
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set
#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set
#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y
On Fri, 2005-04-08 at 15:15 -0500, K.R. Foley wrote:
> Lee Revell wrote:
> > On Fri, 2005-04-08 at 16:22 +0100, Rui Nuno Capela wrote:
> >
> >>>Our first victim!! :-)
> >>>
> >>
> >>No kidding!?
> >>
> >
> >
> > V0.7.44-02 does not even compile for me. It appears to be full of merge
> > errors.
> >
>
> I must be in the twilight zone over here. V0.7.44-02 runs fine on my UP
> system, my older SMP system (although I have to compile in my SCSI
> drivers, but that has nothing to do with this patch) and my faster P4/HT
> SMP system at the office.
Meh, I'll try again, maybe it's some weird NFS problem.
Lee
Lee Revell wrote:
> On Fri, 2005-04-08 at 15:15 -0500, K.R. Foley wrote:
>
>>Lee Revell wrote:
>>
>>>On Fri, 2005-04-08 at 16:22 +0100, Rui Nuno Capela wrote:
>>>
>>>
>>>>>Our first victim!! :-)
>>>>>
>>>>
>>>>No kidding!?
>>>>
>>>
>>>
>>>V0.7.44-02 does not even compile for me. It appears to be full of merge
>>>errors.
>>>
>>
>>I must be in the twilight zone over here. V0.7.44-02 runs fine on my UP
>>system, my older SMP system (although I have to compile in my SCSI
>>drivers, but that has nothing to do with this patch) and my faster P4/HT
>>SMP system at the office.
>
>
> Meh, I'll try again, maybe it's some weird NFS problem.
>
> Lee
>
Hmm. Maybe. I should probably mention that I am doing an FC3 install via
NFS from my older SMP system right now while also building V0.7.44-03.
--
kr
On Fri, 2005-04-08 at 15:26 -0500, K.R. Foley wrote:
> Lee Revell wrote:
> >
> > Meh, I'll try again, maybe it's some weird NFS problem.
> >
> > Lee
> >
>
> Hmm. Maybe. I should probably mention that I am doing an FC3 install via
> NFS from my older SMP system right now while also building V0.7.44-03.
>
Tried again and it works. Weird...
Lee
Lee Revell wrote:
> On Fri, 2005-04-08 at 15:26 -0500, K.R. Foley wrote:
>
>>Lee Revell wrote:
>>
>>>Meh, I'll try again, maybe it's some weird NFS problem.
>>>
>>>Lee
>>>
>>
>>Hmm. Maybe. I should probably mention that I am doing an FC3 install via
>>NFS from my older SMP system right now while also building V0.7.44-03.
>>
>
>
> Tried again and it works. Weird...
>
> Lee
>
>
Very wierd. It worries me when things like that happen. ;-)
--
kr
--- linux-2.6.11/include/linux/jbd.h.orig 2005-03-16 09:18:51.000000000 -0600
+++ linux-2.6.11/include/linux/jbd.h 2005-03-16 09:19:24.000000000 -0600
@@ -65,6 +65,7 @@ extern int journal_enable_debug;
} \
} while (0)
#else
+#define jbd_debug(f, a...) /**/
#endif
extern void * __jbd_kmalloc (const char *where, size_t size, int flags, int retry);
* K.R. Foley <[email protected]> wrote:
> Ingo,
>
> It would seem that in the latest patch RT-V0.7.45-00 we have reverted
> back to removing the define of jbd_debug which the attached patch
> (against one of the 2.6.11 versions) fixed.
> +#define jbd_debug(f, a...) /**/
oops, indeed. '/**/' happens to be my private marker for 'debug code',
which the release scripts automatically strip from the files ...
i've uploaded -45-01 with the fix.
Ingo
On Sun, 2005-04-10 at 19:27 +0200, Ingo Molnar wrote:
> * K.R. Foley <[email protected]> wrote:
>
> > Ingo,
> >
> > It would seem that in the latest patch RT-V0.7.45-00 we have reverted
> > back to removing the define of jbd_debug which the attached patch
> > (against one of the 2.6.11 versions) fixed.
>
> > +#define jbd_debug(f, a...) /**/
>
> oops, indeed. '/**/' happens to be my private marker for 'debug code',
> which the release scripts automatically strip from the files ...
>
> i've uploaded -45-01 with the fix.
>
Would there be any harm with changing that to
#define jbd_debug(f, a...) do {} while(0)
The compiler would strip it anyway, and you wouldn't have to worry about
your scripts removing the macro.
-- Steve
* Steven Rostedt <[email protected]> wrote:
> Would there be any harm with changing that to
>
> #define jbd_debug(f, a...) do {} while(0)
>
> The compiler would strip it anyway, and you wouldn't have to worry
> about your scripts removing the macro.
yeah, that's what i did in -45-01. Since it's not the first time this
has happened i might have to change the marker to /*I*/ or something
like that :-)
Ingo
On Sun, 2005-04-10 at 19:47 +0200, Ingo Molnar wrote:
> yeah, that's what i did in -45-01.
>
Ingo,
This build failure was reported with 45-01 by an AMD64 user. Do you
need the .config?
HOSTCC scripts/bin2c
CC arch/x86_64/kernel/asm-offsets.s
CHK include/asm-x86_64/offset.h
UPD include/asm-x86_64/offset.h
CC init/main.o
In file included from include/linux/rwsem.h:38,
from include/linux/kobject.h:24,
from include/linux/module.h:19,
from init/main.c:16:
include/asm/rwsem.h:55: error: redefinition of `struct rw_semaphore'
In file included from include/linux/rwsem.h:38,
from include/linux/kobject.h:24,
from include/linux/module.h:19,
from init/main.c:16:
include/asm/rwsem.h:79:1: warning: "__RWSEM_INITIALIZER" redefined
In file included from include/linux/spinlock.h:16,
from include/linux/capability.h:45,
from include/linux/sched.h:7,
from include/linux/module.h:10,
from init/main.c:16:
include/linux/rt_lock.h:295:1: warning: this is the location of the
previous definition
In file included from include/linux/rwsem.h:38,
from include/linux/kobject.h:24,
from include/linux/module.h:19,
from init/main.c:16:
include/asm/rwsem.h:83:1: warning: "DECLARE_RWSEM" redefined
In file included from include/linux/spinlock.h:16,
from include/linux/capability.h:45,
from include/linux/sched.h:7,
from include/linux/module.h:10,
from init/main.c:16:
include/linux/rt_lock.h:298:1: warning: this is the location of the
previous definition
include/asm/rwsem.h:86: error: parse error before "do"
In file included from include/linux/kobject.h:24,
from include/linux/module.h:19,
from init/main.c:16:
include/linux/rwsem.h: In function `compat_down_read':
include/linux/rwsem.h:56: warning: passing arg 1 of `__down_read' from
incompatible pointer type
include/linux/rwsem.h: In function `compat_down_read_trylock':
include/linux/rwsem.h:67: warning: passing arg 1 of
`__down_read_trylock' from incompatible pointer type
include/linux/rwsem.h: In function `compat_down_write':
include/linux/rwsem.h:79: warning: passing arg 1 of `__down_write' from
incompatible pointer type
include/linux/rwsem.h: In function `compat_down_write_trylock':
include/linux/rwsem.h:90: warning: passing arg 1 of
`__down_write_trylock' from incompatible pointer type
include/linux/rwsem.h: In function `compat_up_read':
include/linux/rwsem.h:101: warning: passing arg 1 of `__up_read' from
incompatible pointer type
include/linux/rwsem.h: In function `compat_up_write':
include/linux/rwsem.h:111: warning: passing arg 1 of `__up_write' from
incompatible pointer type
include/linux/rwsem.h: In function `compat_downgrade_write':
include/linux/rwsem.h:121: warning: passing arg 1 of `__downgrade_write'
from incompatible pointer type
In file included from include/linux/proc_fs.h:6,
from init/main.c:17:
include/linux/fs.h: In function `lock_super':
include/linux/fs.h:828: warning: implicit declaration of function
`compat_down'
include/linux/fs.h: In function `unlock_super':
include/linux/fs.h:833: warning: implicit declaration of function
`compat_up'
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
Lee
i have released the -V0.7.46-00 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
this is a merge to 2.6.12-rc3, plus the 'ping localhost' fix from
[email protected].
there are still some unsolved slowdowns probably related to the recent
plist.h changes.
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc3.bz2
http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc3-V0.7.46-00
Ingo
2005/4/21, Ingo Molnar <[email protected]>:
>
> i have released the -V0.7.46-00 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> this is a merge to 2.6.12-rc3, plus the 'ping localhost' fix from
> [email protected].
>
> there are still some unsolved slowdowns probably related to the recent
> plist.h changes.
>
> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
> http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc3.bz2
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc3-V0.7.46-00
>
Ingo,
what's your plan for including in mainstream bit of preemptive patch ?
--
http://paoloc.blogspot.com
On Thu, 21 Apr 2005, Ingo Molnar wrote:
>
> i have released the -V0.7.46-00 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> this is a merge to 2.6.12-rc3, plus the 'ping localhost' fix from
> [email protected].
>
> there are still some unsolved slowdowns probably related to the recent
> plist.h changes.
You may want to consider rolling it out for a bit , till I have time to
fix this ..
Daniel
On Thu, 2005-04-21 at 00:35, Ingo Molnar wrote:
> this is a merge to 2.6.12-rc3, plus the 'ping localhost' fix from
> [email protected].
We had some discussion about this one, there just need to be a softirqd
wakeup , the netif_rx_ni() call isn't really needed .
How about removing the softirqd wakeup from interrupt context, and move
it into the softirq scheduler. That would solve this situation and all
others like it .. Plus reduce worst case interrupt latency ..
Daniel
i have released the -V0.7.46-01 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
this includes fixes from Daniel Walker, which could fix the plist
related slowdown bugs:
- fix plist_del_init() argument order bug
- fix plist related priority calculation bug in __up_mutex()
to build a -V0.7.46-01 tree, the following patches have to be applied:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc3.bz2
http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc3-V0.7.46-01
Ingo
> this includes fixes from Daniel Walker, which could fix the plist
> related slowdown bugs:
there are still some problems remaining: i just ran Esben Nielsen's
priority-inheritance validation testsuite, and the plist code gives a
worst-case latency of 9.0 msecs.
I've reverted the plist changes for now and have uploaded -46-02 - this
gives the expected 1.0 msec worst-case latencies. Diffing -01 against
-02 should give you the latest plist snapshot.
Ingo
Is this the PriorityInversionTest (pi_test.tgz) or was there another one?
Daniel
On Fri, 22 Apr 2005, Ingo Molnar wrote:
>
> > this includes fixes from Daniel Walker, which could fix the plist
> > related slowdown bugs:
>
> there are still some problems remaining: i just ran Esben Nielsen's
> priority-inheritance validation testsuite, and the plist code gives a
> worst-case latency of 9.0 msecs.
>
> I've reverted the plist changes for now and have uploaded -46-02 - this
> gives the expected 1.0 msec worst-case latencies. Diffing -01 against
> -02 should give you the latest plist snapshot.
>
> Ingo
>
* Daniel Walker <[email protected]> wrote:
> Is this the PriorityInversionTest (pi_test.tgz) or was there another one?
yes, it's pi_test.tgz.
Ingo
What command line did you use ?
./test --samples 10000 --hertz 128 --tasks 0
Daniel
On Fri, 22 Apr 2005, Ingo Molnar wrote:
>
> * Daniel Walker <[email protected]> wrote:
>
> > Is this the PriorityInversionTest (pi_test.tgz) or was there another one?
>
> yes, it's pi_test.tgz.
>
> Ingo
>
* Daniel Walker <[email protected]> wrote:
> What command line did you use ?
>
> ./test --samples 10000 --hertz 128 --tasks 0
i used:
./test --tasks 10 file.hist
Ingo
* Ingo Molnar <[email protected]> wrote:
>
> * Daniel Walker <[email protected]> wrote:
>
> > What command line did you use ?
> >
> > ./test --samples 10000 --hertz 128 --tasks 0
>
> i used:
>
> ./test --tasks 10 file.hist
but first i did:
chrt -f 98 -p `pidof 'IRQ 8'`
Ingo
>>>>> Ingo Molnar <[email protected]> writes:
>> this includes fixes from Daniel Walker, which could fix the plist
>> related slowdown bugs:
> there are still some problems remaining: i just ran Esben Nielsen's
> priority-inheritance validation testsuite, and the plist code gives
> a worst-case latency of 9.0 msecs.
With which machine is this?
I tried to reproduce with V0.7.45-01 in my 2xPIII 0.9 Ghz I cannot get
more than 1.9ms when doing 2000 samples repeatedly (60 iterations and
counting).
Did you use other parameters to 'test'?
# cnt=0
# while true
> do echo -n "$cnt "
> ./test --samples 2000 file.hist 2>&1 | grep maximum; cnt=$(($cnt+1))
> done
With 2.6.12-rc3-V0.7.46-02 I get:
...
2 maximum cycle time: 0.003ms
3 maximum cycle time: 1.706ms
4 maximum cycle time: 1.538ms
5 maximum cycle time: 1.168ms
6 maximum cycle time: 0.003ms
7 maximum cycle time: 0.008ms
8 maximum cycle time: 1.821ms
9 maximum cycle time: 1.013ms
10 maximum cycle time: 1.043ms
11 maximum cycle time: 1.787ms
12 maximum cycle time: 1.519ms
13 ...
roughly the same as with 0.7.45-01:
0 maximum cycle time: 1.872ms
1 maximum cycle time: 0.008ms
2 maximum cycle time: 1.947ms
3 maximum cycle time: 1.902ms
4 maximum cycle time: 1.925ms
5 maximum cycle time: 0.002ms
6 maximum cycle time: 1.950ms
7 maximum cycle time: 0.008ms
8 maximum cycle time: 0.008ms
9 maximum cycle time: 0.008ms
10 maximum cycle time: 1.943ms
11 maximum cycle time: 1.173ms
12 maximum cycle time: 0.008ms
13 maximum cycle time: 0.008ms
...
--
Inaky
t
On Fri, 22 Apr 2005, Inaky Perez-Gonzalez wrote:
> >>>>> Ingo Molnar <[email protected]> writes:
>
> >> this includes fixes from Daniel Walker, which could fix the plist
> >> related slowdown bugs:
>
> > there are still some problems remaining: i just ran Esben Nielsen's
> > priority-inheritance validation testsuite, and the plist code gives
> > a worst-case latency of 9.0 msecs.
>
> With which machine is this?
>
> I tried to reproduce with V0.7.45-01 in my 2xPIII 0.9 Ghz I cannot get
> more than 1.9ms when doing 2000 samples repeatedly (60 iterations and
> counting).
>
> Did you use other parameters to 'test'?
>
> # cnt=0
> # while true
> > do echo -n "$cnt "
> > ./test --samples 2000 file.hist 2>&1 | grep maximum; cnt=$(($cnt+1))
> > done
>
> With 2.6.12-rc3-V0.7.46-02 I get:
It's still to high , it should be under a millisecond ..
I'm still testing but the times get better with this patch . I was
initializing the lists to 0, instead of MAX_INT . Let me know if it
changes anything.
Daniel
Oops, I missed that you tested a non-plist kernel .. Maybe there are some
lingering problems in current stuff..
Daniel
On Fri, 22 Apr 2005, Inaky Perez-Gonzalez wrote:
> With 2.6.12-rc3-V0.7.46-02 I get:
>
> ...
> 2 maximum cycle time: 0.003ms
> 3 maximum cycle time: 1.706ms
> 4 maximum cycle time: 1.538ms
> 5 maximum cycle time: 1.168ms
> 6 maximum cycle time: 0.003ms
> 7 maximum cycle time: 0.008ms
> 8 maximum cycle time: 1.821ms
> 9 maximum cycle time: 1.013ms
> 10 maximum cycle time: 1.043ms
> 11 maximum cycle time: 1.787ms
> 12 maximum cycle time: 1.519ms
> 13 ...
>
On Fri, 2005-04-22 at 08:55, Ingo Molnar wrote:
> i used:
>
> ./test --tasks 10 file.hist
This patch cleanup the delays on increased numbers of tasks. It goes on
to of the current plist snapshot.
Daniel
On Fri, 2005-04-22 at 08:27 +0200, Ingo Molnar wrote:
> i have released the -V0.7.46-01 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
Ingo,
With Mingming's patch to resolve the ext3 allocate-with-reservation
latency, it looks like we are finally getting close to the lower limit
that can be achieved with PREEMPT_DESKTOP. I've attached the trace of
the lowest latency over several days of testing with
2.6.12-rc3-RT-V0.7.46-02 + Mingming's patch. It's only 127 usecs, and
IIRC you mentioned previously that this code path can't be made
preemptible in !PREEMPT_RT.
Since Mingming's patch will have to live in -mm for a while, can it be
added to the RT patchset as well?
http://lkml.org/lkml/2005/4/22/127
Lee
* Lee Revell <[email protected]> wrote:
> On Fri, 2005-04-22 at 08:27 +0200, Ingo Molnar wrote:
> > i have released the -V0.7.46-01 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
>
> Ingo,
>
> With Mingming's patch to resolve the ext3 allocate-with-reservation
> latency, it looks like we are finally getting close to the lower limit
> that can be achieved with PREEMPT_DESKTOP. I've attached the trace of
> the lowest latency over several days of testing with
> 2.6.12-rc3-RT-V0.7.46-02 + Mingming's patch. It's only 127 usecs, and
> IIRC you mentioned previously that this code path can't be made
> preemptible in !PREEMPT_RT.
yeah, signal delivery will have to stay atomic in !PREEMPT_RT kernels.
> Since Mingming's patch will have to live in -mm for a while, can it be
> added to the RT patchset as well?
i think so - i'll add it to the next patch.
Ingo
* Daniel Walker <[email protected]> wrote:
> > With 2.6.12-rc3-V0.7.46-02 I get:
>
> It's still to high , it should be under a millisecond ..
>
> I'm still testing but the times get better with this patch . I was
> initializing the lists to 0, instead of MAX_INT . Let me know if it
> changes anything.
could you send me a single patch that adds the plist stuff to the
current tree? (that way i'll have your latest and i'll be able to
add/remove it quicker)
Ingo
On Wed, 2005-05-04 at 10:22 +0200, Ingo Molnar wrote:
> * Lee Revell <[email protected]> wrote:
> > it looks like we are finally getting close to the lower limit
> > that can be achieved with PREEMPT_DESKTOP ... It's only 127 usecs, and
> > IIRC you mentioned previously that this code path can't be made
> > preemptible in !PREEMPT_RT.
>
> yeah, signal delivery will have to stay atomic in !PREEMPT_RT kernels.
>
OK. I found a few more.
When umounting, shrink_dcache_sb() will produce a 3-4 ms. bump. However
it's not clear this can be made preemptible. AFAICT the whole thing
needs to be under the dcache_lock. This one is pretty obvious so I'm
not attaching a trace.
There's also still one path in the VM related to page freeing that can
produce ~500 usec latencies but I don't have a trace handy now.
> > Since Mingming's patch will have to live in -mm for a while, can it be
> > added to the RT patchset as well?
>
> i think so - i'll add it to the next patch.
OK, great.
Lee
I have tried to build 2.6.12-rc3 kernel with Ingo's
realtime-preempt-2.6.12-rc3-V0.7.46-02 on amd64
When I enabled option 4, Complete Realtime, make bzImage failed as
described in Lee Revell's Apr 12 lkml post:
http://lkml.org/lkml/2005/4/12/523
"HOSTCC scripts/bin2c
CC arch/x86_64/kernel/asm-offsets.s
CHK include/asm-x86_64/offset.h
UPD include/asm-x86_64/offset.h
CC init/main.o
In file included from include/linux/rwsem.h:38,
from include/linux/kobject.h:24,
from include/linux/module.h:19,
from init/main.c:16:
include/asm/rwsem.h:55: error: redefinition of `struct rw_semaphore'
etc etc......"
When I started again with option 3, Low Latency Desktop, the build got a
bit further before hanging: (Full ouput:
http://www.longforest.com/index.php?option=com_content&task=view&id=133&Itemid=2 )
"
CC arch/x86_64/kernel/head64.o
CC arch/x86_64/kernel/init_task.o
arch/x86_64/kernel/init_task.c:17: warning: implicit declaration of
function `__RWSEM_INITIALIZER'
arch/x86_64/kernel/init_task.c:17: warning: missing braces around
initializer
...etc etc etc...
constant
arch/x86_64/kernel/init_task.c:17: error: (near initialization for
`init_mm.default_kioctx')
make[1]: *** [arch/x86_64/kernel/init_task.o] Error 1
make: *** [arch/x86_64/kernel] Error 2"
Please CC any advice (or abuse!),
I can supply further info if required
Cheers,
Norv
* Daniel Walker <[email protected]> wrote:
> On Fri, 2005-04-22 at 08:55, Ingo Molnar wrote:
>
> > i used:
> >
> > ./test --tasks 10 file.hist
>
> This patch cleanup the delays on increased numbers of tasks. It goes
> on to of the current plist snapshot.
ok, these fixes for priority init appear to have solved the pi-test
latencies. I've uploaded the -rc4-RT-V0.7.47-00 patch with the plist
code re-added again. It's looking good so far on my testboxes.
Ingo