2006-09-20 14:27:24

by Ingo Molnar

[permalink] [raw]
Subject: 2.6.18-rt1

I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
from the usual place:

http://redhat.com/~mingo/realtime-preempt/

This port to the 2.6.18 codebase was very complex (given that 5 major
features moved from -rt into 2.6.18: rtmutex, pi-futex, genirq, gtod and
lockdep), so it took quite some time to finish, but in exchange it
includes nice new features and also lots of bugfixes.

In particular, a nasty softirq performance bug has been fixed, which
caused the "5x slowdown under TCP" bug reported to lkml - those TCP
performance figures are now on par with vanilla performance.

The biggest new features are:

- Dynticks (a tickless kernel). This is a new feature we implemented
ontop of hrtimers for the -hrt patchqueue and now we merged it to -rt
too. There's a new config option: CONFIG_NO_HZ, which if enabled,
produces a system with fewer timer interrupts. Currently i686 and
x86_64 are tested, but in general a hrtimers-ready platform needs
minimal changes to support dynticks too. (from Thomas Gleixner and
me, the x86_64 port is from Arjan van de Ven)

- Timer expiry statistics feature from Thomas Gleixner:
CONFIG_TIMER_STATS. Enable/disable via "echo 1[0] > /proc/tstats",
display via "cat /proc/stats".

This kernel feature tracks the starting site (and expiry function) of
expired timers (both timer_list timers and hrtimers), and the number
of times they expired. This is a nice tool for those who'd like to
minimize the amount of timer ticks on their battery-based systems.
Sample output:

Timerstats sample period: 3.888770 s
12, 0 swapper hrtimer_stop_sched_tick (hrtimer_sched_tick)
15, 1 swapper hcd_submit_urb (rh_timer_func)
4, 959 kedac schedule_timeout (process_timeout)
1, 0 swapper page_writeback_init (wb_timer_fn)
28, 0 swapper hrtimer_stop_sched_tick (hrtimer_sched_tick)
22, 2948 IRQ 4 tty_flip_buffer_push (delayed_work_timer_fn)
3, 3100 bash schedule_timeout (process_timeout)
1, 1 swapper queue_delayed_work_on (delayed_work_timer_fn)
1, 1 swapper queue_delayed_work_on (delayed_work_timer_fn)
1, 1 swapper neigh_table_init_no_netlink (neigh_periodic_timer)
1, 2292 ip __netdev_watchdog_up (dev_watchdog)
1, 23 events/1 do_cache_clean (delayed_work_timer_fn)
90 total events, 30.0 events/sec

- There's also a new runtime-configurable kernel option under
/proc/sys/kernel/timeout_granularity that allows the coarser expiry
of timer_list timers, and hence better batching of timer expiry.
(hrtimers are not affected) The value of this option gives a
'multiplier' to the standard HZ granularity.

- Lock validator ported to -rt: it now checks all the sleeping lock
variants in -rt too. This helps us catch not only deadlocks but also
raw-lock candidates, sooner than before.

- The latest High Resolution Timers queue from Thomas Gleixner with
initial support for ARM and PPC. (Kevin Hilman, Deepak Saksena,
Sergei Shtylyov)

- The latest GTOD (Generic Time Of Day) queue from John Stultz,
including NTP cleanups from Roman Zippel.

- The latest genirq queue: more irq-chip-ization of i686 and x86_64,
MSI cleanups from Eric W. Biederman et al.

- The latest preemptible-RCU queue from Paul E McKenney and Dipankar
Sarma.

- (assorted fixes and improvements.)

Right now i686 and x86_64 are boot-tested, and ARM is compile-tested.
The other architectures likely wont even build yet. This being the first
2.6.18 based release of -rt, some tester caution is called for.

to build a 2.6.18-rt1 tree, the following patches should be applied:

http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2
http://redhat.com/~mingo/realtime-preempt/patch-2.6.18-rt1

as usual, bugreports, fixes and suggestions are welcome,

Ingo


2006-09-20 16:51:05

by Gene Heskett

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wednesday 20 September 2006 10:19, Ingo Molnar wrote:
>I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
>from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
>This port to the 2.6.18 codebase was very complex (given that 5 major
>features moved from -rt into 2.6.18: rtmutex, pi-futex, genirq, gtod and
>lockdep), so it took quite some time to finish, but in exchange it
>includes nice new features and also lots of bugfixes.
>
>In particular, a nasty softirq performance bug has been fixed, which
>caused the "5x slowdown under TCP" bug reported to lkml - those TCP
>performance figures are now on par with vanilla performance.
>
>The biggest new features are:
>
> - Dynticks (a tickless kernel). This is a new feature we implemented
> ontop of hrtimers for the -hrt patchqueue and now we merged it to -rt
> too. There's a new config option: CONFIG_NO_HZ, which if enabled,
> produces a system with fewer timer interrupts. Currently i686 and
> x86_64 are tested, but in general a hrtimers-ready platform needs
> minimal changes to support dynticks too. (from Thomas Gleixner and
> me, the x86_64 port is from Arjan van de Ven)
>
> - Timer expiry statistics feature from Thomas Gleixner:
> CONFIG_TIMER_STATS. Enable/disable via "echo 1[0] > /proc/tstats",
> display via "cat /proc/stats".
>
> This kernel feature tracks the starting site (and expiry function) of
> expired timers (both timer_list timers and hrtimers), and the number
> of times they expired. This is a nice tool for those who'd like to
> minimize the amount of timer ticks on their battery-based systems.
> Sample output:
>
> Timerstats sample period: 3.888770 s
> 12, 0 swapper hrtimer_stop_sched_tick
> (hrtimer_sched_tick) 15, 1 swapper hcd_submit_urb
> (rh_timer_func)
> 4, 959 kedac schedule_timeout (process_timeout)
> 1, 0 swapper page_writeback_init (wb_timer_fn)
> 28, 0 swapper hrtimer_stop_sched_tick
> (hrtimer_sched_tick) 22, 2948 IRQ 4 tty_flip_buffer_push
> (delayed_work_timer_fn) 3, 3100 bash schedule_timeout
> (process_timeout) 1, 1 swapper queue_delayed_work_on
> (delayed_work_timer_fn) 1, 1 swapper queue_delayed_work_on
> (delayed_work_timer_fn) 1, 1 swapper
> neigh_table_init_no_netlink (neigh_periodic_timer) 1, 2292 ip
> __netdev_watchdog_up (dev_watchdog) 1, 23 events/1
> do_cache_clean (delayed_work_timer_fn) 90 total events, 30.0 events/sec
>
> - There's also a new runtime-configurable kernel option under
> /proc/sys/kernel/timeout_granularity that allows the coarser expiry
> of timer_list timers, and hence better batching of timer expiry.
> (hrtimers are not affected) The value of this option gives a
> 'multiplier' to the standard HZ granularity.
>
> - Lock validator ported to -rt: it now checks all the sleeping lock
> variants in -rt too. This helps us catch not only deadlocks but also
> raw-lock candidates, sooner than before.
>
> - The latest High Resolution Timers queue from Thomas Gleixner with
> initial support for ARM and PPC. (Kevin Hilman, Deepak Saksena,
> Sergei Shtylyov)
>
> - The latest GTOD (Generic Time Of Day) queue from John Stultz,
> including NTP cleanups from Roman Zippel.
>
> - The latest genirq queue: more irq-chip-ization of i686 and x86_64,
> MSI cleanups from Eric W. Biederman et al.
>
> - The latest preemptible-RCU queue from Paul E McKenney and Dipankar
> Sarma.
>
> - (assorted fixes and improvements.)
>
>Right now i686 and x86_64 are boot-tested, and ARM is compile-tested.
>The other architectures likely wont even build yet. This being the first
>2.6.18 based release of -rt, some tester caution is called for.
>
>to build a 2.6.18-rt1 tree, the following patches should be applied:
>
> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2
> http://redhat.com/~mingo/realtime-preempt/patch-2.6.18-rt1
>
>as usual, bugreports, fixes and suggestions are welcome,
>
> Ingo
>
I hadn't built one of these in quite a while, mainly because I could never
get tvtime to run while booted to them, some sort of a dma related failure
I think, so I rather dropped off the path here.

But the announcement was enough to make me try to build it, sort of the
ultimate "can an old fart build it test", but the make exits with:

LD .tmp_vmlinux1
kernel/built-in.o(.text+0x16f25): In function `hrtimer_start':
: undefined reference to `hrtimer_update_timer_prio'
make: *** [.tmp_vmlinux1] Error 1

about half way thru the normal time. config attached. I don't think hires
timers are enabled.

Comments?

--
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)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.


Attachments:
(No filename) (4.91 kB)
.config (40.10 kB)
Download all attachments

2006-09-20 17:01:46

by Daniel Walker

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 12:50 -0400, Gene Heskett wrote:

> LD .tmp_vmlinux1
> kernel/built-in.o(.text+0x16f25): In function `hrtimer_start':
> : undefined reference to `hrtimer_update_timer_prio'
> make: *** [.tmp_vmlinux1] Error 1
>
> about half way thru the normal time. config attached. I don't think hires
> timers are enabled.
>
> Comments?
>

Fix attached.

Daniel


Attachments:
fix_hrt_build_issue.patch (550.00 B)

2006-09-20 17:06:35

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* Gene Heskett <[email protected]> wrote:

> LD .tmp_vmlinux1
> kernel/built-in.o(.text+0x16f25): In function `hrtimer_start':
> : undefined reference to `hrtimer_update_timer_prio'
> make: *** [.tmp_vmlinux1] Error 1

yeah, the !hrt build broke in the last minute, i've uploaded -rt2 with
the fix.

Ingo

2006-09-20 17:33:49

by Gene Heskett

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wednesday 20 September 2006 12:58, Ingo Molnar wrote:
>* Gene Heskett <[email protected]> wrote:
>> LD .tmp_vmlinux1
>>
>> kernel/built-in.o(.text+0x16f25): In function `hrtimer_start':
>> : undefined reference to `hrtimer_update_timer_prio'
>>
>> make: *** [.tmp_vmlinux1] Error 1
>
>yeah, the !hrt build broke in the last minute, i've uploaded -rt2 with
>the fix.
>
> Ingo
Link?

--
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)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

2006-09-20 17:38:10

by Paul E. McKenney

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, Sep 20, 2006 at 10:00:38AM -0700, Daniel Walker wrote:
> On Wed, 2006-09-20 at 12:50 -0400, Gene Heskett wrote:
>
> > LD .tmp_vmlinux1
> > kernel/built-in.o(.text+0x16f25): In function `hrtimer_start':
> > : undefined reference to `hrtimer_update_timer_prio'
> > make: *** [.tmp_vmlinux1] Error 1
> >
> > about half way thru the normal time. config attached. I don't think hires
> > timers are enabled.
> >
> > Comments?
> >
>
> Fix attached.
>
> Daniel

Compiles for me with this patch. Will try it out on a couple of machines.

Thanx, Paul

2006-09-20 17:42:06

by Daniel Walker

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 10:38 -0700, Paul E. McKenney wrote:
> On Wed, Sep 20, 2006 at 10:00:38AM -0700, Daniel Walker wrote:
> > On Wed, 2006-09-20 at 12:50 -0400, Gene Heskett wrote:
> >
> > > LD .tmp_vmlinux1
> > > kernel/built-in.o(.text+0x16f25): In function `hrtimer_start':
> > > : undefined reference to `hrtimer_update_timer_prio'
> > > make: *** [.tmp_vmlinux1] Error 1
> > >
> > > about half way thru the normal time. config attached. I don't think hires
> > > timers are enabled.
> > >
> > > Comments?
> > >
> >
> > Fix attached.
> >
> > Daniel
>
> Compiles for me with this patch. Will try it out on a couple of machines.
>

Ingo actually updated with a similar fix , in

http://people.redhat.com/~mingo/realtime-preempt/patch-2.6.18-rt2

Daniel

2006-09-20 18:23:28

by Gene Heskett

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wednesday 20 September 2006 13:41, Daniel Walker wrote:

[...]

>Ingo actually updated with a similar fix , in
>
>http://people.redhat.com/~mingo/realtime-preempt/patch-2.6.18-rt2
>
>Daniel

And that built, but I haven't rebooted yet, thats next.

--
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)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

2006-09-20 18:25:08

by Paul E. McKenney

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, Sep 20, 2006 at 10:41:58AM -0700, Daniel Walker wrote:
> On Wed, 2006-09-20 at 10:38 -0700, Paul E. McKenney wrote:
> > On Wed, Sep 20, 2006 at 10:00:38AM -0700, Daniel Walker wrote:
> > > On Wed, 2006-09-20 at 12:50 -0400, Gene Heskett wrote:
> > >
> > > > LD .tmp_vmlinux1
> > > > kernel/built-in.o(.text+0x16f25): In function `hrtimer_start':
> > > > : undefined reference to `hrtimer_update_timer_prio'
> > > > make: *** [.tmp_vmlinux1] Error 1
> > > >
> > > > about half way thru the normal time. config attached. I don't think hires
> > > > timers are enabled.
> > > >
> > > > Comments?
> > > >
> > >
> > > Fix attached.
> > >
> > > Daniel
> >
> > Compiles for me with this patch. Will try it out on a couple of machines.
> >
>
> Ingo actually updated with a similar fix , in
>
> http://people.redhat.com/~mingo/realtime-preempt/patch-2.6.18-rt2

OK, using that instead.

I get the following at startup, which probably means that I need to use
some machine other than a NUMA-Q. Trying a different machine...

Thanx, Paul

BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c01151ff
*pde = 34d21001
*pte = 00000000
stopped custom tracer.
Oops: 0000 [#1]
PREEMPT SMP
Modules linked in:
CPU: 2
EIP: 0060:[<c01151ff>] Not tainted VLI
EFLAGS: 00010246 (2.6.18-rt2-autokern1 #1)
EIP is at __wake_up_common+0x10/0x55
eax: 00000000 ebx: 00000001 ecx: c113629c edx: 00000000
esi: c113629c edi: c113629c ebp: dff25f34 esp: dff25f24
ds: 007b es: 007b ss: 0068 preempt: 00000001
Process softirq-timer/2 (pid: 27, ti=dff24000 task=dff20e30 task.ti=dff24000)
Stack: 00000000 00000000 c113629c 00000001 dff25f60 c0115267 c113629c 00000006
00000001 00000001 00000000 00000006 00000007 dffd5e40 c1136270 c1136240
c012ecf6 00000000 00000001 c11360e4 00000001 00000000 dff12000 c043b2c0
Call Trace:
[<c0115267>] __wake_up+0x23/0x52
[<c012ecf6>] hrtimer_run_queues+0xf6/0x10f
[<c0123db3>] run_timer_softirq+0x13b/0x31b
[<c011fba0>] ksoftirqd+0xff/0x194
[<c011faa1>] ksoftirqd+0x0/0x194
[<c012beee>] kthread+0x82/0xa7
[<c012be6c>] kthread+0x0/0xa7
[<c0101031>] kernel_thread_helper+0x5/0xb
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c02fd493>] .... __spin_lock_irqsave+0xe/0x35
.....[<00000000>] .. ( <= _stext+0x3feffd68/0x41)

Code: 45 14 00 00 00 00 8b 45 08 83 ca 01 89 55 0c 8b 40 04 89 45 08 5d e9 62 e2 ff ff 55 89 e5 57 56 53 50 8b 7d 08 8b 5d 10 8b 57 20 <8b> 02 89 45 f0 8d 47 20 39 c2 74 31 8b 72 f4 8d 42 f4 ff 75 18
EIP: [<c01151ff>] __wake_up_common+0x10/0x55 SS:ESP 0068:dff25f24

2006-09-20 18:34:09

by Daniel Walker

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 11:25 -0700, Paul E. McKenney wrote:

> OK, using that instead.
>
> I get the following at startup, which probably means that I need to use
> some machine other than a NUMA-Q. Trying a different machine...
>
> Thanx, Paul
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
> printing eip:
> c01151ff
> *pde = 34d21001
> *pte = 00000000
> stopped custom tracer.
> Oops: 0000 [#1]
> PREEMPT SMP
> Modules linked in:
> CPU: 2
> EIP: 0060:[<c01151ff>] Not tainted VLI
> EFLAGS: 00010246 (2.6.18-rt2-autokern1 #1)
> EIP is at __wake_up_common+0x10/0x55

I get this too, it happens when HRT is off.. If you turn HRT on it will
boot .. I haven't found a fix for it, but I imagine Thomas will find it
soon.

Daniel

2006-09-20 18:34:35

by Gene Heskett

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wednesday 20 September 2006 12:58, Ingo Molnar wrote:
>* Gene Heskett <[email protected]> wrote:
>> LD .tmp_vmlinux1
>>
>> kernel/built-in.o(.text+0x16f25): In function `hrtimer_start':
>> : undefined reference to `hrtimer_update_timer_prio'
>>
>> make: *** [.tmp_vmlinux1] Error 1
>
>yeah, the !hrt build broke in the last minute, i've uploaded -rt2 with
>the fix.
>
And that one does an Opps during boot & freezes. The first line says
something about being unable to handle a dereference of $00000000, and
goes on from there. Its about 2 screens full, so I'd have to take a pix
to get any more really accurate data.

I guess we could say the "can an old fart build it" test failed :)

> Ingo
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/

--
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)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

2006-09-20 18:39:55

by Gene Heskett

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wednesday 20 September 2006 14:25, Paul E. McKenney wrote:
>On Wed, Sep 20, 2006 at 10:41:58AM -0700, Daniel Walker wrote:
>> On Wed, 2006-09-20 at 10:38 -0700, Paul E. McKenney wrote:
>> > On Wed, Sep 20, 2006 at 10:00:38AM -0700, Daniel Walker wrote:
>> > > On Wed, 2006-09-20 at 12:50 -0400, Gene Heskett wrote:
>> > > > LD .tmp_vmlinux1
>> > > >
>> > > > kernel/built-in.o(.text+0x16f25): In function `hrtimer_start':
>> > > > : undefined reference to `hrtimer_update_timer_prio'
>> > > >
>> > > > make: *** [.tmp_vmlinux1] Error 1
>> > > >
>> > > > about half way thru the normal time. config attached. I don't
>> > > > think hires timers are enabled.
>> > > >
>> > > > Comments?
>> > >
>> > > Fix attached.
>> > >
>> > > Daniel
>> >
>> > Compiles for me with this patch. Will try it out on a couple of
>> > machines.
>>
>> Ingo actually updated with a similar fix , in
>>
>> http://people.redhat.com/~mingo/realtime-preempt/patch-2.6.18-rt2
>
>OK, using that instead.
>
>I get the following at startup, which probably means that I need to use
>some machine other than a NUMA-Q. Trying a different machine...
>
> Thanx, Paul
>
>BUG: unable to handle kernel NULL pointer dereference at virtual address
> 00000000 printing eip:
>c01151ff
>*pde = 34d21001
>*pte = 00000000
>stopped custom tracer.
>Oops: 0000 [#1]
>PREEMPT SMP
>Modules linked in:
>CPU: 2
>EIP: 0060:[<c01151ff>] Not tainted VLI
>EFLAGS: 00010246 (2.6.18-rt2-autokern1 #1)
>EIP is at __wake_up_common+0x10/0x55
>eax: 00000000 ebx: 00000001 ecx: c113629c edx: 00000000
>esi: c113629c edi: c113629c ebp: dff25f34 esp: dff25f24
>ds: 007b es: 007b ss: 0068 preempt: 00000001
>Process softirq-timer/2 (pid: 27, ti=dff24000 task=dff20e30
> task.ti=dff24000) Stack: 00000000 00000000 c113629c 00000001 dff25f60
> c0115267 c113629c 00000006 00000001 00000001 00000000 00000006 00000007
> dffd5e40 c1136270 c1136240 c012ecf6 00000000 00000001 c11360e4 00000001
> 00000000 dff12000 c043b2c0 Call Trace:
> [<c0115267>] __wake_up+0x23/0x52
> [<c012ecf6>] hrtimer_run_queues+0xf6/0x10f
> [<c0123db3>] run_timer_softirq+0x13b/0x31b
> [<c011fba0>] ksoftirqd+0xff/0x194
> [<c011faa1>] ksoftirqd+0x0/0x194
> [<c012beee>] kthread+0x82/0xa7
> [<c012be6c>] kthread+0x0/0xa7
> [<c0101031>] kernel_thread_helper+0x5/0xb
>---------------------------
>
>| preempt count: 00000001 ]
>| 1-level deep critical section nesting:
>
>----------------------------------------
>.. [<c02fd493>] .... __spin_lock_irqsave+0xe/0x35
>.....[<00000000>] .. ( <= _stext+0x3feffd68/0x41)
>
>Code: 45 14 00 00 00 00 8b 45 08 83 ca 01 89 55 0c 8b 40 04 89 45 08 5d
> e9 62 e2 ff ff 55 89 e5 57 56 53 50 8b 7d 08 8b 5d 10 8b 57 20 <8b> 02
> 89 45 f0 8d 47 20 39 c2 74 31 8b 72 f4 8d 42 f4 ff 75 18 EIP:
> [<c01151ff>] __wake_up_common+0x10/0x55 SS:ESP 0068:dff25f24

That looks like the chorus of the song I saw when it crashed on boot,
pretty darned close to identical.

--
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)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

2006-09-20 18:46:11

by Thomas Gleixner

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 14:36 -0400, Gene Heskett wrote:
> That looks like the chorus of the song I saw when it crashed on boot,
> pretty darned close to identical.

I can reproduce it. It happens when CONFIG_HIGH_RES_TIMERS is off.
Looking into it right now.

tglx


2006-09-20 18:57:38

by K.R. Foley

[permalink] [raw]
Subject: Re: 2.6.18-rt1

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.18-rt1
# Wed Sep 20 10:48:34 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_CPUSETS=y
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"

#
# Processor type and features
#
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HIGH_RES_RESOLUTION=1000
CONFIG_NO_HZ=y
CONFIG_SMP=y
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 is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# 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_MGEODEGX1 is not set
# CONFIG_MGEODE_LX 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_RWSEM_GENERIC_SPINLOCK=y
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_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
# CONFIG_HPET_TIMER is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# 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_BKL=y
# CONFIG_CLASSIC_RCU is not set
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_TRACE=y
CONFIG_ASM_SEMAPHORES=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_DELL_RBU is not set
CONFIG_DCDBAS=m
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_REGPARM=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_KEXEC is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_HOTPLUG_CPU is not set
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_COMPAT_VDSO=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=y
CONFIG_ACPI_IBM=y
# CONFIG_ACPI_IBM_DOCK is not set
CONFIG_ACPI_TOSHIBA=y
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# 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_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA_DMA_API=y
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

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=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_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y

#
# 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_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NETFILTER_XTABLES is not set

#
# 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_CONNTRACK_EVENTS 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_NETBIOS_NS is not set
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
# CONFIG_IP_NF_PPTP is not set
# CONFIG_IP_NF_H323 is not set
# CONFIG_IP_NF_SIP is not set
CONFIG_IP_NF_QUEUE=m

#
# Bridge: Netfilter Configuration
#
# CONFIG_BRIDGE_NF_EBTABLES is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC 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=m
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_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

#
# Queueing/Scheduling
#
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

#
# Classification
#
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_CLS_U32_MARK is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
# CONFIG_NET_CLS_POLICE is not set
# CONFIG_NET_CLS_IND is not set
# CONFIG_NET_ESTIMATOR is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR 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
CONFIG_PNPACPI=y

#
# 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_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# 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_CS5535 is not set
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_IT821X is not set
# 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_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_RAID_ATTRS is not set
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
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=m
# CONFIG_CHR_DEV_SCH is not set

#
# 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
# CONFIG_SCSI_SAS_ATTRS is not set

#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
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=m
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_ADVANSYS is not set
CONFIG_SCSI_IN2000=m
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_HPTIOP 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_MMIO=y
# CONFIG_SCSI_IPR is not set
CONFIG_SCSI_PAS16=m
CONFIG_SCSI_PSI240I=m
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_1280=m
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_LPFC 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_RAID456 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
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Network device support
#
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

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
# CONFIG_CASSINI is not set
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_ULI526X 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_VIA_RHINE_NAPI is not set

#
# 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_E1000_DISABLE_PACKET_SPLIT is not set
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_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
CONFIG_SK98LIN=m
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=m
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE 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_DUMMY is not set
# 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_PPP_MPPE 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
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y

#
# 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

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_ESPSERIAL is not set
# CONFIG_MOXA_INTELLIO 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_SYNCLINK_GT is not set
# CONFIG_N_HDLC is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# 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 is not set
# CONFIG_BLOCKER is not set
# CONFIG_LPPTEST is not set
# 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_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#

#
# Hardware Monitoring support
#
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
CONFIG_VIDEO_V4L2=y

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_USB_DABUSB is not set

#
# Graphics support
#
CONFIG_FIRMWARE_EDID=y
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT 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_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_FB_HGA=m
# CONFIG_FB_HGA_ACCEL is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA 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 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_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=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_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_AC97_BUS=m
# 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_ADLIB is not set
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_DT019X 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_OPL3SA2 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_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set

#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# 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_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X 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_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM 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_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI 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_OSS_OBSOLETE_DRIVER is not set
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ICH 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

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=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_SUSPEND 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_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD 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_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
# CONFIG_USB_LIBUSUAL is not set

#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# 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_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# 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_CYPRESS_CY7C63 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_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set

#
# USB DSL modem support
#
# CONFIG_USB_ATM is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# LED devices
#
# CONFIG_NEW_LEDS is not set

#
# LED drivers
#

#
# LED Triggers
#

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set

#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set

#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set

#
# DMA Clients
#

#
# DMA Devices
#

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP 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
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
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
# CONFIG_FUSE_FS is not set

#
# 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_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set

#
# 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
# CONFIG_UFS_DEBUG is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_COMMON=y
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
# CONFIG_9P_FS is not set

#
# 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_KARMA_PARTITION is not set
# 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

#
# Instrumentation Support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
CONFIG_PROFILE_NMI=y
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_RWSEMS is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_WAKEUP_TIMING is not set
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
CONFIG_FRAME_POINTER=y
CONFIG_UNWIND_INFO=y
# CONFIG_STACK_UNWIND is not set
CONFIG_FORCED_INLINING=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
# CONFIG_SECURITY_SECLVL 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 is not set
# 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_CRC16 is not set
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_PLIST=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y


Attachments:
krfc3.config (38.94 kB)

2006-09-20 19:19:12

by Thomas Gleixner

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 20:47 +0200, Thomas Gleixner wrote:
> On Wed, 2006-09-20 at 14:36 -0400, Gene Heskett wrote:
> > That looks like the chorus of the song I saw when it crashed on boot,
> > pretty darned close to identical.
>
> I can reproduce it. It happens when CONFIG_HIGH_RES_TIMERS is off.
> Looking into it right now.

Fix below.

tglx

Index: linux-2.6.18/kernel/hrtimer.c
===================================================================
--- linux-2.6.18.orig/kernel/hrtimer.c 2006-09-20 19:10:05.000000000 +0200
+++ linux-2.6.18/kernel/hrtimer.c 2006-09-20 21:11:26.000000000 +0200
@@ -873,9 +873,6 @@ static inline void hrtimer_init_hres(str
set_bit(0, &base->check_clocks);
base->hres_active = 0;
hrtimer_init_base_cb_pending(base);
-#ifdef CONFIG_PREEMPT_SOFTIRQS
- init_waitqueue_head(&base->wait);
-#endif
}

static inline int hrtimer_enqueue_reprogram(struct hrtimer *timer,
@@ -1643,6 +1640,9 @@ static void __devinit init_hrtimers_cpu(
cpu_base->clock_base[i].cpu_base = cpu_base;

hrtimer_init_hres(cpu_base);
+#ifdef CONFIG_PREEMPT_SOFTIRQS
+ init_waitqueue_head(&cpu_base->wait);
+#endif
}

#ifdef CONFIG_HOTPLUG_CPU


2006-09-20 19:38:57

by Mark Knecht

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On 9/20/06, Ingo Molnar <[email protected]> wrote:
> I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>

Hi Ingo,
I gave 2.6.18-rt2 a quick try. It compiled fine but crashed on
boot. I've no way to copy the screen. I can send along a digital photo
if the following isn't enough info.

QUESTION: Should I be able to run ati-drivers-8.28.8 with this kernel
or would I have to wait for ATI to put out a 2.6.18 compatible driver?
The current version does not emerge with 2.6.18-rt2.

CRASH INFO:

Unable to handle kernel null pointer derefernce at 0000000000000000 RIP
[< ffffffff80228ae4 >] __wake_up_common+0x24/0x68
PGD 3d6e7067 PUD 3d638067 PMD 0
Oops: 0000 [1] PREEMPT SMP
CPU
Modules linked in:
Pid: 5, comm:softirq-timer/0 Not tainted 2.6.18-rt2 #2

There is a bunch of debug stuff that follows and then finally a trace:

__wake_up
hrt_time_run_queue
run_timer_softirq
kthread
child_rip
DWARF2 unwinder stuck at child_rip

more stuff......

preempt count: 00000001
1-level deep critical nesting:

__spin_trylock


Not sure how much that will help you. Been awhile since I've sent
along crash reports. I'll have to ge a second Linux machine running to
do the console boot capture thing if you need it.

Hope this helps,
Mark

2006-09-20 19:54:58

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* Gene Heskett <[email protected]> wrote:

> That looks like the chorus of the song I saw when it crashed on boot,
> pretty darned close to identical.

ok, i've uploaded -rt3:

http://redhat.com/~mingo/realtime-preempt/

this should have this one fixed.

Ingo

2006-09-20 19:57:42

by Thomas Gleixner

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 13:56 -0500, K.R. Foley wrote:
> EIP: 0060:[<c0130ad4>] Not tainted VLI
> EFLAGS: 00010297 (2.6.17-rt8 #4)

----------------------^^^^^^^^^^^^^

Are you sure, that kernel and .config are related ?

tglx


2006-09-20 19:57:50

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* K.R. Foley <[email protected]> wrote:

> Ingo Molnar wrote:
> > I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> > from the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
>
> I got the following oops when trying to boot the above. Config is attached.

maybe it's not the right kernel image (2.6.17):

> EFLAGS: 00010297 (2.6.17-rt8 #4)

mixed with 2.6.18 modules?

Ingo

2006-09-20 20:05:40

by Paul E. McKenney

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, Sep 20, 2006 at 11:34:00AM -0700, Daniel Walker wrote:
> On Wed, 2006-09-20 at 11:25 -0700, Paul E. McKenney wrote:
> >
> > BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
> > printing eip:
> > c01151ff
> > *pde = 34d21001
> > *pte = 00000000
> > stopped custom tracer.
> > Oops: 0000 [#1]
> > PREEMPT SMP
> > Modules linked in:
> > CPU: 2
> > EIP: 0060:[<c01151ff>] Not tainted VLI
> > EFLAGS: 00010246 (2.6.18-rt2-autokern1 #1)
> > EIP is at __wake_up_common+0x10/0x55
>
> I get this too, it happens when HRT is off.. If you turn HRT on it will
> boot .. I haven't found a fix for it, but I imagine Thomas will find it
> soon.

Enabling HRT works for me too -- thanks to you and Thomas for the hint!

Thanx, Paul

2006-09-20 20:17:27

by Gene Heskett

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wednesday 20 September 2006 14:34, Daniel Walker wrote:
>On Wed, 2006-09-20 at 11:25 -0700, Paul E. McKenney wrote:
>> OK, using that instead.
>>
>> I get the following at startup, which probably means that I need to use
>> some machine other than a NUMA-Q. Trying a different machine...
>>
>> Thanx, Paul
>>
>> BUG: unable to handle kernel NULL pointer dereference at virtual
>> address 00000000 printing eip:
>> c01151ff
>> *pde = 34d21001
>> *pte = 00000000
>> stopped custom tracer.
>> Oops: 0000 [#1]
>> PREEMPT SMP
>> Modules linked in:
>> CPU: 2
>> EIP: 0060:[<c01151ff>] Not tainted VLI
>> EFLAGS: 00010246 (2.6.18-rt2-autokern1 #1)
>> EIP is at __wake_up_common+0x10/0x55
>
>I get this too, it happens when HRT is off.. If you turn HRT on it will
>boot .. I haven't found a fix for it, but I imagine Thomas will find it
>soon.
>
>Daniel

I'm re-building with HRT on now, but I just noticed another side effect of
2.6.18. I have an led sniffer plugged into the pl2302 usb<->serial
adaptor laying where I can see it, and all leds are red, as if the
interface has not been inited properly. And I don't see it being
initialized in the dmesg. I thought the default was to build it. Yup,
pl2303.ko is present in the /lib/modules trees all across the board.

Any ideas on this one folks?

--
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)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

2006-09-20 20:19:56

by Daniel Walker

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 21:46 +0200, Ingo Molnar wrote:
> * Gene Heskett <[email protected]> wrote:
>
> > That looks like the chorus of the song I saw when it crashed on boot,
> > pretty darned close to identical.
>
> ok, i've uploaded -rt3:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> this should have this one fixed.
>
> Ingo

What about the !PREEMPT_RT case.. It still wouldn't disable interrupts
in the below..


- local_irq_save(flags);
if (up->port.sysrq) {
/* serial8250_handle_port() already took the lock */
locked = 0;
} else if (oops_in_progress) {
- locked = spin_trylock(&up->port.lock);
+ locked = spin_trylock_irqsave(&up->port.lock, flags);
} else
- spin_lock(&up->port.lock);
+ spin_lock_irqsave(&up->port.lock, flags);



2006-09-20 20:23:07

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* Daniel Walker <[email protected]> wrote:

> What about the !PREEMPT_RT case.. It still wouldn't disable interrupts
> in the below..
>
> - local_irq_save(flags);
> if (up->port.sysrq) {
> /* serial8250_handle_port() already took the lock */
> locked = 0;
> } else if (oops_in_progress) {
> - locked = spin_trylock(&up->port.lock);
> + locked = spin_trylock_irqsave(&up->port.lock, flags);
> } else
> - spin_lock(&up->port.lock);
> + spin_lock_irqsave(&up->port.lock, flags);

_irqsave disables interrupts, always did.

Ingo

2006-09-20 20:27:41

by Mark Knecht

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On 9/20/06, Mark Knecht <[email protected]> wrote:
> On 9/20/06, Ingo Molnar <[email protected]> wrote:
> > I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> > from the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
>
> Hi Ingo,
> I gave 2.6.18-rt2 a quick try. It compiled fine but crashed on
> boot.

Hi again Ingo.
2.6.18-rt3 booted. For some reason a number of drivers either
didn't get built or didn't get loaded. I'm looking into that now:

lightning ~ # lsmod
Module Size Used by
lightning ~ #

I am wrting you from the machine running the new kernel so we're
making headway.

I spot this in dmesg though:

EXT3-fs: mounted filesystem with ordered data mode.
Adding 2008084k swap on /dev/sda10. Priority:-1 extents:1 across:2008084k
eth0: no IPv6 routers present
BUG: time warp detected!
prev > now, 1014d39b1fe7c3e8 > 1014d39b063d8631:
= 430587319 delta, on CPU#0

Call Trace:
[<ffffffff8020b15c>] dump_stack+0x12/0x17
[<ffffffff8023ba68>] getnstimeofday+0x131/0x13c
[<ffffffff80247bfa>] ktime_get_ts+0x1a/0x4e
[<ffffffff8022ffac>] copy_process+0x449/0x159c
[<ffffffff802312e7>] do_fork+0xd0/0x1d4
[<ffffffff80209c7b>] ptregscall_common+0x67/0xac
DWARF2 unwinder stuck at ptregscall_common+0x67/0xac
Leftover inexact backtrace:

---------------------------
| preempt count: 00000000 ]
| 0-level deep critical section nesting:
----------------------------------------

My kernel config is attached.

Cheers,
Mark


Attachments:
(No filename) (1.47 kB)
KNECHT-2.6.18-rt3.config (31.40 kB)
Download all attachments

2006-09-20 20:31:37

by Daniel Walker

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 22:14 +0200, Ingo Molnar wrote:
> > if (up->port.sysrq) {
> > /* serial8250_handle_port() already took the lock */
> > locked = 0;


In this case it had interrupts off in the !PREEMPT_RT case, but your
change leaves them on here.. _irqsave only runs in two of the three
cases..

Daniel

2006-09-20 20:33:15

by K.R. Foley

[permalink] [raw]
Subject: Re: 2.6.18-rt1

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.18-rt2
# Wed Sep 20 14:42:21 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_CPUSETS=y
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"

#
# Processor type and features
#
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_SMP=y
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 is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# 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_MGEODEGX1 is not set
# CONFIG_MGEODE_LX 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_RWSEM_GENERIC_SPINLOCK=y
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_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
# CONFIG_HPET_TIMER is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# 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_BKL=y
# CONFIG_CLASSIC_RCU is not set
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_TRACE=y
CONFIG_ASM_SEMAPHORES=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_DELL_RBU is not set
CONFIG_DCDBAS=m
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_REGPARM=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_KEXEC is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_HOTPLUG_CPU is not set
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_COMPAT_VDSO=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=y
CONFIG_ACPI_IBM=y
# CONFIG_ACPI_IBM_DOCK is not set
CONFIG_ACPI_TOSHIBA=y
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# 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_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA_DMA_API=y
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

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=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_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y

#
# 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_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NETFILTER_XTABLES is not set

#
# 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_CONNTRACK_EVENTS 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_NETBIOS_NS is not set
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
# CONFIG_IP_NF_PPTP is not set
# CONFIG_IP_NF_H323 is not set
# CONFIG_IP_NF_SIP is not set
CONFIG_IP_NF_QUEUE=m

#
# Bridge: Netfilter Configuration
#
# CONFIG_BRIDGE_NF_EBTABLES is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC 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=m
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_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

#
# Queueing/Scheduling
#
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

#
# Classification
#
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_CLS_U32_MARK is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
# CONFIG_NET_CLS_POLICE is not set
# CONFIG_NET_CLS_IND is not set
# CONFIG_NET_ESTIMATOR is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR 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
CONFIG_PNPACPI=y

#
# 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_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# 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_CS5535 is not set
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_IT821X is not set
# 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_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_RAID_ATTRS is not set
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
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=m
# CONFIG_CHR_DEV_SCH is not set

#
# 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
# CONFIG_SCSI_SAS_ATTRS is not set

#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
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=m
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_ADVANSYS is not set
CONFIG_SCSI_IN2000=m
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_HPTIOP 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_MMIO=y
# CONFIG_SCSI_IPR is not set
CONFIG_SCSI_PAS16=m
CONFIG_SCSI_PSI240I=m
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_1280=m
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_LPFC 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_RAID456 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
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Network device support
#
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

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
# CONFIG_CASSINI is not set
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_ULI526X 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_VIA_RHINE_NAPI is not set

#
# 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_E1000_DISABLE_PACKET_SPLIT is not set
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_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
CONFIG_SK98LIN=m
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=m
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE 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_DUMMY is not set
# 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_PPP_MPPE 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
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y

#
# 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

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_ESPSERIAL is not set
# CONFIG_MOXA_INTELLIO 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_SYNCLINK_GT is not set
# CONFIG_N_HDLC is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# 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 is not set
# CONFIG_BLOCKER is not set
# CONFIG_LPPTEST is not set
# 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_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#

#
# Hardware Monitoring support
#
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
CONFIG_VIDEO_V4L2=y

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_USB_DABUSB is not set

#
# Graphics support
#
CONFIG_FIRMWARE_EDID=y
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT 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_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_FB_HGA=m
# CONFIG_FB_HGA_ACCEL is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA 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 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_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=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_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_AC97_BUS=m
# 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_ADLIB is not set
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_DT019X 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_OPL3SA2 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_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set

#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# 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_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X 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_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM 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_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI 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_OSS_OBSOLETE_DRIVER is not set
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ICH 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

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=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_SUSPEND 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_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD 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_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
# CONFIG_USB_LIBUSUAL is not set

#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# 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_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# 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_CYPRESS_CY7C63 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_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set

#
# USB DSL modem support
#
# CONFIG_USB_ATM is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# LED devices
#
# CONFIG_NEW_LEDS is not set

#
# LED drivers
#

#
# LED Triggers
#

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set

#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set

#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set

#
# DMA Clients
#

#
# DMA Devices
#

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP 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
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
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
# CONFIG_FUSE_FS is not set

#
# 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_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set

#
# 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
# CONFIG_UFS_DEBUG is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_COMMON=y
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
# CONFIG_9P_FS is not set

#
# 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_KARMA_PARTITION is not set
# 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

#
# Instrumentation Support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
CONFIG_PROFILE_NMI=y
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_RWSEMS is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_WAKEUP_TIMING is not set
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
CONFIG_FRAME_POINTER=y
CONFIG_UNWIND_INFO=y
# CONFIG_STACK_UNWIND is not set
CONFIG_FORCED_INLINING=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
# CONFIG_SECURITY_SECLVL 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 is not set
# 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_CRC16 is not set
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_PLIST=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y


Attachments:
config-2.6.18-rt2 (38.90 kB)

2006-09-20 20:34:50

by K.R. Foley

[permalink] [raw]
Subject: Re: 2.6.18-rt1

Thomas Gleixner wrote:
> On Wed, 2006-09-20 at 13:56 -0500, K.R. Foley wrote:
>> EIP: 0060:[<c0130ad4>] Not tainted VLI
>> EFLAGS: 00010297 (2.6.17-rt8 #4)
>
> ----------------------^^^^^^^^^^^^^
>
> Are you sure, that kernel and .config are related ?
>
> tglx

Not at all. See my response to Ingo.

--
kr

2006-09-20 20:39:53

by Thomas Gleixner

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 15:33 -0500, K.R. Foley wrote:
> DOH! The log had two different boots in it. :( Let's try this again. By
> the way, you may notice from my screw up that this is pretty much the
> same oops that I got with 2.6.17-rt*. I have been getting this on all of
> my SMP systems since we went past 2.6.16.

Which module is modprobed ?

tglx


2006-09-20 20:50:38

by K.R. Foley

[permalink] [raw]
Subject: Re: 2.6.18-rt1

Thomas Gleixner wrote:
> On Wed, 2006-09-20 at 15:33 -0500, K.R. Foley wrote:
>> DOH! The log had two different boots in it. :( Let's try this again. By
>> the way, you may notice from my screw up that this is pretty much the
>> same oops that I got with 2.6.17-rt*. I have been getting this on all of
>> my SMP systems since we went past 2.6.16.
>
> Which module is modprobed ?
>
> tglx
>
>
>
How can I tell which particular module is being loaded? The last thing I
see on the console before the oops is that it is starting udev. I am
including the rest of the boot log below in hopes that will help.
Suggestions? Something else I can provide?

Linux version 2.6.18-rt2 (aaektkf@krfc3) (gcc version 3.4.4 20050721
(Red Hat 3.4.4-2)) #4 SMP PREEMPT Wed Sep 20 14:53:58 CDT 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ff70000 (usable)
BIOS-e820: 000000001ff70000 - 000000001ff77000 (ACPI data)
BIOS-e820: 000000001ff77000 - 000000001ff80000 (ACPI NVS)
BIOS-e820: 000000001ff80000 - 0000000020000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000f6b00
DMI present.
ACPI: PM-Timer IO Port: 0x1008
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
Processor #6 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
Processor #7 15:2 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfec80000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 32, address 0xfec80000, GSI 24-47
ACPI: IOAPIC (id[0x04] address[0xfec80100] gsi_base[48])
IOAPIC[2]: apic_id 4, version 32, address 0xfec80100, GSI 48-71
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Enabling APIC mode: Flat. Using 3 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000)
Detected 2591.683 MHz processor.
Real-Time Preemption Support (C) 2004-2006 Ingo Molnar
Built 1 zonelists. Total pages: 130928
Kernel command line: ro root=LABEL=/ console=ttyS0,38400 console=tty0
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
WARNING: experimental RCU implementation.
Event source pit configured with caps set: 03
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 509756k/523712k available (1753k kernel code, 13568k reserved,
1407k data, 196k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 5185.26 BogoMIPS
(lpj=2592634)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 12k freed
ACPI: Core revision 20060707
CPU0: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Booting processor 1/1 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 5182.45 BogoMIPS
(lpj=2591226)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Booting processor 2/6 eip 2000
Initializing CPU#2
Calibrating delay using timer specific routine.. 5182.51 BogoMIPS
(lpj=2591258)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#2.
CPU2: Intel P4/Xeon Extended MCE MSRs (12) available
CPU2: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Booting processor 3/7 eip 2000
Initializing CPU#3
Calibrating delay using timer specific routine.. 5182.53 BogoMIPS
(lpj=2591268)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#3.
CPU3: Intel P4/Xeon Extended MCE MSRs (12) available
CPU3: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Total of 4 processors activated (20732.77 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
lapic max_delta_ns: 1346568721
Event source pit new caps set: 01
Event source lapic configured with caps set: 02
checking TSC synchronization across 4 CPUs: passed.
Event source pit new caps set: 01
Event source lapic configured with caps set: 02
Event source pit new caps set: 01
Event source lapic configured with caps set: 02
Event source pit new caps set: 01
Event source lapic configured with caps set: 02
Brought up 4 CPUs
checking if image is initramfs... it is
Freeing initrd memory: 295k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd915, last bus=5
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
* The chipset may have PM-Timer Bug. Due to workarounds for a bug,
* this clock source is slow. If you are sure your timer does not have
* this bug, please use "acpi_pm_good" to disable the workaround
PCI quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 10 11 14 15) *5
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 *10 11 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 10 *11 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnPACPI: METHOD_NAME__CRS failure for PNP0401
pnp: PnP ACPI: found 12 devices
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a
report
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: e1000000-e1ffffff
PREFETCH window: ec000000-f7ffffff
PCI: Bridge: 0000:02:1d.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:02:1f.0
IO window: disabled.
MEM window: e2100000-e21fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:02.0
IO window: disabled.
MEM window: e2000000-e21fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
IO window: 2000-2fff
MEM window: e2200000-e22fffff
PREFETCH window: 30000000-300fffff
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 7, 655360 bytes)
TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
Simple Boot Flag at 0x36 set to 0x1
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ibm_acpi: ec object not found
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12ac
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
ICH4: chipset revision 2
ICH4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1460-0x1467, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1468-0x146f, BIOS settings: hdc:DMA, hdd:pio
hda: WDC WD800BB-75CAA0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: SONY DVD RW DW-U18A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: Host Protected Area detected.
current capacity is 156250000 sectors (80000 MB)
native capacity is 156301488 sectors (80026 MB)
hda: Host Protected Area disabled.
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63,
UDMA(100)
hda: cache flushes not supported
hda: hda1 hda2 < hda5 hda6 hda7 >
PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 8
NET: Registered protocol family 20
Starting balanced_irq
Using IPI Shortcut mode
Freeing unused kernel memory: 196k freed
Time: tsc clocksource has been installed.
input: AT Translated Set 2 keyboard as /class/input/input0
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
BUG: unable to handle kernel paging request at virtual address f3010000
printing eip:
*pde = 00000000
Oops: 0000 [#1]
PREEMPT SMP
Modules linked in:
CPU: 1
EIP: 0060:[<c0131e02>] Not tainted VLI
EFLAGS: 00010283 (2.6.18-rt2 #4)
EIP is at lookup_symbol+0x11/0x35
eax: 00000001 ebx: e0830e08 ecx: c036ff60 edx: c036dd94
esi: f3010000 edi: e0830e08 ebp: df657e74 esp: df657e68
ds: 007b es: 007b ss: 0068 preempt: 00000001
Process modprobe (pid: 1366, ti=df656000 task=dfc68e90 task.ti=df656000)
Stack: e083c780 00000c00 e0830e08 df657e90 c0131e6f df657ea8 df657ea4
e083c780
00000c00 e0830e08 df657eb8 c0132c21 00000001 00000012 e082d074
00000000
df657ecc e083a434 00000c00 e082d074 df657edc c0133188 e083c780
00000000
Call Trace:
[<c01037a1>] show_stack_log_lvl+0x87/0x8f
[<c010391b>] show_registers+0x12f/0x198
[<c0103b0c>] die+0x114/0x1c6
[<c0111196>] do_page_fault+0x3f2/0x4c8
[<c0103481>] error_code+0x39/0x40
[<c0131e6f>] __find_symbol+0x25/0x2a5
[<c0132c21>] resolve_symbol+0x27/0x5f
[<c0133188>] simplify_symbols+0x83/0xf3
[<c0133e65>] load_module+0x720/0xbb8
[<c013435f>] sys_init_module+0x3f/0x1b5
[<c0102969>] sysenter_past_esp+0x56/0x79
Code: eb 11 8b 75 f0 41 83 c2 28 0f b7 46 30 39 c1 72 c9 31 c0 5a 59 5b
5e 5f 5d c3 55 89 e5 57 56 53 89 c3 39 ca 73 22 8b 72 04 89 df <ac> ae
75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 04 89
EIP: [<c0131e02>] lookup_symbol+0x11/0x35 SS:ESP 0068:df657e68



--
kr

2006-09-20 20:54:22

by Michal Piotrowski

[permalink] [raw]
Subject: Re: 2.6.18-rt1

Hi,

On 20/09/06, Ingo Molnar <[email protected]> wrote:
> I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>

2.6.18-rt3

Ingo, can you take a look at this bugs?

BUG: scheduling with irqs disabled: softirq-timer/1/0x00000001/17
caller is rt_spin_lock_slowlock+0x121/0x1af
[<c0104356>] show_trace_log_lvl+0x68/0x193
[<c0104a5a>] show_trace+0x1b/0x20
[<c0104b38>] dump_stack+0x1f/0x24
[<c02edb34>] schedule+0x69/0xe3
[<c02ee8c0>] rt_spin_lock_slowlock+0x121/0x1af
[<c02eef4f>] rt_spin_lock+0x10/0x2c
[<c0171d6d>] __kmalloc+0xad/0x115
[<c020c146>] soft_cursor+0x52/0x16c
[<c020c00b>] bit_cursor+0x483/0x498
[<c02071ab>] fbcon_cursor+0x218/0x24d
[<c0244ac1>] hide_cursor+0x22/0x61
[<c024811f>] vt_console_print+0x91/0x207
[<c0120d31>] __call_console_drivers+0x6f/0x8c
[<c0120dac>] _call_console_drivers+0x5e/0x67
[<c0121367>] release_console_sem+0x132/0x1f2
[<c0121051>] vprintk+0x28d/0x2f5
[<c01210d3>] printk+0x1a/0x1c
[<c0129ab3>] run_timer_softirq+0x77b/0xbb6
[<c012632c>] ksoftirqd+0x11d/0x200
[<c013386b>] kthread+0xc7/0xf8
[<c0101005>] kernel_thread_helper+0x5/0xb
DWARF2 unwinder stuck at kernel_thread_helper+0x5/0xb
Leftover inexact backtrace:
[<c0104a5a>] show_trace+0x1b/0x20
[<c0104b38>] dump_stack+0x1f/0x24
[<c02edb34>] schedule+0x69/0xe3
[<c02ee8c0>] rt_spin_lock_slowlock+0x121/0x1af
[<c02eef4f>] rt_spin_lock+0x10/0x2c
[<c0171d6d>] __kmalloc+0xad/0x115
[<c020c146>] soft_cursor+0x52/0x16c
[<c020c00b>] bit_cursor+0x483/0x498
[<c02071ab>] fbcon_cursor+0x218/0x24d
[<c0244ac1>] hide_cursor+0x22/0x61
[<c024811f>] vt_console_print+0x91/0x207
[<c0120d31>] __call_console_drivers+0x6f/0x8c
[<c0120dac>] _call_console_drivers+0x5e/0x67
[<c0121367>] release_console_sem+0x132/0x1f2
[<c0121051>] vprintk+0x28d/0x2f5
[<c01210d3>] printk+0x1a/0x1c
[<c0129ab3>] run_timer_softirq+0x77b/0xbb6
[<c012632c>] ksoftirqd+0x11d/0x200
[<c013386b>] kthread+0xc7/0xf8
[<c0101005>] kernel_thread_helper+0x5/0xb
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c02ef447>] .... __spin_lock+0x12/0x35
.....[<c0129387>] .. ( <= run_timer_softirq+0x4f/0xbb6)

skipping trace printing on CPU#1 != -1
BUG: scheduling while atomic: softirq-timer/1/0x00000001/17, CPU#1
[<c0104356>] show_trace_log_lvl+0x68/0x193
[<c0104a5a>] show_trace+0x1b/0x20
[<c0104b38>] dump_stack+0x1f/0x24
[<c02ecc43>] __schedule+0x7d/0xded
[<c02edb8d>] schedule+0xc2/0xe3
[<c02ee8c0>] rt_spin_lock_slowlock+0x121/0x1af
[<c02eef4f>] rt_spin_lock+0x10/0x2c
[<c0171d6d>] __kmalloc+0xad/0x115
[<c020c146>] soft_cursor+0x52/0x16c
[<c020c00b>] bit_cursor+0x483/0x498
[<c02071ab>] fbcon_cursor+0x218/0x24d
[<c0244ac1>] hide_cursor+0x22/0x61
[<c024811f>] vt_console_print+0x91/0x207
[<c0120d31>] __call_console_drivers+0x6f/0x8c
[<c0120dac>] _call_console_drivers+0x5e/0x67
[<c0121367>] release_console_sem+0x132/0x1f2
[<c0121051>] vprintk+0x28d/0x2f5
[<c01210d3>] printk+0x1a/0x1c
[<c0129ab3>] run_timer_softirq+0x77b/0xbb6
[<c012632c>] ksoftirqd+0x11d/0x200
[<c013386b>] kthread+0xc7/0xf8
[<c0101005>] kernel_thread_helper+0x5/0xb
DWARF2 unwinder stuck at kernel_thread_helper+0x5/0xb
Leftover inexact backtrace:
[<c0104a5a>] show_trace+0x1b/0x20
[<c0104b38>] dump_stack+0x1f/0x24
[<c02ecc43>] __schedule+0x7d/0xded
[<c02edb8d>] schedule+0xc2/0xe3
[<c02ee8c0>] rt_spin_lock_slowlock+0x121/0x1af
[<c02eef4f>] rt_spin_lock+0x10/0x2c
[<c0171d6d>] __kmalloc+0xad/0x115
[<c020c146>] soft_cursor+0x52/0x16c
[<c020c00b>] bit_cursor+0x483/0x498
[<c02071ab>] fbcon_cursor+0x218/0x24d
[<c0244ac1>] hide_cursor+0x22/0x61
[<c024811f>] vt_console_print+0x91/0x207
[<c0120d31>] __call_console_drivers+0x6f/0x8c
[<c0120dac>] _call_console_drivers+0x5e/0x67
[<c0121367>] release_console_sem+0x132/0x1f2
[<c0121051>] vprintk+0x28d/0x2f5
[<c01210d3>] printk+0x1a/0x1c
[<c0129ab3>] run_timer_softirq+0x77b/0xbb6
[<c012632c>] ksoftirqd+0x11d/0x200
[<c013386b>] kthread+0xc7/0xf8
[<c0101005>] kernel_thread_helper+0x5/0xb
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c02ef447>] .... __spin_lock+0x12/0x35
.....[<c0129387>] .. ( <= run_timer_softirq+0x4f/0xbb6)

(gdb) l *rt_spin_lock_slowlock+0x121/0x1af
0xc02ee79f is in rt_spin_lock_slowlock (/usr/src/linux-rt/kernel/rtmutex.c:660).
655 * enables the seemless use of arbitrary (blocking) spinlocks within
656 * sleep/wakeup event loops.
657 */
658 static void fastcall noinline __sched
659 rt_spin_lock_slowlock(struct rt_mutex *lock)
660 {
661 struct rt_mutex_waiter waiter;
662 unsigned long saved_state, state;
663
664 debug_rt_mutex_init_waiter(&waiter);

l *__spin_lock+0x12/0x35
0xc02ef435 is in __spin_lock (/usr/src/linux-rt/kernel/spinlock.c:222).
217 _raw_write_lock(lock);
218 }
219 EXPORT_SYMBOL(__write_lock_bh);
220
221 void __lockfunc __spin_lock(raw_spinlock_t *lock)
222 {
223 preempt_disable();
224 spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
225 _raw_spin_lock(lock);
226 }

l *0xc0129387
0xc0129387 is in run_timer_softirq
(/usr/src/linux-rt/include/linux/seqlock.h:148).
143 }
144
145 static __always_inline void __write_seqlock_raw(raw_seqlock_t *sl)
146 {
147 spin_lock(&sl->lock);
148 ++sl->sequence;
149 smp_wmb();
150 }
151
152 static __always_inline void __write_sequnlock_raw(raw_seqlock_t *sl)

SELinux stuff.

=============================================
[ INFO: possible recursive locking detected ]
---------------------------------------------
init/1 is trying to acquire lock:
(policy_rwlock){--..}, at: [<c01df7ab>] security_genfs_sid+0x1f/0xeb

but task is already holding lock:
(policy_rwlock){--..}, at: [<c01df88c>] security_fs_use+0x15/0xbb

other info that might help us debug this:
3 locks held by init/1:
#0: (sel_mutex){--..}, at: [<c01da736>] sel_write_load+0x1b/0x2c0
#1: (&type->s_umount_key#14){--..}, at: [<c01d6de7>]
selinux_complete_init+0x67/0xbe
#2: (policy_rwlock){--..}, at: [<c01df88c>] security_fs_use+0x15/0xbb

stack backtrace:
[<c0104356>] show_trace_log_lvl+0x68/0x193
[<c0104a5a>] show_trace+0x1b/0x20
[<c0104b38>] dump_stack+0x1f/0x24
[<c013b795>] __lock_acquire+0x788/0x9be
[<c013bca4>] lock_acquire+0x55/0x72
[<c02ef13d>] rt_read_lock+0x1f/0x5f
[<c01df7ab>] security_genfs_sid+0x1f/0xeb
[<c01df913>] security_fs_use+0x9c/0xbb
[<c01d667e>] superblock_doinit+0xb5/0x6b5
[<c01d6df5>] selinux_complete_init+0x75/0xbe
[<c01e0ec5>] security_load_policy+0xc9/0x275
[<c01da7c1>] sel_write_load+0xa6/0x2c0
[<c0176411>] vfs_write+0xaf/0x153
[<c0176a71>] sys_write+0x3f/0x66
[<c0103216>] sysenter_past_esp+0x63/0xa1
DWARF2 unwinder stuck at sysenter_past_esp+0x63/0xa1
Leftover inexact backtrace:
[<c0104a5a>] show_trace+0x1b/0x20
[<c0104b38>] dump_stack+0x1f/0x24
[<c013b795>] __lock_acquire+0x788/0x9be
[<c013bca4>] lock_acquire+0x55/0x72
[<c02ef13d>] rt_read_lock+0x1f/0x5f
[<c01df7ab>] security_genfs_sid+0x1f/0xeb
[<c01df913>] security_fs_use+0x9c/0xbb
[<c01d667e>] superblock_doinit+0xb5/0x6b5
[<c01d6df5>] selinux_complete_init+0x75/0xbe
[<c01e0ec5>] security_load_policy+0xc9/0x275
[<c01da7c1>] sel_write_load+0xa6/0x2c0
[<c0176411>] vfs_write+0xaf/0x153
[<c0176a71>] sys_write+0x3f/0x66
[<c0103216>] sysenter_past_esp+0x63/0xa1
---------------------------
| preempt count: 00000000 ]
| 0-level deep critical section nesting:
----------------------------------------

skipping trace printing on CPU#1 != -1

l *security_genfs_sid+0x1f/0xeb
0xc01df78c is in security_genfs_sid
(/usr/src/linux-rt/security/selinux/ss/services.c:1612).
1607 */
1608 int security_genfs_sid(const char *fstype,
1609 char *path,
1610 u16 sclass,
1611 u32 *sid)
1612 {
1613 int len;
1614 struct genfs *genfs;
1615 struct ocontext *c;
1616 int rc = 0, cmp = 0;

l *security_fs_use+0x15/0xbb
0xc01df877 is in security_fs_use
(/usr/src/linux-rt/security/selinux/ss/services.c:1669).
1664 */
1665 int security_fs_use(
1666 const char *fstype,
1667 unsigned int *behavior,
1668 u32 *sid)
1669 {
1670 int rc = 0;
1671 struct ocontext *c;
1672
1673 POLICY_RDLOCK;

config & dmesg http://www.stardust.webpages.pl/files/o_bugs/rt/2.6.18-rt1/

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

2006-09-20 21:38:21

by Gene Heskett

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wednesday 20 September 2006 16:06, Paul E. McKenney wrote:
>On Wed, Sep 20, 2006 at 11:34:00AM -0700, Daniel Walker wrote:
>> On Wed, 2006-09-20 at 11:25 -0700, Paul E. McKenney wrote:
>> > BUG: unable to handle kernel NULL pointer dereference at virtual
>> > address 00000000 printing eip:
>> > c01151ff
>> > *pde = 34d21001
>> > *pte = 00000000
>> > stopped custom tracer.
>> > Oops: 0000 [#1]
>> > PREEMPT SMP
>> > Modules linked in:
>> > CPU: 2
>> > EIP: 0060:[<c01151ff>] Not tainted VLI
>> > EFLAGS: 00010246 (2.6.18-rt2-autokern1 #1)
>> > EIP is at __wake_up_common+0x10/0x55
>>
>> I get this too, it happens when HRT is off.. If you turn HRT on it will
>> boot .. I haven't found a fix for it, but I imagine Thomas will find it
>> soon.
>
>Enabling HRT works for me too -- thanks to you and Thomas for the hint!
>
> Thanx, Paul

Well, enabling HRT allowed it to boot, but there are several casualties.

For some reason, "heyu turn a14 off" which works with non-rt kernels, seems
to hang forever, or until its ctl-c'd. And all my control scripts that
use heyu fail. I killed the background processes that my startup script
starts, re-ran them by hand and now its working. Shakes head in
puzzlement...

Tvtime is still dead, sits in a blue screen & no sound. I have a cx88
tvaudio process running at -5 nice that I can't kill, if I do its back on
the next htop refresh.

/usr/local/bin/upsd (the belkin supplied version) is using up to half the
cpu. The cpu of course is running 10F warmer. And a SIGHUP from htop
killed it. And restarting it via an "sh ./S99bulldog" causes a repeat of
its cpu hogging.

Audacity-1.2.4 takes 30 seconds to clear the busy icon when started with no
arguments from the icon. I don't recall observing that before, but its
been a while since I ran it for any reason too, so my memory could be hazy
on that.

Hot-babe, (a debian toy) when running, looks normal, but uses 20% of the
cpu, which contributes to the strip job. :)

All in all, it could be worse. Now I have to shut down and replace the
ailing battery in my ups, it just walked in the door. And that has
nothing to do with this kernel 2.6.18-rt2.

--
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)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

2006-09-20 22:07:50

by Michal Piotrowski

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On 20/09/06, Ingo Molnar <[email protected]> wrote:
> I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> from the usual place:
>

sudo /etc/init.d/iptables stop

ip_conntrack issue?

BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/20112
caller is drain_array+0x19/0xe6
[<c0104356>] show_trace_log_lvl+0x68/0x193
[<c0104a5a>] show_trace+0x1b/0x20
[<c0104b38>] dump_stack+0x1f/0x24
[<c01f7c3f>] debug_smp_processor_id+0x7f/0x90
[<c01711ea>] drain_array+0x19/0xe6
[<c0171442>] __cache_shrink+0x3b/0x7c
[<c0172e08>] kmem_cache_destroy+0x80/0x145
[<fd9423a8>] ip_conntrack_cleanup+0x88/0xbc [ip_conntrack]
[<fd94540c>] ip_conntrack_standalone_fini+0x5c/0x8b [ip_conntrack]
[<c0143e6f>] sys_delete_module+0x195/0x1be
[<c0103216>] sysenter_past_esp+0x63/0xa1
DWARF2 unwinder stuck at sysenter_past_esp+0x63/0xa1
Leftover inexact backtrace:
[<c0104a5a>] show_trace+0x1b/0x20
[<c0104b38>] dump_stack+0x1f/0x24
[<c01f7c3f>] debug_smp_processor_id+0x7f/0x90
[<c01711ea>] drain_array+0x19/0xe6
[<c0171442>] __cache_shrink+0x3b/0x7c
[<c0172e08>] kmem_cache_destroy+0x80/0x145
[<fd9423a8>] ip_conntrack_cleanup+0x88/0xbc [ip_conntrack]
[<fd94540c>] ip_conntrack_standalone_fini+0x5c/0x8b [ip_conntrack]
[<c0143e6f>] sys_delete_module+0x195/0x1be
[<c0103216>] sysenter_past_esp+0x63/0xa1
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c01f7bfe>] .... debug_smp_processor_id+0x3e/0x90
.....[<c01711ea>] .. ( <= drain_array+0x19/0xe6)
skipping trace printing on CPU#0 != -1
BUG: modprobe:20112 task might have lost a preemption check!
[<c0104356>] show_trace_log_lvl+0x68/0x193
[<c0104a5a>] show_trace+0x1b/0x20
[<c0104b38>] dump_stack+0x1f/0x24
[<c011cd8a>] preempt_enable_no_resched+0x48/0x4d
[<c01f7c47>] debug_smp_processor_id+0x87/0x90
[<c01711ea>] drain_array+0x19/0xe6
[<c0171442>] __cache_shrink+0x3b/0x7c
[<c0172e08>] kmem_cache_destroy+0x80/0x145
[<fd9423a8>] ip_conntrack_cleanup+0x88/0xbc [ip_conntrack]
[<fd94540c>] ip_conntrack_standalone_fini+0x5c/0x8b [ip_conntrack]
[<c0143e6f>] sys_delete_module+0x195/0x1be
[<c0103216>] sysenter_past_esp+0x63/0xa1
DWARF2 unwinder stuck at sysenter_past_esp+0x63/0xa1
Leftover inexact backtrace:
[<c0104a5a>] show_trace+0x1b/0x20
[<c0104b38>] dump_stack+0x1f/0x24
[<c011cd8a>] preempt_enable_no_resched+0x48/0x4d
[<c01f7c47>] debug_smp_processor_id+0x87/0x90
[<c01711ea>] drain_array+0x19/0xe6
[<c0171442>] __cache_shrink+0x3b/0x7c
[<c0172e08>] kmem_cache_destroy+0x80/0x145
[<fd9423a8>] ip_conntrack_cleanup+0x88/0xbc [ip_conntrack]
[<fd94540c>] ip_conntrack_standalone_fini+0x5c/0x8b [ip_conntrack]
[<c0143e6f>] sys_delete_module+0x195/0x1be
[<c0103216>] sysenter_past_esp+0x63/0xa1
---------------------------
| preempt count: 00000000 ]
| 0-level deep critical section nesting:
----------------------------------------

l *0xc01f7bfe
0xc01f7bfe is in debug_smp_processor_id
(/usr/src/linux-rt/lib/smp_processor_id.c:42).
37 /*
38 * Avoid recursion:
39 */
40 preempt_disable();
41
42 if (!printk_ratelimit())
43 goto out_enable;
44
45 printk(KERN_ERR "BUG: using smp_processor_id() in
preemptible [%08x] code: %s/%d\n", preempt_count()-1, current->comm,
current->pid);
46 print_symbol("caller is %s\n",
(long)__builtin_return_address(0));

l *0xc01711ea
0xc01711ea is in drain_array (/usr/src/linux-rt/mm/slab.c:3852).
3847 struct array_cache *ac, int force, int node)
3848 {
3849 int this_cpu = smp_processor_id();
3850 int tofree;
3851
3852 if (!ac || !ac->avail)
3853 return;
3854 if (ac->touched && !force) {
3855 ac->touched = 0;
3856 } else {

http://www.stardust.webpages.pl/files/o_bugs/rt/2.6.18-rt1/rt-config

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

2006-09-20 22:26:31

by Michal Piotrowski

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On 20/09/06, Ingo Molnar <[email protected]> wrote:
> I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/

Hibernation doesn't work for me.

echo shutdown > /sys/power/disk; echo disk > /sys/power/state

Freezing cpus...
Breaking affinity for irq 14
Breaking affinity for irq 15
Breaking affinity for irq 19
Breaking affinity for irq 21

Any ideas why?

http://www.stardust.webpages.pl/files/o_bugs/rt/2.6.18-rt1/rt-config

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

2006-09-21 06:56:46

by Bill Huey

[permalink] [raw]
Subject: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Wed, Sep 20, 2006 at 04:19:07PM +0200, Ingo Molnar wrote:
> I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> from the usual place:
...
> as usual, bugreports, fixes and suggestions are welcome,

Speaking of which...

This patch moves put_task_struct() reaping into a thread instead of an
RCU callback function as discussed with Esben publically and Ingo privately:

bill


Attachments:
(No filename) (399.00 B)
mingo.patch.diff (7.53 kB)
Download all attachments

2006-09-21 07:02:41

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Bill Huey <[email protected]> wrote:

> On Wed, Sep 20, 2006 at 04:19:07PM +0200, Ingo Molnar wrote:
> > I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> > from the usual place:
> ...
> > as usual, bugreports, fixes and suggestions are welcome,
>
> Speaking of which...
>
> This patch moves put_task_struct() reaping into a thread instead of an
> RCU callback function [...]

had some time to think about it since yesterday: RCU reaping is done in
softirqs (check out the softirq-rcu threads on your -rt box), that's why
i removed the delayed-task-drop code to begin with. Now i dont doubt
that you saw crashes under 2.6.17 - but did you manage to figure out
what the reason is for those crashes, and do those reasons really
necessiate the pushing of task-reapdown into yet another set of kernel
threads?

Ingo

2006-09-21 07:19:25

by Bill Huey

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Thu, Sep 21, 2006 at 08:54:02AM +0200, Ingo Molnar wrote:
> * Bill Huey <[email protected]> wrote:
>
> > On Wed, Sep 20, 2006 at 04:19:07PM +0200, Ingo Molnar wrote:
> > > I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> > > from the usual place:
> > ...
> > > as usual, bugreports, fixes and suggestions are welcome,
> >
> > Speaking of which...
> >
> > This patch moves put_task_struct() reaping into a thread instead of an
> > RCU callback function [...]
>
> had some time to think about it since yesterday: RCU reaping is done in
> softirqs (check out the softirq-rcu threads on your -rt box), that's why
> i removed the delayed-task-drop code to begin with. Now i dont doubt

It's correct from the standpoint of it being reaped in another thread,
so it fixed those crashes. But I pushed it down into another thread at the
request of Esben and his private discussion with Paul McKenney, since
a summary from Esben felt that call_rcu() was somehow less than ideal to
do that.

> that you saw crashes under 2.6.17 - but did you manage to figure out
> what the reason is for those crashes, and do those reasons really
> necessiate the pushing of task-reapdown into yet another set of kernel
> threads?

Unfortunately no. I even used Robert's .config on my machine. I added a
disk controller and networking device driver just to boot into his
configuration and I still couldn't replicated any of his kjournald problems
at all. If I had his hardware I'd have a better way of replicating those
problems and pound it out.

bill

2006-09-21 07:24:21

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Bill Huey <[email protected]> wrote:

> > > This patch moves put_task_struct() reaping into a thread instead
> > > of an RCU callback function [...]
> >
> > had some time to think about it since yesterday: RCU reaping is done
> > in softirqs (check out the softirq-rcu threads on your -rt box),
> > that's why i removed the delayed-task-drop code to begin with. Now i
> > dont doubt
>
> It's correct from the standpoint of it being reaped in another thread,
> so it fixed those crashes. But I pushed it down into another thread at
> the request of Esben and his private discussion with Paul McKenney,
> since a summary from Esben felt that call_rcu() was somehow less than
> ideal to do that.

but it _is_ already being reaped in another thread: softirq-rcu.
Splitting that up any further will only fragment the context-switching
and increases cache footprint - it wont (or rather, shouldnt) have any
functional effect. (As a sidenote, i'm considering the unification of
all 'same default priority' softirq threads into a single thread per
CPU, to further reduce this cost of 'spreadout'.)

> > that you saw crashes under 2.6.17 - but did you manage to figure out
> > what the reason is for those crashes, and do those reasons really
> > necessiate the pushing of task-reapdown into yet another set of
> > kernel threads?
>
> Unfortunately no. I even used Robert's .config on my machine. I added
> a disk controller and networking device driver just to boot into his
> configuration and I still couldn't replicated any of his kjournald
> problems at all. If I had his hardware I'd have a better way of
> replicating those problems and pound it out.

ok, then i guess what we have left is to wait and see whether it still
triggers with the current 2.6.18-rt codebase - maybe it triggers for
someone in a scenario that is easier to debug.

Ingo

2006-09-21 07:28:03

by Bill Huey

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Thu, Sep 21, 2006 at 12:18:40AM -0700, Bill Huey wrote:
> On Thu, Sep 21, 2006 at 08:54:02AM +0200, Ingo Molnar wrote:
> > that you saw crashes under 2.6.17 - but did you manage to figure out
> > what the reason is for those crashes, and do those reasons really
> > necessiate the pushing of task-reapdown into yet another set of kernel
> > threads?
>
> Unfortunately no. I even used Robert's .config on my machine. I added a
> disk controller and networking device driver just to boot into his
> configuration and I still couldn't replicated any of his kjournald problems
> at all. If I had his hardware I'd have a better way of replicating those
> problems and pound it out.

Robert's stack traces looked completely wrong as well which is why I gave up.
Symbols showing up in this stack traces should have been completely compiled
out.

Also, triggering a panic() at the beginning of the rt mutex acquire was
very useful since it made "in_atomic()" violations an explicit error stopping
the machine. Stack traces started to get really crazy in this preemptive
kernel with all sorts of things running unlike the non-preemptive kernel and
it was time consuming to figure out the real stuff from the noise in the
stack trace.

It made the stack traces smaller and more immediately local to the problem
logic. Then I discovered panic() didn't work correctly in -rt so I fixed that
as well. There were a lot of little breakdowns in 2.6.17-rt...

bill

2006-09-21 07:30:48

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Bill Huey <[email protected]> wrote:

> Also, triggering a panic() at the beginning of the rt mutex acquire
> was very useful since it made "in_atomic()" violations an explicit
> error stopping the machine. Stack traces started to get really crazy
> in this preemptive kernel with all sorts of things running unlike the
> non-preemptive kernel and it was time consuming to figure out the real
> stuff from the noise in the stack trace.

well you should absolutely have serial console if you effectively want
to hack the Linux kernel. And in the serial console log you should
search for stacktraces top-down, and concentrate on the first one - any
subsequent one might be collateral damage of the first one.

Ingo

2006-09-21 07:32:41

by Bill Huey

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Thu, Sep 21, 2006 at 09:16:24AM +0200, Ingo Molnar wrote:
> * Bill Huey <[email protected]> wrote:
> > It's correct from the standpoint of it being reaped in another thread,
> > so it fixed those crashes. But I pushed it down into another thread at
> > the request of Esben and his private discussion with Paul McKenney,
> > since a summary from Esben felt that call_rcu() was somehow less than
> > ideal to do that.
>
> but it _is_ already being reaped in another thread: softirq-rcu.
> Splitting that up any further will only fragment the context-switching
> and increases cache footprint - it wont (or rather, shouldnt) have any
> functional effect. (As a sidenote, i'm considering the unification of
> all 'same default priority' softirq threads into a single thread per
> CPU, to further reduce this cost of 'spreadout'.)

I overloaded another reaping thread that was doing largely similar
functionality in that it was also reaping, so I don't think it's that bad.
I did it from a cleanliness point of view with the code tree. It's the
"desched_thread" in fork.c that I'm using. It seems to be the right
thing to do. I'm sure Esben will follow up on this.

> > > that you saw crashes under 2.6.17 - but did you manage to figure out
> > > what the reason is for those crashes, and do those reasons really
> > > necessiate the pushing of task-reapdown into yet another set of
> > > kernel threads?
> >
> > Unfortunately no. I even used Robert's .config on my machine. I added
> > a disk controller and networking device driver just to boot into his
> > configuration and I still couldn't replicated any of his kjournald
> > problems at all. If I had his hardware I'd have a better way of
> > replicating those problems and pound it out.
>
> ok, then i guess what we have left is to wait and see whether it still
> triggers with the current 2.6.18-rt codebase - maybe it triggers for
> someone in a scenario that is easier to debug.

bill

2006-09-21 07:35:41

by Bill Huey

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Thu, Sep 21, 2006 at 09:22:16AM +0200, Ingo Molnar wrote:
> * Bill Huey <[email protected]> wrote:
>
> > Also, triggering a panic() at the beginning of the rt mutex acquire
> > was very useful since it made "in_atomic()" violations an explicit
> > error stopping the machine. Stack traces started to get really crazy
> > in this preemptive kernel with all sorts of things running unlike the
> > non-preemptive kernel and it was time consuming to figure out the real
> > stuff from the noise in the stack trace.
>
> well you should absolutely have serial console if you effectively want
> to hack the Linux kernel. And in the serial console log you should
> search for stacktraces top-down, and concentrate on the first one - any
> subsequent one might be collateral damage of the first one.

Of course I did that. I'm not that stupid. :) The stack traces, even with
your above suggestions were too many and I had to break it down a bug at
a time, stack trace at a time, since I realize problems earlier could
clash and trigger other unrelated problems.

It was even problematic with the serial console on which is why I did
that. Maybe it was an artifact of having both the serial console and video
consoles on ?

bill

2006-09-21 07:37:47

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Bill Huey <[email protected]> wrote:

> > but it _is_ already being reaped in another thread: softirq-rcu.
> > Splitting that up any further will only fragment the
> > context-switching and increases cache footprint - it wont (or
> > rather, shouldnt) have any functional effect. (As a sidenote, i'm
> > considering the unification of all 'same default priority' softirq
> > threads into a single thread per CPU, to further reduce this cost of
> > 'spreadout'.)
>
> I overloaded another reaping thread that was doing largely similar
> functionality in that it was also reaping, so I don't think it's that
> bad. I did it from a cleanliness point of view with the code tree.
> It's the "desched_thread" in fork.c that I'm using. It seems to be the
> right thing to do. I'm sure Esben will follow up on this.

the reason why i added desched_thread was not because it's "more right"
to do this from a separate context, but simply because the resource
freed by it is not being freed via RCU by the upstream kernel. If that
resource (mm_struct) were freed by RCU we'd have its rt-friendly
reapdown "for free" and no desched_thread would be needed at all.

Ingo

2006-09-21 07:39:49

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Bill Huey <[email protected]> wrote:

> On Thu, Sep 21, 2006 at 09:22:16AM +0200, Ingo Molnar wrote:
> > * Bill Huey <[email protected]> wrote:
> >
> > > Also, triggering a panic() at the beginning of the rt mutex acquire
> > > was very useful since it made "in_atomic()" violations an explicit
> > > error stopping the machine. Stack traces started to get really crazy
> > > in this preemptive kernel with all sorts of things running unlike the
> > > non-preemptive kernel and it was time consuming to figure out the real
> > > stuff from the noise in the stack trace.
> >
> > well you should absolutely have serial console if you effectively want
> > to hack the Linux kernel. And in the serial console log you should
> > search for stacktraces top-down, and concentrate on the first one - any
> > subsequent one might be collateral damage of the first one.
>
> Of course I did that. I'm not that stupid. :) The stack traces, even
> with your above suggestions were too many and I had to break it down a
> bug at a time, stack trace at a time, since I realize problems earlier
> could clash and trigger other unrelated problems.
>
> It was even problematic with the serial console on which is why I did
> that. Maybe it was an artifact of having both the serial console and
> video consoles on ?

perhaps the real problem was that you got 'intermixed' stackdumps from
multiple CPUs crashing at once? Or was it simply the myriads of
stackdumps? The myriads effect is easy to solve: only look at the first
one, and fix them one by one :-)

Ingo

2006-09-21 07:48:24

by Bill Huey

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Thu, Sep 21, 2006 at 09:29:08AM +0200, Ingo Molnar wrote:
> * Bill Huey <[email protected]> wrote:
> > I overloaded another reaping thread that was doing largely similar
> > functionality in that it was also reaping, so I don't think it's that
> > bad. I did it from a cleanliness point of view with the code tree.
> > It's the "desched_thread" in fork.c that I'm using. It seems to be the
> > right thing to do. I'm sure Esben will follow up on this.
>
> the reason why i added desched_thread was not because it's "more right"
> to do this from a separate context, but simply because the resource

I only did that because I saw it there and I assumed it the was the correct
thing to use and that's why I used it.

> freed by it is not being freed via RCU by the upstream kernel. If that
> resource (mm_struct) were freed by RCU we'd have its rt-friendly
> reapdown "for free" and no desched_thread would be needed at all.

Well, it's difficult to say. I can't say which is the best method. If the
upstream kernel used RCU function in a task allocation or task struct reading
in the first place then call_rcu() would be a clear choice. However, I didn't
see it used in that way (I could be wrong) so I use the next closest thing that
seems reasonable which is the thread desched_thread(). It use it to avoid
overloading the sematics of call_rcu() to be anything other than a pure RCU
callback. I suggest talking to Esben an Paul about this to get their view on
the matter.

Either method, call_rcu or desched_thread does the trick outside of the
scheduler path and fixes the problem. It's your choice.

bill

2006-09-21 07:53:00

by Bill Huey

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Thu, Sep 21, 2006 at 09:31:30AM +0200, Ingo Molnar wrote:
> * Bill Huey <[email protected]> wrote:
> > It was even problematic with the serial console on which is why I did
> > that. Maybe it was an artifact of having both the serial console and
> > video consoles on ?
>
> perhaps the real problem was that you got 'intermixed' stackdumps from
> multiple CPUs crashing at once? Or was it simply the myriads of
> stackdumps? The myriads effect is easy to solve: only look at the first
> one, and fix them one by one :-)

I don't think I have to tell you that things got "really weird" for a
while which is why I took the route of most severity and elected to use
extreme debugging methods. :)

I mean, some of those stack traces kept triggering a jumble of schedule()
calls, etc... I decided to hack the heads off of them one at at time and
stop the kernel immediately after one of those bugs. The immediate panic()
is what caught the tbl raw_spinlock issue and therefore my lock reversion
after auditing that portion of the lock graph.

bill

2006-09-21 08:04:04

by Deepak Saxena

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Sep 20 2006, at 21:46, Ingo Molnar was caught saying:
>
> * Gene Heskett <[email protected]> wrote:
>
> > That looks like the chorus of the song I saw when it crashed on boot,
> > pretty darned close to identical.
>
> ok, i've uploaded -rt3:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> this should have this one fixed.

I am seeing an intermittent lock up on the ARM Versatile board during the
ALSA driver init that only shows up with (PREEMPT_RT & !HIGH_RES_TIMERS
& ARM_EABI) enabled. If HRT is disabled and EABI is enabled, the kernel
works every time, and same with !RT & !HRT & EABI. I get no oops, just
a complete lock up with no console output.

In summary:


PREEMPT HRT EABI BOOTS
------------------------------------------
2.6.18-rt3
------------------------------------------
RT Y Y Y
RT N Y Intermittent
RT N N Y
NONE Y Y Y
NONE N Y Y
NONE N N Y
------------------------------------------
2.6.18-vanilla
------------------------------------------
N/A Y Y
------------------------------------------

I need to go pinpoint the exact point where it is locking up during
the ALSA driver init (calls to udelay() seem suspect to me) and it
is very possible that this is a toolchain issue but want to see if
any other ARM folks are seeing issues with EABI & !HRT.

~Deepak

--
Deepak Saxena - [email protected] - http://www.plexity.net

"An open heart has no possessions, only experiences" - Matt Bibbeau

2006-09-21 08:04:48

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Bill Huey <[email protected]> wrote:

> [...] If the upstream kernel used RCU function in a task allocation or
> task struct reading in the first place then call_rcu() would be a
> clear choice. However, I didn't see it used in that way (I could be
> wrong) [...]

it was RCU-ified briefly but then it was further improved to direct
freeing, because upstream _can_ free it directly.

Ingo

2006-09-21 08:12:52

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* Deepak Saxena <[email protected]> wrote:

> I am seeing an intermittent lock up on the ARM Versatile board during
> the ALSA driver init that only shows up with (PREEMPT_RT &
> !HIGH_RES_TIMERS & ARM_EABI) enabled. If HRT is disabled and EABI is
> enabled, the kernel works every time, and same with !RT & !HRT & EABI.
> I get no oops, just a complete lock up with no console output.

does enabling LOCKDEP give you any better info? (It might not make a
difference on the bootup that locks, but maybe you'll get a lockdep clue
about the problem in one of the successful bootups.)

Ingo

2006-09-21 08:13:57

by Bill Huey

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Thu, Sep 21, 2006 at 09:56:33AM +0200, Ingo Molnar wrote:
> * Bill Huey <[email protected]> wrote:
>
> > [...] If the upstream kernel used RCU function in a task allocation or
> > task struct reading in the first place then call_rcu() would be a
> > clear choice. However, I didn't see it used in that way (I could be
> > wrong) [...]
>
> it was RCU-ified briefly but then it was further improved to direct
> freeing, because upstream _can_ free it directly.

Unfortunately, this is a problem with -rt patch and the lock ordering
in this system when you have to call a memory allocator within an atomic
critical section. I fully accept this as part of what goes into making a
kernel preemptive and I'm ok with it. Not many folks know about the
special case locking rules in the -rt kernel so this might be new to
various folks.

If you're looking for validation of this technique from me and an ego
stroking, then you have it from me. :)

Fortunately, it's in a non-critical place so this should *not* be too
much of a problem, but I've already encountered oddies trying to
allocate a pool of entities for populating a free list under an atomic
critical section of some sort for some code I've been writing. This is
a significant problem with kernel coding in -rt, but I can't say what
the general solution is other than making the memory allocators
non-preemptible by reverting the locks back to raw spinlocks, etc...
using lock-break, who knows. I'm ok with the current scenario, but this
could eventually be a larger problem.

bill

2006-09-21 08:24:23

by Deepak Saxena

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Sep 21 2006, at 10:04, Ingo Molnar was caught saying:
>
> * Deepak Saxena <[email protected]> wrote:
>
> > I am seeing an intermittent lock up on the ARM Versatile board during
> > the ALSA driver init that only shows up with (PREEMPT_RT &
> > !HIGH_RES_TIMERS & ARM_EABI) enabled. If HRT is disabled and EABI is
> > enabled, the kernel works every time, and same with !RT & !HRT & EABI.
> > I get no oops, just a complete lock up with no console output.
>
> does enabling LOCKDEP give you any better info? (It might not make a
> difference on the bootup that locks, but maybe you'll get a lockdep clue
> about the problem in one of the successful bootups.)

This is with LOCKDEP enabled. I'll look at this more tommorrow but
I think next steps for me are printks to see if I can pinpoint the
issue and possibly looking at the assembly to see if there's an obvious
compiler issue.

~Deepak

--
Deepak Saxena - [email protected] - http://www.plexity.net

"An open heart has no possessions, only experiences" - Matt Bibbeau

2006-09-21 12:23:28

by Esben Nielsen

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]




On Thu, 21 Sep 2006, Bill Huey wrote:

> On Thu, Sep 21, 2006 at 09:56:33AM +0200, Ingo Molnar wrote:
>> * Bill Huey <[email protected]> wrote:
>>
>>> [...] If the upstream kernel used RCU function in a task allocation or
>>> task struct reading in the first place then call_rcu() would be a
>>> clear choice. However, I didn't see it used in that way (I could be
>>> wrong) [...]
>>
>> it was RCU-ified briefly but then it was further improved to direct
>> freeing, because upstream _can_ free it directly.
>
> Unfortunately, this is a problem with -rt patch and the lock ordering
> in this system when you have to call a memory allocator within an atomic
> critical section. I fully accept this as part of what goes into making a
> kernel preemptive and I'm ok with it. Not many folks know about the
> special case locking rules in the -rt kernel so this might be new to
> various folks.
>
> If you're looking for validation of this technique from me and an ego
> stroking, then you have it from me. :)
>
> Fortunately, it's in a non-critical place so this should *not* be too
> much of a problem, but I've already encountered oddies trying to
> allocate a pool of entities for populating a free list under an atomic
> critical section of some sort for some code I've been writing. This is
> a significant problem with kernel coding in -rt, but I can't say what
> the general solution is other than making the memory allocators
> non-preemptible by reverting the locks back to raw spinlocks, etc...
> using lock-break, who knows. I'm ok with the current scenario, but this
> could eventually be a larger problem.
>

The whole point is to defer those frees to a task. In -rt call_rcu() is
abused to do that in the case of put_task_struct(). But it is abuse since
call_rcu() is much more resourcefull than simply defering to a task.

Paul's idea behind de-RCU'ing put_task_struct() is mostly performance and
partly readability because the extra RCU protection isn't needed.

So the answer is:
Make a general softirq to which free's can be defered from atomic regions,
don't abuse call_rcu().

Esben

> bill
>

2006-09-21 13:07:46

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Esben Nielsen <[email protected]> wrote:

> The whole point is to defer those frees to a task. In -rt call_rcu()
> is abused to do that in the case of put_task_struct(). But it is abuse
> since call_rcu() is much more resourcefull than simply defering to a
> task.

nah, it's not nearly as "resourceful" as having a separate thread for
each teardown type ... It is also the easiest to maintain way of tearing
down stuff, so i'm quite happy with it. If then i'll move the mm_struct
teardown to RCU too. (Later on we can do some 'fastpath RCU' thing
perhaps, to force an RCU batch of work through quiescent state)

but this is quite likely a side-issue that probably has no connection to
the crash Bill was seeing. Whether separate teardown thread or
softirq-rcu, it's a separate thread already.

Ingo

2006-09-21 19:11:22

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* Daniel Walker <[email protected]> wrote:

> On Wed, 2006-09-20 at 22:14 +0200, Ingo Molnar wrote:
> > > if (up->port.sysrq) {
> > > /* serial8250_handle_port() already took the lock */
> > > locked = 0;
>
>
> In this case it had interrupts off in the !PREEMPT_RT case, but your
> change leaves them on here.. _irqsave only runs in two of the three
> cases..

doh, right you are. I updated to the patch below.

Ingo

Index: linux/drivers/serial/8250.c
===================================================================
--- linux.orig/drivers/serial/8250.c
+++ linux/drivers/serial/8250.c
@@ -2252,14 +2252,10 @@ serial8250_console_write(struct console

touch_nmi_watchdog();

- local_irq_save(flags);
- if (up->port.sysrq) {
- /* serial8250_handle_port() already took the lock */
- locked = 0;
- } else if (oops_in_progress) {
- locked = spin_trylock(&up->port.lock);
- } else
- spin_lock(&up->port.lock);
+ if (up->port.sysrq || oops_in_progress)
+ locked = spin_trylock_irqsave(&up->port.lock, flags);
+ else
+ spin_lock_irqsave(&up->port.lock, flags);

/*
* First save the IER then disable the interrupts
@@ -2281,8 +2277,7 @@ serial8250_console_write(struct console
serial_out(up, UART_IER, ier);

if (locked)
- spin_unlock(&up->port.lock);
- local_irq_restore(flags);
+ spin_unlock_irqrestore(&up->port.lock, flags);
}

static int serial8250_console_setup(struct console *co, char *options)

2006-09-21 19:16:12

by john stultz

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 15:50 -0500, K.R. Foley wrote:
> Thomas Gleixner wrote:
> > On Wed, 2006-09-20 at 15:33 -0500, K.R. Foley wrote:
> >> DOH! The log had two different boots in it. :( Let's try this again. By
> >> the way, you may notice from my screw up that this is pretty much the
> >> same oops that I got with 2.6.17-rt*. I have been getting this on all of
> >> my SMP systems since we went past 2.6.16.
> >
> > Which module is modprobed ?
> >
> > tglx
> >
> >
> >
> How can I tell which particular module is being loaded? The last thing I
> see on the console before the oops is that it is starting udev. I am
> including the rest of the boot log below in hopes that will help.
> Suggestions? Something else I can provide?
>
[snip]
>kjournald starting. Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
> BUG: unable to handle kernel paging request at virtual address f3010000
> printing eip:
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT SMP
> Modules linked in:
> CPU: 1
> EIP: 0060:[<c0131e02>] Not tainted VLI
> EFLAGS: 00010283 (2.6.18-rt2 #4)
> EIP is at lookup_symbol+0x11/0x35
> eax: 00000001 ebx: e0830e08 ecx: c036ff60 edx: c036dd94
> esi: f3010000 edi: e0830e08 ebp: df657e74 esp: df657e68
> ds: 007b es: 007b ss: 0068 preempt: 00000001
> Process modprobe (pid: 1366, ti=df656000 task=dfc68e90 task.ti=df656000)
> Stack: e083c780 00000c00 e0830e08 df657e90 c0131e6f df657ea8 df657ea4
> e083c780
> 00000c00 e0830e08 df657eb8 c0132c21 00000001 00000012 e082d074
> 00000000
> df657ecc e083a434 00000c00 e082d074 df657edc c0133188 e083c780
> 00000000
> Call Trace:
> [<c01037a1>] show_stack_log_lvl+0x87/0x8f
> [<c010391b>] show_registers+0x12f/0x198
> [<c0103b0c>] die+0x114/0x1c6
> [<c0111196>] do_page_fault+0x3f2/0x4c8
> [<c0103481>] error_code+0x39/0x40
> [<c0131e6f>] __find_symbol+0x25/0x2a5
> [<c0132c21>] resolve_symbol+0x27/0x5f
> [<c0133188>] simplify_symbols+0x83/0xf3
> [<c0133e65>] load_module+0x720/0xbb8
> [<c013435f>] sys_init_module+0x3f/0x1b5
> [<c0102969>] sysenter_past_esp+0x56/0x79
> Code: eb 11 8b 75 f0 41 83 c2 28 0f b7 46 30 39 c1 72 c9 31 c0 5a 59 5b
> 5e 5f 5d c3 55 89 e5 57 56 53 89 c3 39 ca 73 22 8b 72 04 89 df <ac> ae
> 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 04 89
> EIP: [<c0131e02>] lookup_symbol+0x11/0x35 SS:ESP 0068:df657e68
>


I'm seeing a similar issue. Although the log is a bit futzed. Maybe its
the sd_mod?

at virtual address 75010000le kernel paging requestproc filesystem

printing eip:

Creating /dev
c01372d5
Starting udev
L*pde = cccccccc
oading sd_mod.kostopped custom tracer.
module
Oops: 0000 [#1]
PREEMPT SMP
Modules linked in:
CPU: 3
EIP: 0060:[<c01372d5>] Not tainted VLI
EFLAGS: 00010293 (2.6.18-rt3johnsmp #1)
EIP is at lookup_symbol+0x15/0x37
eax: ffffffff ebx: f88209a0 ecx: c03916fc edx: c038eba0
esi: 75010000 edi: f881a405 ebp: c7d01ea4 esp: c7d01e64
ds: 007b es: 007b ss: 0068 preempt: 00000001
Process insmod (pid: 462, ti=c7d00000 task=f7d6c1f0 task.ti=c7d00000)
Stack: f8821e00 f881a405 c0137345 f881a405 c038c658 c03916fc f88209a0 f8821e00
f881a405 00000000 c0138145 f881a405 c7d01ea0 c7d01ea4 00000001 00000000
f881a405 f88209a0 00000500 0000003c c01386d2 f88193d0 0000000b f881a405
Call Trace:
[<c0137345>] __find_symbol+0x26/0x2e0
[<c0138145>] resolve_symbol+0x23/0x5f
[<c01386d2>] simplify_symbols+0x7e/0xf0
[<c013942d>] load_module+0x7c4/0xc14
[<c01398dd>] sys_init_module+0x3d/0x1ae
[<c01029d9>] sysenter_past_esp+0x56/0x79
Code: c8 eb 0e 0f b7 45 30 41 83 c2 28 39 c1 72 ca 31 c0 5b 5e 5f 5d c3 57 56 8b 4c 24 14 8b 54 24 10 39 ca 73 24 8b 72 04 8b 7c 24 0c <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 04 89
EIP: [<c01372d5>] lookup_symbol+0x15/0x37 SS:ESP 0068:c7d01e64
ERROR: /bin/insmod exited abnormally! (pid 462)
Loading jbd.ko module


thanks
-john


2006-09-21 19:18:51

by Daniel Walker

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Thu, 2006-09-21 at 21:02 +0200, Ingo Molnar wrote:

> + if (up->port.sysrq || oops_in_progress)
> + locked = spin_trylock_irqsave(&up->port.lock, flags);
> + else
> + spin_lock_irqsave(&up->port.lock, flags);

Nice!

Daniel

2006-09-22 02:14:24

by john cooper

[permalink] [raw]
Subject: Re: 2.6.18-rt1

include/asm-arm/arch-pxa/timex.h | 2 ++
kernel/latency_trace.c | 2 ++
2 files changed, 4 insertions(+)
=================================================================
--- ./kernel/latency_trace.c.ORG 2006-09-20 21:10:15.000000000 -0400
+++ ./kernel/latency_trace.c 2006-09-21 21:28:49.000000000 -0400
@@ -150,6 +150,8 @@ enum trace_flag_type
*/
#if !defined(CONFIG_DEBUG_PAGEALLOC) && !defined(CONFIG_SMP) && !defined(CONFIG_ARM)
# define MAX_TRACE (unsigned long)(8192*16-1)
+#elif defined(CONFIG_ARM) /* 4MB kernel image size limitation */
+# define MAX_TRACE (unsigned long)(128*2-1)
#else
# define MAX_TRACE (unsigned long)(8192*2-1)
#endif
=================================================================
--- ./include/asm-arm/arch-pxa/timex.h.ORG 2006-09-20 21:10:15.000000000 -0400
+++ ./include/asm-arm/arch-pxa/timex.h 2006-09-21 21:57:43.000000000 -0400
@@ -16,6 +16,8 @@
#define CLOCK_TICK_RATE 3686400
#elif defined(CONFIG_PXA27x)
/* PXA27x timer base */
+#include <asm-arm/arch-pxa/hardware.h>
+#include <asm-arm/arch-pxa/pxa-regs.h>
#ifdef CONFIG_MACH_MAINSTONE
#define CLOCK_TICK_RATE 3249600
#else


Attachments:
patch-2.6.18-rt3-pxa270 (1.13 kB)

2006-09-22 02:21:17

by K.R. Foley

[permalink] [raw]
Subject: Re: 2.6.18-rt1

john stultz wrote:
> On Wed, 2006-09-20 at 15:50 -0500, K.R. Foley wrote:
>> Thomas Gleixner wrote:
>>> On Wed, 2006-09-20 at 15:33 -0500, K.R. Foley wrote:
>>>> DOH! The log had two different boots in it. :( Let's try this again. By
>>>> the way, you may notice from my screw up that this is pretty much the
>>>> same oops that I got with 2.6.17-rt*. I have been getting this on all of
>>>> my SMP systems since we went past 2.6.16.
>>> Which module is modprobed ?
>>>
>>> tglx
>>>
>>>
>>>
>> How can I tell which particular module is being loaded? The last thing I
>> see on the console before the oops is that it is starting udev. I am
>> including the rest of the boot log below in hopes that will help.
>> Suggestions? Something else I can provide?
>>
> [snip]
>> kjournald starting. Commit interval 5 seconds
>> EXT3-fs: mounted filesystem with ordered data mode.
>> BUG: unable to handle kernel paging request at virtual address f3010000
>> printing eip:
>> *pde = 00000000
>> Oops: 0000 [#1]
>> PREEMPT SMP
>> Modules linked in:
>> CPU: 1
>> EIP: 0060:[<c0131e02>] Not tainted VLI
>> EFLAGS: 00010283 (2.6.18-rt2 #4)
>> EIP is at lookup_symbol+0x11/0x35
>> eax: 00000001 ebx: e0830e08 ecx: c036ff60 edx: c036dd94
>> esi: f3010000 edi: e0830e08 ebp: df657e74 esp: df657e68
>> ds: 007b es: 007b ss: 0068 preempt: 00000001
>> Process modprobe (pid: 1366, ti=df656000 task=dfc68e90 task.ti=df656000)
>> Stack: e083c780 00000c00 e0830e08 df657e90 c0131e6f df657ea8 df657ea4
>> e083c780
>> 00000c00 e0830e08 df657eb8 c0132c21 00000001 00000012 e082d074
>> 00000000
>> df657ecc e083a434 00000c00 e082d074 df657edc c0133188 e083c780
>> 00000000
>> Call Trace:
>> [<c01037a1>] show_stack_log_lvl+0x87/0x8f
>> [<c010391b>] show_registers+0x12f/0x198
>> [<c0103b0c>] die+0x114/0x1c6
>> [<c0111196>] do_page_fault+0x3f2/0x4c8
>> [<c0103481>] error_code+0x39/0x40
>> [<c0131e6f>] __find_symbol+0x25/0x2a5
>> [<c0132c21>] resolve_symbol+0x27/0x5f
>> [<c0133188>] simplify_symbols+0x83/0xf3
>> [<c0133e65>] load_module+0x720/0xbb8
>> [<c013435f>] sys_init_module+0x3f/0x1b5
>> [<c0102969>] sysenter_past_esp+0x56/0x79
>> Code: eb 11 8b 75 f0 41 83 c2 28 0f b7 46 30 39 c1 72 c9 31 c0 5a 59 5b
>> 5e 5f 5d c3 55 89 e5 57 56 53 89 c3 39 ca 73 22 8b 72 04 89 df <ac> ae
>> 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 04 89
>> EIP: [<c0131e02>] lookup_symbol+0x11/0x35 SS:ESP 0068:df657e68
>>
>
>
> I'm seeing a similar issue. Although the log is a bit futzed. Maybe its
> the sd_mod?
>
> at virtual address 75010000le kernel paging requestproc filesystem
>
> printing eip:
>
> Creating /dev
> c01372d5
> Starting udev
> L*pde = cccccccc
> oading sd_mod.kostopped custom tracer.
> module
> Oops: 0000 [#1]
> PREEMPT SMP
> Modules linked in:
> CPU: 3
> EIP: 0060:[<c01372d5>] Not tainted VLI
> EFLAGS: 00010293 (2.6.18-rt3johnsmp #1)
> EIP is at lookup_symbol+0x15/0x37
> eax: ffffffff ebx: f88209a0 ecx: c03916fc edx: c038eba0
> esi: 75010000 edi: f881a405 ebp: c7d01ea4 esp: c7d01e64
> ds: 007b es: 007b ss: 0068 preempt: 00000001
> Process insmod (pid: 462, ti=c7d00000 task=f7d6c1f0 task.ti=c7d00000)
> Stack: f8821e00 f881a405 c0137345 f881a405 c038c658 c03916fc f88209a0 f8821e00
> f881a405 00000000 c0138145 f881a405 c7d01ea0 c7d01ea4 00000001 00000000
> f881a405 f88209a0 00000500 0000003c c01386d2 f88193d0 0000000b f881a405
> Call Trace:
> [<c0137345>] __find_symbol+0x26/0x2e0
> [<c0138145>] resolve_symbol+0x23/0x5f
> [<c01386d2>] simplify_symbols+0x7e/0xf0
> [<c013942d>] load_module+0x7c4/0xc14
> [<c01398dd>] sys_init_module+0x3d/0x1ae
> [<c01029d9>] sysenter_past_esp+0x56/0x79
> Code: c8 eb 0e 0f b7 45 30 41 83 c2 28 39 c1 72 ca 31 c0 5b 5e 5f 5d c3 57 56 8b 4c 24 14 8b 54 24 10 39 ca 73 24 8b 72 04 8b 7c 24 0c <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 04 89
> EIP: [<c01372d5>] lookup_symbol+0x15/0x37 SS:ESP 0068:c7d01e64
> ERROR: /bin/insmod exited abnormally! (pid 462)
> Loading jbd.ko module
>
>
> thanks
> -john
>

Yes. This looks very much like the problem I am having. However, on the
system that this log came from I have no SCSI.

--
kr

2006-09-22 06:36:24

by Lennert Buytenhek

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Thu, Sep 21, 2006 at 10:19:21PM -0400, john cooper wrote:

> >ok, i've uploaded -rt3:
>
> Attached is a patch which fixes a build problem
> for ARM pxa270, and general ARM boot issue when
> LATENCY_TRACE is configured.
>
> -john
>
> --
> [email protected]

> include/asm-arm/arch-pxa/timex.h | 2 ++
> kernel/latency_trace.c | 2 ++
> 2 files changed, 4 insertions(+)
> =================================================================
> --- ./kernel/latency_trace.c.ORG 2006-09-20 21:10:15.000000000 -0400
> +++ ./kernel/latency_trace.c 2006-09-21 21:28:49.000000000 -0400
> @@ -150,6 +150,8 @@ enum trace_flag_type
> */
> #if !defined(CONFIG_DEBUG_PAGEALLOC) && !defined(CONFIG_SMP) && !defined(CONFIG_ARM)
> # define MAX_TRACE (unsigned long)(8192*16-1)
> +#elif defined(CONFIG_ARM) /* 4MB kernel image size limitation */
> +# define MAX_TRACE (unsigned long)(128*2-1)

This patch (queued for Linus) lifts that 4MB limitation:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3809/2

(I ran into the limit when enabling lockdep on ARM.)


cheers,
Lennert

2006-09-22 12:04:58

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* Lennert Buytenhek <[email protected]> wrote:

> On Thu, Sep 21, 2006 at 10:19:21PM -0400, john cooper wrote:
>
> > >ok, i've uploaded -rt3:
> >
> > Attached is a patch which fixes a build problem
> > for ARM pxa270, and general ARM boot issue when
> > LATENCY_TRACE is configured.
>
> This patch (queued for Linus) lifts that 4MB limitation:
>
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3809/2
>
> (I ran into the limit when enabling lockdep on ARM.)

ok, i've added this no-4M-limit patch to -rt. John, does that solve your
problem?

Ingo

2006-09-22 12:07:19

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* john stultz <[email protected]> wrote:

> I'm seeing a similar issue. Although the log is a bit futzed. Maybe
> its the sd_mod?
>
> at virtual address 75010000le kernel paging requestproc filesystem

would be nice to figure out why it crashes - unfortunately i cannot
trigger it. Could it be some build tool incompatibility perhaps? Some
sizing issue (some module struct gets too large)?

Ingo

2006-09-22 14:13:07

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 12:38 -0700, Mark Knecht wrote:
> On 9/20/06, Ingo Molnar <[email protected]> wrote:
> > I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> > from the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
>
> Hi Ingo,
> I gave 2.6.18-rt2 a quick try. It compiled fine but crashed on
> boot. I've no way to copy the screen. I can send along a digital photo
> if the following isn't enough info.
>
> QUESTION: Should I be able to run ati-drivers-8.28.8 with this kernel
> or would I have to wait for ATI to put out a 2.6.18 compatible driver?
> The current version does not emerge with 2.6.18-rt2.
>

I would not expect any proprietary ATI driver to work with an -rt
kernel, unless they specifically release a binary for -rt.

> Not sure how much that will help you. Been awhile since I've sent
> along crash reports. I'll have to ge a second Linux machine running to
> do the console boot capture thing if you need it.

Try -rt3. If the crash persists, you could take a picture of the screen
with a digital camera and post a link to it.

Lee


2006-09-22 14:42:56

by Daniel Walker

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Thu, 2006-09-21 at 21:02 +0200, Ingo Molnar wrote:
> * Daniel Walker <[email protected]> wrote:
>
> > On Wed, 2006-09-20 at 22:14 +0200, Ingo Molnar wrote:
> > > > if (up->port.sysrq) {
> > > > /* serial8250_handle_port() already took the lock */
> > > > locked = 0;
> >
> >
> > In this case it had interrupts off in the !PREEMPT_RT case, but your
> > change leaves them on here.. _irqsave only runs in two of the three
> > cases..
>
> doh, right you are. I updated to the patch below.
>
> Ingo


On closer inspection I still think this is wrong. (Although it looks
really nice..) find below speaking only in term of !PREEMPT_RT ,


> Index: linux/drivers/serial/8250.c
> ===================================================================
> --- linux.orig/drivers/serial/8250.c
> +++ linux/drivers/serial/8250.c
> @@ -2252,14 +2252,10 @@ serial8250_console_write(struct console
>
> touch_nmi_watchdog();
>
> - local_irq_save(flags);
> - if (up->port.sysrq) {
> - /* serial8250_handle_port() already took the lock */
> - locked = 0;

in the old version interrupts are off, and stay off until the function
returns in all cases. Even "locked = 0" .

> - } else if (oops_in_progress) {
> - locked = spin_trylock(&up->port.lock);
> - } else
> - spin_lock(&up->port.lock);
> + if (up->port.sysrq || oops_in_progress)
> + locked = spin_trylock_irqsave(&up->port.lock, flags);

Now in the new version interrupts are only off if you _get the lock_.
Presumably the lock is taken in the calling function, but interrupts
aren't disabled.

I'm assuming the code is disabling interrupts for a good reason, I don't
know enough about the code to say it isn't.

> + else
> + spin_lock_irqsave(&up->port.lock, flags);
>
> /*
> * First save the IER then disable the interrupts
> @@ -2281,8 +2277,7 @@ serial8250_console_write(struct console
> serial_out(up, UART_IER, ier);
>
> if (locked)
> - spin_unlock(&up->port.lock);
> - local_irq_restore(flags);
> + spin_unlock_irqrestore(&up->port.lock, flags);
> }
>
> static int serial8250_console_setup(struct console *co, char *options)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

2006-09-25 09:53:34

by Florian Schmidt

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wednesday 20 September 2006 16:19, Ingo Molnar wrote:
> I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> This port to the 2.6.18 codebase was very complex (given that 5 major
> features moved from -rt into 2.6.18: rtmutex, pi-futex, genirq, gtod and
> lockdep), so it took quite some time to finish, but in exchange it
> includes nice new features and also lots of bugfixes.

Hi, i tried 2.6.18-rt3 on my athlon 1.2ghz box and it builds and boots just
fine (tried complete preemption, hi res timers and tickless kernel). I see
some rather strange hi-level problems though:


- I haven't built the realtime lsm yet, nor does debian have rt_limits support
for pam (i think, and even if it does i haven't set it up as i use rt-lsm). I
can run jackd in realtime mode without problems though. This is very strange.
As if no capabilities checkign is done.

- I cannot log into X through gdm, as it seems that independent of what kind
of session i select X dies right after login. I need to startx from the
console. I wouldn't know where to look for more info on this though.

- Switching from X to another virtual console takes ca. 20 seconds in which
nothing happens, the screen locks, but the mouse cursor is still movable,
then finally it switches to the console allright.

.config attached

Besides these problems it ran very well for the hours i had it up. Nothing
suspicious in the logs. Will try another build with more aggressive debugging
options.

Regards,
Flo

--
Palimm Palimm!
http://tapas.affenbande.org


Attachments:
(No filename) (1.59 kB)
.config (36.28 kB)
Download all attachments

2006-09-25 16:12:16

by Mike Kravetz

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, Sep 20, 2006 at 04:19:07PM +0200, Ingo Molnar wrote:
> In particular, a nasty softirq performance bug has been fixed, which
> caused the "5x slowdown under TCP" bug reported to lkml - those TCP
> performance figures are now on par with vanilla performance.

Just curious about the cause and fix for this issue. I tried searching
the mail lists for discussion but came up empty. The patch it too big
for me to determine what specific changes addressed this issue. If anyone
can point me in the right direction, that would be appreciated.

Thanks,
--
Mike

2006-09-26 07:57:34

by Florian Schmidt

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Monday 25 September 2006 11:53, Florian Schmidt wrote:
> .config attached
>
> Besides these problems it ran very well for the hours i had it up. Nothing
> suspicious in the logs. Will try another build with more aggressive
> debugging options.

Erm, forget this bug report.

- The long switching to console time seems to be duee to the xorg nv driver

- logging into X via gdm now fails under different kernels, too (though i
still have no clue why)

- also in 2.6.17-rt8 i can run jack with rt even though no rt-lsm is loaded.
This is the only really funky one, but i suspect there's some other mechanism
that explains this.

Regarsd,
Flo

--
Palimm Palimm!
http://tapas.affenbande.org

2006-09-27 03:08:35

by Eric W. Biederman

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

Bill Huey (hui) <[email protected]> writes:

> On Wed, Sep 20, 2006 at 04:19:07PM +0200, Ingo Molnar wrote:
>> I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
>> from the usual place:
> ...
>> as usual, bugreports, fixes and suggestions are welcome,
>
> Speaking of which...
>
> This patch moves put_task_struct() reaping into a thread instead of an
> RCU callback function as discussed with Esben publically and Ingo privately:

Stupid question.

Why does the rt tree make all calls to put_task_struct an rcu action?
We only need the rcu callback from kernel/exit.c

Nothing else needs those semantics.

I agree that put_task_struct is the most common point so this is unlikely
to remove your issues with rcu callbacks but it just seems completely backwards
to increase the number of rcu callbacks in the rt tree.

Eric

2006-09-27 05:09:36

by Bill Huey

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Tue, Sep 26, 2006 at 08:55:41PM -0600, Eric W. Biederman wrote:
> Bill Huey (hui) <[email protected]> writes:
> > This patch moves put_task_struct() reaping into a thread instead of an
> > RCU callback function as discussed with Esben publically and Ingo privately:
>
> Stupid question.

It's a great question actually.

> Why does the rt tree make all calls to put_task_struct an rcu action?
> We only need the rcu callback from kernel/exit.c

Because the conversion of memory allocation routines like kmalloc and kfree aren't
safely callable within a preempt_disable critical section since they were incompletely
converted in the -rt. It can run into the sleeping in atomic scenario which can result
in a deadlock since those routines use blocking locks internally in the implementation
now as a result of the spinlock_t conversion to blocking locks.

> Nothing else needs those semantics.

Right, blame it on the incomplete conversion of the kmalloc and friends. GFP_ATOMIC is
is kind of meaningless in the -rt tree and it might be a good thing to add something
like GFP_RT_ATOMIC for cases like this to be handled properly and restore that particular
semantic in a more meaningful way.

> I agree that put_task_struct is the most common point so this is unlikely
> to remove your issues with rcu callbacks but it just seems completely backwards
> to increase the number of rcu callbacks in the rt tree.

I'm not sure what mean here, but if you mean that you don't like the RCU API abuse then
I agree with you on that. However, Ingo disagrees and I'm not going to argue it with him.
Although, I'm not going stop you if you do. :)

bill

2006-09-27 06:13:57

by Eric W. Biederman

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

Bill Huey (hui) <[email protected]> writes:

> On Tue, Sep 26, 2006 at 08:55:41PM -0600, Eric W. Biederman wrote:
>> Bill Huey (hui) <[email protected]> writes:
>> > This patch moves put_task_struct() reaping into a thread instead of an
>> > RCU callback function as discussed with Esben publically and Ingo privately:
>>
>> Stupid question.
>
> It's a great question actually.
>
>> Why does the rt tree make all calls to put_task_struct an rcu action?
>> We only need the rcu callback from kernel/exit.c
>
> Because the conversion of memory allocation routines like kmalloc and kfree aren't
> safely callable within a preempt_disable critical section since they were incompletely
> converted in the -rt. It can run into the sleeping in atomic scenario which can result
> in a deadlock since those routines use blocking locks internally in the implementation
> now as a result of the spinlock_t conversion to blocking locks.

Interesting. I think the easy solution would just be to assert that put_task_struct
can sleep and to fix any callers that expect differently. I haven't looked very
closely but I don't recall anything that needs put_task_struct to be atomic.
With a function that complex I certainly would not expect it to never sleep unless
it had a big fat comment.

Well I did find an instance where we call put_task_struct with a
spinlock held. Inside of lib/rwsem.c:rwsem_down_failed_common().

Still that may be the only user that cares. I suspect with a little
code rearrangement that case is fixable. It's not like that code is a
fast path or anything. It should just be a matter of passing the
task struct outside of the spinlock before calling put_task_struct.

>> Nothing else needs those semantics.
>
> Right, blame it on the incomplete conversion of the kmalloc and friends. GFP_ATOMIC is
> is kind of meaningless in the -rt tree and it might be a good thing to add something
> like GFP_RT_ATOMIC for cases like this to be handled properly and restore that
> particular semantic in a more meaningful way.

But this is a path where we are freeing data, so GFP_ATOMIC should not come
into it. I just read through the code and there are not allocations
there.

>> I agree that put_task_struct is the most common point so this is unlikely
>> to remove your issues with rcu callbacks but it just seems completely backwards
>> to increase the number of rcu callbacks in the rt tree.
>
> I'm not sure what mean here, but if you mean that you don't like the RCU API abuse then
> I agree with you on that. However, Ingo disagrees and I'm not going to argue it with him.
> Although, I'm not going stop you if you do. :)

What I was thinking is that rcu isn't terribly friendly to realtime
activities because it postpones work and can wind up with a lot of
work to do at some random time later which can be bad for latencies.

So I was very surprised to see an rt patch making more things under
rcu protection. Especially as I have heard other developers worried
about rt issues discussing removing the rcu functionality.

My gut feel now that I understand the pieces is that this approach has
all of the hallmarks of a hack, both the kmalloc/kfree thing and even
more calling put_task_struct in an atomic context. If the callers
were fixed put_task_struct could safely sleep so kmalloc/kfree
sleeping would not be a problem.

Eric

2006-09-27 06:34:37

by Bill Huey

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Wed, Sep 27, 2006 at 12:02:21AM -0600, Eric W. Biederman wrote:
> Bill Huey (hui) <[email protected]> writes:
> > Because the conversion of memory allocation routines like kmalloc and kfree aren't
> > safely callable within a preempt_disable critical section since they were incompletely
> > converted in the -rt. It can run into the sleeping in atomic scenario which can result
> > in a deadlock since those routines use blocking locks internally in the implementation
> > now as a result of the spinlock_t conversion to blocking locks.
>
> Interesting. I think the easy solution would just be to assert that put_task_struct
> can sleep and to fix any callers that expect differently. I haven't looked very
> closely but I don't recall anything that needs put_task_struct to be atomic.
> With a function that complex I certainly would not expect it to never sleep unless
> it had a big fat comment.

One of the main claims about the -rt patch is that the kernel is basically
conversion of the current locking semantics in the kernel. What you mentioned
above would deviate from that and and clutter non-preemptive kernel maintenance.
If you're suggesting a more general change to that function, then it wouldn't
violate that.

> Well I did find an instance where we call put_task_struct with a
> spinlock held. Inside of lib/rwsem.c:rwsem_down_failed_common().
>
> Still that may be the only user that cares. I suspect with a little
> code rearrangement that case is fixable. It's not like that code is a
> fast path or anything. It should just be a matter of passing the
> task struct outside of the spinlock before calling put_task_struct.

Yeah, that's what the small patch of mine does outside of doing an RCU
callback.

> > Right, blame it on the incomplete conversion of the kmalloc and friends. GFP_ATOMIC is
> > is kind of meaningless in the -rt tree and it might be a good thing to add something
> > like GFP_RT_ATOMIC for cases like this to be handled properly and restore that
> > particular semantic in a more meaningful way.
>
> But this is a path where we are freeing data, so GFP_ATOMIC should not come
> into it. I just read through the code and there are not allocations
> there.

Correct, I see it as a possibly bigger problem since memory allocators and
destructors aren't available readily in preempt_disable critical sections.
It's not the case in the regular kernel which could be a significant concern.

> > I'm not sure what mean here, but if you mean that you don't like the RCU API abuse then
> > I agree with you on that. However, Ingo disagrees and I'm not going to argue it with him.
> > Although, I'm not going stop you if you do. :)
>
> What I was thinking is that rcu isn't terribly friendly to realtime
> activities because it postpones work and can wind up with a lot of
> work to do at some random time later which can be bad for latencies.
>
> So I was very surprised to see an rt patch making more things under
> rcu protection. Especially as I have heard other developers worried
> about rt issues discussing removing the rcu functionality.

There are a couple of issues here.

(1) The RCU callback isn't used in this case to back other RCU read critical
sections. It's just used as a generic callback mechanism in this case. Some
consider it a hack.

(2) RCU isn't necessarily bad for -rt since Paul McKenney and folks are
working on making it preempt friendly. Any talk of removing the use RCU in -rt
is premature and probably unlikely because of this work. There are many options
here. RCU very useful for scalability so seeing it go away in -rt would be
generally a bad thing IMO.

The use of lock-free techinques is something that could eventually be more
widely used in -rt since it'll make kernel call paths potentially more
deterministic without worrying about hitting a contending mutex and that can
effect determinism. It's not expect to be the case where calls into the kernel
are going to be deterministic but to extend the basic idea of determinism into
certain critical kernel paths like a read() to a special device driver, etc...

Route table look up also comes to mind here that benefits from this case if
there's a need for real time facilities in networking.

Just some ideas here.

> My gut feel now that I understand the pieces is that this approach has
> all of the hallmarks of a hack, both the kmalloc/kfree thing and even
> more calling put_task_struct in an atomic context. If the callers
> were fixed put_task_struct could safely sleep so kmalloc/kfree
> sleeping would not be a problem.

I can't say. The current logic just queues the request into a list and a
thread wakes to reap that task_struct. It's sufficient and the need to
convert put_task_struct so that it can block.

bill

2006-09-27 07:31:26

by Eric W. Biederman

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

Bill Huey (hui) <[email protected]> writes:

> On Wed, Sep 27, 2006 at 12:02:21AM -0600, Eric W. Biederman wrote:
>> Bill Huey (hui) <[email protected]> writes:
>> Interesting. I think the easy solution would just be to assert that put_task_struct
>> can sleep and to fix any callers that expect differently. I haven't looked very
>> closely but I don't recall anything that needs put_task_struct to be atomic.
>> With a function that complex I certainly would not expect it to never sleep unless
>> it had a big fat comment.
>
> One of the main claims about the -rt patch is that the kernel is basically
> conversion of the current locking semantics in the kernel. What you mentioned
> above would deviate from that and and clutter non-preemptive kernel maintenance.
> If you're suggesting a more general change to that function, then it wouldn't
> violate that.

Yes I am. The motivator would be the RT work but I don't see a reason why
the it couldn't be put in the mainline kernel. If not at least we need
the big fat comment in the mainline kernel that says put_task_struct must
be safe to call with interrupts disabled.

The way the code is structured now it deviates from the mainline kernel in
more than just changing locking behavior. Which is what brought me into
this conversation in the first place. So removing that point of discord
would be good.

>> Well I did find an instance where we call put_task_struct with a
>> spinlock held. Inside of lib/rwsem.c:rwsem_down_failed_common().
>>
>> Still that may be the only user that cares. I suspect with a little
>> code rearrangement that case is fixable. It's not like that code is a
>> fast path or anything. It should just be a matter of passing the
>> task struct outside of the spinlock before calling put_task_struct.
>
> Yeah, that's what the small patch of mine does outside of doing an RCU
> callback.

If you have fixed rwsem_down_failed_common() like it sounds like you have.
That would be a nice patch to for the mainline kernel.


>> But this is a path where we are freeing data, so GFP_ATOMIC should not come
>> into it. I just read through the code and there are not allocations
>> there.
>
> Correct, I see it as a possibly bigger problem since memory allocators and
> destructors aren't available readily in preempt_disable critical sections.
> It's not the case in the regular kernel which could be a significant concern.

Yes. I would say that memory allocators have never been readily available in
sections where we have preemption disabled, but they at least are available
and sometimes they will even give you the memory you asked for.

> There are a couple of issues here.
>
> (1) The RCU callback isn't used in this case to back other RCU read critical
> sections. It's just used as a generic callback mechanism in this case. Some
> consider it a hack.
>
> (2) RCU isn't necessarily bad for -rt since Paul McKenney and folks are
> working on making it preempt friendly. Any talk of removing the use RCU in -rt
> is premature and probably unlikely because of this work. There are many options
> here. RCU very useful for scalability so seeing it go away in -rt would be
> generally a bad thing IMO.

Agreed. However until the issues are resolved with call_rcu it appears quite
silly to increase the usage of it in the RT tree.

About the rcu removal discussion I heard it was more the possibility was
suggested because the downside was significant, and normal locks were
more deterministic. The emphasis was that call_rcu could be a problem and
that something needs to happen to fix that.

> The use of lock-free techinques is something that could eventually be more
> widely used in -rt since it'll make kernel call paths potentially more
> deterministic without worrying about hitting a contending mutex and that can
> effect determinism. It's not expect to be the case where calls into the kernel
> are going to be deterministic but to extend the basic idea of determinism into
> certain critical kernel paths like a read() to a special device driver, etc...
>
> Route table look up also comes to mind here that benefits from this case if
> there's a need for real time facilities in networking.
>
> Just some ideas here.

Agreed. The normal rcu path is quite nice. It is the call_rcu part used
to implement delayed freeing where things get ugly.

>> My gut feel now that I understand the pieces is that this approach has
>> all of the hallmarks of a hack, both the kmalloc/kfree thing and even
>> more calling put_task_struct in an atomic context. If the callers
>> were fixed put_task_struct could safely sleep so kmalloc/kfree
>> sleeping would not be a problem.
>
> I can't say. The current logic just queues the request into a list and a
> thread wakes to reap that task_struct. It's sufficient and the need to
> convert put_task_struct so that it can block.

Yes the current logic is simple and requires no changes elsewhere.
It is always nice when you can do that. But in this case it adds unnecessary
overhead, and indeterminism. From what little I understand of RCU both
of those are bad things. Thus my gut feeling that the approach is a hack
and should get fixed properly.

Anyway short of submitting a patch I think I have said enough.
Thank you for the explanation.

Eric

2006-09-27 08:42:27

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* Mike Kravetz <[email protected]> wrote:

> On Wed, Sep 20, 2006 at 04:19:07PM +0200, Ingo Molnar wrote:
> > In particular, a nasty softirq performance bug has been fixed, which
> > caused the "5x slowdown under TCP" bug reported to lkml - those TCP
> > performance figures are now on par with vanilla performance.
>
> Just curious about the cause and fix for this issue. I tried
> searching the mail lists for discussion but came up empty. The patch
> it too big for me to determine what specific changes addressed this
> issue. If anyone can point me in the right direction, that would be
> appreciated.

i /think/ it's this bit of code commented out in kernel/softirq.c:

//if (!in_interrupt() && local_softirq_pending())
// invoke_softirq();

try to uncomment that. (this should i think do the trick on PREEMPT_RT -
but no guarantees. It might cause problems on !PREEMPT_RT configs, i had
to juggle around some code here. Maybe the easiest would be if you tried
to take the new softirq.c, sans the lockdep changes. Not sure how
feasible that is though.)

Ingo

2006-09-27 08:44:23

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* Daniel Walker <[email protected]> wrote:

> On closer inspection I still think this is wrong. (Although it looks
> really nice..) find below speaking only in term of !PREEMPT_RT ,

> > - } else if (oops_in_progress) {
> > - locked = spin_trylock(&up->port.lock);
> > - } else
> > - spin_lock(&up->port.lock);
> > + if (up->port.sysrq || oops_in_progress)
> > + locked = spin_trylock_irqsave(&up->port.lock, flags);
>
> Now in the new version interrupts are only off if you _get the lock_.
> Presumably the lock is taken in the calling function, but interrupts
> aren't disabled.
>
> I'm assuming the code is disabling interrupts for a good reason, I
> don't know enough about the code to say it isn't.

yeah, agreed - behavior now changed due to my patch. This is really
twisted code...

Ingo

2006-09-27 09:05:37

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Bill Huey <[email protected]> wrote:

> Because the conversion of memory allocation routines like kmalloc and
> kfree aren't safely callable within a preempt_disable critical section
> since they were incompletely converted in the -rt. [...]

they were not 'incompletely converted' - they are /intentionally/ fully
preemptible.

Ingo

2006-09-27 09:09:47

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Eric W. Biederman <[email protected]> wrote:

> Yes I am. The motivator would be the RT work but I don't see a reason
> why the it couldn't be put in the mainline kernel. If not at least we
> need the big fat comment in the mainline kernel that says
> put_task_struct must be safe to call with interrupts disabled.
>
> The way the code is structured now it deviates from the mainline
> kernel in more than just changing locking behavior. Which is what
> brought me into this conversation in the first place. So removing
> that point of discord would be good.

well, this is one of those few cases (out of ~50,000 lock uses in the
kernel) where such a change was unavoidable: put_task_struct() is used
in the scheduler context-switch path. (see sched.c:finish_task_switch())

So that's why i first turned it into a separate, extra delayed-free via
the "desched thread", and later on picked up the RCUification from Paul
McKenney. The RCUification was the simpler (and hence easier to
maintain) change. There is no problem with putting this into the RCU
path on PREEMPT_RT, as this is a resource-freeing act. I.e. whatever
'delay' there might be in RCU processing, it does not impact program
logic. I agree with you that on !PREEMPT_RT there's no reason to
complicate things with an extra layer of indirection.

Ingo

2006-09-27 09:10:19

by Bill Huey

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Wed, Sep 27, 2006 at 01:29:44AM -0600, Eric W. Biederman wrote:
> Bill Huey (hui) <[email protected]> writes:
> > One of the main claims about the -rt patch is that the kernel is basically
> > conversion of the current locking semantics in the kernel. What you mentioned
> > above would deviate from that and and clutter non-preemptive kernel maintenance.
> > If you're suggesting a more general change to that function, then it wouldn't
> > violate that.
>
> Yes I am. The motivator would be the RT work but I don't see a reason why
> the it couldn't be put in the mainline kernel. If not at least we need
> the big fat comment in the mainline kernel that says put_task_struct must
> be safe to call with interrupts disabled.
>
> The way the code is structured now it deviates from the mainline kernel in
> more than just changing locking behavior. Which is what brought me into
> this conversation in the first place. So removing that point of discord
> would be good.

Yes, there are few places. It was primarily to handle the reaping during the
finishing parts of a fork. All in all, it's not at all a critical path.

> If you have fixed rwsem_down_failed_common() like it sounds like you have.
> That would be a nice patch to for the mainline kernel.

The problem only exists under -rt in that scheduling path. I can't comment if
it's desired for mainline or not.

> > There are a couple of issues here.
> >
> > (1) The RCU callback isn't used in this case to back other RCU read critical
> > sections. It's just used as a generic callback mechanism in this case. Some
> > consider it a hack.
> >
> > (2) RCU isn't necessarily bad for -rt since Paul McKenney and folks are
> > working on making it preempt friendly. Any talk of removing the use RCU in -rt
> > is premature and probably unlikely because of this work. There are many options
> > here. RCU very useful for scalability so seeing it go away in -rt would be
> > generally a bad thing IMO.
>
> Agreed. However until the issues are resolved with call_rcu it appears quite
> silly to increase the usage of it in the RT tree.
>
> About the rcu removal discussion I heard it was more the possibility was
> suggested because the downside was significant, and normal locks were
> more deterministic. The emphasis was that call_rcu could be a problem and
> that something needs to happen to fix that.

In a general purpose system as complicated as Linux, "locks being more
deterministic" is kind of ridiculous. Tons of stuff can happen that you
can't control. The RCU thing that you heard was probably just ideas being
thrown around and there are many options that haven't been explored yet.
The actual scenario is more complicated than what you might have initially
heard.

> Agreed. The normal rcu path is quite nice. It is the call_rcu part used
> to implement delayed freeing where things get ugly.

The RCU callback stuff runs as a thread. The key part of a preemptible system
that can make guarantees is the ability to response to a higher priority thread
in a deterministic amount of time. That's the only real guarantee that can be
made in that system. Because of it running in a thread, callbacks in RCU don't
effect the preemptibility of the system at all.

Any kernel thread taking the risk of acquiring a lock cannot be deterministic
in any reasonable sense. Any claims of a guarantee is pretty much a lie since
the system is too complicated to analysize for determinism in any meaningful
way using the analysis techniques out there. The kernel is just too complicated.

In contrast, specialize RT apps with few threads is another scenario that's much
more controllable.

> Yes the current logic is simple and requires no changes elsewhere.
> It is always nice when you can do that. But in this case it adds unnecessary
> overhead, and indeterminism. From what little I understand of RCU both
> of those are bad things. Thus my gut feeling that the approach is a hack
> and should get fixed properly.

I agree. It's a hack and it should go away. You're the fourth person to mention
something about this, but it's up to Ingo.

> Anyway short of submitting a patch I think I have said enough.
> Thank you for the explanation.

No problem, any time :)

bill

2006-09-27 09:13:48

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Bill Huey <[email protected]> wrote:

> > more than just changing locking behavior. Which is what brought me
> > into this conversation in the first place. So removing that point
> > of discord would be good.
>
> Yes, there are few places. It was primarily to handle the reaping
> during the finishing parts of a fork. All in all, it's not at all a
> critical path.

no. It was primarily to move the put_task_struct() off the
context-switch fastpath. (In comparison the fork use is much rarer)

Ingo

2006-09-27 09:15:23

by Bill Huey

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Wed, Sep 27, 2006 at 10:57:12AM +0200, Ingo Molnar wrote:
> * Bill Huey <[email protected]> wrote:
>
> > Because the conversion of memory allocation routines like kmalloc and
> > kfree aren't safely callable within a preempt_disable critical section
> > since they were incompletely converted in the -rt. [...]
>
> they were not 'incompletely converted' - they are /intentionally/ fully
> preemptible.

What I meant by "incompletely converted" is that the allocators could be
made more safe in non-preemptible scenarios under -rt. It's potentially
a valuable thing to have since GFP_ATOMIC semantics already exist in the
current allocators and a newer category could be added as a new feature of
that allocator for those scenarios. I'm happy dequeuing things off of my
own free list, but that's just me.

-rt semanatics created a couple of new locking scenarios that the previous
kernel didn't really have to address. That's all that I meant by that. :)

bill

2006-09-27 09:17:09

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Eric W. Biederman <[email protected]> wrote:

> About the rcu removal discussion I heard it was more the possibility
> was suggested because the downside was significant, and normal locks
> were more deterministic. The emphasis was that call_rcu could be a
> problem and that something needs to happen to fix that.

RCU is really mostly used as a garbage-collection scheme, and hence its
latency, while it can be practically problematic in some cases, never is
directly visible in terms of application or kernel behavior.

the same is in this case: the call_rcu() use is for gathering totally
unused task structs. There should be no side-effects.

Ingo

2006-09-27 09:23:06

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Bill Huey <[email protected]> wrote:

> On Wed, Sep 27, 2006 at 10:57:12AM +0200, Ingo Molnar wrote:
> > * Bill Huey <[email protected]> wrote:
> >
> > > Because the conversion of memory allocation routines like kmalloc and
> > > kfree aren't safely callable within a preempt_disable critical section
> > > since they were incompletely converted in the -rt. [...]
> >
> > they were not 'incompletely converted' - they are /intentionally/ fully
> > preemptible.
>
> What I meant by "incompletely converted" is that the allocators could
> be made more safe in non-preemptible scenarios under -rt. [...]

no, the -rt kernel intentionally does not do that and wont do that.
There's lots of complex stuff going on within allocators, even in the
GFP_ATOMIC path. We might be able to plug in more deterministic
allocators (like SLOB), but even they must be fully preemptible. In the
-rt kernel there's basically no compromise on the "do as little as
possible in non-preemptible regions" stance.

Ingo

2006-09-27 13:13:21

by john cooper

[permalink] [raw]
Subject: 2.6.18-rt4

Ingo Molnar wrote:
> * Lennert Buytenhek <[email protected]> wrote:
>
>> On Thu, Sep 21, 2006 at 10:19:21PM -0400, john cooper wrote:
>>
>>>> ok, i've uploaded -rt3:
>>> Attached is a patch which fixes a build problem
>>> for ARM pxa270, and general ARM boot issue when
>>> LATENCY_TRACE is configured.
>> This patch (queued for Linus) lifts that 4MB limitation:
>>
>> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3809/2
>>
>> (I ran into the limit when enabling lockdep on ARM.)
>
> ok, i've added this no-4M-limit patch to -rt. John, does that solve your
> problem?

A few of us hit a snag in Lennert's original patch. He has a
fix which addresses this, attached.

-john

--
[email protected]


Attachments:
fix-allow-large-kernels.diff (985.00 B)

2006-09-27 13:17:21

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt4


* john cooper <[email protected]> wrote:

> >ok, i've added this no-4M-limit patch to -rt. John, does that solve
> >your problem?
>
> A few of us hit a snag in Lennert's original patch. He has a fix
> which addresses this, attached.

ok, applied.

Ingo

2006-09-27 14:01:57

by Eric W. Biederman

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

Ingo Molnar <[email protected]> writes:

> * Eric W. Biederman <[email protected]> wrote:
>
>> Yes I am. The motivator would be the RT work but I don't see a reason
>> why the it couldn't be put in the mainline kernel. If not at least we
>> need the big fat comment in the mainline kernel that says
>> put_task_struct must be safe to call with interrupts disabled.
>>
>> The way the code is structured now it deviates from the mainline
>> kernel in more than just changing locking behavior. Which is what
>> brought me into this conversation in the first place. So removing
>> that point of discord would be good.
>
> well, this is one of those few cases (out of ~50,000 lock uses in the
> kernel) where such a change was unavoidable: put_task_struct() is used
> in the scheduler context-switch path. (see sched.c:finish_task_switch())

I had missed that was in a preempt disable path when I skimmed through
the users.

> So that's why i first turned it into a separate, extra delayed-free via
> the "desched thread", and later on picked up the RCUification from Paul
> McKenney. The RCUification was the simpler (and hence easier to
> maintain) change. There is no problem with putting this into the RCU
> path on PREEMPT_RT, as this is a resource-freeing act. I.e. whatever
> 'delay' there might be in RCU processing, it does not impact program
> logic. I agree with you that on !PREEMPT_RT there's no reason to
> complicate things with an extra layer of indirection.

I'm still wondering if we can move put_task_struct a little lower in
the logic in the places where it is called, so it isn't called under a
lock, or with preemption disabled. The only downside I see is that it
might convolute the logic into unreadability.

In general I get nervous about calling big functions while holding locks.

Eric

2006-09-27 14:15:07

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Eric W. Biederman <[email protected]> wrote:

> I'm still wondering if we can move put_task_struct a little lower in
> the logic in the places where it is called, so it isn't called under a
> lock, or with preemption disabled. The only downside I see is that it
> might convolute the logic into unreadability.

well it's all a function of the task reaping logic: right now we in
essence complete the reaping from the scheduler, via prev_state ==
TASK_DEAD. We cannot do it sooner because the task is still in use. I
had one other implementation upstream some time ago, which was a
single-slot cache for reaped tasks - but that uglified other codepaths
because _something_ has to notice that the task has been unscheduled.

Ingo

2006-09-27 16:17:55

by Paul E. McKenney

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

On Wed, Sep 27, 2006 at 04:06:59PM +0200, Ingo Molnar wrote:
>
> * Eric W. Biederman <[email protected]> wrote:
>
> > I'm still wondering if we can move put_task_struct a little lower in
> > the logic in the places where it is called, so it isn't called under a
> > lock, or with preemption disabled. The only downside I see is that it
> > might convolute the logic into unreadability.
>
> well it's all a function of the task reaping logic: right now we in
> essence complete the reaping from the scheduler, via prev_state ==
> TASK_DEAD. We cannot do it sooner because the task is still in use. I
> had one other implementation upstream some time ago, which was a
> single-slot cache for reaped tasks - but that uglified other codepaths
> because _something_ has to notice that the task has been unscheduled.

I believe that we are way too far into the task-teardown process for
something like synchronize_rcu() to be feasible (not enough of the
task left to be able to sleep!), but thought I should bring up the
possibility on the off-chance that it caused someone to come up with a
better approach.

Another possible approach would be workqueues. The disadvantages here are
(1) higher overhead (2) workqueues can be delayed for a -long- time in a
realtime environment, which increases vulnerability to memory exhaustion.

Again, hoping this provokes some better ideas...

Thanx, Paul

2006-09-27 20:29:12

by Esben Nielsen

[permalink] [raw]
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]



On Wed, 27 Sep 2006, Eric W. Biederman wrote:

> Bill Huey (hui) <[email protected]> writes:
>
>> On Tue, Sep 26, 2006 at 08:55:41PM -0600, Eric W. Biederman wrote:
>>> Bill Huey (hui) <[email protected]> writes:
>>>> This patch moves put_task_struct() reaping into a thread instead of an
>>>> RCU callback function as discussed with Esben publically and Ingo privately:
>>>
>>> Stupid question.
>>
>> It's a great question actually.
>>
>>> Why does the rt tree make all calls to put_task_struct an rcu action?
>>> We only need the rcu callback from kernel/exit.c
>>
>> Because the conversion of memory allocation routines like kmalloc and kfree aren't
>> safely callable within a preempt_disable critical section since they were incompletely
>> converted in the -rt. It can run into the sleeping in atomic scenario which can result
>> in a deadlock since those routines use blocking locks internally in the implementation
>> now as a result of the spinlock_t conversion to blocking locks.
>
> Interesting. I think the easy solution would just be to assert that put_task_struct
> can sleep and to fix any callers that expect differently. I haven't looked very
> closely but I don't recall anything that needs put_task_struct to be atomic.
> With a function that complex I certainly would not expect it to never sleep unless
> it had a big fat comment.
>
> Well I did find an instance where we call put_task_struct with a
> spinlock held. Inside of lib/rwsem.c:rwsem_down_failed_common().
>
> Still that may be the only user that cares. I suspect with a little
> code rearrangement that case is fixable. It's not like that code is a
> fast path or anything. It should just be a matter of passing the
> task struct outside of the spinlock before calling put_task_struct.
>
>>> Nothing else needs those semantics.
>>
>> Right, blame it on the incomplete conversion of the kmalloc and friends. GFP_ATOMIC is
>> is kind of meaningless in the -rt tree and it might be a good thing to add something
>> like GFP_RT_ATOMIC for cases like this to be handled properly and restore that
>> particular semantic in a more meaningful way.
>
> But this is a path where we are freeing data, so GFP_ATOMIC should not come
> into it. I just read through the code and there are not allocations
> there.
>
>>> I agree that put_task_struct is the most common point so this is unlikely
>>> to remove your issues with rcu callbacks but it just seems completely backwards
>>> to increase the number of rcu callbacks in the rt tree.
>>
>> I'm not sure what mean here, but if you mean that you don't like the RCU API abuse then
>> I agree with you on that. However, Ingo disagrees and I'm not going to argue it with him.
>> Although, I'm not going stop you if you do. :)
>
> What I was thinking is that rcu isn't terribly friendly to realtime
> activities because it postpones work and can wind up with a lot of
> work to do at some random time later which can be bad for latencies.
>

Only activities with no deadlines are postponed. And therefore RCU is good
for the latencies of the application. No high-priority, low-latency task
should bother spend time traversing and freeing a complicated datastructure.
Defer that to some lower priority task.

Esben

> So I was very surprised to see an rt patch making more things under
> rcu protection. Especially as I have heard other developers worried
> about rt issues discussing removing the rcu functionality.
>
> My gut feel now that I understand the pieces is that this approach has
> all of the hallmarks of a hack, both the kmalloc/kfree thing and even
> more calling put_task_struct in an atomic context. If the callers
> were fixed put_task_struct could safely sleep so kmalloc/kfree
> sleeping would not be a problem.
>

That put_task_struct uses RCU is a hack to defer the job to a lower
priority task. I think the right solution is to defer the job to a lower
priority task using a cheaper mechanism. put_task_struct() is used from
high priority tasks in the priority inheritance code and should only do
the minimal job of defering the real work to another task.

Esben

> Eric
>

2006-09-28 00:42:08

by john stultz

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Fri, 2006-09-22 at 13:58 +0200, Ingo Molnar wrote:
> * john stultz <[email protected]> wrote:
>
> > I'm seeing a similar issue. Although the log is a bit futzed. Maybe
> > its the sd_mod?
> >
> > at virtual address 75010000le kernel paging requestproc filesystem
>
> would be nice to figure out why it crashes - unfortunately i cannot
> trigger it. Could it be some build tool incompatibility perhaps? Some
> sizing issue (some module struct gets too large)?

Been looking a bit deeper into this again:

BUG: unable to handle kernel paging request at virtual address 75010000
printing eip:
c01354ea
*pde = cccccccc
stopped custom tracer.
Oops: 0000 [#1]
SMP
Modules linked in:
CPU: 1
EIP: 0060:[<c01354ea>] Not tainted VLI
EFLAGS: 00010282 (2.6.18-rtjohn #9)
EIP is at lookup_symbol+0x37/0x5b
eax: 00000018 ebx: c0387a10 ecx: f7df7e58 edx: c0349c7e
esi: 75010000 edi: f881a229 ebp: c038a524 esp: f7df7e5c
ds: 007b es: 007b ss: 0068 preempt: 00000000
Process insmod (pid: 453, ti=f7df6000 task=c2b54030 task.ti=f7df6000)
Stack: f881f940 f8820c80 f881a229 f7df7ea4 c013555c f881a229 c03855a0
c038a524
f881f940 f8820c80 f881a229 00000000 c01362dd f881a229 f7df7ea0
f7df7ea4
00000001 00000000 f881a229 f881f940 000004f0 0000003c c0136855
f881922c
Call Trace:
[<c013555c>] __find_symbol+0x26/0x2e0
[<c01362dd>] resolve_symbol+0x23/0x5f
[<c0136855>] simplify_symbols+0x7e/0xf0
[<c01375b0>] load_module+0x7c4/0xc14
[<c0137a60>] sys_init_module+0x3d/0x171
[<c0102855>] sysenter_past_esp+0x56/0x79
Code: 55 53 ff 74 24 1c 68 5f 9c 34 c0 e8 df 80 fe ff 83 c4 10 39 eb 73
31 53 68 7e 9c 34 c0 e8 cd 80 fe ff 5e 5f 8b 73 04 8b 7c 24 14 <ac> ae
75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 04 89
EIP: [<c01354ea>] lookup_symbol+0x37/0x5b SS:ESP 0068:f7df7e5c


Put some debugging into __find_symbol() and came up w/ this:

lookup_symbol: scsi_print_sense_hdr 0xc0385590 0xc038a514

Where it goes through that range in kernel_symbol increments.

The last one it checks before crashing is: 0xc0387a10

>From Symbol.map:
c0385590 R __start___ksymtab
c038a514 R __stop___ksymtab

That looks right. Now looking up 0xc0387a10, there's no symbol there.

c03879e8 r __ksymtab_find_next_bit
c03879f0 r __ksymtab_find_next_zero_bit
c03879f8 R __write_lock_failed
c0387a18 R __read_lock_failed
c0387a2c r __ksymtab___delay
c0387a34 r __ksymtab___const_udelay
c0387a3c r __ksymtab___udelay
c0387a44 r __ksymtab___ndelay

That __read/__write_lock_failed bit looks wrong.

That's as far as I've gotten so far, but will email with more as I find
it.

thanks
-john

2006-09-28 22:50:08

by john stultz

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-27 at 17:42 -0700, john stultz wrote:
> On Fri, 2006-09-22 at 13:58 +0200, Ingo Molnar wrote:
> > * john stultz <[email protected]> wrote:
> >
> > > I'm seeing a similar issue. Although the log is a bit futzed. Maybe
> > > its the sd_mod?
> > >
> > > at virtual address 75010000le kernel paging requestproc filesystem
> >
> > would be nice to figure out why it crashes - unfortunately i cannot
> > trigger it. Could it be some build tool incompatibility perhaps? Some
> > sizing issue (some module struct gets too large)?
>
> Been looking a bit deeper into this again:
[snip]
> c03879e8 r __ksymtab_find_next_bit
> c03879f0 r __ksymtab_find_next_zero_bit
> c03879f8 R __write_lock_failed
> c0387a18 R __read_lock_failed
> c0387a2c r __ksymtab___delay
> c0387a34 r __ksymtab___const_udelay
> c0387a3c r __ksymtab___udelay
> c0387a44 r __ksymtab___ndelay
>
> That __read/__write_lock_failed bit looks wrong.


So it seems gcc 3.4.4 misplaces the __write_lock_failed function into
the ksymtab. It doesn't happen w/ 4.0.3.

Anyway, this patch explicitly defines the section and fixes the issue
for me. Would the other reporters of this issue give it a whirl as well?

thanks
-john


Index: linux-rtj14/arch/i386/lib/bitops.c
===================================================================
--- linux-rtj14.orig/arch/i386/lib/bitops.c 2006-09-28 15:24:08.000000000 -0700
+++ linux-rtj14/arch/i386/lib/bitops.c 2006-09-28 15:35:29.000000000 -0700
@@ -75,6 +75,7 @@
*/
#ifdef CONFIG_SMP
asm(
+".section .sched.text\n"
".align 4\n"
".globl __write_lock_failed\n"
"__write_lock_failed:\n\t"
@@ -88,6 +89,7 @@
);

asm(
+".section .sched.text\n"
".align 4\n"
".globl __read_lock_failed\n"
"__read_lock_failed:\n\t"


2006-09-29 02:09:43

by K.R. Foley

[permalink] [raw]
Subject: Re: 2.6.18-rt1

john stultz wrote:
> On Wed, 2006-09-27 at 17:42 -0700, john stultz wrote:
>> On Fri, 2006-09-22 at 13:58 +0200, Ingo Molnar wrote:
>>> * john stultz <[email protected]> wrote:
>>>
>>>> I'm seeing a similar issue. Although the log is a bit futzed. Maybe
>>>> its the sd_mod?
>>>>
>>>> at virtual address 75010000le kernel paging requestproc filesystem
>>> would be nice to figure out why it crashes - unfortunately i cannot
>>> trigger it. Could it be some build tool incompatibility perhaps? Some
>>> sizing issue (some module struct gets too large)?
>> Been looking a bit deeper into this again:
> [snip]
>> c03879e8 r __ksymtab_find_next_bit
>> c03879f0 r __ksymtab_find_next_zero_bit
>> c03879f8 R __write_lock_failed
>> c0387a18 R __read_lock_failed
>> c0387a2c r __ksymtab___delay
>> c0387a34 r __ksymtab___const_udelay
>> c0387a3c r __ksymtab___udelay
>> c0387a44 r __ksymtab___ndelay
>>
>> That __read/__write_lock_failed bit looks wrong.
>
>
> So it seems gcc 3.4.4 misplaces the __write_lock_failed function into
> the ksymtab. It doesn't happen w/ 4.0.3.
>
> Anyway, this patch explicitly defines the section and fixes the issue
> for me. Would the other reporters of this issue give it a whirl as well?
>
> thanks
> -john
>

John,

This fixes my problem on my fc3 box here at home. I will check my other
development boxes at work tomorrow. Nice catch and thanks for effort.


--
kr

2006-09-29 12:32:38

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* john stultz <[email protected]> wrote:

> > That __read/__write_lock_failed bit looks wrong.
>
> So it seems gcc 3.4.4 misplaces the __write_lock_failed function into
> the ksymtab. It doesn't happen w/ 4.0.3.
>
> Anyway, this patch explicitly defines the section and fixes the issue
> for me. Would the other reporters of this issue give it a whirl as
> well?

nice catch! applied.

Ingo

2006-09-29 12:49:07

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* john stultz <[email protected]> wrote:

> [snip]
> > c03879e8 r __ksymtab_find_next_bit
> > c03879f0 r __ksymtab_find_next_zero_bit
> > c03879f8 R __write_lock_failed
> > c0387a18 R __read_lock_failed
> > c0387a2c r __ksymtab___delay
> > c0387a34 r __ksymtab___const_udelay
> > c0387a3c r __ksymtab___udelay
> > c0387a44 r __ksymtab___ndelay
> >
> > That __read/__write_lock_failed bit looks wrong.
>
>
> So it seems gcc 3.4.4 misplaces the __write_lock_failed function into
> the ksymtab. It doesn't happen w/ 4.0.3.

i think it's an ld bug, and it's related to the nested
.section/.previous use in the LOCK_PREFIX macro in
include/asm-i386/alternatives.h.

this is the second time i have seen smp-alternatives related linker
breakage.

Ingo

2006-09-30 18:06:06

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Wed, 2006-09-20 at 16:19 +0200, Ingo Molnar wrote:
> I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/

I got this Oops with -rt3, looks RCU related. Apologies in advance if
it's already known.

Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
[<ffffffff802aafa7>] __rcu_read_unlock+0x2e/0x82
PGD 46a3067 PUD 4e27067 PMD 0
Oops: 0002 [1] PREEMPT SMP
CPU 1
Modules linked in: rfcomm hidp l2cap bluetooth nfsd exportfs lockd nfs_acl sunrpc powernow_k8 cpufreq_userspace cpufreq_stats freq_table cpufreq_powersave cpufreq_ondemand cpufreq_conservative video button battery container ac asus_acpi dm_mod md_mod sr_mod sbp2 lp psmouse serio_raw sg evdev floppy parport_pc parport pcspkr i2c_nforce2 i2c_core shpchp pci_hotplug ext3 jbd mbcache ohci_hcd ehci_hcd ohci1394 ieee1394 forcedeth ide_generic ide_cd cdrom sd_mod sata_nv libata scsi_mod generic amd74xx ide_core thermal processor fan
Pid: 21372, comm: fixdep Not tainted 2.6.18-rt3-smp-noipv6 #1
RIP: 0010:[<ffffffff802aafa7>] [<ffffffff802aafa7>] __rcu_read_unlock+0x2e/0x82
RSP: 0018:ffff8100045dbbf0 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff810015a63070 RCX: 0000000000000246
RDX: 0000000000000000 RSI: ffff8100188bf007 RDI: ffff810015a63078
RBP: ffff810015a63070 R08: 0000000000000000 R09: ffff81001212d6c0
R10: ffff81001b9c0d48 R11: ffffffff8022ae94 R12: ffff810015a63078
R13: ffff8100119da4b0 R14: ffff8100045dbca8 R15: 0000000071bf92cd
FS: 00002b7fb742d6d0(0000) GS:ffff81001b9178c0(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000194c3000 CR4: 00000000000006e0
Process fixdep (pid: 21372, threadinfo ffff8100045da000, task ffff81001622d800)
Stack: ffffffff80208db8 0000000100000105 0000000700000001 ffff8100188bf000
00000000000041ed ffff8100045dbea8 ffff8100119f5180 ffff810001232480
ffff8100045dbea8 ffff8100045dbca8 ffffffff8020c353 ffff81001b9c0d00
Call Trace:
[<ffffffff80208db8>] __d_lookup+0x10b/0x11d
[<ffffffff8020c353>] do_lookup+0x2a/0x173
[<ffffffff80209179>] __link_path_walk+0x3af/0xf5c
[<ffffffff8020c537>] file_read_actor+0x0/0xce
[<ffffffff80299575>] _atomic_dec_and_spin_lock+0x2b/0x33
[<ffffffff8020dc2c>] link_path_walk+0x5c/0xe5
[<ffffffff8029955e>] _atomic_dec_and_spin_lock+0x14/0x33
[<ffffffff80213fe4>] get_unused_fd+0xf9/0x107
[<ffffffff802117be>] filemap_nopage+0x1cb/0x39b
[<ffffffff8020c201>] do_path_lookup+0x26c/0x290
[<ffffffff8029a09b>] __rt_rwlock_init+0x9/0x12
[<ffffffff80221a87>] __path_lookup_intent_open+0x56/0x97
[<ffffffff8021909c>] open_namei+0x6d/0x6a4
[<ffffffff8021ca81>] free_pgtables+0xe6/0x172
[<ffffffff802bbada>] __cache_free+0x51/0x1f2
[<ffffffff80225776>] do_filp_open+0x1c/0x3d
[<ffffffff8029955e>] _atomic_dec_and_spin_lock+0x14/0x33
[<ffffffff80213fe4>] get_unused_fd+0xf9/0x107
[<ffffffff80217e96>] do_sys_open+0x44/0xc5
[<ffffffff8025b1ce>] system_call+0x7e/0x83


Code: f0 ff 08 65 48 8b 04 25 00 00 00 00 48 c7 80 a8 00 00 00 00
RIP [<ffffffff802aafa7>] __rcu_read_unlock+0x2e/0x82
RSP <ffff8100045dbbf0>
CR2: 0000000000000000



2006-09-30 18:18:23

by Dipankar Sarma

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Sat, Sep 30, 2006 at 02:06:04PM -0400, Lee Revell wrote:
> On Wed, 2006-09-20 at 16:19 +0200, Ingo Molnar wrote:
> > I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> > from the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
>
> I got this Oops with -rt3, looks RCU related. Apologies in advance if
> it's already known.
>
> Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
> [<ffffffff802aafa7>] __rcu_read_unlock+0x2e/0x82
> PGD 46a3067 PUD 4e27067 PMD 0
> Oops: 0002 [1] PREEMPT SMP
> CPU 1

I see a very similar crash while running rcutorture on 2.6.18-mm1 and
my rcu patchset that has rcupreempt stuff rom -rt. I don't see this
while running on 2.6.18-rc3, but then rc3 had an older version
of rcutorture. I am working on narrowing it down.

The following script reproduces the problem quickly (within
a couple of minutes) in my 4-cpu x86_64 system -

#! /bin/sh
for ((i=0 ; i<200 ; i++))
do
echo "Starting pass $i"
modprobe rcutorture stat_interval=10 # test_no_idle_hz=1 shuffle_interval=5
sleep 30
rmmod rcutorture
dmesg | sed -n -e '/^rcutorture: --- End of test:/p' | tail -1
done
exit 0

Thanks
Dipankar

2006-09-30 18:25:52

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Sat, 2006-09-30 at 23:48 +0530, Dipankar Sarma wrote:
> On Sat, Sep 30, 2006 at 02:06:04PM -0400, Lee Revell wrote:
> > I got this Oops with -rt3, looks RCU related. Apologies in advance if
> > it's already known.
> >
> > Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
> > [<ffffffff802aafa7>] __rcu_read_unlock+0x2e/0x82
> > PGD 46a3067 PUD 4e27067 PMD 0
> > Oops: 0002 [1] PREEMPT SMP
> > CPU 1
>
> I see a very similar crash while running rcutorture on 2.6.18-mm1 and
> my rcu patchset that has rcupreempt stuff rom -rt. I don't see this
> while running on 2.6.18-rc3, but then rc3 had an older version
> of rcutorture. I am working on narrowing it down.
>
> The following script reproduces the problem quickly (within
> a couple of minutes) in my 4-cpu x86_64 system -

Let me know if you want more info such as config. I was compiling a
kernel when the Oops occurred. System is Athlon X2.

Lee

2006-10-13 21:16:34

by Karsten Wiese

[permalink] [raw]
Subject: Re: 2.6.18-rt1

Am Samstag, 30. September 2006 20:18 schrieb Dipankar Sarma:
> On Sat, Sep 30, 2006 at 02:06:04PM -0400, Lee Revell wrote:
> > On Wed, 2006-09-20 at 16:19 +0200, Ingo Molnar wrote:
> > > I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> > > from the usual place:
> > >
> > > http://redhat.com/~mingo/realtime-preempt/
> >
> > I got this Oops with -rt3, looks RCU related. Apologies in advance if
> > it's already known.
> >
> > Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
> > [<ffffffff802aafa7>] __rcu_read_unlock+0x2e/0x82
> > PGD 46a3067 PUD 4e27067 PMD 0
> > Oops: 0002 [1] PREEMPT SMP
> > CPU 1
>
> I see a very similar crash while running rcutorture on 2.6.18-mm1 and
> my rcu patchset that has rcupreempt stuff rom -rt. I don't see this
> while running on 2.6.18-rc3, but then rc3 had an older version
> of rcutorture. I am working on narrowing it down.
>
> The following script reproduces the problem quickly (within
> a couple of minutes) in my 4-cpu x86_64 system -
>
> #! /bin/sh
> for ((i=0 ; i<200 ; i++))
> do
> echo "Starting pass $i"
> modprobe rcutorture stat_interval=10 # test_no_idle_hz=1 shuffle_interval=5
> sleep 30
> rmmod rcutorture
> dmesg | sed -n -e '/^rcutorture: --- End of test:/p' | tail -1
> done
> exit 0
>

Bug just happened here on a tainted UP x86_64 running rt4.
IIRC this is the second time in 2 weeks or so.
Machine seams to be fine still after the oops...

<Oops>
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
[<ffffffff802a1b21>] __rcu_read_unlock+0x2e/0x80
PGD 3b616067 PUD 1718b067 PMD 0
Oops: 0002 [1] PREEMPT
CPU 0
Modules linked in: autofs4 sunrpc video button ac lp parport_pc parport nvram snd_via82xx gameport snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq nvidia snd_pcm_oss snd_mixer_oss snd_pcm ehci_hcd uhci_hcd snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi pcspkr snd_seq_device snd i2c_viapro i2c_core r8169 soundcore ext3 jbd
Pid: 7102, comm: sh Tainted: P 2.6.18-rt4 #4
RIP: 0010:[<ffffffff802a1b21>] [<ffffffff802a1b21>] __rcu_read_unlock+0x2e/0x80
RSP: 0018:ffff8100189ebc00 EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff81003fd0d450 RCX: 0000000000000246
RDX: 0000000000000000 RSI: ffff81003e351008 RDI: ffff81003fd0d458
RBP: ffff81003fd0d450 R08: ffff81003e351005 R09: 0000000000000000
R10: 0000000000000000 R11: ffffffff8022a714 R12: ffff81003fd0d458
R13: ffff81003f43b070 R14: ffff8100189ebcb8 R15: 000000000023605a
FS: 00002ac8f7d9dd50(0000) GS:ffffffff8053f000(0000) knlGS:00000000f7fa96c0
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000003582f000 CR4: 00000000000006e0
Process sh (pid: 7102, threadinfo ffff8100189ea000, task ffff81000c8d2080)
Stack: ffffffff80208d3b 00000001000200d2 00000003804686b0 ffff81003e351005
00000000000041ed ffff8100189ebe48 ffff81003f7bd788 ffff81003fde8cc0
ffff8100189ebe48 ffff8100189ebcb8 ffffffff8020be2c 00000000000041ed
Call Trace:
[<ffffffff80208d3b>] __d_lookup+0x10a/0x11c
[<ffffffff8020be2c>] do_lookup+0x2a/0x173
[<ffffffff802090f9>] __link_path_walk+0x3ac/0xf4a
[<ffffffff8020d93b>] link_path_walk+0x5a/0xe1
[<ffffffff8020bc82>] do_path_lookup+0x26d/0x2e9
[<ffffffff80210f67>] getname+0x15b/0x1c1
[<ffffffff802216e3>] __user_walk_fd+0x37/0x4c
[<ffffffff802265ce>] vfs_stat_fd+0x1b/0x4a
[<ffffffff8022143c>] sys_newstat+0x19/0x31
[<ffffffff8025a7a1>] error_exit+0x0/0x84
[<ffffffff80259ece>] system_call+0x7e/0x83


Code: ff 08 65 48 8b 04 25 00 00 00 00 48 c7 80 a8 00 00 00 00 00
RIP [<ffffffff802a1b21>] __rcu_read_unlock+0x2e/0x80
RSP <ffff8100189ebc00>
CR2: 0000000000000000
</Oops>

Thanks

Karsten

2006-10-13 21:19:54

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Fri, 2006-10-13 at 23:18 +0200, Karsten Wiese wrote:
> Bug just happened here on a tainted UP x86_64 running rt4.
> IIRC this is the second time in 2 weeks or so.
> Machine seams to be fine still after the oops...

I just hit it again with (untainted) 2.6.18-rt5.

Lee

2006-10-13 21:25:12

by Dipankar Sarma

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Fri, Oct 13, 2006 at 11:18:01PM +0200, Karsten Wiese wrote:
> Am Samstag, 30. September 2006 20:18 schrieb Dipankar Sarma:
> > On Sat, Sep 30, 2006 at 02:06:04PM -0400, Lee Revell wrote:
> > > On Wed, 2006-09-20 at 16:19 +0200, Ingo Molnar wrote:
> > > > I'm pleased to announce the 2.6.18-rt1 tree, which can be downloaded
> > > > from the usual place:
> > > >
> > > > http://redhat.com/~mingo/realtime-preempt/
> > >
> > > I got this Oops with -rt3, looks RCU related. Apologies in advance if
> > > it's already known.
> > >
> > > Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
> > > [<ffffffff802aafa7>] __rcu_read_unlock+0x2e/0x82
> > > PGD 46a3067 PUD 4e27067 PMD 0
> > > Oops: 0002 [1] PREEMPT SMP
> > > CPU 1
> >
> > I see a very similar crash while running rcutorture on 2.6.18-mm1 and
> > my rcu patchset that has rcupreempt stuff rom -rt. I don't see this
> >
>
> Bug just happened here on a tainted UP x86_64 running rt4.
> IIRC this is the second time in 2 weeks or so.
> Machine seams to be fine still after the oops...
>
> <Oops>
> Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
> [<ffffffff802a1b21>] __rcu_read_unlock+0x2e/0x80
> PGD 3b616067 PUD 1718b067 PMD 0
> Oops: 0002 [1] PREEMPT
> CPU 0
> Modules linked in: autofs4 sunrpc video button ac lp parport_pc parport nvram snd_via82xx gameport snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq nvidia snd_pcm_oss snd_mixer_oss snd_pcm ehci_hcd uhci_hcd snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi pcspkr snd_seq_device snd i2c_viapro i2c_core r8169 soundcore ext3 jbd
> Pid: 7102, comm: sh Tainted: P 2.6.18-rt4 #4
> RIP: 0010:[<ffffffff802a1b21>] [<ffffffff802a1b21>] __rcu_read_unlock+0x2e/0x80


Sorry, I should have published my investigations long ago. I tracked
this down (atleast the crash in my machine) to NMI interference
with rcu_read_lock()/rcu_read_unlock(). We use those APIs
from NMI context as well
(default_do_nmi()->notify_die()->atomic_notifier_call_chain()).

Can you try with nmi_watchdog=0 in the kernel command line ?

Paul has an NMI-safe patch for rcupreempt which I am adopting
and testing at the moment. If this works well, I will publish
a new patchset.

Thanks
Dipankar

2006-10-13 22:11:16

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Sat, 2006-10-14 at 02:54 +0530, Dipankar Sarma wrote:
> Can you try with nmi_watchdog=0 in the kernel command line ?
>
> Paul has an NMI-safe patch for rcupreempt which I am adopting
> and testing at the moment. If this works well, I will publish
> a new patchset.
>

The bug is too hard to hit for me to provide useful feedback. I've only
seen it once since my original report.

FWIW, I am also seeing hard lockups every 12-24 hours but the box is
headless and I don't have the bandwidth to debug these further. It was
stable with 2.6.17-rt*.

Lee

2006-10-13 22:16:49

by Dipankar Sarma

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Fri, Oct 13, 2006 at 06:12:16PM -0400, Lee Revell wrote:
> On Sat, 2006-10-14 at 02:54 +0530, Dipankar Sarma wrote:
> > Can you try with nmi_watchdog=0 in the kernel command line ?
> >
> > Paul has an NMI-safe patch for rcupreempt which I am adopting
> > and testing at the moment. If this works well, I will publish
> > a new patchset.
> >
>
> The bug is too hard to hit for me to provide useful feedback. I've only
> seen it once since my original report.
>
> FWIW, I am also seeing hard lockups every 12-24 hours but the box is
> headless and I don't have the bandwidth to debug these further. It was
> stable with 2.6.17-rt*.

Can you try whatever you were doing with nmi_watchdog=0 ? If it is
stable, then that would explain the problem. I believe Andi enabled
nmi watchdog on x86_64 by default recently, that might be why
we are seeing it now.

Thanks
Dipankar

2006-10-17 14:46:36

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.18-rt1

On Sat, 2006-10-14 at 03:46 +0530, Dipankar Sarma wrote:
> > FWIW, I am also seeing hard lockups every 12-24 hours but the box is
> > headless and I don't have the bandwidth to debug these further. It
> was
> > stable with 2.6.17-rt*.
>
> Can you try whatever you were doing with nmi_watchdog=0 ? If it is
> stable, then that would explain the problem. I believe Andi enabled
> nmi watchdog on x86_64 by default recently, that might be why
> we are seeing it now.

Looks like that was the problem, the hard lockups are gone.

Lee

2006-10-18 07:20:54

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* Dipankar Sarma <[email protected]> wrote:

> Sorry, I should have published my investigations long ago. I tracked
> this down (atleast the crash in my machine) to NMI interference with
> rcu_read_lock()/rcu_read_unlock(). We use those APIs from NMI context
> as well
> (default_do_nmi()->notify_die()->atomic_notifier_call_chain()).
>
> Can you try with nmi_watchdog=0 in the kernel command line ?
>
> Paul has an NMI-safe patch for rcupreempt which I am adopting and
> testing at the moment. If this works well, I will publish a new
> patchset.

spent some good time debugging this 2 weeks ago and added the fix below
to rt5, but i forgot to do the symmetric fix for x86_64...

Ingo

----------->
arch/i386/kernel/traps.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

Index: linux/arch/i386/kernel/traps.c
===================================================================
--- linux.orig/arch/i386/kernel/traps.c
+++ linux/arch/i386/kernel/traps.c
@@ -716,9 +716,6 @@ static void default_do_nmi(struct pt_reg
reason = get_nmi_reason();

if (!(reason & 0xc0)) {
- if (notify_die(DIE_NMI_IPI, "nmi_ipi", regs, reason, 2, SIGINT)
- == NOTIFY_STOP)
- return;
#ifdef CONFIG_X86_LOCAL_APIC
/*
* Ok, so this is none of the documented NMI sources,
@@ -729,6 +726,9 @@ static void default_do_nmi(struct pt_reg
return;
}
#endif
+ if (notify_die(DIE_NMI_IPI, "nmi_ipi", regs, reason, 2, SIGINT)
+ == NOTIFY_STOP)
+ return;
unknown_nmi_error(reason, regs);
return;
}

2006-10-18 08:46:20

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.18-rt1


* Lee Revell <[email protected]> wrote:

> > Can you try whatever you were doing with nmi_watchdog=0 ? If it is
> > stable, then that would explain the problem. I believe Andi enabled
> > nmi watchdog on x86_64 by default recently, that might be why we are
> > seeing it now.
>
> Looks like that was the problem, the hard lockups are gone.

ok. Meanwhile i discovered that i fixed this bug on i686 but not on
x86_64. Could you try -rt6, does it work with the NMI watchdog
re-enabled?

Ingo