i have released the 2.6.14-rc4-rt7 tree, which can be downloaded from
the usual place:
http://redhat.com/~mingo/realtime-preempt/
the biggest change is the merging of "ktimers next step", a'ka the
clockevents framework, from Thomas Gleixner. This is mostly a design
cleanup of the existing timekeeping, timer and HRT codebase. One
user-visible aspect is that the PIT timer is now available as a hres
source too - APIC-less systems will find this useful.
otherwise, there are lots of fixes all across the spectrum.
Changes since 2.6.14-rc4-rt1:
- clockevents framework (Thomas Gleixner)
- ktimer and HRT updates (Thomas Gleixner)
- robust futex updates (David Singleton)
- symbol export fixes (Steven Rostedt)
- export tsc_c3_compensate for real (reported by Rui Nuno Capela)
- fix for the nanosleep() -ERESTARTBLOCK bug
(reported by Fernando Lopez-Lezcano)
- x64 latency tracer fixes (reported by Mark Knecht)
- PRINTK_IGNORE_LOGLEVEL bugfix
- various build fixes
to build a 2.6.14-rc4-rt7 tree, the following patches should be applied:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.14-rc4.bz2
http://redhat.com/~mingo/realtime-preempt/patch-2.6.14-rc4-rt7
Ingo
On 10/17/05, Ingo Molnar <[email protected]> wrote:
>
> i have released the 2.6.14-rc4-rt7
Hi Ingo,
-rt7 is up and running here. As far as I can tell so far I am
getting good realtime response. No xruns so far, but certianly very
little testing.
The problem I'm seeing, which is consistent, is that it takes 1:45
to 2 minutes ot log out of Gnome. If I log in, wait about 15 seconds,
and the choose 'logout' from the panel, I have to wait almost 2
minutes for the confirmation screen to come up. When I choose logout
from that screen the final part of logout is immediate.
This was not a problem on rc4-rt1, but has been a problem on -rt5,
-rt6 and -rt7.
I commented on this earlier but possibly the comment was missed.
Anyway, I'll be doing more testing with Jack today, but it would be
great if we could debug this problem along the way.
Kernel config attached.
On Mon, 2005-10-17 at 18:05 +0200, Ingo Molnar wrote:
> i have released the 2.6.14-rc4-rt7 tree, which can be downloaded from
> the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> the biggest change is the merging of "ktimers next step", a'ka the
> clockevents framework, from Thomas Gleixner. This is mostly a design
> cleanup of the existing timekeeping, timer and HRT codebase. One
> user-visible aspect is that the PIT timer is now available as a hres
> source too - APIC-less systems will find this useful.
Some feedback. It looks like the issues I was having are gone, no weird
key repeats or screensaver activations __plus__ no problems so far with
spurious warnings from Jack! Woohooo!!! (of course it may be that I
start getting them as soon as I press send)
[BTW, I'm running now with PREEMPT_RT as well].
Thanks!!
-- Fernando
I found this latency ~5 minutes after boot up, no load . It looks like
vgacon_scroll() has a memset like operation which can grow.
Daniel
On Mon, 17 Oct 2005, Ingo Molnar wrote:
>
> i have released the 2.6.14-rc4-rt7 tree, which can be downloaded from
> the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> the biggest change is the merging of "ktimers next step", a'ka the
> clockevents framework, from Thomas Gleixner. This is mostly a design
> cleanup of the existing timekeeping, timer and HRT codebase. One
> user-visible aspect is that the PIT timer is now available as a hres
> source too - APIC-less systems will find this useful.
>
> otherwise, there are lots of fixes all across the spectrum.
>
> Changes since 2.6.14-rc4-rt1:
>
> - clockevents framework (Thomas Gleixner)
>
> - ktimer and HRT updates (Thomas Gleixner)
>
> - robust futex updates (David Singleton)
>
> - symbol export fixes (Steven Rostedt)
>
> - export tsc_c3_compensate for real (reported by Rui Nuno Capela)
>
> - fix for the nanosleep() -ERESTARTBLOCK bug
> (reported by Fernando Lopez-Lezcano)
>
> - x64 latency tracer fixes (reported by Mark Knecht)
>
> - PRINTK_IGNORE_LOGLEVEL bugfix
>
> - various build fixes
>
> to build a 2.6.14-rc4-rt7 tree, the following patches should be applied:
>
> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.tar.bz2
> http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.14-rc4.bz2
> http://redhat.com/~mingo/realtime-preempt/patch-2.6.14-rc4-rt7
>
> 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/
>
On Mon, 2005-10-17 at 14:43 -0700, Daniel Walker wrote:
> I found this latency ~5 minutes after boot up, no load . It looks like
> vgacon_scroll() has a memset like operation which can grow.
5 minutes after bootup could also be related to a jiffies wrap problem.
tglx
On Tue, 18 Oct 2005, Thomas Gleixner wrote:
> On Mon, 2005-10-17 at 14:43 -0700, Daniel Walker wrote:
> > I found this latency ~5 minutes after boot up, no load . It looks like
> > vgacon_scroll() has a memset like operation which can grow.
>
> 5 minutes after bootup could also be related to a jiffies wrap problem.
>
I saw it multiple times , but this trace was the biggest .. It looks like
it might be related to CONFIG_PRINTK_IGNORE_LOGLEVEL .. I don't see how
jiffies could be related though .
Daniel
On Mon, 2005-10-17 at 15:05 -0700, Daniel Walker wrote:
>
> On Tue, 18 Oct 2005, Thomas Gleixner wrote:
>
> > On Mon, 2005-10-17 at 14:43 -0700, Daniel Walker wrote:
> > > I found this latency ~5 minutes after boot up, no load . It looks like
> > > vgacon_scroll() has a memset like operation which can grow.
> >
> > 5 minutes after bootup could also be related to a jiffies wrap problem.
> >
>
> I saw it multiple times , but this trace was the biggest .. It looks like
> it might be related to CONFIG_PRINTK_IGNORE_LOGLEVEL .. I don't see how
> jiffies could be related though .
Ah, ok. I just pointed to that as I trapped several times into the 5
minutes wrap already.
tglx
The clocksource_lock should be a raw because it's locked with the raw lock
system_time_lock held, and interrupts are off . So it could sleep with
interrupts disabled. I just compile tested this, but I think it should be
fine .
Daniel
Index: linux-2.6.13/kernel/time/clocksource.c
===================================================================
--- linux-2.6.13.orig/kernel/time/clocksource.c
+++ linux-2.6.13/kernel/time/clocksource.c
@@ -46,7 +46,7 @@ extern struct clocksource clocksource_ji
static struct clocksource *curr_clocksource = &clocksource_jiffies;
static struct clocksource *next_clocksource;
static LIST_HEAD(clocksource_list);
-static DECLARE_SEQLOCK(clocksource_lock);
+static DECLARE_RAW_SEQLOCK(clocksource_lock);
static char override_name[32];
On Mon, 2005-10-17 at 12:21 -0700, Fernando Lopez-Lezcano wrote:
> On Mon, 2005-10-17 at 18:05 +0200, Ingo Molnar wrote:
> > i have released the 2.6.14-rc4-rt7 tree, which can be downloaded from
> > the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
> > the biggest change is the merging of "ktimers next step", a'ka the
> > clockevents framework, from Thomas Gleixner. This is mostly a design
> > cleanup of the existing timekeeping, timer and HRT codebase. One
> > user-visible aspect is that the PIT timer is now available as a hres
> > source too - APIC-less systems will find this useful.
>
> Some feedback. It looks like the issues I was having are gone, no weird
> key repeats or screensaver activations __plus__ no problems so far with
> spurious warnings from Jack! Woohooo!!! (of course it may be that I
> start getting them as soon as I press send)
It took some time but I got a couple of instances of keys repeating too
fast (it happened 3 or 4 times). Regretfully no BUG messages
in /var/log/messages this time...
-- Fernando
On 10/17/05, Fernando Lopez-Lezcano <[email protected]> wrote:
> On Mon, 2005-10-17 at 12:21 -0700, Fernando Lopez-Lezcano wrote:
> > On Mon, 2005-10-17 at 18:05 +0200, Ingo Molnar wrote:
> > > i have released the 2.6.14-rc4-rt7 tree, which can be downloaded from
> > > the usual place:
> > >
> > > http://redhat.com/~mingo/realtime-preempt/
> > >
> > > the biggest change is the merging of "ktimers next step", a'ka the
> > > clockevents framework, from Thomas Gleixner. This is mostly a design
> > > cleanup of the existing timekeeping, timer and HRT codebase. One
> > > user-visible aspect is that the PIT timer is now available as a hres
> > > source too - APIC-less systems will find this useful.
> >
> > Some feedback. It looks like the issues I was having are gone, no weird
> > key repeats or screensaver activations __plus__ no problems so far with
> > spurious warnings from Jack! Woohooo!!! (of course it may be that I
> > start getting them as soon as I press send)
>
> It took some time but I got a couple of instances of keys repeating too
> fast (it happened 3 or 4 times). Regretfully no BUG messages
> in /var/log/messages this time...
>
> -- Fernando
>
1) I managed to get through the whole day running Jack at 64/2 with no
xruns. A first.
2) I'm not clear about the latency Daniel reported. IS that the logout
problem I'm seeing or something else.
WRT the logout problem - after being logged in for a while the log out
problem doesn't happen. It only happens if I log out relatively soon
after logging in.
Great work Ingo!
- Mark
* Daniel Walker <[email protected]> wrote:
> I found this latency ~5 minutes after boot up, no load . It looks like
> vgacon_scroll() has a memset like operation which can grow.
do you have PRINTK_IGNORE_LOGLEVEL enabled? If yes then much of the
printk code will run with interrupts disabled - hence non-preemptable.
PRINTK_IGNORE_LOGLEVEL is a debugging feature for developers. I have
added an extra explanation to the Kconfig, see below.
Ingo
Index: linux/lib/Kconfig.debug
===================================================================
--- linux.orig/lib/Kconfig.debug
+++ linux/lib/Kconfig.debug
@@ -18,6 +18,11 @@ config PRINTK_IGNORE_LOGLEVEL
distributions disable kernel log messages during
certain phases of system startup.)
+ NOTE: this option also makes printk non-preemptible,
+ which might improve the output of debugging info or
+ crash info, but it might also cause latencies if your
+ kernel is printk-ing alot.
+
Normally you dont need or want this option.
config DEBUG_KERNEL
* Daniel Walker <[email protected]> wrote:
> The clocksource_lock should be a raw because it's locked with the raw
> lock system_time_lock held, and interrupts are off . So it could sleep
> with interrupts disabled. I just compile tested this, but I think it
> should be fine .
yeah, indeed - applied.
Thomas: clocksource_lock being a seqlock is pretty pointless too right
now, as nothing uses the read variant.
Ingo
* Fernando Lopez-Lezcano <[email protected]> wrote:
> > Some feedback. It looks like the issues I was having are gone, no weird
> > key repeats or screensaver activations __plus__ no problems so far with
> > spurious warnings from Jack! Woohooo!!! (of course it may be that I
> > start getting them as soon as I press send)
>
> It took some time but I got a couple of instances of keys repeating
> too fast (it happened 3 or 4 times). Regretfully no BUG messages in
> /var/log/messages this time...
yeah, those warning messages got zapped during the merge to the latest
ktimers/clockevents code. Will re-add them.
Ingo
* Fernando Lopez-Lezcano <[email protected]> wrote:
> > Some feedback. It looks like the issues I was having are gone, no weird
> > key repeats or screensaver activations __plus__ no problems so far with
> > spurious warnings from Jack! Woohooo!!! (of course it may be that I
> > start getting them as soon as I press send)
>
> It took some time but I got a couple of instances of keys repeating
> too fast (it happened 3 or 4 times). Regretfully no BUG messages in
> /var/log/messages this time...
ok, i have uploaded the -rt8 patch, which has the ktimer debugging code
included again. Could you give it a try and see whether there are any
debugging messages happening at the same time the keys repeat?
the debugging code checks for two things:
1) is the monotonic clock truly monotonic (ktimers rely on this). Your
previous debug messages never indicated this, but it can happen on
other boxes so i kept it for completeness.
2) if a timer finishes 'early' then we assume it was due to a
user-signal - double-check that this is in fact true. [timer
programming bugs can cause early returns for other reasons, which
can result in bogus -ERESTARTBLOCK error codes fed to userspace,
confusing it.]
Ingo
Ingo Molnar wrote:
Ingo,
The attached patch is necessary to build -rt8 if high res timers are not
enabled.
--
kr
* K.R. Foley <[email protected]> wrote:
> Ingo,
>
> The attached patch is necessary to build -rt8 if high res timers are
> not enabled.
thanks - applied.
Ingo
On Tue, 2005-10-18 at 08:42 +0200, Ingo Molnar wrote:
> * Daniel Walker <[email protected]> wrote:
>
> > I found this latency ~5 minutes after boot up, no load . It looks like
> > vgacon_scroll() has a memset like operation which can grow.
>
> do you have PRINTK_IGNORE_LOGLEVEL enabled? If yes then much of the
> printk code will run with interrupts disabled - hence non-preemptable.
> PRINTK_IGNORE_LOGLEVEL is a debugging feature for developers. I have
> added an extra explanation to the Kconfig, see below.
I was just running a "make defconfig" and I enabled latency tracing .
PRINTK_IGNORE_LOGLEVEL defaults to off (doesn't it?), and I didn't make
any changes to it . Unless it get switched on by something else ..
It looks like the logic might be reversed in release_console_sem() .
Daniel
* Daniel Walker <[email protected]> wrote:
> > > I found this latency ~5 minutes after boot up, no load . It looks like
> > > vgacon_scroll() has a memset like operation which can grow.
> >
> > do you have PRINTK_IGNORE_LOGLEVEL enabled? If yes then much of the
> > printk code will run with interrupts disabled - hence non-preemptable.
> > PRINTK_IGNORE_LOGLEVEL is a debugging feature for developers. I have
> > added an extra explanation to the Kconfig, see below.
>
> I was just running a "make defconfig" and I enabled latency tracing .
> PRINTK_IGNORE_LOGLEVEL defaults to off (doesn't it?), and I didn't
> make any changes to it . Unless it get switched on by something else
> ..
>
> It looks like the logic might be reversed in release_console_sem() .
yeah, it is reversed. I 'fixed' it a couple of releases ago - but in
fact it was correct previously and i introduced this bug. I have fixed
this in my tree and have released -rt9 with the fix.
Ingo
On Tue, 2005-10-18 at 09:28 +0200, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
>
> > > Some feedback. It looks like the issues I was having are gone, no weird
> > > key repeats or screensaver activations __plus__ no problems so far with
> > > spurious warnings from Jack! Woohooo!!! (of course it may be that I
> > > start getting them as soon as I press send)
> >
> > It took some time but I got a couple of instances of keys repeating
> > too fast (it happened 3 or 4 times). Regretfully no BUG messages in
> > /var/log/messages this time...
>
> ok, i have uploaded the -rt8 patch, which has the ktimer debugging code
> included again. Could you give it a try and see whether there are any
> debugging messages happening at the same time the keys repeat?
-rt8 lead to two hard crashes (the "press the reset button" kind) this
morning, both while evolution was starting up (reading email), and the
last one lead to nfs fcntl locking issues with evo that eventually
required a server reboot.
So I'm back at -rt6 for now...
-- Fernando
Hello,
Getting up to speed on the latest -rt changes again. Just happened
to notice this warning with -rt8 and -rt9:
kernel/ktimers.c: In function `check_ktimer_signal':
kernel/ktimers.c:1209: warning: passing argument 1 of `unlock_ktimer_base' from incompatible pointer type
And the obvious fix:
--- linux/kernel/ktimers.c.orig 2005-10-18 14:10:48.000000000 -0700
+++ linux/kernel/ktimers.c 2005-10-18 14:24:43.000000000 -0700
@@ -1206,7 +1206,7 @@
struct ktimer_base *base = lock_ktimer_base(timer, &flags);
ktime_t now = base->get_time();
- unlock_ktimer_base(base, &flags);
+ unlock_ktimer_base(timer, &flags);
printk("\n");
printk("expires: %u/%u\n",
Cheers
--ww
On Tue, 18 Oct 2005, William Weston wrote:
>
> Getting up to speed on the latest -rt changes again. Just happened
> to notice this warning with -rt8 and -rt9:
>
> kernel/ktimers.c: In function `check_ktimer_signal':
> kernel/ktimers.c:1209: warning: passing argument 1 of `unlock_ktimer_base' from incompatible pointer type
>
> And the obvious fix:
>
> --- linux/kernel/ktimers.c.orig 2005-10-18 14:10:48.000000000 -0700
> +++ linux/kernel/ktimers.c 2005-10-18 14:24:43.000000000 -0700
> @@ -1206,7 +1206,7 @@
> struct ktimer_base *base = lock_ktimer_base(timer, &flags);
> ktime_t now = base->get_time();
>
> - unlock_ktimer_base(base, &flags);
> + unlock_ktimer_base(timer, &flags);
>
> printk("\n");
> printk("expires: %u/%u\n",
>
>
You beat me to the punch. I noticed this yesterday on -rt8 but I was
already at my hotel and had no internet access (wasn't worth 3 euros to
send right away).
Acked: Steven Rostedt <[email protected]>
-- Steve
* William Weston <[email protected]> wrote:
> Hello,
>
> Getting up to speed on the latest -rt changes again. Just happened to
> notice this warning with -rt8 and -rt9:
>
> kernel/ktimers.c: In function `check_ktimer_signal':
> kernel/ktimers.c:1209: warning: passing argument 1 of
> `unlock_ktimer_base' from incompatible pointer type
>
> And the obvious fix:
>
> --- linux/kernel/ktimers.c.orig 2005-10-18 14:10:48.000000000 -0700
> +++ linux/kernel/ktimers.c 2005-10-18 14:24:43.000000000 -0700
> @@ -1206,7 +1206,7 @@
> struct ktimer_base *base = lock_ktimer_base(timer, &flags);
> ktime_t now = base->get_time();
>
> - unlock_ktimer_base(base, &flags);
> + unlock_ktimer_base(timer, &flags);
>
indeed - and this could explain some of the lockups reported. I've
uploaded -rt10 with your fix included.
Ingo
* Fernando Lopez-Lezcano <[email protected]> wrote:
> > indeed - and this could explain some of the lockups reported. I've
> > uploaded -rt10 with your fix included.
>
> No lockups so far with -rt12 (running for 1/2 a day already).
>
> I'm getting BUG messages again, some examples below...
would be interesting to check whether the cycle_t u64 fix in -rt14 gets
rid of these BUG messages.
Ingo
On Wed, 2005-10-19 at 13:19 +0200, Ingo Molnar wrote:
> * William Weston <[email protected]> wrote:
>
> > Hello,
> >
> > Getting up to speed on the latest -rt changes again. Just happened to
> > notice this warning with -rt8 and -rt9:
> >
> > kernel/ktimers.c: In function `check_ktimer_signal':
> > kernel/ktimers.c:1209: warning: passing argument 1 of
> > `unlock_ktimer_base' from incompatible pointer type
> >
> > And the obvious fix:
> >
> > --- linux/kernel/ktimers.c.orig 2005-10-18 14:10:48.000000000 -0700
> > +++ linux/kernel/ktimers.c 2005-10-18 14:24:43.000000000 -0700
> > @@ -1206,7 +1206,7 @@
> > struct ktimer_base *base = lock_ktimer_base(timer, &flags);
> > ktime_t now = base->get_time();
> >
> > - unlock_ktimer_base(base, &flags);
> > + unlock_ktimer_base(timer, &flags);
> >
>
> indeed - and this could explain some of the lockups reported. I've
> uploaded -rt10 with your fix included.
No lockups so far with -rt12 (running for 1/2 a day already).
I'm getting BUG messages again, some examples below...
-- Fernando
expires: 63460/186377996
expired: 63459/262930743
at: 857
interval: 0/0
now: 63459/262931265
rem: 0/923447253
overrun: 0
getoffset: 00000000
gpm/4215[CPU#1]: BUG in check_ktimer_signal at kernel/ktimers.c:1345
[<c01280a7>] __WARN_ON+0x67/0x90 (8)
[<c01421ba>] check_ktimer_signal+0x12a/0x140 (48)
[<c0142279>] ktimer_nanosleep+0xa9/0xf0 (52)
[<c01422fb>] ktimer_nanosleep_mono+0x3b/0x50 (56)
[<c03751b0>] nanosleep_restart_mono+0x0/0x30 (8)
[<c0142080>] process_ktimer+0x0/0x10 (64)
[<c01423ac>] sys_nanosleep+0x4c/0x50 (32)
[<c0103481>] syscall_call+0x7/0xb (16)
SELinux: initialized (dev 0:19, type nfs), uses genfs_contexts
SELinux: initialized (dev 0:19, type nfs), uses genfs_contexts
expires: 63652/92742733
expired: 63652/77934422
at: 857
interval: 0/0
now: 63652/77934985
rem: 0/14808311
overrun: 0
getoffset: 00000000
hydrogen/14762[CPU#0]: BUG in check_ktimer_signal at
kernel/ktimers.c:1345
[<c01280a7>] __WARN_ON+0x67/0x90 (8)
[<c01421ba>] check_ktimer_signal+0x12a/0x140 (48)
[<c0142279>] ktimer_nanosleep+0xa9/0xf0 (52)
[<c01422fb>] ktimer_nanosleep_mono+0x3b/0x50 (56)
[<c03751b0>] nanosleep_restart_mono+0x0/0x30 (8)
[<c0142080>] process_ktimer+0x0/0x10 (64)
[<c01423ac>] sys_nanosleep+0x4c/0x50 (32)
[<c0103481>] syscall_call+0x7/0xb (16)
expires: 63730/580407432
expired: 63730/580219182
at: 857
interval: 0/0
now: 63730/580220260
rem: 0/188250
overrun: 0
getoffset: 00000000
hald-addon-stor/4308[CPU#1]: BUG in check_ktimer_signal at
kernel/ktimers.c:1345 [<c01280a7>] __WARN_ON+0x67/0x90 (8)
[<c01421ba>] check_ktimer_signal+0x12a/0x140 (48)
[<c0142279>] ktimer_nanosleep+0xa9/0xf0 (52)
[<c01422fb>] ktimer_nanosleep_mono+0x3b/0x50 (56)
[<c03751b0>] nanosleep_restart_mono+0x0/0x30 (8)
[<c0142080>] process_ktimer+0x0/0x10 (64)
[<c01423ac>] sys_nanosleep+0x4c/0x50 (32)
[<c0103481>] syscall_call+0x7/0xb (16)
expires: 63748/350884596
expired: 63748/259469299
at: 857
interval: 0/0
now: 63748/259469761
rem: 0/91415297
overrun: 0
getoffset: 00000000
hydrogen/14762[CPU#0]: BUG in check_ktimer_signal at
kernel/ktimers.c:1345
[<c01280a7>] __WARN_ON+0x67/0x90 (8)
[<c01421ba>] check_ktimer_signal+0x12a/0x140 (48)
[<c0142279>] ktimer_nanosleep+0xa9/0xf0 (52)
[<c01422fb>] ktimer_nanosleep_mono+0x3b/0x50 (56)
[<c03751b0>] nanosleep_restart_mono+0x0/0x30 (8)
[<c0142080>] process_ktimer+0x0/0x10 (64)
[<c01423ac>] sys_nanosleep+0x4c/0x50 (32)
[<c0103481>] syscall_call+0x7/0xb (16)
expires: 63749/750924523
expired: 63748/261658939
at: 857
interval: 0/0
now: 63748/261660137
rem: 1/489265584
overrun: 0
getoffset: 00000000
gpm/4215[CPU#1]: BUG in check_ktimer_signal at kernel/ktimers.c:1345
[<c01280a7>] __WARN_ON+0x67/0x90 (8)
[<c01421ba>] check_ktimer_signal+0x12a/0x140 (48)
[<c0142279>] ktimer_nanosleep+0xa9/0xf0 (52)
[<c01422fb>] ktimer_nanosleep_mono+0x3b/0x50 (56)
[<c03751b0>] nanosleep_restart_mono+0x0/0x30 (8)
[<c0142080>] process_ktimer+0x0/0x10 (64)
[<c01423ac>] sys_nanosleep+0x4c/0x50 (32)
[<c0103481>] syscall_call+0x7/0xb (16)
expires: 63759/124237114
expired: 63759/123513573
at: 857
interval: 0/0
now: 63759/123514487
rem: 0/723541
overrun: 0
getoffset: 00000000
hald-addon-stor/4308[CPU#1]: BUG in check_ktimer_signal at
kernel/ktimers.c:1345 [<c01280a7>] __WARN_ON+0x67/0x90 (8)
[<c01421ba>] check_ktimer_signal+0x12a/0x140 (48)
[<c0142279>] ktimer_nanosleep+0xa9/0xf0 (52)
[<c01422fb>] ktimer_nanosleep_mono+0x3b/0x50 (56)
[<c03751b0>] nanosleep_restart_mono+0x0/0x30 (8)
[<c0142080>] process_ktimer+0x0/0x10 (64)
[<c01423ac>] sys_nanosleep+0x4c/0x50 (32)
[<c0103481>] syscall_call+0x7/0xb (16)
expires: 63759/779202647
expired: 63759/778470948
at: 857
interval: 0/0
now: 63759/778471567
rem: 0/731699
overrun: 0
getoffset: 00000000
hydrogen/14762[CPU#1]: BUG in check_ktimer_signal at
kernel/ktimers.c:1345
[<c01280a7>] __WARN_ON+0x67/0x90 (8)
[<c01421ba>] check_ktimer_signal+0x12a/0x140 (48)
[<c0142279>] ktimer_nanosleep+0xa9/0xf0 (52)
[<c01422fb>] ktimer_nanosleep_mono+0x3b/0x50 (56)
[<c03751b0>] nanosleep_restart_mono+0x0/0x30 (8)
[<c0142080>] process_ktimer+0x0/0x10 (64)
[<c01423ac>] sys_nanosleep+0x4c/0x50 (32)
[<c0103481>] syscall_call+0x7/0xb (16)
expires: 63764/938411799
expired: 63764/937703455
at: 857
interval: 0/0
now: 63764/937704138
rem: 0/708344
overrun: 0
getoffset: 00000000
ypbind/3729[CPU#1]: BUG in check_ktimer_signal at kernel/ktimers.c:1345
[<c01280a7>] __WARN_ON+0x67/0x90 (8)
[<c01421ba>] check_ktimer_signal+0x12a/0x140 (48)
[<c0142279>] ktimer_nanosleep+0xa9/0xf0 (52)
[<c01422fb>] ktimer_nanosleep_mono+0x3b/0x50 (56)
[<c03751b0>] nanosleep_restart_mono+0x0/0x30 (8)
[<c0142080>] process_ktimer+0x0/0x10 (64)
[<c01423ac>] sys_nanosleep+0x4c/0x50 (32)
[<c0103481>] syscall_call+0x7/0xb (16)
SELinux: initialized (dev 0:19, type nfs), uses genfs_contexts
expires: 63779/216066094
expired: 63779/215384514
at: 857
interval: 0/0
now: 63779/215385152
rem: 0/681580
overrun: 0
getoffset: 00000000
hydrogen/14762[CPU#1]: BUG in check_ktimer_signal at
kernel/ktimers.c:1345
[<c01280a7>] __WARN_ON+0x67/0x90 (8)
[<c01421ba>] check_ktimer_signal+0x12a/0x140 (48)
[<c0142279>] ktimer_nanosleep+0xa9/0xf0 (52)
[<c01422fb>] ktimer_nanosleep_mono+0x3b/0x50 (56)
[<c03751b0>] nanosleep_restart_mono+0x0/0x30 (8)
[<c0142080>] process_ktimer+0x0/0x10 (64)
[<c01423ac>] sys_nanosleep+0x4c/0x50 (32)
[<c0103481>] syscall_call+0x7/0xb (16)
SELinux: initialized (dev 0:19, type nfs), uses genfs_contexts
i have released the 2.6.14-rc5-rt1 tree, which can be downloaded from
the usual place:
http://redhat.com/~mingo/realtime-preempt/
this release includes various smaller fixlets, the cycle_t u64 fix from
Steven Rostedt which might fix the ktimer expired short bug messages,
and lots of ktimer/clockevents updates.
Changes since 2.6.14-rc4-rt7:
- cycle_t u64 fix (Steven Rostedt)
- fix the the ktimer monotonicity check (Steven Rostedt)
- raw seqlock fix (Daniel Walker)
- scsi race fix (Steven Rostedt)
- ktimer/clockevents updates (Thomas Gleixner, me)
- PRINTK_IGNORE_LOGLEVEL fix's fix
- ktimer debugging code added
to build a 2.6.14-rc5-rt1 tree, the following patches should be applied:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.14-rc5.bz2
http://redhat.com/~mingo/realtime-preempt/patch-2.6.14-rc5-rt1
Ingo
I have the following build error with make allyesconfig:
CC arch/i386/kernel/mca.o
arch/i386/kernel/mca.c: In function ‘mca_timer_ack’:
arch/i386/kernel/mca.c:488: error: ‘irq’ undeclared (first use in this function)
arch/i386/kernel/mca.c:488: error: (Each undeclared identifier is reported only once
arch/i386/kernel/mca.c:488: error: for each function it appears in.)
make[1]: *** [arch/i386/kernel/mca.o] Error 1
make: *** [arch/i386/kernel] Error 2
regards,
Felix
On Thu, 2005-10-20 at 21:16 +0200, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
>
> > > indeed - and this could explain some of the lockups reported. I've
> > > uploaded -rt10 with your fix included.
> >
> > No lockups so far with -rt12 (running for 1/2 a day already).
> >
> > I'm getting BUG messages again, some examples below...
>
> would be interesting to check whether the cycle_t u64 fix in -rt14 gets
> rid of these BUG messages.
Found this on the logs:
Oct 20 15:52:57 cmn3 kernel: BUG in hydrogen:4810, ktimer expired short
without user signal!:
Oct 20 15:52:57 cmn3 kernel: expires: 2289/357933580
Oct 20 15:52:57 cmn3 kernel: expired: 2289/357891080
Oct 20 15:52:57 cmn3 kernel: at line: 942
Oct 20 15:52:57 cmn3 kernel: interval: 0/0
Oct 20 15:52:57 cmn3 kernel: now: 2289/357891595
Oct 20 15:52:57 cmn3 kernel: rem: 0/42500
Oct 20 15:52:57 cmn3 kernel: overrun: 0
Oct 20 15:52:57 cmn3 kernel: getoffset: 00000000
Oct 20 15:52:57 cmn3 kernel: hydrogen/4810[CPU#1]: BUG in
check_ktimer_signal at kernel/ktimers.c:1305
Oct 20 15:52:57 cmn3 kernel: [<c01280a7>] __WARN_ON+0x67/0x90 (8)
Oct 20 15:52:57 cmn3 kernel: [<c0141fac>] check_ktimer_signal
+0x17c/0x190 (48)
Oct 20 15:52:57 cmn3 kernel: [<c0142069>] __ktimer_nanosleep+0xa9/0xf0
(56)
Oct 20 15:52:57 cmn3 kernel: [<c01420eb>] ktimer_nanosleep+0x3b/0x50
(56)
Oct 20 15:52:57 cmn3 kernel: [<c0375480>] nanosleep_restart_mono
+0x0/0x30 (8)
Oct 20 15:52:57 cmn3 kernel: [<c0141e20>] ktimer_wake_up+0x0/0x10 (64)
Oct 20 15:52:57 cmn3 kernel: [<c014219c>] sys_nanosleep+0x4c/0x50 (32)
Oct 20 15:52:57 cmn3 kernel: [<c0103481>] syscall_call+0x7/0xb (16)
...left for a while and came back to find the machine catatonic. No hard
lock but not much I could do (would ping back but could not ssh, managed
to switch to a text console but login did not work). I found this in the
logs:
Oct 20 15:58:49 cmn3 kernel: BUG: swapper:0, possible softlockup
detected on CPU#1!
Oct 20 15:58:49 cmn3 kernel: [<c01532c6>] softlockup_detected+0x36/0x50
(8)
Oct 20 15:58:49 cmn3 kernel: [<c011913f>] smp_apic_timer_interrupt
+0x3f/0x50 (20)
Oct 20 15:58:49 cmn3 kernel: [<c0103f54>] apic_timer_interrupt
+0x1c/0x24 (8)
Oct 20 15:58:49 cmn3 kernel: [<c023c70d>] acpi_processor_idle+0x0/0x2a7
(8)
Oct 20 15:58:49 cmn3 kernel: [<c023c801>] acpi_processor_idle
+0xf4/0x2a7 (36)
Oct 20 15:58:49 cmn3 kernel: [<c0101134>] cpu_idle+0x84/0xf0 (48)
Oct 20 15:58:49 cmn3 kernel: [<c0376582>] _raw_spin_unlock_irq
+0x12/0x20 (4)
-- Fernando
On 10/20/05, Felix Oxley <[email protected]> wrote:
>
> I have the following build error with make allyesconfig:
>
> CC arch/i386/kernel/mca.o
> arch/i386/kernel/mca.c: In function 'mca_timer_ack':
> arch/i386/kernel/mca.c:488: error: 'irq' undeclared (first use in this function)
> arch/i386/kernel/mca.c:488: error: (Each undeclared identifier is reported only once
> arch/i386/kernel/mca.c:488: error: for each function it appears in.)
> make[1]: *** [arch/i386/kernel/mca.o] Error 1
> make: *** [arch/i386/kernel] Error 2
>
>
> regards,
> Felix
2.6.14-rc5-rt1 is up and running for me. No errors or problems in
dmesg. Jack is running at 64/2 (<3mS) with no problems so far.
NOTE: I don't know if it matters but I switched from the generic
64-bit processor to AMD-Opteron/Athlon64 at -rc4-rt11 and am using
that with rc5-rt1.
Cheers,
Mark
* Fernando Lopez-Lezcano <[email protected]> wrote:
> Found this on the logs:
>
> Oct 20 15:52:57 cmn3 kernel: BUG in hydrogen:4810, ktimer expired
> short without user signal!:
hm. This suggests that hydrogen executing schedule_ktimer() was waken up
45 microseconds too early, and most likely it was not woken up by the
hres timer code (which should have done the wakeup 45 microseconds later
anyway).
I've added special hres-wakeup-debugging code to the scheduler in
-rc5-rt2 to catch this particular scenario, you might want to give it a
try. The new code is always enabled and it should pinpoint the precise
place that does the wrong wakeup. You should see a new type of warning
in your log:
BUG: foo:1234 waking up bar:4321, expiring ktimer short without user signal!
in shortly before the usual "BUG: ktimer expired short" message. Both
messages will be triggered only once per bootup - but the condition
itself likely occurs much more often on your box.
Ingo
A second build error with make allyesconfig:
CC kernel/ktimers.o
kernel/ktimers.c: In function ‘enqueue_ktimer’:
kernel/ktimers.c:762: error: request for member ‘tv’ in something not a structure or union
kernel/ktimers.c:762: error: request for member ‘tv’ in something not a structure or union
make[1]: *** [kernel/ktimers.o] Error 1
make: *** [kernel] Error 2
Seems to be a probelm with definition ktimer_trace :
Signed-off-by: Felix Oxley <[email protected]>
---
--- include/linux/ktimer.h 2005-10-21 00:20:03.000000000 +0100
+++ include/linux/ktimer.h 2005-10-21 10:55:44.000000000 +0100
@@ -141,7 +141,7 @@ extern int ktimer_interrupt(void);
#define KTIME_REALTIME_RES CONFIG_HIGH_RES_RESOLUTION
#define KTIME_MONOTONIC_RES CONFIG_HIGH_RES_RESOLUTION
-#define ktimer_trace(a,b) trace_special((a).tv.sec,(a).tv.nsec,b)
+#define ktimer_trace(a,b) trace_special((a).tv_sec,(a).tv_nsec,b)
#else
* Felix Oxley <[email protected]> wrote:
> A second build error with make allyesconfig:
ah, indeed.
> Seems to be a probelm with definition ktimer_trace :
>
> Signed-off-by: Felix Oxley <[email protected]>
> ---
> --- include/linux/ktimer.h 2005-10-21 00:20:03.000000000 +0100
> +++ include/linux/ktimer.h 2005-10-21 10:55:44.000000000 +0100
> @@ -141,7 +141,7 @@ extern int ktimer_interrupt(void);
> #define KTIME_REALTIME_RES CONFIG_HIGH_RES_RESOLUTION
> #define KTIME_MONOTONIC_RES CONFIG_HIGH_RES_RESOLUTION
>
> -#define ktimer_trace(a,b) trace_special((a).tv.sec,(a).tv.nsec,b)
> +#define ktimer_trace(a,b) trace_special((a).tv_sec,(a).tv_nsec,b)
yeah. Btw., your fix is still not complete (it wont work with the scalar
representation of ktime_t, on 64-bit platforms) - the full solution
should be the patch below.
Ingo
Index: linux/include/linux/ktimer.h
===================================================================
--- linux.orig/include/linux/ktimer.h
+++ linux/include/linux/ktimer.h
@@ -141,7 +141,7 @@ extern int ktimer_interrupt(void);
#define KTIME_REALTIME_RES CONFIG_HIGH_RES_RESOLUTION
#define KTIME_MONOTONIC_RES CONFIG_HIGH_RES_RESOLUTION
-#define ktimer_trace(a,b) trace_special((a).tv.sec,(a).tv.nsec,b)
+#define ktimer_trace(a,b) trace_special(ktime_get_high(a),ktime_get_low(a),b)
#else
On Friday 21 October 2005 11:01, Felix Oxley wrote:
>
> A second build error with make allyesconfig:
>
> CC kernel/ktimers.o
> kernel/ktimers.c: In function ‘enqueue_ktimer’:
> kernel/ktimers.c:762: error: request for member ‘tv’ in something not a structure or union
> kernel/ktimers.c:762: error: request for member ‘tv’ in something not a structure or union
> make[1]: *** [kernel/ktimers.o] Error 1
> make: *** [kernel] Error 2
>
> Seems to be a probelm with definition ktimer_trace :
>
> Signed-off-by: Felix Oxley <[email protected]>
> ---
> --- include/linux/ktimer.h 2005-10-21 00:20:03.000000000 +0100
> +++ include/linux/ktimer.h 2005-10-21 10:55:44.000000000 +0100
> @@ -141,7 +141,7 @@ extern int ktimer_interrupt(void);
> #define KTIME_REALTIME_RES CONFIG_HIGH_RES_RESOLUTION
> #define KTIME_MONOTONIC_RES CONFIG_HIGH_RES_RESOLUTION
>
> -#define ktimer_trace(a,b) trace_special((a).tv.sec,(a).tv.nsec,b)
> +#define ktimer_trace(a,b) trace_special((a).tv_sec,(a).tv_nsec,b)
>
> #else
Looks like that is only <50% of a fix since we still have:
ktimer_trace(now, 0);
being called where now is not of type struct timeval.
I can't see what to do with that I'm afraid.
So since I am only build testing I will comment it out.
regards,
Felix
On Friday 21 October 2005 11:18, Felix Oxley wrote:
> So since I am only build testing I will comment it out.
>
Thta did not advance me very far!
CC kernel/time/clockevents.o
kernel/time/clockevents.c: In function ‘clockevents_set_next_event’:
kernel/time/clockevents.c:519: error: request for member ‘tv_sec’ in something not a structure or union
kernel/time/clockevents.c:519: error: request for member ‘tv_nsec’ in something not a structure or union
make[2]: *** [kernel/time/clockevents.o] Error 1
make[1]: *** [kernel/time] Error 2
make: *** [kernel] Error 2
Another ktimer_trace with incorrect arguments AFAICT.
I will try again with -rc5-rt3. :-)
regards,
Felix
On 10/20/05, Mark Knecht <[email protected]> wrote:
<SNIP>
>
> 2.6.14-rc5-rt1 is up and running for me. No errors or problems in
> dmesg. Jack is running at 64/2 (<3mS) with no problems so far.
>
<SNIP>
Unfortunately I got a large rash of xruns late in the evening. First
problem like that in days.
I'll turn on latency tracing and see if I can catch anything today.
There still appears to be somethign going on here.
- Mark
On Fri, 2005-10-21 at 10:05 +0200, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
>
> > Found this on the logs:
> >
> > Oct 20 15:52:57 cmn3 kernel: BUG in hydrogen:4810, ktimer expired
> > short without user signal!:
>
> hm. This suggests that hydrogen executing schedule_ktimer() was waken up
> 45 microseconds too early, and most likely it was not woken up by the
> hres timer code (which should have done the wakeup 45 microseconds later
> anyway).
>
> I've added special hres-wakeup-debugging code to the scheduler in
> -rc5-rt2 to catch this particular scenario, you might want to give it a
> try. The new code is always enabled and it should pinpoint the precise
> place that does the wrong wakeup. You should see a new type of warning
> in your log:
>
> BUG: foo:1234 waking up bar:4321, expiring ktimer short without user signal!
>
> in shortly before the usual "BUG: ktimer expired short" message. Both
> messages will be triggered only once per bootup - but the condition
> itself likely occurs much more often on your box.
Here's one with rc5-rt3:
Oct 21 15:01:46 cmn3 kernel: BUG: ktimer expired short without user
signal! (hald-addon-stor:4309)
Oct 21 15:01:46 cmn3 kernel: .. expires: 1012/751245500
Oct 21 15:01:46 cmn3 kernel: .. expired: 1012/750908115
Oct 21 15:01:46 cmn3 kernel: .. at line: 942
Oct 21 15:01:46 cmn3 kernel: .. interval: 0/0
Oct 21 15:01:46 cmn3 kernel: .. now: 1012/750908723
Oct 21 15:01:46 cmn3 kernel: .. rem: 0/337385
Oct 21 15:01:46 cmn3 kernel: .. overrun: 0
Oct 21 15:01:46 cmn3 kernel: .. getoffset: 00000000
Oct 21 15:01:46 cmn3 kernel: [<c014205d>] check_ktimer_signal
+0x16d/0x190 (8)
Oct 21 15:01:46 cmn3 kernel: [<c0142129>] __ktimer_nanosleep+0xa9/0xf0
(56)
Oct 21 15:01:46 cmn3 kernel: [<c01421ab>] ktimer_nanosleep+0x3b/0x50
(56)
Oct 21 15:01:46 cmn3 kernel: [<c0375d20>] nanosleep_restart_mono
+0x0/0x30 (8)
Oct 21 15:01:46 cmn3 kernel: [<c0141ee0>] ktimer_wake_up+0x0/0x10 (64)
Oct 21 15:01:46 cmn3 kernel: [<c014225c>] sys_nanosleep+0x4c/0x50 (32)
Oct 21 15:01:46 cmn3 kernel: [<c0103481>] syscall_call+0x7/0xb (16)
And another (the same?) after a reboot:
Oct 21 16:06:11 cmn3 kernel: BUG: ktimer expired short without user
signal! (udev:317)
Oct 21 16:06:11 cmn3 kernel: .. expires: 9/24925742
Oct 21 16:06:11 cmn3 kernel: .. expired: 9/24924523
Oct 21 16:06:11 cmn3 kernel: .. at line: 942
Oct 21 16:06:11 cmn3 kernel: .. interval: 0/0
Oct 21 16:06:11 cmn3 kernel: .. now: 9/24925385
Oct 21 16:06:11 cmn3 kernel: .. rem: 0/1219
Oct 21 16:06:11 cmn3 kernel: .. overrun: 0
Oct 21 16:06:11 cmn3 kernel: .. getoffset: 00000000
Oct 21 16:06:11 cmn3 kernel: [<c014205d>] check_ktimer_signal
+0x16d/0x190 (8)
Oct 21 16:06:11 cmn3 kernel: [<c0142129>] __ktimer_nanosleep+0xa9/0xf0
(56)
Oct 21 16:06:11 cmn3 kernel: [<c01421ab>] ktimer_nanosleep+0x3b/0x50
(56)
Oct 21 16:06:11 cmn3 kernel: [<c0375d20>] nanosleep_restart_mono
+0x0/0x30 (8)
Oct 21 16:06:11 cmn3 kernel: [<c0141ee0>] ktimer_wake_up+0x0/0x10 (64)
Oct 21 16:06:11 cmn3 kernel: [<c014225c>] sys_nanosleep+0x4c/0x50 (32)
Oct 21 16:06:11 cmn3 kernel: [<c0103481>] syscall_call+0x7/0xb (16)
In both cases the machine goes catatonic, I don't know if right after
this or not. It responds to the SysRQ key but that's pretty much it, I
should probably try to get a serial console going somehow.
-- Fernando
On 10/21/05, Fernando Lopez-Lezcano <[email protected]> wrote:
<SNIP>
>
> Here's one with rc5-rt3:
>
> Oct 21 15:01:46 cmn3 kernel: BUG: ktimer expired short without user
> signal! (hald-addon-stor:4309)
> Oct 21 15:01:46 cmn3 kernel: .. expires: 1012/751245500
> Oct 21 15:01:46 cmn3 kernel: .. expired: 1012/750908115
> Oct 21 15:01:46 cmn3 kernel: .. at line: 942
> Oct 21 15:01:46 cmn3 kernel: .. interval: 0/0
><SNIP>
Refresh me. What sort of machine is this and what log file are you
seeing these in. I am surprised at my not seeing them at all, but I
have not gone into the high res timer stuff much. Should I?
- Mark
* Mark Knecht <[email protected]> wrote:
> On 10/21/05, Fernando Lopez-Lezcano <[email protected]> wrote:
> <SNIP>
> >
> > Here's one with rc5-rt3:
> >
> > Oct 21 15:01:46 cmn3 kernel: BUG: ktimer expired short without user
> > signal! (hald-addon-stor:4309)
> > Oct 21 15:01:46 cmn3 kernel: .. expires: 1012/751245500
> > Oct 21 15:01:46 cmn3 kernel: .. expired: 1012/750908115
> > Oct 21 15:01:46 cmn3 kernel: .. at line: 942
> > Oct 21 15:01:46 cmn3 kernel: .. interval: 0/0
> ><SNIP>
>
> Refresh me. What sort of machine is this and what log file are you
> seeing these in. I am surprised at my not seeing them at all, but I
> have not gone into the high res timer stuff much. Should I?
high-res timers are not ported (and thus not switchable via the .config)
to x64, yet - so you are much less likely to be seeing such problems.
x64 does run the generic ktimer code - but this particular problem seems
to be related to hres timers.
Ingo
* Fernando Lopez-Lezcano <[email protected]> wrote:
> Here's one with rc5-rt3:
>
> Oct 21 15:01:46 cmn3 kernel: BUG: ktimer expired short without user
> signal! (hald-addon-stor:4309)
and no "BUG: foo:1234 waking up bar:4321, expiring ktimer short" message
prior to that? Very weird, this line:
> Oct 21 15:01:46 cmn3 kernel: .. expires: 1012/751245500
> Oct 21 15:01:46 cmn3 kernel: .. expired: 1012/750908115
> Oct 21 15:01:46 cmn3 kernel: .. at line: 942
suggests that the ktimer was expired by ktimer_try_to_cancel() /
ktimer_cancel(), in ktimer_schedule(). I.e. something must have woken
the task early. Probably this theory of mine is incorrect then. I'll try
extend the debug info a bit: it would be interesting to see a 'timer
inserted at' timestamp as well (was it shortly before the problem
happened?), and a 'which PID cancelled the timer' info.
a heavy-hitting but complex-to-set-up solution would be to add a serial
console, and to enable WAKEUP_TIMING+LATENCY_TRACING in the .config, and
to edit kernel/latency.c to initialize the default value of the
following variables:
int wakeup_timing = 0;
int trace_all_cpus = 1;
int trace_freerunning = 1;
int trace_print_at_crash = 1;
int trace_user_triggered = 1;
these variables are in the top portion of latency.c. Important: if you
try this then you should probably also enable IGNORE_PRINTK_LOGLEVEL,
which will improve mass-output to the serial console. Another important
thing is to add a stop_trace() call to kernel/ktimers.c's
check_ktimer_signal() function:
unlock_ktimer_base(timer, &flags);
stop_trace();
printk("BUG: ktimer expired short without user signal! (%s:%d)\n",
current->comm, current->pid);
(otherwise all the trace output you'd be getting would be boring printk
related trace entries.)
this will cause the dump_stack() to also output thousands of trace
entries - all the kernel activity (from all CPUs) that preceded the
ktimer problem. Hopefully this pinpoints the bug.
> In both cases the machine goes catatonic, I don't know if right after
> this or not. It responds to the SysRQ key but that's pretty much it, I
> should probably try to get a serial console going somehow.
would it be easy for you to try the UP kernel? One possibility is that
this is some sort of SMP/APIC-timer related problem.
Ingo
On Sat, 2005-10-22 at 05:41 +0200, Ingo Molnar wrote:
> high-res timers are not ported (and thus not switchable via the .config)
> to x64, yet - so you are much less likely to be seeing such problems.
> x64 does run the generic ktimer code - but this particular problem seems
> to be related to hres timers.
Fernando, this is somewhat OT, but are you really planning to enable
high res timers in the ccrma kernel? My impression so far has been that
they are too experimental for a distro kernel.
Lee
On Sat, 2005-10-22 at 01:12 -0400, Lee Revell wrote:
> On Sat, 2005-10-22 at 05:41 +0200, Ingo Molnar wrote:
> > high-res timers are not ported (and thus not switchable via the .config)
> > to x64, yet - so you are much less likely to be seeing such problems.
> > x64 does run the generic ktimer code - but this particular problem seems
> > to be related to hres timers.
>
> Fernando, this is somewhat OT, but are you really planning to enable
> high res timers in the ccrma kernel? My impression so far has been that
> they are too experimental for a distro kernel.
No, I was not planning on that. In my previous bug hunt it was suggested
I turn them on and I did. Maybe it is time to try again with them off
and see if the bug(s) still show up (I was also under the impression
they were too experimental).
-- Fernando
On Friday 21 October 2005 11:26, Felix Oxley wrote:
> I will try again with -rc5-rt3. :-)
>
-rc5-rt3 builds fine.
I got these messages while doing 'make allmodconfig':
CC [M] drivers/pcmcia/i82365.o
CC [M] drivers/pcmcia/i82092.o
CC [M] drivers/pcmcia/tcic.o
CC [M] drivers/scsi/NCR_Q720.o
In file included from drivers/scsi/ncr53c8xx.h:47,
from drivers/scsi/NCR_Q720.c:21:
drivers/scsi/sym53c8xx_defs.h:292:1: warning: "ktime_add" redefined
In file included from include/linux/ktimer.h:19,
from include/linux/sched.h:264,
from include/linux/module.h:10,
from include/linux/device.h:20,
from include/linux/genhd.h:15,
from include/linux/blkdev.h:6,
from drivers/scsi/NCR_Q720.c:8:
include/linux/ktime.h:110:1: warning: this is the location of the previous definition
In file included from drivers/scsi/ncr53c8xx.h:47,
from drivers/scsi/NCR_Q720.c:21:
drivers/scsi/sym53c8xx_defs.h:293:1: warning: "ktime_sub" redefined
In file included from include/linux/ktimer.h:19,
from include/linux/sched.h:264,
from include/linux/module.h:10,
from include/linux/device.h:20,
from include/linux/genhd.h:15,
from include/linux/blkdev.h:6,
from drivers/scsi/NCR_Q720.c:8:
include/linux/ktime.h:107:1: warning: this is the location of the previous definition
CC [M] drivers/scsi/ncr53c8xx.o
In file included from drivers/scsi/ncr53c8xx.h:47,
from drivers/scsi/ncr53c8xx.c:129:
drivers/scsi/sym53c8xx_defs.h:292:1: warning: "ktime_add" redefined
In file included from include/linux/ktimer.h:19,
from include/linux/sched.h:264,
from include/linux/module.h:10,
from include/linux/device.h:20,
from include/linux/genhd.h:15,
from include/linux/blkdev.h:6,
from drivers/scsi/ncr53c8xx.c:100:
include/linux/ktime.h:110:1: warning: this is the location of the previous definition
In file included from drivers/scsi/ncr53c8xx.h:47,
from drivers/scsi/ncr53c8xx.c:129:
drivers/scsi/sym53c8xx_defs.h:293:1: warning: "ktime_sub" redefined
In file included from include/linux/ktimer.h:19,
from include/linux/sched.h:264,
from include/linux/module.h:10,
from include/linux/device.h:20,
from include/linux/genhd.h:15,
from include/linux/blkdev.h:6,
from drivers/scsi/ncr53c8xx.c:100:
include/linux/ktime.h:107:1: warning: this is the location of the previous definition
drivers/scsi/ncr53c8xx.c:7622: warning: ‘ncr53c8xx_setup’ defined but not used
CC [M] drivers/scsi/libata-core.o
CC [M] drivers/scsi/libata-scsi.o
CC [M] drivers/scsi/scsi.o
Are they of any interest?
regards,
Felix
On Sat, 2005-10-22 at 05:58 +0200, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
>
> > Here's one with rc5-rt3:
rc5-rt5, _without_ HIGH_RES_TIMERS. No messages after this but the
Gnome/X session got really confused and unusable after starting fine
(ie: windows would not redraw, apparently everything suddenly slowed
down to a crawl):
Oct 24 12:10:43 host kernel: Using specific hotkey driver
Oct 24 12:10:43 host kernel: ACPI: CPU0 (power states: C1[C1])
Oct 24 12:10:43 host kernel: ACPI: CPU1 (power states: C1[C1])
Oct 24 12:10:43 host kernel: Time: tsc clocksource has been installed.
Oct 24 12:10:43 host kernel: WARNING: non-monotonic time!
Oct 24 12:10:43 host kernel: ... time warped from 578911413 to
539189615.
Oct 24 12:10:43 host kernel: softirq-timer/1/13[CPU#1]: BUG in ktime_get
at kernel/ktimers.c:103
Oct 24 12:10:43 host kernel: [<c0128157>] __WARN_ON+0x67/0x90 (8)
Oct 24 12:10:43 host kernel: [<c01408d2>] ktime_get+0xf2/0x170 (48)
Oct 24 12:10:43 host kernel: [<c014151f>] ktimer_run_queues+0x2f/0x130
(68)
Oct 24 12:10:43 host kernel: [<c013162e>] run_timer_softirq+0xde/0x380
(48)
Oct 24 12:10:43 host kernel: [<c0374435>] schedule+0x85/0x100 (24)
Oct 24 12:10:43 host kernel: [<c012d3c8>] ksoftirqd+0x118/0x1e0 (28)
Oct 24 12:10:43 host kernel: [<c012d2b0>] ksoftirqd+0x0/0x1e0 (44)
Oct 24 12:10:43 host kernel: [<c013d15c>] kthread+0xac/0xb0 (4)
Oct 24 12:10:43 host kernel: [<c013d0b0>] kthread+0x0/0xb0 (12)
Oct 24 12:10:43 host kernel: [<c0101545>] kernel_thread_helper+0x5/0x10
(16)
Oct 24 12:10:43 host kernel: WARNING: non-monotonic time!
Oct 24 12:10:43 host kernel: ... time warped from 579911260 to
539914810.
Oct 24 12:10:43 host kernel: softirq-timer/0/4[CPU#0]: BUG in ktime_get
at kernel/ktimers.c:103
Oct 24 12:10:43 host kernel: [<c0128157>] __WARN_ON+0x67/0x90 (8)
Oct 24 12:10:43 host kernel: [<c01408d2>] ktime_get+0xf2/0x170 (48)
Oct 24 12:10:43 host kernel: [<c014151f>] ktimer_run_queues+0x2f/0x130
(68)
Oct 24 12:10:43 host kernel: [<c013162e>] run_timer_softirq+0xde/0x380
(48)
Oct 24 12:10:43 host kernel: [<c0374435>] schedule+0x85/0x100 (24)
Oct 24 12:10:43 host kernel: [<c012d3c8>] ksoftirqd+0x118/0x1e0 (28)
Oct 24 12:10:43 host kernel: [<c012d2b0>] ksoftirqd+0x0/0x1e0 (44)
Oct 24 12:10:43 host kernel: [<c013d15c>] kthread+0xac/0xb0 (4)
Oct 24 12:10:43 host kernel: [<c013d0b0>] kthread+0x0/0xb0 (12)
Oct 24 12:10:43 host kernel: [<c0101545>] kernel_thread_helper+0x5/0x10
(16)
Oct 24 12:10:43 host kernel: WARNING: non-monotonic time!
Oct 24 12:10:44 host kernel: ... time warped from 578911413 to
540188071.
Oct 24 12:10:44 host kernel: softirq-timer/1/13[CPU#1]: BUG in ktime_get
at kernel/ktimers.c:103
Oct 24 12:10:44 host kernel: [<c0128157>] __WARN_ON+0x67/0x90 (8)
Oct 24 12:10:44 host kernel: [<c01408d2>] ktime_get+0xf2/0x170 (48)
Oct 24 12:10:44 host kernel: [<c014151f>] ktimer_run_queues+0x2f/0x130
(68)
Oct 24 12:10:44 host kernel: [<c013162e>] run_timer_softirq+0xde/0x380
(48)
Oct 24 12:10:44 host kernel: [<c0374435>] schedule+0x85/0x100 (24)
Oct 24 12:10:44 host kernel: [<c012d3c8>] ksoftirqd+0x118/0x1e0 (28)
Oct 24 12:10:44 host kernel: [<c012d2b0>] ksoftirqd+0x0/0x1e0 (44)
Oct 24 12:10:44 host kernel: [<c013d15c>] kthread+0xac/0xb0 (4)
Oct 24 12:10:44 host kernel: [<c013d0b0>] kthread+0x0/0xb0 (12)
Oct 24 12:10:44 host kernel: [<c0101545>] kernel_thread_helper+0x5/0x10
(16)
Oct 24 12:10:44 host kernel: isapnp: Scanning for PnP cards...
Oct 24 12:10:44 host kernel: isapnp: No Plug & Play device found
Oct 24 12:10:44 host kernel: Real Time Clock Driver v1.12
Oct 24 12:10:44 host kernel: Linux agpgart interface v0.101 (c) Dave
Jones
-- Fernando
On Mon, 2005-10-24 at 12:28 -0700, Fernando Lopez-Lezcano wrote:
> On Sat, 2005-10-22 at 05:58 +0200, Ingo Molnar wrote:
> > * Fernando Lopez-Lezcano <[email protected]> wrote:
> >
> > > Here's one with rc5-rt3:
>
> rc5-rt5, _without_ HIGH_RES_TIMERS.
Same warnings when booting into the UP kernel, so far no hang but I have
not been logged in for long:
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: CPU0 (power states: C1[C1])
isapnp: Scanning for PnP cards...
Time: tsc clocksource has been installed.
WARNING: non-monotonic time!
... time warped from 452930691 to 440940768.
udev/33[CPU#0]: BUG in ktime_get at kernel/ktimers.c:103
[<c012147c>] __WARN_ON+0x5c/0xa0 (8)
[<c0138105>] ktime_get+0xe5/0x160 (48)
[<c013848e>] enqueue_ktimer+0x2e/0x330 (64)
[<c018389f>] dput+0xef/0x220 (4)
[<c01388fa>] internal_restart_ktimer+0x9a/0x130 (80)
[<c03509a7>] schedule_ktimer+0x47/0xc0 (44)
[<c0350a48>] schedule_ktimer_interruptible+0x28/0x50 (20)
[<c0138f90>] __ktimer_nanosleep+0x40/0xe0 (24)
[<c017510a>] vfs_lstat+0x1a/0x50 (12)
[<c013906b>] ktimer_nanosleep+0x3b/0x50 (36)
[<c0350b50>] nanosleep_restart_mono+0x0/0x30 (8)
[<c0138dc0>] ktimer_wake_up+0x0/0x10 (64)
[<c013911c>] sys_nanosleep+0x4c/0x50 (32)
[<c01031fd>] syscall_call+0x7/0xb (16)
WARNING: non-monotonic time!
... time warped from 452930691 to 441930456.
softirq-timer/0/3[CPU#0]: BUG in ktime_get at kernel/ktimers.c:103
[<c012147c>] __WARN_ON+0x5c/0xa0 (8)
[<c0138105>] ktime_get+0xe5/0x160 (48)
[<c0138cbd>] ktimer_run_queues+0x1d/0x120 (64)
[<c0129ad7>] run_timer_softirq+0xc7/0x3d0 (48)
[<c034fd35>] schedule+0x85/0x100 (12)
[<c0125c27>] ksoftirqd+0xc7/0x130 (28)
[<c0125b60>] ksoftirqd+0x0/0x130 (32)
[<c0134a18>] kthread+0x98/0xa0 (8)
[<c0134980>] kthread+0x0/0xa0 (12)
[<c01013c5>] kernel_thread_helper+0x5/0x10 (12)
WARNING: non-monotonic time!
... time warped from 452930691 to 442929843.
softirq-timer/0/3[CPU#0]: BUG in ktime_get at kernel/ktimers.c:103
[<c012147c>] __WARN_ON+0x5c/0xa0 (8)
[<c0138105>] ktime_get+0xe5/0x160 (48)
[<c0138cbd>] ktimer_run_queues+0x1d/0x120 (64)
[<c011c21c>] __wake_up+0x3c/0x70 (16)
[<c0129ad7>] run_timer_softirq+0xc7/0x3d0 (32)
[<c034fd35>] schedule+0x85/0x100 (12)
[<c0125c27>] ksoftirqd+0xc7/0x130 (28)
[<c0125b60>] ksoftirqd+0x0/0x130 (32)
[<c0134a18>] kthread+0x98/0xa0 (8)
[<c0134980>] kthread+0x0/0xa0 (12)
[<c01013c5>] kernel_thread_helper+0x5/0x10 (12)
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12
Linux agpgart interface v0.101 (c) Dave Jones
And this when starting Hydrogen for the first time (the next startup is
fine):
hydrogen:4610 userspace BUG: scheduling in user-atomic context!
[<c034fd9a>] schedule+0xea/0x100 (8)
[<c034ff74>] wait_for_completion+0xa4/0xe0 (28)
[<c011c150>] default_wake_function+0x0/0x20 (12)
[<c0177951>] coredump_wait+0xa1/0x100 (28)
[<c01ec60c>] copy_from_user+0x4c/0xc0 (8)
[<c0177aaa>] do_coredump+0xfa/0x270 (108)
[<c015456d>] kmem_cache_free+0x4d/0xb0 (40)
[<c012aab5>] __dequeue_signal+0xf5/0x1c0 (24)
[<c012aba3>] dequeue_signal+0x23/0xe0 (32)
[<c012ca58>] get_signal_to_deliver+0x298/0x310 (20)
[<c0351ee0>] do_page_fault+0x0/0x590 (24)
[<c0102f80>] do_signal+0x70/0x180 (8)
[<c014f495>] free_pages_bulk+0x225/0x2a0 (28)
[<c0129493>] try_to_del_timer_sync+0x43/0x50 (12)
[<c0147735>] audit_filter_syscall+0x45/0xe0 (4)
[<c014834b>] audit_syscall_exit+0x4b/0x400 (36)
[<c035219d>] do_page_fault+0x2bd/0x590 (40)
[<c0351ee0>] do_page_fault+0x0/0x590 (48)
[<c01030b5>] do_notify_resume+0x25/0x34 (8)
[<c0103294>] work_notifysig+0x13/0x1b (8)
No other BUG messages that I can see.
-- Fernando
On Mon, 2005-10-24 at 12:38 -0700, Fernando Lopez-Lezcano wrote:
> On Mon, 2005-10-24 at 12:28 -0700, Fernando Lopez-Lezcano wrote:
> > On Sat, 2005-10-22 at 05:58 +0200, Ingo Molnar wrote:
> > > * Fernando Lopez-Lezcano <[email protected]> wrote:
> > >
> > > > Here's one with rc5-rt3:
> >
> > rc5-rt5, _without_ HIGH_RES_TIMERS.
>
> Same warnings when booting into the UP kernel, so far no hang but I have
> not been logged in for long:
Can you send me a full dmesg?
thanks
-john
On Mon, 2005-10-24 at 12:38 -0700, Fernando Lopez-Lezcano wrote:
> On Mon, 2005-10-24 at 12:28 -0700, Fernando Lopez-Lezcano wrote:
> > On Sat, 2005-10-22 at 05:58 +0200, Ingo Molnar wrote:
> > > * Fernando Lopez-Lezcano <[email protected]> wrote:
> > >
> > > > Here's one with rc5-rt3:
> >
> > rc5-rt5, _without_ HIGH_RES_TIMERS.
>
> Same warnings when booting into the UP kernel, so far no hang but I have
> not been logged in for long:
>
> pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> ACPI: CPU0 (power states: C1[C1])
> isapnp: Scanning for PnP cards...
> Time: tsc clocksource has been installed.
> WARNING: non-monotonic time!
> ... time warped from 452930691 to 440940768.
> udev/33[CPU#0]: BUG in ktime_get at kernel/ktimers.c:103
> [<c012147c>] __WARN_ON+0x5c/0xa0 (8)
> [<c0138105>] ktime_get+0xe5/0x160 (48)
> [<c013848e>] enqueue_ktimer+0x2e/0x330 (64)
> [<c018389f>] dput+0xef/0x220 (4)
> [<c01388fa>] internal_restart_ktimer+0x9a/0x130 (80)
> [<c03509a7>] schedule_ktimer+0x47/0xc0 (44)
> [<c0350a48>] schedule_ktimer_interruptible+0x28/0x50 (20)
> [<c0138f90>] __ktimer_nanosleep+0x40/0xe0 (24)
> [<c017510a>] vfs_lstat+0x1a/0x50 (12)
> [<c013906b>] ktimer_nanosleep+0x3b/0x50 (36)
> [<c0350b50>] nanosleep_restart_mono+0x0/0x30 (8)
> [<c0138dc0>] ktimer_wake_up+0x0/0x10 (64)
> [<c013911c>] sys_nanosleep+0x4c/0x50 (32)
> [<c01031fd>] syscall_call+0x7/0xb (16)
> WARNING: non-monotonic time!
> ... time warped from 452930691 to 441930456.
> softirq-timer/0/3[CPU#0]: BUG in ktime_get at kernel/ktimers.c:103
> [<c012147c>] __WARN_ON+0x5c/0xa0 (8)
> [<c0138105>] ktime_get+0xe5/0x160 (48)
> [<c0138cbd>] ktimer_run_queues+0x1d/0x120 (64)
> [<c0129ad7>] run_timer_softirq+0xc7/0x3d0 (48)
> [<c034fd35>] schedule+0x85/0x100 (12)
> [<c0125c27>] ksoftirqd+0xc7/0x130 (28)
> [<c0125b60>] ksoftirqd+0x0/0x130 (32)
> [<c0134a18>] kthread+0x98/0xa0 (8)
> [<c0134980>] kthread+0x0/0xa0 (12)
> [<c01013c5>] kernel_thread_helper+0x5/0x10 (12)
> WARNING: non-monotonic time!
> ... time warped from 452930691 to 442929843.
> softirq-timer/0/3[CPU#0]: BUG in ktime_get at kernel/ktimers.c:103
> [<c012147c>] __WARN_ON+0x5c/0xa0 (8)
> [<c0138105>] ktime_get+0xe5/0x160 (48)
> [<c0138cbd>] ktimer_run_queues+0x1d/0x120 (64)
> [<c011c21c>] __wake_up+0x3c/0x70 (16)
> [<c0129ad7>] run_timer_softirq+0xc7/0x3d0 (32)
> [<c034fd35>] schedule+0x85/0x100 (12)
> [<c0125c27>] ksoftirqd+0xc7/0x130 (28)
> [<c0125b60>] ksoftirqd+0x0/0x130 (32)
> [<c0134a18>] kthread+0x98/0xa0 (8)
> [<c0134980>] kthread+0x0/0xa0 (12)
> [<c01013c5>] kernel_thread_helper+0x5/0x10 (12)
> isapnp: No Plug & Play device found
> Real Time Clock Driver v1.12
> Linux agpgart interface v0.101 (c) Dave Jones
>
The above is being worked on. John, I believe this will be solved when
we get your latest into Ingo's kernel.
> And this when starting Hydrogen for the first time (the next startup is
> fine):
>
> hydrogen:4610 userspace BUG: scheduling in user-atomic context!
> [<c034fd9a>] schedule+0xea/0x100 (8)
> [<c034ff74>] wait_for_completion+0xa4/0xe0 (28)
> [<c011c150>] default_wake_function+0x0/0x20 (12)
> [<c0177951>] coredump_wait+0xa1/0x100 (28)
> [<c01ec60c>] copy_from_user+0x4c/0xc0 (8)
> [<c0177aaa>] do_coredump+0xfa/0x270 (108)
> [<c015456d>] kmem_cache_free+0x4d/0xb0 (40)
> [<c012aab5>] __dequeue_signal+0xf5/0x1c0 (24)
> [<c012aba3>] dequeue_signal+0x23/0xe0 (32)
> [<c012ca58>] get_signal_to_deliver+0x298/0x310 (20)
> [<c0351ee0>] do_page_fault+0x0/0x590 (24)
> [<c0102f80>] do_signal+0x70/0x180 (8)
> [<c014f495>] free_pages_bulk+0x225/0x2a0 (28)
> [<c0129493>] try_to_del_timer_sync+0x43/0x50 (12)
> [<c0147735>] audit_filter_syscall+0x45/0xe0 (4)
> [<c014834b>] audit_syscall_exit+0x4b/0x400 (36)
> [<c035219d>] do_page_fault+0x2bd/0x590 (40)
> [<c0351ee0>] do_page_fault+0x0/0x590 (48)
> [<c01030b5>] do_notify_resume+0x25/0x34 (8)
> [<c0103294>] work_notifysig+0x13/0x1b (8)
>
> No other BUG messages that I can see.
> -- Fernando
This part is new, I'll take a look into this.
-- Steve
On Mon, 2005-10-24 at 16:39 -0400, Steven Rostedt wrote:
> > And this when starting Hydrogen for the first time (the next startup is
> > fine):
> >
> > hydrogen:4610 userspace BUG: scheduling in user-atomic context!
> > [<c034fd9a>] schedule+0xea/0x100 (8)
> > [<c034ff74>] wait_for_completion+0xa4/0xe0 (28)
> > [<c011c150>] default_wake_function+0x0/0x20 (12)
> > [<c0177951>] coredump_wait+0xa1/0x100 (28)
> > [<c01ec60c>] copy_from_user+0x4c/0xc0 (8)
> > [<c0177aaa>] do_coredump+0xfa/0x270 (108)
> > [<c015456d>] kmem_cache_free+0x4d/0xb0 (40)
> > [<c012aab5>] __dequeue_signal+0xf5/0x1c0 (24)
> > [<c012aba3>] dequeue_signal+0x23/0xe0 (32)
> > [<c012ca58>] get_signal_to_deliver+0x298/0x310 (20)
> > [<c0351ee0>] do_page_fault+0x0/0x590 (24)
> > [<c0102f80>] do_signal+0x70/0x180 (8)
> > [<c014f495>] free_pages_bulk+0x225/0x2a0 (28)
> > [<c0129493>] try_to_del_timer_sync+0x43/0x50 (12)
> > [<c0147735>] audit_filter_syscall+0x45/0xe0 (4)
> > [<c014834b>] audit_syscall_exit+0x4b/0x400 (36)
> > [<c035219d>] do_page_fault+0x2bd/0x590 (40)
> > [<c0351ee0>] do_page_fault+0x0/0x590 (48)
> > [<c01030b5>] do_notify_resume+0x25/0x34 (8)
> > [<c0103294>] work_notifysig+0x13/0x1b (8)
> >
> > No other BUG messages that I can see.
> > -- Fernando
>
> This part is new, I'll take a look into this.
Hydrogen segfaulted in the RT thread, and it was decided a while back
that an RT thread should lose RT priority when it coredumps - previously
we were seeing long latencies if the highest priority thread caught a
sig 11. So this looks like a false positive in the userspace atomicity
debugger.
Lee
For those using kgdb on the rt kernel, I have just updated the patches at:
http://source.mvista.com/~ganzinger/
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
Hi,
I have a similar message with a 2.6.14-rc5-rt3 kernel (compiled
choosing doing a make oldconfig from the vanilla rc5 and choosing all
no and Complete Preemption):
ACPI: PCI Interrupt 0000:01:05.0[A] -> Link [LNKA] -> GSI 10 (level,
low) -> IRQ 10
radeonfb: Found Intel x86 BIOS ROM Image
Time: tsc clocksource has been installed.
WARNING: non-monotonic time!
softirq-timer/0/3[CPU#0]: BUG in ktime_get at kernel/ktimers.c:101
[<c011b058>] __WARN_ON+0x68/0xa0 (8)
[<c0133435>] ktime_get+0xe5/0x100 (48)
[<c0133ff2>] ktimer_run_queues+0x22/0x120 (40)
[<c0115ba8>] __wake_up+0x48/0x80 (12)
[<c0124027>] run_timer_softirq+0xc7/0x410 (44)
[<c0322935>] schedule+0x85/0x120 (12)
[<c011fccd>] ksoftirqd+0xad/0x110 (28)
[<c011fc20>] ksoftirqd+0x0/0x110 (32)
[<c012fa45>] kthread+0xb5/0xc0 (4)
[<c012f990>] kthread+0x0/0xc0 (24)
[<c0101105>] kernel_thread_helper+0x5/0x10 (16)
radeonfb: Retreived PLL infos from BIOS
I don't have any strange behaviour though.
Cheers,
~ Antonio
John
i found one source of timekeeping bugs on SMP boxes, it's the
non-monotonicity of the TSC:
... time warped from 1270809453 to 1270808096.
... MTSC warped from 0000000a731a8c3c [0] to 0000000a731a899c [2].
... MTSC warped from 0000000a7c93baec [0] to 0000000a7c93b7a8 [3].
... MTSC warped from 0000000a881d6afc [0] to 0000000a881d67d0 [2].
... MTSC warped from 0000000a924217a0 [0] to 0000000a924216ac [3].
... MTSC warped from 0000000a9c592788 [0] to 0000000a9c59232c [2].
... MTSC warped from 0000000aa7aa95c8 [0] to 0000000aa7aa9338 [3].
... MTSC warped from 0000000b33206d60 [0] to 0000000b33206a48 [3].
... time warped from 26699635824 to 26699633144.
... MTSC warped from 00000013f379cb88 [0] to 00000013f379c7e0 [3].
... MTSC warped from 0000001413df8660 [0] to 0000001413df8200 [3].
... MTSC warped from 00000014194f5360 [1] to 00000014194f51b0 [2].
... time warped from 60775269225 to 60775266727.
the number in square brackets is the CPU#. I.e. CPUs on this 4-CPU box
have small TSC differences, which ends up leaking into the generic TOD
code, causing real time warps, which causes ktimer weirdnesses (timers
failed to expire, etc.).
(the above output tracks TSC results globally, under a spinlock. It also
detects time-warps that propagate into the monotonic clock output.)
unfortunately, there's no easy solution for this. We could make
cycle_last per-CPU, but that again brings up the question of how to set
up the per-CPU 'TSC offset' values - those would need similar technique
that the current clear-all-TSCs-on-all-CPUs code does - which as we can
see failed ...
Ingo
On Tue, 25 Oct 2005, Ingo Molnar wrote:
>
> John
>
> i found one source of timekeeping bugs on SMP boxes, it's the
> non-monotonicity of the TSC:
>
> ... time warped from 1270809453 to 1270808096.
> ... MTSC warped from 0000000a731a8c3c [0] to 0000000a731a899c [2].
> ... MTSC warped from 0000000a7c93baec [0] to 0000000a7c93b7a8 [3].
> ... MTSC warped from 0000000a881d6afc [0] to 0000000a881d67d0 [2].
> ... MTSC warped from 0000000a924217a0 [0] to 0000000a924216ac [3].
> ... MTSC warped from 0000000a9c592788 [0] to 0000000a9c59232c [2].
> ... MTSC warped from 0000000aa7aa95c8 [0] to 0000000aa7aa9338 [3].
> ... MTSC warped from 0000000b33206d60 [0] to 0000000b33206a48 [3].
> ... time warped from 26699635824 to 26699633144.
> ... MTSC warped from 00000013f379cb88 [0] to 00000013f379c7e0 [3].
> ... MTSC warped from 0000001413df8660 [0] to 0000001413df8200 [3].
> ... MTSC warped from 00000014194f5360 [1] to 00000014194f51b0 [2].
> ... time warped from 60775269225 to 60775266727.
>
> the number in square brackets is the CPU#. I.e. CPUs on this 4-CPU box
> have small TSC differences, which ends up leaking into the generic TOD
> code, causing real time warps, which causes ktimer weirdnesses (timers
> failed to expire, etc.).
>
> (the above output tracks TSC results globally, under a spinlock. It also
> detects time-warps that propagate into the monotonic clock output.)
>
> unfortunately, there's no easy solution for this. We could make
> cycle_last per-CPU, but that again brings up the question of how to set
> up the per-CPU 'TSC offset' values - those would need similar technique
> that the current clear-all-TSCs-on-all-CPUs code does - which as we can
> see failed ...
>
> Ingo
Anything that uses the CPU clock is going to fail in the long-run.
Many motherboards are now shipped with "spread-spectrum" clocks
that can't be disabled. This means that the frequency will no
longer be constant. This is particularly horrible when some
boards sweep the clock on only one direction!
FYI, the spread-spectrum method of cheating on the FCC part 15
rules will eventually catch up with manufacturers. There has been
about 10 years of idiocy where the observed interference is simply
smeared by the spectrum analyzer filters to seem like it's 20 dB
or so lower than it really is. The increased interference from
electronic equipment that use such fundamental cheating is only
now beginning to be recognized by th FCC. The DOC (Canada) has
been complaining about this for many years.
Maybe the RTC chip should be used as a RTC instead of a gravitational
clamp used once upon startup and once upon shutdown?
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Tue, 2005-10-25 at 17:44 +0200, Ingo Molnar wrote:
> John
>
> i found one source of timekeeping bugs on SMP boxes, it's the
> non-monotonicity of the TSC:
>
> ... time warped from 1270809453 to 1270808096.
> ... MTSC warped from 0000000a731a8c3c [0] to 0000000a731a899c [2].
> ... MTSC warped from 0000000a7c93baec [0] to 0000000a7c93b7a8 [3].
> ... MTSC warped from 0000000a881d6afc [0] to 0000000a881d67d0 [2].
> ... MTSC warped from 0000000a924217a0 [0] to 0000000a924216ac [3].
> ... MTSC warped from 0000000a9c592788 [0] to 0000000a9c59232c [2].
> ... MTSC warped from 0000000aa7aa95c8 [0] to 0000000aa7aa9338 [3].
> ... MTSC warped from 0000000b33206d60 [0] to 0000000b33206a48 [3].
> ... time warped from 26699635824 to 26699633144.
> ... MTSC warped from 00000013f379cb88 [0] to 00000013f379c7e0 [3].
> ... MTSC warped from 0000001413df8660 [0] to 0000001413df8200 [3].
> ... MTSC warped from 00000014194f5360 [1] to 00000014194f51b0 [2].
> ... time warped from 60775269225 to 60775266727.
>
> the number in square brackets is the CPU#. I.e. CPUs on this 4-CPU box
> have small TSC differences, which ends up leaking into the generic TOD
> code, causing real time warps, which causes ktimer weirdnesses (timers
> failed to expire, etc.).
>
> (the above output tracks TSC results globally, under a spinlock. It also
> detects time-warps that propagate into the monotonic clock output.)
>
> unfortunately, there's no easy solution for this. We could make
> cycle_last per-CPU, but that again brings up the question of how to set
> up the per-CPU 'TSC offset' values - those would need similar technique
> that the current clear-all-TSCs-on-all-CPUs code does - which as we can
> see failed ...
I presume there would be no workarounds either in terms of kernel
configuration options, right? I have a bunch of SMP machines waiting for
the right kernel :-)
BTW: perhaps this is what is actually hitting me, I've been running a UP
kernel since yesterday as a test with no problems so far.
-- Fernando
On Tue, 2005-10-25 at 17:44 +0200, Ingo Molnar wrote:
> John
>
> i found one source of timekeeping bugs on SMP boxes, it's the
> non-monotonicity of the TSC:
>
> ... time warped from 1270809453 to 1270808096.
> ... MTSC warped from 0000000a731a8c3c [0] to 0000000a731a899c [2].
> ... MTSC warped from 0000000a7c93baec [0] to 0000000a7c93b7a8 [3].
> ... MTSC warped from 0000000a881d6afc [0] to 0000000a881d67d0 [2].
> ... MTSC warped from 0000000a924217a0 [0] to 0000000a924216ac [3].
> ... MTSC warped from 0000000a9c592788 [0] to 0000000a9c59232c [2].
> ... MTSC warped from 0000000aa7aa95c8 [0] to 0000000aa7aa9338 [3].
> ... MTSC warped from 0000000b33206d60 [0] to 0000000b33206a48 [3].
> ... time warped from 26699635824 to 26699633144.
> ... MTSC warped from 00000013f379cb88 [0] to 00000013f379c7e0 [3].
> ... MTSC warped from 0000001413df8660 [0] to 0000001413df8200 [3].
> ... MTSC warped from 00000014194f5360 [1] to 00000014194f51b0 [2].
> ... time warped from 60775269225 to 60775266727.
>
> the number in square brackets is the CPU#. I.e. CPUs on this 4-CPU box
> have small TSC differences, which ends up leaking into the generic TOD
> code, causing real time warps, which causes ktimer weirdnesses (timers
> failed to expire, etc.).
>
> (the above output tracks TSC results globally, under a spinlock. It also
> detects time-warps that propagate into the monotonic clock output.)
>
> unfortunately, there's no easy solution for this. We could make
> cycle_last per-CPU, but that again brings up the question of how to set
> up the per-CPU 'TSC offset' values - those would need similar technique
> that the current clear-all-TSCs-on-all-CPUs code does - which as we can
> see failed ...
Indeed. This is a nasty issue can affect a number of different systems.
The best solution in my mind is to utilize alternative clocksources when
necessary (one of the main reasons for creating the flexible clocksource
interface: so we can easily use something else).
In my patches, I have a function mark_tsc_unstable(), when called will
drop the tsc's rating value and will cause another clocksource to be
chosen (as long as one is available). Right now we call it when we know
the TSC is going to have problems. But maybe we should be more dynamic
in our detection.
Do you have any details about the hardware? Are the TSCs not being
synced well enough, or are they falling out of sync? i386 is a bit more
aggressive about using the TSC in SMP systems, where x86-64 has more
conditionals. Maybe some of the x86-64 logic should be moved to i386 as
well.
thanks
-john
john stultz wrote:
> On Tue, 2005-10-25 at 17:44 +0200, Ingo Molnar wrote:
>
>>John
>>
>>i found one source of timekeeping bugs on SMP boxes, it's the
>>non-monotonicity of the TSC:
>>
>>... time warped from 1270809453 to 1270808096.
>>... MTSC warped from 0000000a731a8c3c [0] to 0000000a731a899c [2].
>>... MTSC warped from 0000000a7c93baec [0] to 0000000a7c93b7a8 [3].
>>... MTSC warped from 0000000a881d6afc [0] to 0000000a881d67d0 [2].
>>... MTSC warped from 0000000a924217a0 [0] to 0000000a924216ac [3].
>>... MTSC warped from 0000000a9c592788 [0] to 0000000a9c59232c [2].
>>... MTSC warped from 0000000aa7aa95c8 [0] to 0000000aa7aa9338 [3].
>>... MTSC warped from 0000000b33206d60 [0] to 0000000b33206a48 [3].
>>... time warped from 26699635824 to 26699633144.
>>... MTSC warped from 00000013f379cb88 [0] to 00000013f379c7e0 [3].
>>... MTSC warped from 0000001413df8660 [0] to 0000001413df8200 [3].
>>... MTSC warped from 00000014194f5360 [1] to 00000014194f51b0 [2].
>>... time warped from 60775269225 to 60775266727.
>>
>>the number in square brackets is the CPU#. I.e. CPUs on this 4-CPU box
>>have small TSC differences, which ends up leaking into the generic TOD
>>code, causing real time warps, which causes ktimer weirdnesses (timers
>>failed to expire, etc.).
>>
>>(the above output tracks TSC results globally, under a spinlock. It also
>>detects time-warps that propagate into the monotonic clock output.)
>>
>>unfortunately, there's no easy solution for this. We could make
>>cycle_last per-CPU, but that again brings up the question of how to set
>>up the per-CPU 'TSC offset' values - those would need similar technique
>>that the current clear-all-TSCs-on-all-CPUs code does - which as we can
>>see failed ...
>
>
>
> Indeed. This is a nasty issue can affect a number of different systems.
> The best solution in my mind is to utilize alternative clocksources when
> necessary (one of the main reasons for creating the flexible clocksource
> interface: so we can easily use something else).
The TSC is such a fast and, usually, accurate answer, I think it deserves a little effort to save
it. With your new clock code I think we could use per cpu TSC counters, read the full 64 bits and,
in real corner cases, even per cpu conversion "constants" and solve this problem.
George
>
> In my patches, I have a function mark_tsc_unstable(), when called will
> drop the tsc's rating value and will cause another clocksource to be
> chosen (as long as one is available). Right now we call it when we know
> the TSC is going to have problems. But maybe we should be more dynamic
> in our detection.
>
> Do you have any details about the hardware? Are the TSCs not being
> synced well enough, or are they falling out of sync? i386 is a bit more
> aggressive about using the TSC in SMP systems, where x86-64 has more
> conditionals. Maybe some of the x86-64 logic should be moved to i386 as
> well.
>
> thanks
> -john
>
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
* George Anzinger <[email protected]> wrote:
> The TSC is such a fast and, usually, accurate answer, I think it
> deserves a little effort to save it. With your new clock code I think
> we could use per cpu TSC counters, read the full 64 bits and, in real
> corner cases, even per cpu conversion "constants" and solve this
> problem.
the problem is, this is the same issue as 'boot-time TSC syncing', but
in disguise: to get any 'per CPU TSC offset' you need to do exactly the
same type of careful all-CPUs-dance to ensure that the TSCs were sampled
at around the same moment in time!
The box where i have these small TSC inconsistencies shows that it's the
bootup synchronization of TSCs that failed to be 100% accurate. Even a 2
usecs error in synchronization can show up as a time-warp - regardless
of whether we keep per-CPU TSC offsets or whether we clear these offsets
back to 0. So it is not a solution to do another type of synchronization
dance. The only solution is to fix the boot-time synchronization (where
the hardware keeps TSCs synchronized all the time), or to switch TSCs
off where this is not possible.
Ingo
Ingo Molnar wrote:
> * George Anzinger <[email protected]> wrote:
>
>
>>The TSC is such a fast and, usually, accurate answer, I think it
>>deserves a little effort to save it. With your new clock code I think
>>we could use per cpu TSC counters, read the full 64 bits and, in real
>>corner cases, even per cpu conversion "constants" and solve this
>>problem.
>
>
> the problem is, this is the same issue as 'boot-time TSC syncing', but
> in disguise: to get any 'per CPU TSC offset' you need to do exactly the
> same type of careful all-CPUs-dance to ensure that the TSCs were sampled
> at around the same moment in time!
>
> The box where i have these small TSC inconsistencies shows that it's the
> bootup synchronization of TSCs that failed to be 100% accurate. Even a 2
> usecs error in synchronization can show up as a time-warp - regardless
> of whether we keep per-CPU TSC offsets or whether we clear these offsets
> back to 0. So it is not a solution to do another type of synchronization
> dance. The only solution is to fix the boot-time synchronization (where
> the hardware keeps TSCs synchronized all the time), or to switch TSCs
> off where this is not possible.
>
I was rather thinking of only comparing a cup's TSC with the SAME cup's TSC. We only use the TSC to
bridge from the latest update of the the clock to now and when we update the clock we capture (i.e.
update this cup's last TSC value) the TSC on that CPU. If we also capture the system time then we
have a set of (last TSC, sys clock) for each CPU. If we further, keep 64-bits of TSC, we don't
really require each cpu to update the clock very often, or, we could force such and update from time
to time as needed. This would not require the TSC to be synced at all and even if they had
different rates we could add that to the per cpu data and cover that too.
What this does require is that we do a really good job of figuring the TSC multiplier, something we
don't do at all well today (rc5-rt5 on my box is fast by ~15 sec/ day). We might also want to
verify that we are not letting monotonic time be other than monotonic :)
As you might suspect, I have some ideas about how to do a much better job of figuring out the TSC
multiplier.
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
George Anzinger wrote:
> Ingo Molnar wrote:
>
>> * George Anzinger <[email protected]> wrote:
>>
>>
>>> The TSC is such a fast and, usually, accurate answer, I think it
>>> deserves a little effort to save it. With your new clock code I
>>> think we could use per cpu TSC counters, read the full 64 bits and,
>>> in real corner cases, even per cpu conversion "constants" and solve
>>> this problem.
>>
>>
>>
>> the problem is, this is the same issue as 'boot-time TSC syncing', but
>> in disguise: to get any 'per CPU TSC offset' you need to do exactly
>> the same type of careful all-CPUs-dance to ensure that the TSCs were
>> sampled at around the same moment in time!
>>
>> The box where i have these small TSC inconsistencies shows that it's
>> the bootup synchronization of TSCs that failed to be 100% accurate.
>> Even a 2 usecs error in synchronization can show up as a time-warp -
>> regardless of whether we keep per-CPU TSC offsets or whether we clear
>> these offsets back to 0. So it is not a solution to do another type of
>> synchronization dance. The only solution is to fix the boot-time
>> synchronization (where the hardware keeps TSCs synchronized all the
>> time), or to switch TSCs off where this is not possible.
>>
> I was rather thinking of only comparing a cup's TSC with the SAME cup's
> TSC. We only use the TSC to bridge from the latest update of the the
> clock to now and when we update the clock we capture (i.e. update this
> cup's last TSC value) the TSC on that CPU. If we also capture the
> system time then we have a set of (last TSC, sys clock) for each CPU.
> If we further, keep 64-bits of TSC, we don't really require each cpu to
> update the clock very often, or, we could force such and update from
> time to time as needed. This would not require the TSC to be synced at
> all and even if they had different rates we could add that to the per
> cpu data and cover that too.
Well fooie! Still have to get them all in sync. So this does not solve the problem.
>
> What this does require is that we do a really good job of figuring the
> TSC multiplier, something we don't do at all well today (rc5-rt5 on my
> box is fast by ~15 sec/ day). We might also want to verify that we are
> not letting monotonic time be other than monotonic :)
>
> As you might suspect, I have some ideas about how to do a much better
> job of figuring out the TSC multiplier.
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
Hi all,
Just noticed a couple or more of this on dmesg. Maybe its old news and
being discussed already. Otherwise my [email protected]/UP laptop boots and
runs without hicups on 2.6.14-rc5-rt7 (config.gz attached).
... time warped from 13551912584 to 13551905960.
... system time: 13488892865 .. 13488892865.
udevstart/1579[CPU#0]: BUG in get_monotonic_clock_ts at
kernel/time/timeofday.c:
262
[<c0116fcb>] __WARN_ON+0x4f/0x6c (8)
[<c012f8b0>] get_monotonic_clock_ts+0x27a/0x2f0 (40)
[<c0141c9d>] kmem_cache_alloc+0x51/0xac (76)
[<c0114826>] copy_process+0x2ff/0xeed (44)
[<c0139444>] unlock_page+0x17/0x4a (12)
[<c0147a8a>] do_wp_page+0x245/0x372 (20)
[<c01154f5>] do_fork+0x69/0x1b5 (56)
[<c02c120b>] do_page_fault+0x432/0x543 (32)
[<c01017aa>] sys_clone+0x32/0x36 (72)
[<c0102a9b>] sysenter_past_esp+0x54/0x75 (16)
Bye now.
--
rncbc aka Rui Nuno Capela
[email protected]
On Wed, 26 Oct 2005, Rui Nuno Capela wrote:
> Just noticed a couple or more of this on dmesg. Maybe its old news and
> being discussed already. Otherwise my [email protected]/UP laptop boots and
> runs without hicups on 2.6.14-rc5-rt7 (config.gz attached).
>
> ... time warped from 13551912584 to 13551905960.
> ... system time: 13488892865 .. 13488892865.
> udevstart/1579[CPU#0]: BUG in get_monotonic_clock_ts at
> kernel/time/timeofday.c:
> 262
> [<c0116fcb>] __WARN_ON+0x4f/0x6c (8)
> [<c012f8b0>] get_monotonic_clock_ts+0x27a/0x2f0 (40)
> [<c0141c9d>] kmem_cache_alloc+0x51/0xac (76)
> [<c0114826>] copy_process+0x2ff/0xeed (44)
> [<c0139444>] unlock_page+0x17/0x4a (12)
> [<c0147a8a>] do_wp_page+0x245/0x372 (20)
> [<c01154f5>] do_fork+0x69/0x1b5 (56)
> [<c02c120b>] do_page_fault+0x432/0x543 (32)
> [<c01017aa>] sys_clone+0x32/0x36 (72)
> [<c0102a9b>] sysenter_past_esp+0x54/0x75 (16)
I'm getting these with two different machines running 2.6.14-rc5-rt7 with
Steven's ktimer_interrupt() patch from yesterday. Did not see these with
previous -rt kernels. Shutting down NTP makes no difference.
This is from the athlon-xp/via-kt400 box (xeon smt box looks similar):
... time warped from 945167068424 to 945167068179.
... system time: 945133952528 .. 945133952528.
crond/2584[CPU#0]: BUG in get_monotonic_clock_ts at
kernel/time/timeofday.c:262
[<c011befe>] __WARN_ON+0x5e/0xa0 (8)
[<c013610e>] get_monotonic_clock_ts+0x24e/0x2c0 (48)
[<c011953d>] copy_process+0x41d/0xf10 (84)
[<c011600f>] activate_task+0x5f/0x70 (12)
[<c011a12b>] do_fork+0x6b/0x1f0 (68)
[<c0335285>] __schedule+0x365/0x6b0 (24)
[<c0107302>] do_syscall_trace+0x1d2/0x1f0 (32)
[<c01019b2>] sys_clone+0x32/0x40 (28)
[<c0102ddd>] syscall_call+0x7/0xb (16)
... time warped from 6853686562624 to 6853686562329.
... system time: 6853631273662 .. 6853631273662.
top/3207[CPU#0]: BUG in get_monotonic_clock_ts at
kernel/time/timeofday.c:262
[<c011befe>] __WARN_ON+0x5e/0xa0 (8)
[<c013610e>] get_monotonic_clock_ts+0x24e/0x2c0 (48)
[<c0198cde>] uptime_read_proc+0x2e/0xd0 (84)
[<c01411a5>] audit_filter_syscall+0x45/0xd0 (28)
[<c0198cb0>] uptime_read_proc+0x0/0xd0 (20)
[<c0196740>] proc_file_read+0x1a0/0x250 (16)
[<c01965a0>] proc_file_read+0x0/0x250 (48)
[<c0163ce6>] vfs_read+0xb6/0x170 (4)
[<c0164071>] sys_read+0x41/0x70 (24)
[<c0102ddd>] syscall_call+0x7/0xb (28)
... time warped from 8420727047178 to 8420727046873.
... system time: 8420661679983 .. 8420661679983.
wget/3250[CPU#0]: BUG in get_monotonic_clock_ts at
kernel/time/timeofday.c:262
[<c011befe>] __WARN_ON+0x5e/0xa0 (8)
[<c013610e>] get_monotonic_clock_ts+0x24e/0x2c0 (48)
[<c012dcc0>] posix_ktime_get_ts+0x0/0x10 (68)
[<c0133790>] ktimer_get_res+0x0/0x20 (4)
[<c012dcc7>] posix_ktime_get_ts+0x7/0x10 (12)
[<c012ed44>] sys_clock_gettime+0x74/0x90 (4)
[<c0102ddd>] syscall_call+0x7/0xb (20)
( phasex-3174 |#0): new 27 us maximum-latency wakeup.
... time warped from 10109461139641 to 10109461139296.
... system time: 10109399212009 .. 10109399212009.
top/3207[CPU#0]: BUG in get_monotonic_clock_ts at
kernel/time/timeofday.c:262
[<c011befe>] __WARN_ON+0x5e/0xa0 (8)
[<c013610e>] get_monotonic_clock_ts+0x24e/0x2c0 (48)
[<c0198cde>] uptime_read_proc+0x2e/0xd0 (84)
[<c01411a5>] audit_filter_syscall+0x45/0xd0 (28)
[<c0198cb0>] uptime_read_proc+0x0/0xd0 (20)
[<c0196740>] proc_file_read+0x1a0/0x250 (16)
[<c01965a0>] proc_file_read+0x0/0x250 (48)
[<c0163ce6>] vfs_read+0xb6/0x170 (4)
[<c0164071>] sys_read+0x41/0x70 (24)
[<c0102ddd>] syscall_call+0x7/0xb (28)
... time warped from 32482693158437 to 32482693158230.
... system time: 32482660250031 .. 32482660250031.
top/3725[CPU#0]: BUG in get_monotonic_clock_ts at
kernel/time/timeofday.c:262
[<c011befe>] __WARN_ON+0x5e/0xa0 (8)
[<c013610e>] get_monotonic_clock_ts+0x24e/0x2c0 (48)
[<c0198cde>] uptime_read_proc+0x2e/0xd0 (84)
[<c01411a5>] audit_filter_syscall+0x45/0xd0 (28)
[<c0198cb0>] uptime_read_proc+0x0/0xd0 (20)
[<c0196740>] proc_file_read+0x1a0/0x250 (16)
[<c01965a0>] proc_file_read+0x0/0x250 (48)
[<c0163ce6>] vfs_read+0xb6/0x170 (4)
[<c0164071>] sys_read+0x41/0x70 (24)
[<c0102ddd>] syscall_call+0x7/0xb (28)
... time warped from 32716462596526 to 32716462596335.
... system time: 32716439248732 .. 32716439248732.
bash/2994[CPU#0]: BUG in get_monotonic_clock_ts at
kernel/time/timeofday.c:262
[<c011befe>] __WARN_ON+0x5e/0xa0 (8)
[<c013610e>] get_monotonic_clock_ts+0x24e/0x2c0 (48)
[<c011953d>] copy_process+0x41d/0xf10 (84)
[<c013427b>] __init_rt_mutex+0x1b/0x30 (12)
[<c011a12b>] do_fork+0x6b/0x1f0 (68)
[<c0107302>] do_syscall_trace+0x1d2/0x1f0 (56)
[<c01019b2>] sys_clone+0x32/0x40 (28)
[<c0102ddd>] syscall_call+0x7/0xb (16)
... time warped from 35905926422502 to 35905926422326.
... system time: 35905875002399 .. 35905875002399.
0logwatch/3805[CPU#0]: BUG in get_monotonic_clock_ts at
kernel/time/timeofday.c:262
[<c011befe>] __WARN_ON+0x5e/0xa0 (8)
[<c013610e>] get_monotonic_clock_ts+0x24e/0x2c0 (48)
[<c011953d>] copy_process+0x41d/0xf10 (84)
[<c011a12b>] do_fork+0x6b/0x1f0 (80)
[<c0107302>] do_syscall_trace+0x1d2/0x1f0 (56)
[<c01019b2>] sys_clone+0x32/0x40 (28)
[<c0102ddd>] syscall_call+0x7/0xb (16)
... time warped from 35906285042477 to 35906285042296.
... system time: 35906218002396 .. 35906218002396.
sh/4023[CPU#0]: BUG in get_monotonic_clock_ts at
kernel/time/timeofday.c:262
[<c011befe>] __WARN_ON+0x5e/0xa0 (8)
[<c013610e>] get_monotonic_clock_ts+0x24e/0x2c0 (48)
[<c011953d>] copy_process+0x41d/0xf10 (84)
[<c011a12b>] do_fork+0x6b/0x1f0 (80)
[<c0107302>] do_syscall_trace+0x1d2/0x1f0 (56)
[<c01019b2>] sys_clone+0x32/0x40 (28)
[<c0102ddd>] syscall_call+0x7/0xb (16)
... time warped from 35907691480506 to 35907691480313.
... system time: 35907639002385 .. 35907639002385.
sh/4038[CPU#0]: BUG in get_monotonic_clock_ts at
kernel/time/timeofday.c:262
[<c011befe>] __WARN_ON+0x5e/0xa0 (8)
[<c013610e>] get_monotonic_clock_ts+0x24e/0x2c0 (48)
[<c011953d>] copy_process+0x41d/0xf10 (84)
[<c011a12b>] do_fork+0x6b/0x1f0 (80)
[<c0107302>] do_syscall_trace+0x1d2/0x1f0 (56)
[<c01019b2>] sys_clone+0x32/0x40 (28)
[<c0102ddd>] syscall_call+0x7/0xb (16)
... time warped from 35929004908544 to 35929004908333.
... system time: 35928954002217 .. 35928954002217.
makewhatis.cron/4201[CPU#0]: BUG in get_monotonic_clock_ts at
kernel/time/timeofday.c:262
[<c011befe>] __WARN_ON+0x5e/0xa0 (8)
[<c013610e>] get_monotonic_clock_ts+0x24e/0x2c0 (48)
[<c011953d>] copy_process+0x41d/0xf10 (84)
[<c011a12b>] do_fork+0x6b/0x1f0 (80)
[<c0107302>] do_syscall_trace+0x1d2/0x1f0 (56)
[<c01019b2>] sys_clone+0x32/0x40 (28)
[<c0102ddd>] syscall_call+0x7/0xb (16)
--ww
On Wed, 2005-10-26 at 15:07 -0700, William Weston wrote:
> On Wed, 26 Oct 2005, Rui Nuno Capela wrote:
>
> > Just noticed a couple or more of this on dmesg. Maybe its old news and
> > being discussed already. Otherwise my [email protected]/UP laptop boots and
> > runs without hicups on 2.6.14-rc5-rt7 (config.gz attached).
> >
> > ... time warped from 13551912584 to 13551905960.
> > ... system time: 13488892865 .. 13488892865.
> > udevstart/1579[CPU#0]: BUG in get_monotonic_clock_ts at
> > kernel/time/timeofday.c:
> > 262
> > [<c0116fcb>] __WARN_ON+0x4f/0x6c (8)
> > [<c012f8b0>] get_monotonic_clock_ts+0x27a/0x2f0 (40)
> > [<c0141c9d>] kmem_cache_alloc+0x51/0xac (76)
> > [<c0114826>] copy_process+0x2ff/0xeed (44)
> > [<c0139444>] unlock_page+0x17/0x4a (12)
> > [<c0147a8a>] do_wp_page+0x245/0x372 (20)
> > [<c01154f5>] do_fork+0x69/0x1b5 (56)
> > [<c02c120b>] do_page_fault+0x432/0x543 (32)
> > [<c01017aa>] sys_clone+0x32/0x36 (72)
> > [<c0102a9b>] sysenter_past_esp+0x54/0x75 (16)
>
> I'm getting these with two different machines running 2.6.14-rc5-rt7 with
> Steven's ktimer_interrupt() patch from yesterday. Did not see these with
> previous -rt kernels. Shutting down NTP makes no difference.
>
> This is from the athlon-xp/via-kt400 box (xeon smt box looks similar):
I'm grabbing rt7 to try to reproduce this. Not yet sure what the cause
could be. From Rui's dmesg the tsc clocksource was being used, I assume
this is the case with you as well, William?
thanks
-john
On Wed, 26 Oct 2005, john stultz wrote:
> On Wed, 2005-10-26 at 15:07 -0700, William Weston wrote:
> > On Wed, 26 Oct 2005, Rui Nuno Capela wrote:
> >
> > > Just noticed a couple or more of this on dmesg. Maybe its old news and
> > > being discussed already. Otherwise my [email protected]/UP laptop boots and
> > > runs without hicups on 2.6.14-rc5-rt7 (config.gz attached).
> > >
> > > ... time warped from 13551912584 to 13551905960.
> > > ... system time: 13488892865 .. 13488892865.
> > > udevstart/1579[CPU#0]: BUG in get_monotonic_clock_ts at
> > > kernel/time/timeofday.c:
> > > 262
> > > [<c0116fcb>] __WARN_ON+0x4f/0x6c (8)
> > > [<c012f8b0>] get_monotonic_clock_ts+0x27a/0x2f0 (40)
> > > [<c0141c9d>] kmem_cache_alloc+0x51/0xac (76)
> > > [<c0114826>] copy_process+0x2ff/0xeed (44)
> > > [<c0139444>] unlock_page+0x17/0x4a (12)
> > > [<c0147a8a>] do_wp_page+0x245/0x372 (20)
> > > [<c01154f5>] do_fork+0x69/0x1b5 (56)
> > > [<c02c120b>] do_page_fault+0x432/0x543 (32)
> > > [<c01017aa>] sys_clone+0x32/0x36 (72)
> > > [<c0102a9b>] sysenter_past_esp+0x54/0x75 (16)
> >
> > I'm getting these with two different machines running 2.6.14-rc5-rt7 with
> > Steven's ktimer_interrupt() patch from yesterday. Did not see these with
> > previous -rt kernels. Shutting down NTP makes no difference.
> >
> > This is from the athlon-xp/via-kt400 box (xeon smt box looks similar):
>
> I'm grabbing rt7 to try to reproduce this. Not yet sure what the cause
> could be. From Rui's dmesg the tsc clocksource was being used, I assume
> this is the case with you as well, William?
Yes, tsc is used:
Time: tsc clocksource has been installed.
Ktimers: Switched to high resolution mode CPU 0
Full dmesg and config is attached to my previous email. I just built a
debug -rt7 so I can grab some latency traces if need be. Should I try
disabling high res timers?
Cheers,
--ww
On Wed, 2005-10-26 at 15:07 -0700, William Weston wrote:
> On Wed, 26 Oct 2005, Rui Nuno Capela wrote:
>
> > Just noticed a couple or more of this on dmesg. Maybe its old news and
> > being discussed already. Otherwise my [email protected]/UP laptop boots and
> > runs without hicups on 2.6.14-rc5-rt7 (config.gz attached).
> >
> > ... time warped from 13551912584 to 13551905960.
> > ... system time: 13488892865 .. 13488892865.
> > udevstart/1579[CPU#0]: BUG in get_monotonic_clock_ts at
> > kernel/time/timeofday.c:
> > 262
> > [<c0116fcb>] __WARN_ON+0x4f/0x6c (8)
> > [<c012f8b0>] get_monotonic_clock_ts+0x27a/0x2f0 (40)
> > [<c0141c9d>] kmem_cache_alloc+0x51/0xac (76)
> > [<c0114826>] copy_process+0x2ff/0xeed (44)
> > [<c0139444>] unlock_page+0x17/0x4a (12)
> > [<c0147a8a>] do_wp_page+0x245/0x372 (20)
> > [<c01154f5>] do_fork+0x69/0x1b5 (56)
> > [<c02c120b>] do_page_fault+0x432/0x543 (32)
> > [<c01017aa>] sys_clone+0x32/0x36 (72)
> > [<c0102a9b>] sysenter_past_esp+0x54/0x75 (16)
>
> I'm getting these with two different machines running 2.6.14-rc5-rt7 with
> Steven's ktimer_interrupt() patch from yesterday. Did not see these with
> previous -rt kernels. Shutting down NTP makes no difference.
Yeah, that ktimer_interrupt patch was for something completely
different. Is this happening on boot up, or is this consistently
happening?
Also, Rui, do they show up at different times or clustered together?
(William, I see your output is clustered) The reason I asked, is that
the test may produce more than one warning message for the same time
warp. Since the time used to check for the time warp is not updated if
time goes backwards, so if you call the this routine more than once
before the time warp catches back up, it will warn again.
>
> This is from the athlon-xp/via-kt400 box (xeon smt box looks similar):
>
> ... time warped from 945167068424 to 945167068179.
> ... system time: 945133952528 .. 945133952528.
> crond/2584[CPU#0]: BUG in get_monotonic_clock_ts at
> kernel/time/timeofday.c:262
> [<c011befe>] __WARN_ON+0x5e/0xa0 (8)
> [<c013610e>] get_monotonic_clock_ts+0x24e/0x2c0 (48)
> [<c011953d>] copy_process+0x41d/0xf10 (84)
> [<c011600f>] activate_task+0x5f/0x70 (12)
> [<c011a12b>] do_fork+0x6b/0x1f0 (68)
> [<c0335285>] __schedule+0x365/0x6b0 (24)
> [<c0107302>] do_syscall_trace+0x1d2/0x1f0 (32)
> [<c01019b2>] sys_clone+0x32/0x40 (28)
> [<c0102ddd>] syscall_call+0x7/0xb (16)
Is this SMP? And if so, do you get this with UP other than on boot up?
Unfortunately, all my test machines are running other tests that will
take all night to finish, so I can't look into this till tomorrow.
-- Steve
On Wed, 2005-10-26 at 16:33 -0700, john stultz wrote:
> I'm grabbing rt7 to try to reproduce this. Not yet sure what the cause
> could be. From Rui's dmesg the tsc clocksource was being used, I assume
> this is the case with you as well, William?
John (and/or Ingo and Thomas),
Does -rt7 have your latest code?
-- Steve
On Wed, 26 Oct 2005, Steven Rostedt wrote:
> On Wed, 2005-10-26 at 15:07 -0700, William Weston wrote:
>
> > I'm getting these with two different machines running 2.6.14-rc5-rt7 with
> > Steven's ktimer_interrupt() patch from yesterday. Did not see these with
> > previous -rt kernels. Shutting down NTP makes no difference.
>
> Yeah, that ktimer_interrupt patch was for something completely
> different. Is this happening on boot up, or is this consistently
> happening?
Not during boot, but fairly consistent. Usually a cluster of 2 or 3 every
couple of hours.
--ww
On Wed, 2005-10-26 at 19:58 -0400, Steven Rostedt wrote:
> On Wed, 2005-10-26 at 16:33 -0700, john stultz wrote:
>
> > I'm grabbing rt7 to try to reproduce this. Not yet sure what the cause
> > could be. From Rui's dmesg the tsc clocksource was being used, I assume
> > this is the case with you as well, William?
>
> John (and/or Ingo and Thomas),
>
> Does -rt7 have your latest code?
Not quite my latest, but rt7 does have B8 or better.
thanks
-john
On Wed, 26 Oct 2005, john stultz wrote:
> I'm grabbing rt7 to try to reproduce this. Not yet sure what the cause
> could be. From Rui's dmesg the tsc clocksource was being used, I assume
> this is the case with you as well, William?
I found a relatively quick way to trigger the 'time warp' and 'BUG in
get_monotonic_clock_ts' warnings.
while [ 1 ]; do /bin/date > /dev/null; done
I got 1 to 3 warnings a minute (for the first 5 minutes) with a debug -rt7
on the xeon/smt box. ymmv.
--ww
On Wed, 2005-10-26 at 19:57 -0400, Steven Rostedt wrote:
> On Wed, 2005-10-26 at 15:07 -0700, William Weston wrote:
> > On Wed, 26 Oct 2005, Rui Nuno Capela wrote:
> >
> > > Just noticed a couple or more of this on dmesg. Maybe its old news and
> > > being discussed already. Otherwise my [email protected]/UP laptop boots and
> > > runs without hicups on 2.6.14-rc5-rt7 (config.gz attached).
> > >
> > > ... time warped from 13551912584 to 13551905960.
> > > ... system time: 13488892865 .. 13488892865.
> > > udevstart/1579[CPU#0]: BUG in get_monotonic_clock_ts at
> > > kernel/time/timeofday.c:
> > > 262
> > > [<c0116fcb>] __WARN_ON+0x4f/0x6c (8)
> > > [<c012f8b0>] get_monotonic_clock_ts+0x27a/0x2f0 (40)
> > > [<c0141c9d>] kmem_cache_alloc+0x51/0xac (76)
> > > [<c0114826>] copy_process+0x2ff/0xeed (44)
> > > [<c0139444>] unlock_page+0x17/0x4a (12)
> > > [<c0147a8a>] do_wp_page+0x245/0x372 (20)
> > > [<c01154f5>] do_fork+0x69/0x1b5 (56)
> > > [<c02c120b>] do_page_fault+0x432/0x543 (32)
> > > [<c01017aa>] sys_clone+0x32/0x36 (72)
> > > [<c0102a9b>] sysenter_past_esp+0x54/0x75 (16)
> >
> > I'm getting these with two different machines running 2.6.14-rc5-rt7 with
> > Steven's ktimer_interrupt() patch from yesterday. Did not see these with
> > previous -rt kernels. Shutting down NTP makes no difference.
>
> Yeah, that ktimer_interrupt patch was for something completely
> different. Is this happening on boot up, or is this consistently
> happening?
>
> Also, Rui, do they show up at different times or clustered together?
> (William, I see your output is clustered) The reason I asked, is that
> the test may produce more than one warning message for the same time
> warp. Since the time used to check for the time warp is not updated if
> time goes backwards, so if you call the this routine more than once
> before the time warp catches back up, it will warn again.
Ok, I've reproduced the issue.
However, running a clock_gettime(CLOCK_MONOTONIC) inconsistency check
results in no failures, but triggers this code in the kernel.
Looking at the code, these may be false positives. The bit that is
complaining I believe Ingo added to get_monotonic_clock_ts() in
kernel/time/timeofday.c. However I don't see any locking that
serializes the writes the prev in the same order as the
get_monotonic_clock_ts is called.
I'm still digging and will send out some mail when I figure out whats
wrong.
thanks
-john
On Wed, 2005-10-26 at 17:45 -0700, john stultz wrote:
> Ok, I've reproduced the issue.
>
> However, running a clock_gettime(CLOCK_MONOTONIC) inconsistency check
> results in no failures, but triggers this code in the kernel.
>
> Looking at the code, these may be false positives. The bit that is
> complaining I believe Ingo added to get_monotonic_clock_ts() in
> kernel/time/timeofday.c. However I don't see any locking that
> serializes the writes the prev in the same order as the
> get_monotonic_clock_ts is called.
>
> I'm still digging and will send out some mail when I figure out whats
> wrong.
Hmm, I'm wondering if these are a false positive. Being a fully
preemptible kernel, we could be preempted between taking now and getting
prev, so the prev could be updated to a time after now and show a warp.
William and Rui, could you try this patch and see if you still get the
warnings. Although I doubt this is really the problem, since I can't
see how it would cause clusters of these messages.
-- Steve
Index: linux-2.6.14-rc5-rt7/kernel/time/timeofday.c
===================================================================
--- linux-2.6.14-rc5-rt7.orig/kernel/time/timeofday.c 2005-10-26 16:57:03.000000000 -0400
+++ linux-2.6.14-rc5-rt7/kernel/time/timeofday.c 2005-10-26 21:03:22.000000000 -0400
@@ -243,8 +243,8 @@
ns_to_timespec(ts, mc);
- now = timespec_to_ktime(*ts);
prev = per_cpu(prev_mono_time, cpu);
+ now = timespec_to_ktime(*ts);
prev_st = per_cpu(prev_system_time, cpu);
curr_st = system_time;
On Wed, 2005-10-26 at 21:07 -0400, Steven Rostedt wrote:
> On Wed, 2005-10-26 at 17:45 -0700, john stultz wrote:
>
> > Ok, I've reproduced the issue.
> >
> > However, running a clock_gettime(CLOCK_MONOTONIC) inconsistency check
> > results in no failures, but triggers this code in the kernel.
> >
> > Looking at the code, these may be false positives. The bit that is
> > complaining I believe Ingo added to get_monotonic_clock_ts() in
> > kernel/time/timeofday.c. However I don't see any locking that
> > serializes the writes the prev in the same order as the
> > get_monotonic_clock_ts is called.
> >
> > I'm still digging and will send out some mail when I figure out whats
> > wrong.
>
> Hmm, I'm wondering if these are a false positive. Being a fully
> preemptible kernel, we could be preempted between taking now and getting
> prev, so the prev could be updated to a time after now and show a warp.
>
> William and Rui, could you try this patch and see if you still get the
> warnings. Although I doubt this is really the problem, since I can't
> see how it would cause clusters of these messages.
I don't know if that would really fix it, because ideally you want to
read the prev_mono_time at the same point you calculate the time inside
the read lock'ed critical section.
The difficulty is then even if you do read the prev value in a
serialized manner, you have to serialize the writes properly as well. So
really you want to do all four operations (read prev, calculate time, do
comparision, write prev) under a write lock.
Again, I'm not totally sure about this, but even removing the part where
it overwrites the ts pointer w/ the prev time, I do not see
inconsistencies from userland.
Also I'm not seeing clusters of messages. If you call
clock_gettime(CLOCK_MONOTONIC,..) in a loop, you'll see tons of these
message.
The only odd part is the regularness of the errors. I'm seeing the ~5000
ns deltas ~every ms. So there may be something going wrong, but I don't
see it yet.
thanks
-john
On Wed, 2005-10-26 at 21:07 -0400, Steven Rostedt wrote:
> Index: linux-2.6.14-rc5-rt7/kernel/time/timeofday.c
> ===================================================================
> --- linux-2.6.14-rc5-rt7.orig/kernel/time/timeofday.c 2005-10-26 16:57:03.000000000 -0400
> +++ linux-2.6.14-rc5-rt7/kernel/time/timeofday.c 2005-10-26 21:03:22.000000000 -0400
> @@ -243,8 +243,8 @@
>
> ns_to_timespec(ts, mc);
>
> - now = timespec_to_ktime(*ts);
> prev = per_cpu(prev_mono_time, cpu);
> + now = timespec_to_ktime(*ts);
>
> prev_st = per_cpu(prev_system_time, cpu);
> curr_st = system_time;
>
Silly me! I was thinking the "now = timespec_to_ktime(*ts)" was where
the time was taken.
Try this patch instead!
-- Steve
Index: linux-2.6.14-rc5-rt7/kernel/time/timeofday.c
===================================================================
--- linux-2.6.14-rc5-rt7.orig/kernel/time/timeofday.c 2005-10-26 16:57:03.000000000 -0400
+++ linux-2.6.14-rc5-rt7/kernel/time/timeofday.c 2005-10-26 21:23:05.000000000 -0400
@@ -233,6 +233,9 @@
ktime_t prev, now;
nsec_t mc, prev_st, curr_st;
+ prev = per_cpu(prev_mono_time, cpu);
+ prev_st = per_cpu(prev_system_time, cpu);
+
/* atomically read __get_monotonic_clock_ns() */
do {
seq = read_seqbegin(&system_time_lock);
@@ -242,11 +245,7 @@
} while (read_seqretry(&system_time_lock, seq));
ns_to_timespec(ts, mc);
-
now = timespec_to_ktime(*ts);
- prev = per_cpu(prev_mono_time, cpu);
-
- prev_st = per_cpu(prev_system_time, cpu);
curr_st = system_time;
if (ktime_cmp(now, <, prev)) {
On Wed, 2005-10-26 at 18:22 -0700, john stultz wrote:
>
> I don't know if that would really fix it, because ideally you want to
> read the prev_mono_time at the same point you calculate the time inside
> the read lock'ed critical section.
Ideally yes, but this is just for debugging, so as long as prev is read
before now, this should prevent false positives due to ordering. But
I'm not sure if my patch did anything regardless, since the
prev_mono_time is a cpu variable, and the get_cpu and put_cpu implement
a preempt_disable, so unless an interrupt is changing it, it should be
OK.
-- Steve
On Wed, 2005-10-26 at 21:37 -0400, Steven Rostedt wrote:
> On Wed, 2005-10-26 at 18:22 -0700, john stultz wrote:
>
> >
> > I don't know if that would really fix it, because ideally you want to
> > read the prev_mono_time at the same point you calculate the time inside
> > the read lock'ed critical section.
>
> Ideally yes, but this is just for debugging, so as long as prev is read
> before now, this should prevent false positives due to ordering.
Ah, you're right, good point! I was being overly paranoid.
So as long as the writing of the 64bit value is atomic (which it isn't,
but that can be fixed) there shouldn't be ordering problems w/ your
patch.
And sure enough, it seems to take care of the warnings on my box.
Great debugging job!
-john
On Wed, 2005-10-26 at 18:52 -0700, john stultz wrote:
> On Wed, 2005-10-26 at 21:37 -0400, Steven Rostedt wrote:
> > On Wed, 2005-10-26 at 18:22 -0700, john stultz wrote:
> >
> > >
> > > I don't know if that would really fix it, because ideally you want to
> > > read the prev_mono_time at the same point you calculate the time inside
> > > the read lock'ed critical section.
> >
> > Ideally yes, but this is just for debugging, so as long as prev is read
> > before now, this should prevent false positives due to ordering.
>
> Ah, you're right, good point! I was being overly paranoid.
>
> So as long as the writing of the 64bit value is atomic (which it isn't,
> but that can be fixed) there shouldn't be ordering problems w/ your
> patch.
Turning off IRQs should be good enough.
>
> And sure enough, it seems to take care of the warnings on my box.
So I guess interrupts do call this. :-)
Thanks,
-- Steve
Here's a updated patch.
Index: linux-2.6.14-rc5-rt7/kernel/time/timeofday.c
===================================================================
--- linux-2.6.14-rc5-rt7.orig/kernel/time/timeofday.c 2005-10-26 16:57:03.000000000 -0400
+++ linux-2.6.14-rc5-rt7/kernel/time/timeofday.c 2005-10-26 22:10:32.000000000 -0400
@@ -232,6 +232,12 @@
unsigned long seq;
ktime_t prev, now;
nsec_t mc, prev_st, curr_st;
+ unsigned long flags;
+
+ raw_local_irq_save(flags);
+ prev = per_cpu(prev_mono_time, cpu);
+ prev_st = per_cpu(prev_system_time, cpu);
+ raw_local_irq_restore(flags);
/* atomically read __get_monotonic_clock_ns() */
do {
@@ -242,11 +248,7 @@
} while (read_seqretry(&system_time_lock, seq));
ns_to_timespec(ts, mc);
-
now = timespec_to_ktime(*ts);
- prev = per_cpu(prev_mono_time, cpu);
-
- prev_st = per_cpu(prev_system_time, cpu);
curr_st = system_time;
if (ktime_cmp(now, <, prev)) {
@@ -264,8 +266,12 @@
ktime_to_timespec(ts, prev);
return;
}
+
+ raw_local_irq_save(flags);
per_cpu(prev_mono_time, cpu) = now;
per_cpu(prev_system_time, cpu) = system_time;
+ raw_local_irq_restore(flags);
+
put_cpu();
}
Steven Rostedt wrote:
>
>>On Wed, 26 Oct 2005, Rui Nuno Capela wrote:
>>
>>
>>>Just noticed a couple or more of this on dmesg. Maybe its old news and
>>>being discussed already. Otherwise my [email protected]/UP laptop boots and
>>>runs without hicups on 2.6.14-rc5-rt7 (config.gz attached).
>>>
>>>... time warped from 13551912584 to 13551905960.
>>>... system time: 13488892865 .. 13488892865.
>>>udevstart/1579[CPU#0]: BUG in get_monotonic_clock_ts at
>>>kernel/time/timeofday.c:
>>>262
>>> [<c0116fcb>] __WARN_ON+0x4f/0x6c (8)
>>> [<c012f8b0>] get_monotonic_clock_ts+0x27a/0x2f0 (40)
>>> [<c0141c9d>] kmem_cache_alloc+0x51/0xac (76)
>>> [<c0114826>] copy_process+0x2ff/0xeed (44)
>>> [<c0139444>] unlock_page+0x17/0x4a (12)
>>> [<c0147a8a>] do_wp_page+0x245/0x372 (20)
>>> [<c01154f5>] do_fork+0x69/0x1b5 (56)
>>> [<c02c120b>] do_page_fault+0x432/0x543 (32)
>>> [<c01017aa>] sys_clone+0x32/0x36 (72)
>>> [<c0102a9b>] sysenter_past_esp+0x54/0x75 (16)
>>
>>[...]
>
> Also, Rui, do they show up at different times or clustered together?
> (William, I see your output is clustered) The reason I asked, is that
> the test may produce more than one warning message for the same time
> warp. Since the time used to check for the time warp is not updated if
> time goes backwards, so if you call the this routine more than once
> before the time warp catches back up, it will warn again.
>
Don't really know if its consistent, but it does occur on several times,
on only on boot.
Sorry for the delay.
--
rncbc aka Rui Nuno Capela
[email protected]
On Thu, 2005-10-27 at 09:01 +0100, Rui Nuno Capela wrote:
>
> Don't really know if its consistent, but it does occur on several times,
> on only on boot.
Rui,
Have you tried the last patch that I sent John? It may just be a race
condition in the checking that causes a false positive. My last patch
fixes that.
-- Steve
On Wed, 26 Oct 2005, Steven Rostedt wrote:
> Here's a updated patch.
>
> Index: linux-2.6.14-rc5-rt7/kernel/time/timeofday.c
> ===================================================================
> --- linux-2.6.14-rc5-rt7.orig/kernel/time/timeofday.c 2005-10-26 16:57:03.000000000 -0400
> +++ linux-2.6.14-rc5-rt7/kernel/time/timeofday.c 2005-10-26 22:10:32.000000000 -0400
> @@ -232,6 +232,12 @@
> unsigned long seq;
> ktime_t prev, now;
> nsec_t mc, prev_st, curr_st;
> + unsigned long flags;
> +
> + raw_local_irq_save(flags);
> + prev = per_cpu(prev_mono_time, cpu);
> + prev_st = per_cpu(prev_system_time, cpu);
> + raw_local_irq_restore(flags);
>
> /* atomically read __get_monotonic_clock_ns() */
> do {
> @@ -242,11 +248,7 @@
> } while (read_seqretry(&system_time_lock, seq));
>
> ns_to_timespec(ts, mc);
> -
> now = timespec_to_ktime(*ts);
> - prev = per_cpu(prev_mono_time, cpu);
> -
> - prev_st = per_cpu(prev_system_time, cpu);
> curr_st = system_time;
>
> if (ktime_cmp(now, <, prev)) {
> @@ -264,8 +266,12 @@
> ktime_to_timespec(ts, prev);
> return;
> }
> +
> + raw_local_irq_save(flags);
> per_cpu(prev_mono_time, cpu) = now;
> per_cpu(prev_system_time, cpu) = system_time;
> + raw_local_irq_restore(flags);
> +
> put_cpu();
> }
Hi Steven. I think you fixed it!
The xeon-smt box has been up for over 30 minutes with this patch, and no
warnings as of yet. Also, 'rtc_wakeup -f 1024' is reporting a max jitter
of 131us (decent for this box considering its hardware induced latencies)
instead of the >500us jitter seen earlier.
I'll try the patch out on the athlon box (which does mostly audio/midi)
when I get home.
--ww
On Thu, 2005-10-27 at 15:01 -0700, William Weston wrote:
> Hi Steven. I think you fixed it!
>
> The xeon-smt box has been up for over 30 minutes with this patch, and no
> warnings as of yet. Also, 'rtc_wakeup -f 1024' is reporting a max jitter
> of 131us (decent for this box considering its hardware induced latencies)
> instead of the >500us jitter seen earlier.
>
> I'll try the patch out on the athlon box (which does mostly audio/midi)
> when I get home.
Yeah, I finally got a machine available that I could run Ingo's RT patch
on. And with out this fix, I get the warning messages with the
following program, and with the fix I don't. So I guess that solves it.
-- Steve
#include <stdio.h>
#include <time.h>
/* I'm sure there's a compare for this, but I was to lazy to look */
static inline int comparets(struct timespec *a, struct timespec *b)
{
return (a->tv_sec < b->tv_sec) ? -1 :
(a->tv_sec > b->tv_sec) ? 1 :
(a->tv_nsec < b->tv_nsec) ? -1 :
(a->tv_nsec > b->tv_nsec) ? 1 :
0;
}
int main(int argc, char **argv)
{
struct timespec ts, oldts;
int i;
clock_gettime(CLOCK_MONOTONIC, &oldts);
for (i=0; i < 1000000; i++) {
clock_gettime(CLOCK_MONOTONIC, &ts);
if (comparets(&ts,&oldts) < 0) {
printf("time went backwards from %ld.%09ld to %ld.%09ld\n",
oldts.tv_sec, oldts.tv_nsec,
ts.tv_sec, ts.tv_nsec);
}
oldts = ts;
}
return 0;
}
Steven Rostedt wrote:
> On Thu, 2005-10-27 at 09:01 +0100, Rui Nuno Capela wrote:
>
>
>>Don't really know if its consistent, but it does occur on several times,
>>on only on boot.
>
>
> Rui,
>
> Have you tried the last patch that I sent John? It may just be a race
> condition in the checking that causes a false positive. My last patch
> fixes that.
>
> -- Steve
>
So far so good.
Tks.
--
rncbc aka Rui Nuno Capela
[email protected]
On Thu, 2005-10-27 at 13:44 -0400, Steven Rostedt wrote:
> On Thu, 2005-10-27 at 09:01 +0100, Rui Nuno Capela wrote:
>
> >
> > Don't really know if its consistent, but it does occur on several times,
> > on only on boot.
>
> Rui,
>
> Have you tried the last patch that I sent John? It may just be a race
> condition in the checking that causes a false positive. My last patch
> fixes that.
I booted into rc5-rt7 SMP with your patch yesterday and the machine is
still up, which is something :-) No time warp debug messages so far.
When I logged in today Nautilus died on login. Never happened before.
Logged out, logged in again and it was fine. Now it looks like things
are "stable" but this happened while Evolution was reading email after
logging in. Running this:
#!/bin/bash
while true ; do
echo "--- `date`">>time
START=`date +"%s"`
strace -o timelog sleep 10
RES=$?
if [ "$?" -ne "0" ] ; then
echo "Error $RES" >>time
exit
fi
if grep -q 516 timelog &>/dev/null ; then
echo "Found 516 in timelog!" >>time
exit
fi
END=`date +"%s"`
let DIFF=END-START
echo "$DIFF" >>time
echo "---" >>time
done
Got this:
--- Fri Oct 28 09:40:47 PDT 2005
10
---
--- Fri Oct 28 09:40:57 PDT 2005
10
---
--- Fri Oct 28 09:41:07 PDT 2005
10
---
--- Fri Oct 28 09:41:17 PDT 2005
10
---
--- Fri Oct 28 09:41:27 PDT 2005
33
---
--- Fri Oct 28 09:42:00 PDT 2005
10
---
--- Fri Oct 28 09:42:10 PDT 2005
16
---
--- Fri Oct 28 09:42:26 PDT 2005
12
---
--- Fri Oct 28 09:42:38 PDT 2005
10
---
--- Fri Oct 28 09:42:49 PDT 2005
10
---
--- Fri Oct 28 09:42:59 PDT 2005
11
---
--- Fri Oct 28 09:43:10 PDT 2005
11
---
--- Fri Oct 28 09:43:21 PDT 2005
10
---
--- Fri Oct 28 09:43:31 PDT 2005
10
---
--- Fri Oct 28 09:43:41 PDT 2005
10
---
--- Fri Oct 28 09:43:51 PDT 2005
10
---
--- Fri Oct 28 09:44:01 PDT 2005
11
---
--- Fri Oct 28 09:44:12 PDT 2005
10
---
--- Fri Oct 28 09:44:22 PDT 2005
11
---
--- Fri Oct 28 09:44:33 PDT 2005
10
---
--- Fri Oct 28 09:44:43 PDT 2005
10
---
--- Fri Oct 28 09:44:53 PDT 2005
10
---
--- Fri Oct 28 09:45:03 PDT 2005
12
---
--- Fri Oct 28 09:45:15 PDT 2005
10
---
--- Fri Oct 28 09:45:25 PDT 2005
10
---
--- Fri Oct 28 09:45:35 PDT 2005
10
---
--- Fri Oct 28 09:45:45 PDT 2005
10
---
So, it appears I'm not getting short timeouts as I did before but some
of them are too long.
After the initial startup it looks like now this is not happening again,
at most I'm getting "11" instead of "10".
The Jack warnings about late interrupts have returned...
-- Fernando
i have released the 2.6.14-rt1 tree, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
this release is mainly about ktimer fixes: it updates to the latest
ktimer tree from Thomas Gleixner (which includes John Stultz's latest
GTOD tree), it fixes TSC synchronization problems on HT systems, and
updates the ktimers debugging code.
These together could fix most of the timer warnings and annoyances
reported for 2.6.14-rc5-rt kernels. In particular the new
TSC-synchronization code could fix SMP systems: the upstream TSC
synchronization method is fine for 1 usec resolution, but it was not
good enough for 1 nsec resolution and likely caused the SMP bugs
reported by Fernando Lopez-Lezcano and Rui Nuno Capela.
Please re-report any bugs that remain.
Changes since 2.6.14-rc5-rt1:
- GTOD -B9 (John Stultz)
- ktimer updates (Thomas Gleixner, me)
- ktimer debugging check fixes (Steven Rostedt)
- smarter TSC synchronization on SMP - we now rely on it for nsecs (me)
- x64 build fix (reported by Mark Knecht)
- tracing fix (reported by Florian Schmidt)
- rtc histogram fixes (K.R. Foley)
- merge to 2.6.14
to build a 2.6.14-rt1 tree, the following patches should be applied:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.tar.bz2
http://redhat.com/~mingo/realtime-preempt/patch-2.6.14-rt1
Ingo
Ingo Molnar wrote:
> i have released the 2.6.14-rt1 tree, which can be downloaded from the
> usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> this release is mainly about ktimer fixes: it updates to the latest
> ktimer tree from Thomas Gleixner (which includes John Stultz's latest
> GTOD tree), it fixes TSC synchronization problems on HT systems, and
> updates the ktimers debugging code.
>
> These together could fix most of the timer warnings and annoyances
> reported for 2.6.14-rc5-rt kernels. In particular the new
> TSC-synchronization code could fix SMP systems: the upstream TSC
> synchronization method is fine for 1 usec resolution, but it was not
> good enough for 1 nsec resolution and likely caused the SMP bugs
> reported by Fernando Lopez-Lezcano and Rui Nuno Capela.
>
> Please re-report any bugs that remain.
>
> Changes since 2.6.14-rc5-rt1:
>
> - GTOD -B9 (John Stultz)
>
> - ktimer updates (Thomas Gleixner, me)
>
> - ktimer debugging check fixes (Steven Rostedt)
>
> - smarter TSC synchronization on SMP - we now rely on it for nsecs (me)
>
> - x64 build fix (reported by Mark Knecht)
>
> - tracing fix (reported by Florian Schmidt)
>
> - rtc histogram fixes (K.R. Foley)
Actually it doesn't look like these made it into the patch. :)
>
> - merge to 2.6.14
>
> to build a 2.6.14-rt1 tree, the following patches should be applied:
>
> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.tar.bz2
> http://redhat.com/~mingo/realtime-preempt/patch-2.6.14-rt1
>
> Ingo
>
--
kr
On Sun, 30 Oct 2005, K.R. Foley wrote:
> Ingo Molnar wrote:
> >
> > Please re-report any bugs that remain.
> >
> > Changes since 2.6.14-rc5-rt1:
> >
> > - GTOD -B9 (John Stultz)
> >
> > - ktimer updates (Thomas Gleixner, me)
> >
> > - ktimer debugging check fixes (Steven Rostedt)
> >
> > - smarter TSC synchronization on SMP - we now rely on it for nsecs (me)
> >
> > - x64 build fix (reported by Mark Knecht)
> >
> > - tracing fix (reported by Florian Schmidt)
> >
> > - rtc histogram fixes (K.R. Foley)
>
> Actually it doesn't look like these made it into the patch. :)
Yeah, I noticed that there isn't even a check anymore in
get_monotonic_clock_ts for time warping backwards. I guess John's new
updates and Ingo's "smarter" code makes it unnecessary ;-)
Still, thanks for the credit Ingo!
-- Steve
>
> >
> > - merge to 2.6.14
> >
On 10/30/05, Ingo Molnar <[email protected]> wrote:
>
> i have released the 2.6.14-rt1 tree, which can be downloaded from the
> usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> this release is mainly about ktimer fixes: it updates to the latest
> ktimer tree from Thomas Gleixner (which includes John Stultz's latest
> GTOD tree), it fixes TSC synchronization problems on HT systems, and
> updates the ktimers debugging code.
>
> These together could fix most of the timer warnings and annoyances
> reported for 2.6.14-rc5-rt kernels. In particular the new
> TSC-synchronization code could fix SMP systems: the upstream TSC
> synchronization method is fine for 1 usec resolution, but it was not
> good enough for 1 nsec resolution and likely caused the SMP bugs
> reported by Fernando Lopez-Lezcano and Rui Nuno Capela.
>
> Please re-report any bugs that remain.
>
> Changes since 2.6.14-rc5-rt1:
>
> - GTOD -B9 (John Stultz)
>
> - ktimer updates (Thomas Gleixner, me)
I am no longer seeing any ktimer messages in dmesg after booting. So
far so good.
>
> - ktimer debugging check fixes (Steven Rostedt)
>
> - smarter TSC synchronization on SMP - we now rely on it for nsecs (me)
>
> - x64 build fix (reported by Mark Knecht)
Thanks Ingo. This seems fixed. 2.6.14-rt1 up and running here.
>
> - tracing fix (reported by Florian Schmidt)
>
> - rtc histogram fixes (K.R. Foley)
>
> - merge to 2.6.14
>
> to build a 2.6.14-rt1 tree, the following patches should be applied:
>
> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.tar.bz2
> http://redhat.com/~mingo/realtime-preempt/patch-2.6.14-rt1
>
> Ingo
>
Cheers,
Mark
* Steven Rostedt <[email protected]> wrote:
> > > - tracing fix (reported by Florian Schmidt)
> > >
> > > - rtc histogram fixes (K.R. Foley)
> >
> > Actually it doesn't look like these made it into the patch. :)
>
> Yeah, I noticed that there isn't even a check anymore in
> get_monotonic_clock_ts for time warping backwards. I guess John's new
> updates and Ingo's "smarter" code makes it unnecessary ;-)
well, the nsec_offset check was bogus (since it was relative to the last
tick) - but still your fundamental fix for disabling interrupts is
present, via the tsc_lock. I have moved the remaining checks to
__get_nsec_offset(), so they are still there.
Ingo
* K.R. Foley <[email protected]> wrote:
> > - rtc histogram fixes (K.R. Foley)
>
> Actually it doesn't look like these made it into the patch. :)
they were there, but they apparently went missing during a rebase. I've
re-added them and they should show up in -rt2.
Ingo
On Sun, 2005-10-30 at 14:33 +0100, Ingo Molnar wrote:
> i have released the 2.6.14-rt1 tree, which can be downloaded from the
> usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> this release is mainly about ktimer fixes: it updates to the latest
> ktimer tree from Thomas Gleixner (which includes John Stultz's latest
> GTOD tree), it fixes TSC synchronization problems on HT systems, and
> updates the ktimers debugging code.
>
> These together could fix most of the timer warnings and annoyances
> reported for 2.6.14-rc5-rt kernels. In particular the new
> TSC-synchronization code could fix SMP systems: the upstream TSC
> synchronization method is fine for 1 usec resolution, but it was not
> good enough for 1 nsec resolution and likely caused the SMP bugs
> reported by Fernando Lopez-Lezcano and Rui Nuno Capela.
I just booted into 2.6.14-rt1 (SMP, no HIGH_REG_TIMERS) and got these:
... ITSC warped from 000000622fc9fbbf [0] to 000000622fc87638 [1].
softirq-timer/1/13[CPU#1]: BUG in __get_nsec_offset at
kernel/time/timeofday.c:181
[<c0128167>] __WARN_ON+0x67/0x90 (8)
[<c0143d16>] get_realtime_clock+0x266/0x2d0 (48)
[<c014104f>] ktimer_run_queues+0x2f/0x130 (96)
[<c01317ee>] run_timer_softirq+0xde/0x380 (48)
[<c03750b5>] schedule+0x85/0x100 (24)
[<c012d588>] ksoftirqd+0x118/0x1e0 (28)
[<c012d470>] ksoftirqd+0x0/0x1e0 (44)
[<c013d31c>] kthread+0xac/0xb0 (4)
[<c013d270>] kthread+0x0/0xb0 (12)
[<c0101545>] kernel_thread_helper+0x5/0x10 (16)
... ITSC warped from 00000064bbf83c4f [0] to 00000064bbf216ec [1].
softirq-timer/1/13[CPU#1]: BUG in __get_nsec_offset at
kernel/time/timeofday.c:181
[<c0128167>] __WARN_ON+0x67/0x90 (8)
[<c0143d16>] get_realtime_clock+0x266/0x2d0 (48)
[<c014104f>] ktimer_run_queues+0x2f/0x130 (96)
[<c01317ee>] run_timer_softirq+0xde/0x380 (48)
[<c03750b5>] schedule+0x85/0x100 (24)
[<c012d588>] ksoftirqd+0x118/0x1e0 (28)
[<c012d470>] ksoftirqd+0x0/0x1e0 (44)
[<c013d31c>] kthread+0xac/0xb0 (4)
[<c013d270>] kthread+0x0/0xb0 (12)
[<c0101545>] kernel_thread_helper+0x5/0x10 (16)
... ITSC warped from 0000006748267cdf [0] to 00000067481d6636 [1].
softirq-timer/1/13[CPU#1]: BUG in __get_nsec_offset at
kernel/time/timeofday.c:181
[<c0128167>] __WARN_ON+0x67/0x90 (8)
[<c0143d16>] get_realtime_clock+0x266/0x2d0 (48)
[<c014104f>] ktimer_run_queues+0x2f/0x130 (96)
[<c01317ee>] run_timer_softirq+0xde/0x380 (48)
[<c03750b5>] schedule+0x85/0x100 (24)
[<c012d588>] ksoftirqd+0x118/0x1e0 (28)
[<c012d470>] ksoftirqd+0x0/0x1e0 (44)
[<c013d31c>] kthread+0xac/0xb0 (4)
[<c013d270>] kthread+0x0/0xb0 (12)
[<c0101545>] kernel_thread_helper+0x5/0x10 (16)
... ITSC warped from 00000069d454bd6f [0] to 00000069d44857fc [1].
softirq-timer/1/13[CPU#1]: BUG in __get_nsec_offset at
kernel/time/timeofday.c:181
[<c0128167>] __WARN_ON+0x67/0x90 (8)
[<c0143d16>] get_realtime_clock+0x266/0x2d0 (48)
[<c014104f>] ktimer_run_queues+0x2f/0x130 (96)
[<c01317ee>] run_timer_softirq+0xde/0x380 (48)
[<c03750b5>] schedule+0x85/0x100 (24)
[<c012d588>] ksoftirqd+0x118/0x1e0 (28)
[<c012d470>] ksoftirqd+0x0/0x1e0 (44)
[<c013d31c>] kthread+0xac/0xb0 (4)
[<c013d270>] kthread+0x0/0xb0 (12)
[<c0101545>] kernel_thread_helper+0x5/0x10 (16)
... ITSC warped from 00000069d454bd6f [1] to 00000069d4515d11 [1].
softirq-timer/1/13[CPU#1]: BUG in __get_nsec_offset at
kernel/time/timeofday.c:181
[<c0128167>] __WARN_ON+0x67/0x90 (8)
[<c01436e6>] get_monotonic_clock+0x246/0x2b0 (48)
[<c014104f>] ktimer_run_queues+0x2f/0x130 (96)
[<c01317ee>] run_timer_softirq+0xde/0x380 (48)
[<c03750b5>] schedule+0x85/0x100 (24)
[<c012d588>] ksoftirqd+0x118/0x1e0 (28)
[<c012d470>] ksoftirqd+0x0/0x1e0 (44)
[<c013d31c>] kthread+0xac/0xb0 (4)
[<c013d270>] kthread+0x0/0xb0 (12)
[<c0101545>] kernel_thread_helper+0x5/0x10 (16)
-- Fernando
On Sun, 2005-10-30 at 14:33 +0100, Ingo Molnar wrote:
> i have released the 2.6.14-rt1 tree, which can be downloaded from the
> usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> this release is mainly about ktimer fixes: it updates to the latest
> ktimer tree from Thomas Gleixner (which includes John Stultz's latest
> GTOD tree), it fixes TSC synchronization problems on HT systems, and
> updates the ktimers debugging code.
>
> These together could fix most of the timer warnings and annoyances
> reported for 2.6.14-rc5-rt kernels. In particular the new
> TSC-synchronization code could fix SMP systems: the upstream TSC
> synchronization method is fine for 1 usec resolution, but it was not
> good enough for 1 nsec resolution and likely caused the SMP bugs
> reported by Fernando Lopez-Lezcano and Rui Nuno Capela.
>
> Please re-report any bugs that remain.
2.6.14-rt2 seems to be running fine on my athlon x2 smp system. Apart
from some time warp messages when starting up it looks fine so far (this
is on fc4).
The same kernel built for fc3 fails to boot in my Sony laptop. I see
this:
Kernel panic - not syncing: Attempted to kill init!
... then it sits there for some time, no traceback or anything and
then...
<3>BUG: init:1, possible softlockup detected on CPU#0
[<c0148760>] softlockup_detected+0x30/0x40 (8)
[] softlockup_tick+0xa0/0xb0 (20)
[] update_process_times+0x62/0x70 (8)
[] timer_interrupt+0x3b/0x70 (8)
[] handle_IRQ_event+0x56/0xd0 (12)
[] handle_IRQ_event+0x56/0xd0 (4)
[] printk+0x17/0x20 (8)
[] __do_IRQ+0x9e/0x140 (36)
[] do_IRQ+0x34/0x70 (32)
[] do_IRQ+0x34/0x70 (4)
[] common_interrupt+0x1a/0x20 (16)
[] __delay+0x20/0x30 (44)
[] panic+0xe5/0xf0 (12)
[] do_exit+0x3d1/0x400 (16)
[] vfs_write+0x133/0x180 (20)
[] do_group_exit+0x35/0xc0 (20)
[] sys_write+0x41/0x70 (4)
[] sysenter_past_esp+0x54/0x75 (28)
This message keeps repeating at regular intervals. Subsequent prints
don't start with the "<3>".
There could be typos and I ommited beginning addresses to save time,
copied directly from my laptop screen.
-- Fernando
On Tue, 2005-11-01 at 12:18 -0800, Fernando Lopez-Lezcano wrote:
> On Sun, 2005-10-30 at 14:33 +0100, Ingo Molnar wrote:
> > i have released the 2.6.14-rt1 tree, which can be downloaded from the
> > usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
> > this release is mainly about ktimer fixes: it updates to the latest
> > ktimer tree from Thomas Gleixner (which includes John Stultz's latest
> > GTOD tree), it fixes TSC synchronization problems on HT systems, and
> > updates the ktimers debugging code.
> >
> > These together could fix most of the timer warnings and annoyances
> > reported for 2.6.14-rc5-rt kernels. In particular the new
> > TSC-synchronization code could fix SMP systems: the upstream TSC
> > synchronization method is fine for 1 usec resolution, but it was not
> > good enough for 1 nsec resolution and likely caused the SMP bugs
> > reported by Fernando Lopez-Lezcano and Rui Nuno Capela.
> >
> > Please re-report any bugs that remain.
>
> 2.6.14-rt2 seems to be running fine on my athlon x2 smp system. Apart
> from some time warp messages when starting up it looks fine so far (this
> is on fc4).
Actually, after enough time logged in (or maybe just with the kernel
running without a reboot) I still get the usual Jack warnings:
delay of 5469.000 usecs exceeds estimated spare time of 2641.000;
restart ...
-- Fernando
On 11/1/05, Fernando Lopez-Lezcano <[email protected]> wrote:
> On Tue, 2005-11-01 at 12:18 -0800, Fernando Lopez-Lezcano wrote:
> > On Sun, 2005-10-30 at 14:33 +0100, Ingo Molnar wrote:
> > > i have released the 2.6.14-rt1 tree, which can be downloaded from the
> > > usual place:
> > >
> > > http://redhat.com/~mingo/realtime-preempt/
> > >
> > > this release is mainly about ktimer fixes: it updates to the latest
> > > ktimer tree from Thomas Gleixner (which includes John Stultz's latest
> > > GTOD tree), it fixes TSC synchronization problems on HT systems, and
> > > updates the ktimers debugging code.
> > >
> > > These together could fix most of the timer warnings and annoyances
> > > reported for 2.6.14-rc5-rt kernels. In particular the new
> > > TSC-synchronization code could fix SMP systems: the upstream TSC
> > > synchronization method is fine for 1 usec resolution, but it was not
> > > good enough for 1 nsec resolution and likely caused the SMP bugs
> > > reported by Fernando Lopez-Lezcano and Rui Nuno Capela.
> > >
> > > Please re-report any bugs that remain.
> >
> > 2.6.14-rt2 seems to be running fine on my athlon x2 smp system. Apart
> > from some time warp messages when starting up it looks fine so far (this
> > is on fc4).
>
> Actually, after enough time logged in (or maybe just with the kernel
> running without a reboot) I still get the usual Jack warnings:
>
> delay of 5469.000 usecs exceeds estimated spare time of 2641.000;
> restart ...
>
Fernando,
I'm also having some when using SCHED_FIFO and SCHED_RR. When running
several hundred threads, each sleeping on a loop for 20ms, SCHED_OTHER
performs ok with latencies of less than 10ms while with SCHED_FIFO or
SCHED_RR, I see latencies exceeding 1 full second!
Carlos
--
"We hold [...] that all men are created equal; that they are
endowed [...] with certain inalienable rights; that among
these are life, liberty, and the pursuit of happiness"
-- Thomas Jefferson
On Tue, 2005-11-01 at 21:55 -0500, Carlos Antunes wrote:
>
> Fernando,
>
> I'm also having some when using SCHED_FIFO and SCHED_RR. When running
> several hundred threads, each sleeping on a loop for 20ms, SCHED_OTHER
> performs ok with latencies of less than 10ms while with SCHED_FIFO or
> SCHED_RR, I see latencies exceeding 1 full second!
Are you saying that you have several hundred threads in SCHED_FIFO or
SCHED_RR? Or is just Jack as that.
-- Steve
On 11/1/05, Steven Rostedt <[email protected]> wrote:
> On Tue, 2005-11-01 at 21:55 -0500, Carlos Antunes wrote:
>
> >
> > Fernando,
> >
> > I'm also having some when using SCHED_FIFO and SCHED_RR. When running
> > several hundred threads, each sleeping on a loop for 20ms, SCHED_OTHER
> > performs ok with latencies of less than 10ms while with SCHED_FIFO or
> > SCHED_RR, I see latencies exceeding 1 full second!
>
> Are you saying that you have several hundred threads in SCHED_FIFO or
> SCHED_RR? Or is just Jack as that.
>
It's a simple program I put together to test wakeup latency. Each
thread basically sleeps for 20ms, wakes up and executes a couple of
instructions and goes back to sleep for another 20ms. Multiply this by
a thousand. What I found out is that, inthis situation, and using
realtime-preempt, SCHED_OTHER offers 3 orders of magnitude less
latency than SCHED_FIFO or SCHED_RR. Which suggests to me there is
something fishy going on.
Carlos
--
"We hold [...] that all men are created equal; that they are
endowed [...] with certain inalienable rights; that among
these are life, liberty, and the pursuit of happiness"
-- Thomas Jefferson
On Tue, 2005-11-01 at 22:26 -0500, Carlos Antunes wrote:
>
> It's a simple program I put together to test wakeup latency. Each
> thread basically sleeps for 20ms, wakes up and executes a couple of
> instructions and goes back to sleep for another 20ms. Multiply this by
> a thousand. What I found out is that, inthis situation, and using
> realtime-preempt, SCHED_OTHER offers 3 orders of magnitude less
> latency than SCHED_FIFO or SCHED_RR. Which suggests to me there is
> something fishy going on.
Could you supply this program? I like to see what it does on my
systems.
Thanks,
-- Steve
On 11/1/05, Steven Rostedt <[email protected]> wrote:
> On Tue, 2005-11-01 at 22:26 -0500, Carlos Antunes wrote:
>
> >
> > It's a simple program I put together to test wakeup latency. Each
> > thread basically sleeps for 20ms, wakes up and executes a couple of
> > instructions and goes back to sleep for another 20ms. Multiply this by
> > a thousand. What I found out is that, inthis situation, and using
> > realtime-preempt, SCHED_OTHER offers 3 orders of magnitude less
> > latency than SCHED_FIFO or SCHED_RR. Which suggests to me there is
> > something fishy going on.
>
> Could you supply this program? I like to see what it does on my
> systems.
>
Sure, let me just clean it up a little bit. I'll post it soon.
Carlos
--
"We hold [...] that all men are created equal; that they are
endowed [...] with certain inalienable rights; that among
these are life, liberty, and the pursuit of happiness"
-- Thomas Jefferson
On 11/1/05, Steven Rostedt <[email protected]> wrote:
> On Tue, 2005-11-01 at 22:26 -0500, Carlos Antunes wrote:
>
> >
> > It's a simple program I put together to test wakeup latency. Each
> > thread basically sleeps for 20ms, wakes up and executes a couple of
> > instructions and goes back to sleep for another 20ms. Multiply this by
> > a thousand. What I found out is that, inthis situation, and using
> > realtime-preempt, SCHED_OTHER offers 3 orders of magnitude less
> > latency than SCHED_FIFO or SCHED_RR. Which suggests to me there is
> > something fishy going on.
>
> Could you supply this program? I like to see what it does on my
> systems.
>
Steve,
Here's the thing:
http://www.nowthor.com/OpenPBX/timing.c
Let me know what kind of results you get.
Thanks!
Carlos
--
"We hold [...] that all men are created equal; that they are
endowed [...] with certain inalienable rights; that among
these are life, liberty, and the pursuit of happiness"
-- Thomas Jefferson
* Fernando Lopez-Lezcano <[email protected]> wrote:
> The same kernel built for fc3 fails to boot in my Sony laptop. I see
> this:
>
> Kernel panic - not syncing: Attempted to kill init!
why did it panic - no indication of that?
Ingo
On Tue, 1 Nov 2005 23:05:09 -0500
Carlos Antunes <[email protected]> wrote:
> Here's the thing:
> http://www.nowthor.com/OpenPBX/timing.c
>
> Let me know what kind of results you get.
Hi,
running the code i simply get:
~$ ./timing
Failed to create thread # 382
Failed to create thread # 383
Failed to create thread # 384
Failed to create thread # 385
Failed to create thread # 386
Failed to create thread # 387
..
Failed to create thread # 498
Failed to create thread # 499
and then
Segmentation fault
Probably caused by not handling that some threads didn't get created. I
reduced the number down to 300:
~$ ./timing
Histogram
Delay(ms) Count
0 300000
1 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
10 0
11 0
12 0
13 0
14 0
15 0
16 0
17 0
18 0
19 0
20 0
Num threads = 300
Total sleeps = 300000
Min error = 0.014 ms
Max error = 0.133 ms
What would you expect to see? BTW: cpu load stayed moderately small with
this setting here.
As a sidenote: Of course the scheduling works completely different with
hundreds of threads running SCHED_FIFO at the same priority than with
hundreds of threads running SCHED_OTHER. SCHED_OTHER threads can preempt
each other when the dynamic priority changes. SCHED_FIFO threads OTOH
just sit and wait until they get to run, not preempting other SCHED_FIFO
threads of the same priority. So basically each SCHED_FIFO thread waits
until all others have run.
Dunno, if that would make a difference in this case though..
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
On 11/2/05, Florian Schmidt <[email protected]> wrote:
> On Tue, 1 Nov 2005 23:05:09 -0500
> Carlos Antunes <[email protected]> wrote:
>
> > Here's the thing:
> > http://www.nowthor.com/OpenPBX/timing.c
> >
> > Let me know what kind of results you get.
>
> Hi,
>
> running the code i simply get:
>
> ~$ ./timing
> Failed to create thread # 382
> Failed to create thread # 383
> Failed to create thread # 384
> Failed to create thread # 385
> Failed to create thread # 386
> Failed to create thread # 387
> ..
> Failed to create thread # 498
> Failed to create thread # 499
>
> and then
>
> Segmentation fault
>
That's interesting. Are you running a fairly recent pthread lib?
>
> Probably caused by not handling that some threads didn't get created. I
> reduced the number down to 300:
>
> ~$ ./timing
> Histogram
> Delay(ms) Count
> 0 300000
> 1 0
> 2 0
> 3 0
> 4 0
> 5 0
> 6 0
> 7 0
> 8 0
> 9 0
> 10 0
> 11 0
> 12 0
> 13 0
> 14 0
> 15 0
> 16 0
> 17 0
> 18 0
> 19 0
> 20 0
> Num threads = 300
> Total sleeps = 300000
> Min error = 0.014 ms
> Max error = 0.133 ms
>
> What would you expect to see? BTW: cpu load stayed moderately small with
> this setting here.
>
Did you run that with SCHED_FIFO or SCHED_OTHER? If it was with
SCHED_FIFO, it was a pretty good result. But maybe your machine is
just very fast. What CPU is that? DId you use 2.6.14-rt2 or some other
version?
>
> As a sidenote: Of course the scheduling works completely different with
> hundreds of threads running SCHED_FIFO at the same priority than with
> hundreds of threads running SCHED_OTHER. SCHED_OTHER threads can preempt
> each other when the dynamic priority changes. SCHED_FIFO threads OTOH
> just sit and wait until they get to run, not preempting other SCHED_FIFO
> threads of the same priority. So basically each SCHED_FIFO thread waits
> until all others have run.
>
Yes, they are supposed to act differently. In particular, my
understanding of realtime scheduling suggests SCHED_FIFO is supposed
to provide better (meaning lower) wakeup latency.
Thanks for tryting this out. Although I'm still puzzled at the low
number of threads you were able to create.
Carlos
--
"We hold [...] that all men are created equal; that they are
endowed [...] with certain inalienable rights; that among
these are life, liberty, and the pursuit of happiness"
-- Thomas Jefferson
* Carlos Antunes <[email protected]> wrote:
> > running the code i simply get:
> >
> > ~$ ./timing
> > Failed to create thread # 382
i suspect this is due to the stack ulimit being too high. Try something
like 'ulimit -s 128', which will make it 128K, instead of the default
8MB.
Ingo
On 11/2/05, Ingo Molnar <[email protected]> wrote:
>
> * Carlos Antunes <[email protected]> wrote:
>
> > > running the code i simply get:
> > >
> > > ~$ ./timing
> > > Failed to create thread # 382
>
> i suspect this is due to the stack ulimit being too high. Try something
> like 'ulimit -s 128', which will make it 128K, instead of the default
> 8MB.
>
Ingo,
First of all, thank you for all the great work you've contributed to
the Linux community.
Now the question: do you have any ideas about what might make
SCHED_OTHER perform better than SCHED_FIFO when in the presence of a
great number of (mostly) sleeping threads?
Thanks!
Carlos
--
"We hold [...] that all men are created equal; that they are
endowed [...] with certain inalienable rights; that among
these are life, liberty, and the pursuit of happiness"
-- Thomas Jefferson
On Wed, 2005-11-02 at 09:45 -0500, Carlos Antunes wrote:
> On 11/2/05, Ingo Molnar <[email protected]> wrote:
> >
> > * Carlos Antunes <[email protected]> wrote:
> >
> > > > running the code i simply get:
> > > >
> > > > ~$ ./timing
> > > > Failed to create thread # 382
> >
> > i suspect this is due to the stack ulimit being too high. Try something
> > like 'ulimit -s 128', which will make it 128K, instead of the default
> > 8MB.
> >
>
> Ingo,
>
> First of all, thank you for all the great work you've contributed to
> the Linux community.
>
> Now the question: do you have any ideas about what might make
> SCHED_OTHER perform better than SCHED_FIFO when in the presence of a
Hi Carlos,
Sorry I didn't get back to you sooner. I was already getting ready for
bed last night when you sent me your program. So I'm just getting
around to looking into this now.
To answer your question of why SCHED_OTHER may be preforming better than
SCHED_FIFO (although it shouldn't), probably shows something in either
the timing code, or the priority inheritance. Since a SCHED_OTHER
thread will skip the PI and other things to get it to perform
reliable.
Now could you post/send your CONFIG_FILE. I'm currently getting a test
machine ready to run your program.
Thanks,
-- Steve
On 11/2/05, Steven Rostedt <[email protected]> wrote:
>
> Sorry I didn't get back to you sooner. I was already getting ready for
> bed last night when you sent me your program. So I'm just getting
> around to looking into this now.
>
Hey, a man has got to sleep every now and then! :-)
>
> To answer your question of why SCHED_OTHER may be preforming better than
> SCHED_FIFO (although it shouldn't), probably shows something in either
> the timing code, or the priority inheritance. Since a SCHED_OTHER
> thread will skip the PI and other things to get it to perform
> reliable.
>
And you know what? The new rt3 solved the problem. Meanig that
SCHED_FIFO now gives better results than SCHED_OTHER.
THANKS INGO! ;-)
>
> Now could you post/send your CONFIG_FILE. I'm currently getting a test
> machine ready to run your program.
>
Given rt3 changes, do you still need my config?
Thanks!
Carlos
--
"We hold [...] that all men are created equal; that they are
endowed [...] with certain inalienable rights; that among
these are life, liberty, and the pursuit of happiness"
-- Thomas Jefferson
On Wed, 2005-11-02 at 11:07 -0500, Carlos Antunes wrote:
> >
> > Now could you post/send your CONFIG_FILE. I'm currently getting a test
> > machine ready to run your program.
> >
>
> Given rt3 changes, do you still need my config?
Nope,
So Ingo, what did you fix? :) (since now it's also at -rt4)
-- Steve
I hope you guys (Ingo and Thomas) are done changing the API to
ktime_to_timespec. I have over 200 debug statements doing this
conversion. Unfortunately, I didn't make it into a separate macro, so I
had to go by hand converting all of these.
They are temporary (but still needed) debugging, that I did cut & paste
mostly with, and modified them to what was needed. But its still to
complex to make a script make the changes. Well it will be easier to do
it by hand.
Hmm, maybe it is time to make a macro out of this too :-/
-- Steve
On 11/2/05, Steven Rostedt <[email protected]> wrote:
>
> So Ingo, what did you fix? :) (since now it's also at -rt4)
>
Maybe this was the culprit?
On Wed, Nov 02, 2005 at 02:12:29PM +0100, Ingo Molnar wrote:
>
> * Paul E. McKenney <[email protected]> wrote:
>
> > Hello!
> >
> > I guess I need to be more careful when creating experimental RCU
> > patches, as people have been copying my mistakes. Here is a patch to
> > fix some of them in -rt.
>
> thanks, applied - will show up in -rt3. Should be done for -mm too,
> which now includes rcu-signal-handling.patch?
--
"We hold [...] that all men are created equal; that they are
endowed [...] with certain inalienable rights; that among
these are life, liberty, and the pursuit of happiness"
-- Thomas Jefferson
On Wed, 2005-11-02 at 08:02 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
>
> > The same kernel built for fc3 fails to boot in my Sony laptop. I see
> > this:
> >
> > Kernel panic - not syncing: Attempted to kill init!
>
> why did it panic - no indication of that?
No. It just sits there for a while and then the message I posted
appears. No other thing I can see.
-- Fernando
On Tue, 2005-11-01 at 21:55 -0500, Carlos Antunes wrote:
> On 11/1/05, Fernando Lopez-Lezcano <[email protected]> wrote:
> > On Tue, 2005-11-01 at 12:18 -0800, Fernando Lopez-Lezcano wrote:
> > > On Sun, 2005-10-30 at 14:33 +0100, Ingo Molnar wrote:
> > > > i have released the 2.6.14-rt1 tree, which can be downloaded from the
> > > > usual place:
> > > >
> > > > http://redhat.com/~mingo/realtime-preempt/
> > > >
> > > > this release is mainly about ktimer fixes: it updates to the latest
> > > > ktimer tree from Thomas Gleixner (which includes John Stultz's latest
> > > > GTOD tree), it fixes TSC synchronization problems on HT systems, and
> > > > updates the ktimers debugging code.
> > > >
> > > > These together could fix most of the timer warnings and annoyances
> > > > reported for 2.6.14-rc5-rt kernels. In particular the new
> > > > TSC-synchronization code could fix SMP systems: the upstream TSC
> > > > synchronization method is fine for 1 usec resolution, but it was not
> > > > good enough for 1 nsec resolution and likely caused the SMP bugs
> > > > reported by Fernando Lopez-Lezcano and Rui Nuno Capela.
> > > >
> > > > Please re-report any bugs that remain.
> > >
> > > 2.6.14-rt2 seems to be running fine on my athlon x2 smp system. Apart
> > > from some time warp messages when starting up it looks fine so far (this
> > > is on fc4).
> >
> > Actually, after enough time logged in (or maybe just with the kernel
> > running without a reboot) I still get the usual Jack warnings:
> >
> > delay of 5469.000 usecs exceeds estimated spare time of 2641.000;
> > restart ...
> >
>
> I'm also having some when using SCHED_FIFO and SCHED_RR. When running
> several hundred threads, each sleeping on a loop for 20ms, SCHED_OTHER
> performs ok with latencies of less than 10ms while with SCHED_FIFO or
> SCHED_RR, I see latencies exceeding 1 full second!
Wow...
I still have to find time to try to get more data, but I'm _not_ getting
xruns. Something in the kernel timekeeping or the way Jack uses it is
wrong. The messages appear to be bogus as far as I can tell, but they
should not be there in the first place. As before they depend on the
kernel being running for a while, they don't happen right after a
reboot.
-- Fernando
Hey Ingo,
I just booted 2.6.14-rt4 and I'm getting lots of the
__get_nsec_offset() warnings where there isn't really a problem.
The main issue is that the clocksource may not be a TSC (acpi_pm in my
case), so the check to see if the cycle value ever goes backwards will
falsely trigger when the 24bit wide ACPI PM counter wraps.
To properly check for algorithmic inconsistencies, the checks should
probably be similar to what you had earlier inside
__get_monotonic_clock(), since at __get_nsec_offset() you really don't
have enough information to sort out if an inconsistency has occurred.
If we want to watch for hardware inconsistencies (like unsynced TSCs),
those checks really need to go inside the clocksource drivers
themselves.
I'll write up a paranoid debug patch that provides similar checks for
both cases and include it in my patch set so you don't have to keep
forward porting your own versions.
thanks
-john
* john stultz <[email protected]> wrote:
> I'll write up a paranoid debug patch that provides similar checks for
> both cases and include it in my patch set so you don't have to keep
> forward porting your own versions.
ok. I'll drop mine for the time being.
Ingo
On Wed, 2005-10-26 at 04:28, Ingo Molnar wrote:
> The box where i have these small TSC inconsistencies shows that it's the
> bootup synchronization of TSCs that failed to be 100% accurate. Even a 2
> usecs error in synchronization can show up as a time-warp - regardless
> of whether we keep per-CPU TSC offsets or whether we clear these offsets
> back to 0. So it is not a solution to do another type of synchronization
> dance. The only solution is to fix the boot-time synchronization (where
> the hardware keeps TSCs synchronized all the time), or to switch TSCs
> off where this is not possible.
>
> Ingo
Hi Ingo, Everyone,
I adapted the IA-64 ITC synchronization code to synchronize the
TSC for i386 and posted a patch in Jan 2003. It is here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=104273559400918&w=2
I'm including a version updated to linux-2.6.13.
The existing i386 code trys to synchronize all of the processors
at once. It sets a global flag and expects all of the processors
to notice it change at the same time. All of the processors see
a cache invalidate on the bus but then they have to queue up and
do a read cycle. This results in s systematic error where each
additional cpu is delayed by the time it takes to arbitrate the
bus and complete the read.
The IA-64 code works with pairs of processors and uses a feedback
loop to compensate for the bus latency and the overhead of adjusting
the ITC.
Andi Kleen has recently done the same work for x86_64.
Jim Houston - Concurrent Computer Corp.
--- linux-2.6.13/arch/i386/kernel/smpboot.c.0 2005-10-25 16:01:53.000000000 -0400
+++ linux-2.6.13/arch/i386/kernel/smpboot.c 2005-11-03 16:41:12.000000000 -0500
@@ -211,141 +211,231 @@
}
/*
- * TSC synchronization.
- *
- * We first check whether all CPUs have their TSC's synchronized,
- * then we print a warning if not, and always resync.
+ * TSC synchronization based on ia64 itc synchronization code. Synchronize
+ * pairs of processors rahter than tring to synchronize all of the processors
+ * with a single event. When several processors are all waiting for an
+ * event they don't all see it at the same time. The write will cause
+ * an invalidate on each processors cache and then they all scramble to
+ * re-read that cache line.
+ *
+ * Writing the TSC resets the upper 32-bits, so we need to be careful
+ * that all of the cpus can be synchronized before we overflow the
+ * 32-bit count.
*/
-static atomic_t tsc_start_flag = ATOMIC_INIT(0);
-static atomic_t tsc_count_start = ATOMIC_INIT(0);
-static atomic_t tsc_count_stop = ATOMIC_INIT(0);
-static unsigned long long tsc_values[NR_CPUS];
+#define MASTER 0
+#define SLAVE (SMP_CACHE_BYTES/sizeof(long))
-#define NR_LOOPS 5
+#define NUM_ROUNDS 64 /* magic value */
+#define NUM_ITERS 5 /* likewise */
-static void __init synchronize_tsc_bp (void)
+static volatile unsigned long go[2*SLAVE] __cacheline_aligned;
+static volatile int current_slave = -1;
+static volatile int tsc_sync_complete = 0;
+static volatile int tsc_adj_latency = 0;
+static unsigned int max_rt = 0;
+static unsigned int max_delta = 0;
+
+#define DEBUG_TSC_SYNC 0
+#if DEBUG_TSC_SYNC
+struct tsc_sync_debug {
+ long rt; /* roundtrip time */
+ long master; /* master's timestamp */
+ long diff; /* difference between midpoint and master's timestamp */
+ long lat; /* estimate of tsc adjustment latency */
+} tsc_sync_debug[NUM_ROUNDS*NR_CPUS];
+#endif
+
+void
+sync_master(void)
{
- int i;
- unsigned long long t0;
- unsigned long long sum, avg;
- long long delta;
- unsigned int one_usec;
- int buggy = 0;
+ unsigned long n, tsc, last_go_master;
- printk(KERN_INFO "checking TSC synchronization across %u CPUs: ", num_booting_cpus());
+ last_go_master = 0;
+ while (1) {
+ while ((n = go[MASTER]) == last_go_master)
+ rep_nop();
+ if (n == ~0)
+ break;
+ rdtscl(tsc);
+ if (unlikely(!tsc))
+ tsc = 1;
+ go[SLAVE] = tsc;
+ last_go_master = n;
+ }
+}
- /* convert from kcyc/sec to cyc/usec */
- one_usec = cpu_khz / 1000;
+/*
+ * Return the number of cycles by which our TSC differs from the TSC on
+ * the master (time-keeper) CPU. A positive number indicates our TSC is
+ * ahead of the master, negative that it is behind.
+ */
+static inline long
+get_delta (long *rt, long *master)
+{
+ unsigned long best_t0 = 0, best_t1 = ~0UL, best_tm = 0;
+ unsigned long tcenter, t0, t1, tm, last_go_slave;
+ long i;
+
+ last_go_slave = go[SLAVE];
+ for (i = 0; i < NUM_ITERS; ++i) {
+ rdtscl(t0);
+ go[MASTER] = i+1;
+ while ((tm = go[SLAVE]) == last_go_slave)
+ rep_nop();
+ rdtscl(t1);
+
+ if (t1 - t0 < best_t1 - best_t0)
+ best_t0 = t0, best_t1 = t1, best_tm = tm;
+ last_go_slave = tm;
+ }
+
+ *rt = best_t1 - best_t0;
+ *master = best_tm - best_t0;
+
+ /* average best_t0 and best_t1 without overflow: */
+ tcenter = (best_t0/2 + best_t1/2);
+ if (best_t0 % 2 + best_t1 % 2 == 2)
+ ++tcenter;
+ return tcenter - best_tm;
+}
- atomic_set(&tsc_start_flag, 1);
- wmb();
+/*
+ * Synchronize TSC of the current (slave) CPU with the TSC of the MASTER CPU
+ * (normally the time-keeper CPU). We use a closed loop to eliminate the
+ * possibility of unaccounted-for errors (such as getting a machine check in
+ * the middle of a calibration step). The basic idea is for the slave to ask
+ * the master what TSC value it has and to read its own TSC before and after
+ * the master responds. Each iteration gives us three
+ * timestamps:
+ *
+ * slave master
+ *
+ * t0 ---\
+ * ---\
+ * --->
+ * tm
+ * /---
+ * /---
+ * t1 <---
+ *
+ *
+ * The goal is to adjust the slave's TSC such that tm falls exactly half-way
+ * between t0 and t1. If we achieve this, the clocks are synchronized provided
+ * the interconnect between the slave and the master is symmetric. Even if the
+ * interconnect were asymmetric, we would still know that the synchronization
+ * error is smaller than the roundtrip latency (t0 - t1).
+ *
+ * When the interconnect is quiet and symmetric, this lets us synchronize the
+ * TSC to within one or two cycles. However, we can only *guarantee* that the
+ * synchronization is accurate to within a round-trip time, which is typically
+ * in the range of several hundred cycles (e.g., ~500 cycles). In practice,
+ * this means that the TSC's are usually almost perfectly synchronized, but we
+ * shouldn't assume that the accuracy is much better than half a micro second
+ * or so.
+ */
+static void __init
+synchronize_tsc_ap (void)
+{
+ long i, delta, adj, adjust_latency, n_rounds;
+ unsigned long rt, master_time_stamp, tsc;
+#if DEBUG_TSC_SYNC
+ struct tsc_sync_debug *t =
+ &tsc_sync_debug[smp_processor_id() * NUM_ROUNDS];
+#endif
+
/*
- * We loop a few times to get a primed instruction cache,
- * then the last pass is more or less synchronized and
- * the BP and APs set their cycle counters to zero all at
- * once. This reduces the chance of having random offsets
- * between the processors, and guarantees that the maximum
- * delay between the cycle counters is never bigger than
- * the latency of information-passing (cachelines) between
- * two CPUs.
+ * Wait for our turn to synchronize with the boot processor.
*/
- for (i = 0; i < NR_LOOPS; i++) {
- /*
- * all APs synchronize but they loop on '== num_cpus'
- */
- while (atomic_read(&tsc_count_start) != num_booting_cpus()-1)
- mb();
- atomic_set(&tsc_count_stop, 0);
- wmb();
- /*
- * this lets the APs save their current TSC:
- */
- atomic_inc(&tsc_count_start);
-
- rdtscll(tsc_values[smp_processor_id()]);
- /*
- * We clear the TSC in the last loop:
- */
- if (i == NR_LOOPS-1)
- write_tsc(0, 0);
+ while (current_slave != smp_processor_id())
+ rep_nop();
+ adjust_latency = tsc_adj_latency;
- /*
- * Wait for all APs to leave the synchronization point:
- */
- while (atomic_read(&tsc_count_stop) != num_booting_cpus()-1)
- mb();
- atomic_set(&tsc_count_start, 0);
- wmb();
- atomic_inc(&tsc_count_stop);
- }
+ go[SLAVE] = 0;
+ go[MASTER] = 0;
+ write_tsc(0,0);
+ for (i = 0; i < NUM_ROUNDS; ++i) {
+ delta = get_delta(&rt, &master_time_stamp);
+ if (delta == 0)
+ break;
- sum = 0;
- for (i = 0; i < NR_CPUS; i++) {
- if (cpu_isset(i, cpu_callout_map)) {
- t0 = tsc_values[i];
- sum += t0;
- }
+ if (i > 0)
+ adjust_latency += -delta;
+ adj = -delta + adjust_latency/8;
+ rdtscl(tsc);
+ write_tsc(tsc + adj, 0);
+#if DEBUG_TSC_SYNC
+ t[i].rt = rt;
+ t[i].master = master_time_stamp;
+ t[i].diff = delta;
+ t[i].lat = adjust_latency/8;
+#endif
}
- avg = sum;
- do_div(avg, num_booting_cpus());
+ n_rounds = i;
+ go[MASTER] = ~0;
- sum = 0;
- for (i = 0; i < NR_CPUS; i++) {
- if (!cpu_isset(i, cpu_callout_map))
- continue;
- delta = tsc_values[i] - avg;
- if (delta < 0)
- delta = -delta;
- /*
- * We report bigger than 2 microseconds clock differences.
- */
- if (delta > 2*one_usec) {
- long realdelta;
- if (!buggy) {
- buggy = 1;
- printk("\n");
- }
- realdelta = delta;
- do_div(realdelta, one_usec);
- if (tsc_values[i] < avg)
- realdelta = -realdelta;
-
- printk(KERN_INFO "CPU#%d had %ld usecs TSC skew, fixed it up.\n", i, realdelta);
- }
+#if (DEBUG_TSC_SYNC == 2)
+ for (i = 0; i < n_rounds; ++i)
+ printk("rt=%5ld master=%5ld diff=%5ld adjlat=%5ld\n",
+ t[i].rt, t[i].master, t[i].diff, t[i].lat);
- sum += delta;
- }
- if (!buggy)
- printk("passed.\n");
+ printk("CPU %d: synchronized TSC (last diff %ld cycles, maxerr %lu cycles)\n",
+ smp_processor_id(), delta, rt);
+
+ printk("It took %ld rounds\n", n_rounds);
+#endif
+ if (rt > max_rt)
+ max_rt = rt;
+ if (delta < 0)
+ delta = -delta;
+ if (delta > max_delta)
+ max_delta = delta;
+ tsc_adj_latency = adjust_latency;
+ current_slave = -1;
+ while (!tsc_sync_complete)
+ rep_nop();
}
-static void __init synchronize_tsc_ap (void)
-{
- int i;
-
- /*
- * Not every cpu is online at the time
- * this gets called, so we first wait for the BP to
- * finish SMP initialization:
- */
- while (!atomic_read(&tsc_start_flag)) mb();
+/*
+ * The boot processor set its own TSC to zero and then gives each
+ * slave processor the chance to synchronize itself.
+ */
- for (i = 0; i < NR_LOOPS; i++) {
- atomic_inc(&tsc_count_start);
- while (atomic_read(&tsc_count_start) != num_booting_cpus())
- mb();
+static void __init synchronize_tsc_bp (void)
+{
+ unsigned int tsc_low, tsc_high, error;
+ int cpu;
- rdtscll(tsc_values[smp_processor_id()]);
- if (i == NR_LOOPS-1)
- write_tsc(0, 0);
+ printk("start TSC synchronization\n");
+ write_tsc(0, 0);
- atomic_inc(&tsc_count_stop);
- while (atomic_read(&tsc_count_stop) != num_booting_cpus()) mb();
+ for (cpu = 0; cpu < NR_CPUS; cpu++) {
+ if (!cpu_isset(cpu, cpu_callout_map))
+ continue;
+ if (cpu == smp_processor_id())
+ continue;
+ go[MASTER] = 0;
+ current_slave = cpu;
+ sync_master();
+ while (current_slave != -1)
+ rep_nop();
+ }
+ rdtsc(tsc_low, tsc_high);
+ if (tsc_high)
+ printk("TSC overflowed during synchronization\n");
+ else
+ printk("TSC synchronization complete max_delta=%d cycles\n",
+ max_delta);
+ if (max_rt < 4293) {
+ error = (max_rt * 1000000)/cpu_khz;
+ printk("TSC sync round-trip time %d.%03d microseconds\n",
+ error/1000, error%1000);
+ } else {
+ printk("TSC sync round-trip time %d cycles\n", max_rt);
}
+ tsc_sync_complete = 1;
}
-#undef NR_LOOPS
extern void calibrate_delay(void);
On Wed, 2005-11-02 at 08:02 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
>
> > The same kernel built for fc3 fails to boot in my Sony laptop. I see
> > this:
> >
> > Kernel panic - not syncing: Attempted to kill init!
>
> why did it panic - no indication of that?
I said no but I did not look close enough. Sorry.
I tried 2.6.14-rt4 on my laptop and there's no backtrace or anything
like that before the panic, but there was a message from selinux (I
don't have a copy and I'm not on that kernel - something like "no policy
loaded but in enforcing mode"). So I turned selinux off and it booted...
I'm also seeing selinux oddities in my amd smp system, rpm complaining
about things when installing a package:
line 1574 has invalid context system_u:object_r:spamd_exec_t
/etc/selinux/targeted/contexts/files/file_contexts: line 1575 has
invalid context system_u:object_r:spamd_exec_t
/etc/selinux/targeted/contexts/files/file_contexts: line 1576 has
invalid context system_u:object_r:spamd_exec_t
I'll have to investigate a bit more tomorrow if I find the time.
Booting into previous kernels with the same selinux setup shows no
problems. This is recent, probably started with 2.6.14-rt1.
-- Fernando
On Sun, 2005-10-30 at 14:33 +0100, Ingo Molnar wrote:
> i have released the 2.6.14-rt1 tree, which can be downloaded from the
> usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> this release is mainly about ktimer fixes: it updates to the latest
> ktimer tree from Thomas Gleixner (which includes John Stultz's latest
> GTOD tree), it fixes TSC synchronization problems on HT systems, and
> updates the ktimers debugging code.
>
> These together could fix most of the timer warnings and annoyances
> reported for 2.6.14-rc5-rt kernels. In particular the new
> TSC-synchronization code could fix SMP systems: the upstream TSC
> synchronization method is fine for 1 usec resolution, but it was not
> good enough for 1 nsec resolution and likely caused the SMP bugs
> reported by Fernando Lopez-Lezcano and Rui Nuno Capela.
>
> Please re-report any bugs that remain.
I've been running 2.6.14-rt6 fine in my smp system the whole day and
suddenly, just a moment ago, I suddenly started getting key repeats and
screensaver bliiiinks [not my typo]. No HIGH_RES_TIMERS, with
PREEMPT_RT. No messages in the logs or dmesg.
Doing a loop with "sleep 10" bbracketed by calls to date gives me
sporadic results:
--- Fri Nov 4 18:30:25 PST 2005
10
---
--- Fri Nov 4 19:43:53 PST 2005
10
---
--- Fri Nov 4 19:44:03 PST 2005
3
---
--- Fri Nov 4 18:30:48 PST 2005
10
---
--- Fri Nov 4 18:30:58 PST 2005
0
---
--- Fri Nov 4 18:30:58 PST 2005
2
---
--- Fri Nov 4 18:31:00 PST 2005
10
---
--- Fri Nov 4 18:31:10 PST 2005
10
---
-- Fernando
On 11/4/05, Fernando Lopez-Lezcano <[email protected]> wrote:
> On Sun, 2005-10-30 at 14:33 +0100, Ingo Molnar wrote:
> > i have released the 2.6.14-rt1 tree, which can be downloaded from the
> > usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
> > this release is mainly about ktimer fixes: it updates to the latest
> > ktimer tree from Thomas Gleixner (which includes John Stultz's latest
> > GTOD tree), it fixes TSC synchronization problems on HT systems, and
> > updates the ktimers debugging code.
> >
> > These together could fix most of the timer warnings and annoyances
> > reported for 2.6.14-rc5-rt kernels. In particular the new
> > TSC-synchronization code could fix SMP systems: the upstream TSC
> > synchronization method is fine for 1 usec resolution, but it was not
> > good enough for 1 nsec resolution and likely caused the SMP bugs
> > reported by Fernando Lopez-Lezcano and Rui Nuno Capela.
> >
> > Please re-report any bugs that remain.
>
> I've been running 2.6.14-rt6 fine in my smp system the whole day and
> suddenly, just a moment ago, I suddenly started getting key repeats and
> screensaver bliiiinks [not my typo]. No HIGH_RES_TIMERS, with
> PREEMPT_RT. No messages in the logs or dmesg.
This sounds so familiar and similar to me, but with such a different
presentation. I ran about 15 hours yesterday with no xruns. Suddenly
at the end of the day I get about 8. I start up again this morning,
get two almost immediately, and then run the rest of the day with
none.
No HIGH_RES_TIMERS, with RT_PREEMPT.
Very strange.
Yesterday was 2.6.14-rt4. Today was -rt6.
- Mark
* Fernando Lopez-Lezcano <[email protected]> wrote:
> I've been running 2.6.14-rt6 fine in my smp system the whole day and
> suddenly, just a moment ago, I suddenly started getting key repeats
> and screensaver bliiiinks [not my typo]. No HIGH_RES_TIMERS, with
> PREEMPT_RT. No messages in the logs or dmesg.
>
> Doing a loop with "sleep 10" bbracketed by calls to date gives me
> sporadic results:
>
> --- Fri Nov 4 18:30:25 PST 2005
> 10
> ---
> --- Fri Nov 4 19:43:53 PST 2005
> 10
> ---
> --- Fri Nov 4 19:44:03 PST 2005
> 3
hm ... could you try the -rt9 kernel, does it still produce these short
timeouts? If yes, then could you strace the 'sleep 10' processes and
send me the strace output of such a short sleep? (does it still return
-516, aka -ERESTART_RESTARTBLOCK?)
Ingo
* Fernando Lopez-Lezcano <[email protected]> wrote:
> Doing a loop with "sleep 10" bbracketed by calls to date gives me
> sporadic results:
>
> --- Fri Nov 4 18:30:25 PST 2005
> 10
> ---
> --- Fri Nov 4 19:43:53 PST 2005
> 10
> ---
> --- Fri Nov 4 19:44:03 PST 2005
> 3
> ---
> --- Fri Nov 4 18:30:48 PST 2005
> 10
> ---
> --- Fri Nov 4 18:30:58 PST 2005
> 0
> ---
i'm running your timer-test script with an earlier config you sent
(kernel-2.6.13-i686-smp.ccrma.config), on a similar SMP box, and i'm not
getting these timeout problems (using -rt9). How easily do the above
problems reproduce - does it happen right after bootup?
(to make sure could you send me your current SMP .config too? You have
CONFIG_KTIME_SCALAR disabled, right?)
Ingo
On Thu, 2005-11-10 at 13:15 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
>
> > Doing a loop with "sleep 10" bbracketed by calls to date gives me
> > sporadic results:
> >
> > --- Fri Nov 4 18:30:25 PST 2005
> > 10
> > ---
> > --- Fri Nov 4 19:43:53 PST 2005
> > 10
> > ---
> > --- Fri Nov 4 19:44:03 PST 2005
> > 3
> > ---
> > --- Fri Nov 4 18:30:48 PST 2005
> > 10
> > ---
> > --- Fri Nov 4 18:30:58 PST 2005
> > 0
> > ---
>
> i'm running your timer-test script with an earlier config you sent
> (kernel-2.6.13-i686-smp.ccrma.config), on a similar SMP box, and i'm not
> getting these timeout problems (using -rt9). How easily do the above
> problems reproduce - does it happen right after bootup?
[BTW, I'm in Seattle right now and away from my test systems, I'll be
back to Stanford in a week or so, till then I probably won't be able to
test -rt9 or later]
It is not immediate, the problems take a while to show up after a
reboot. In the latest test with -rt6 I was logged in for almost a day
before it started happening (key repeats, screensaver stuff as before -
it took longer than in previous test kernels, I think). This was in the
afternoon. I finally logged out for the day and when I got back the next
day (without rebooting) the problem was gone and did not happen again. I
have not seen anything that seems to trigger it, just time after a
reboot. I did not see any weird messages in dmesg or /var/log/messages.
The third "symptom", the delay messages coming from Jack, is easier to
reproduce. Right after a reboot everything is fine, after running the
kernel for a while they start happening till I reboot.
> (to make sure could you send me your current SMP .config too? You have
> CONFIG_KTIME_SCALAR disabled, right?)
That's correct, should I turn that on? I also went back to not using
HIGH_RES_TIMERS.
I'm attaching the last config file I used for the smp kernel.
-- Fernando
* George Anzinger <[email protected]> wrote:
> For those using kgdb on the rt kernel, I have just updated the patches at:
> http://source.mvista.com/~ganzinger/
i tried your kgdb-ga-rt.patch patch on the -rt tree, and it doesnt seem
to work: i get up to the initial breakpoint, but after the 'cont' the
target system hangs indefinitely. Does it work for you? Config attached.
Ingo
* Ingo Molnar <[email protected]> wrote:
>
> * George Anzinger <[email protected]> wrote:
>
> > For those using kgdb on the rt kernel, I have just updated the patches at:
> > http://source.mvista.com/~ganzinger/
>
> i tried your kgdb-ga-rt.patch patch on the -rt tree, and it doesnt seem
> to work: i get up to the initial breakpoint, but after the 'cont' the
> target system hangs indefinitely. Does it work for you? Config attached.
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.14-rt12
# Sat Nov 12 17:18:48 2005
#
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=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 is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_KMOD is not set
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII 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_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
# CONFIG_KTIME_SCALAR is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HIGH_RES_RESOLUTION=1000
# CONFIG_SMP is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT_DESKTOP is not set
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STATS=y
CONFIG_RCU_TORTURE_TEST=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ASM_SEMAPHORES=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_IOAPIC_FAST=y
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
CONFIG_DCDBAS=m
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
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 is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_REGPARM=y
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PHYSICAL_START=0x100000
# CONFIG_KEXEC is not set
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
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_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_IBM=y
# CONFIG_ACPI_TOSHIBA is not set
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 is not set
# 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_LEGACY_PROC 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=y
CONFIG_BINFMT_MISC=y
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
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 is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_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 is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_INET6_TUNNEL=y
CONFIG_IPV6_TUNNEL=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_NETFILTER_NETLINK is not set
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
CONFIG_IP_NF_CT_PROTO_SCTP=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
# CONFIG_IP_NF_NETBIOS_NS is not set
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
# CONFIG_IP_NF_PPTP is not set
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_REALM=y
CONFIG_IP_NF_MATCH_SCTP=y
# CONFIG_IP_NF_MATCH_DCCP is not set
CONFIG_IP_NF_MATCH_COMMENT=y
# CONFIG_IP_NF_MATCH_CONNBYTES is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
# CONFIG_IP_NF_MATCH_STRING is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
# CONFIG_IP_NF_TARGET_NFQUEUE is not set
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
# CONFIG_IP_NF_TARGET_TTL is not set
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_TARGET_NOTRACK=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y
#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
CONFIG_IP6_NF_QUEUE=y
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_MATCH_LIMIT=y
CONFIG_IP6_NF_MATCH_MAC=y
CONFIG_IP6_NF_MATCH_RT=y
CONFIG_IP6_NF_MATCH_OPTS=y
CONFIG_IP6_NF_MATCH_FRAG=y
CONFIG_IP6_NF_MATCH_HL=y
CONFIG_IP6_NF_MATCH_MULTIPORT=y
CONFIG_IP6_NF_MATCH_OWNER=y
CONFIG_IP6_NF_MATCH_MARK=y
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
CONFIG_IP6_NF_MATCH_AHESP=y
CONFIG_IP6_NF_MATCH_LENGTH=y
CONFIG_IP6_NF_MATCH_EUI64=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_LOG=y
# CONFIG_IP6_NF_TARGET_REJECT is not set
# CONFIG_IP6_NF_TARGET_NFQUEUE is not set
CONFIG_IP6_NF_MANGLE=y
CONFIG_IP6_NF_TARGET_MARK=y
# CONFIG_IP6_NF_TARGET_HL is not set
CONFIG_IP6_NF_RAW=y
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
CONFIG_NET_CLS_ROUTE=y
#
# 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 is not set
# CONFIG_DEBUG_DRIVER 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=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_SERIAL=y
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
CONFIG_PARPORT_NOT_PC=y
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_1284=y
#
# Plug and Play support
#
# CONFIG_PNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# 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=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# 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=4096
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_LBD is not set
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
# 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_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# 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 is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# 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 is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# 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=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# 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 is not set
# CONFIG_SCSI_LOGGING is not set
#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=y
# 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_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=1000
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
# CONFIG_SCSI_AIC7XXX_OLD is not set
CONFIG_SCSI_AIC79XX=y
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=1000
# CONFIG_AIC79XX_ENABLE_RD_STRM is not set
CONFIG_AIC79XX_DEBUG_ENABLE=y
CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_AIC79XX_REG_PRETTY_PRINT=y
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_IN2000 is not set
# 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_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA24XX is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
#
# 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 is not set
CONFIG_BLK_DEV_DM=y
# 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=y
#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_IEEE1394_OUI_DB is not set
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y
# CONFIG_IEEE1394_EXPORT_FULL_API is not set
#
# Device Drivers
#
CONFIG_IEEE1394_PCILYNX=y
CONFIG_IEEE1394_OHCI1394=y
#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=y
# CONFIG_IEEE1394_SBP2 is not set
CONFIG_IEEE1394_ETH1394=y
CONFIG_IEEE1394_DV1394=y
CONFIG_IEEE1394_RAWIO=y
CONFIG_IEEE1394_CMP=y
CONFIG_IEEE1394_AMDTP=y
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN 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=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
CONFIG_E1000_NAPI=y
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
CONFIG_SK98LIN=y
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=y
# CONFIG_BNX2 is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# 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=1600
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1200
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# 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 is not set
# 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 is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_GAMEPORT=y
CONFIG_GAMEPORT_NS558=y
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_FM801 is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_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
# CONFIG_PRINTER is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set
#
# IPMI
#
CONFIG_IPMI_HANDLER=y
CONFIG_IPMI_PANIC_EVENT=y
CONFIG_IPMI_PANIC_STRING=y
CONFIG_IPMI_DEVICE_INTERFACE=y
CONFIG_IPMI_SI=y
CONFIG_IPMI_WATCHDOG=y
CONFIG_IPMI_POWEROFF=y
#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_I8XX_TCO is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
#
# ISA-based Watchdog Cards
#
# CONFIG_PCWATCHDOG is not set
# CONFIG_MIXCOMWD is not set
# CONFIG_WDT is not set
#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_RTC_HISTOGRAM is not set
CONFIG_BLOCKER=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD64=y
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=y
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_MGA=y
# CONFIG_DRM_SIS is not set
CONFIG_DRM_VIA=y
# CONFIG_DRM_SAVAGE is not set
# CONFIG_MWAVE 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
#
# I2C support
#
CONFIG_I2C=y
# CONFIG_I2C_CHARDEV is not set
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
CONFIG_I2C_I801=y
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_ISA=y
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
CONFIG_SENSORS_W83781D=y
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF 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 Capabilities Port drivers
#
#
# Multimedia devices
#
CONFIG_VIDEO_DEV=y
#
# Video For Linux
#
#
# Video Adapters
#
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
CONFIG_VIDEO_ZORAN=y
CONFIG_VIDEO_ZORAN_BUZ=y
CONFIG_VIDEO_ZORAN_DC10=y
CONFIG_VIDEO_ZORAN_DC30=y
CONFIG_VIDEO_ZORAN_LML33=y
CONFIG_VIDEO_ZORAN_LML33R10=y
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
CONFIG_VIDEO_OVCAMCHIP=y
#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
CONFIG_SOUND=y
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_SEQ_DUMMY=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_VERBOSE_PRINTK is not set
CONFIG_SND_DEBUG=y
CONFIG_SND_DEBUG_MEMORY=y
CONFIG_SND_DEBUG_DETECT=y
CONFIG_SND_GENERIC_DRIVER=y
#
# Generic devices
#
CONFIG_SND_MPU401_UART=y
CONFIG_SND_DUMMY=y
CONFIG_SND_VIRMIDI=y
CONFIG_SND_MTPAV=y
CONFIG_SND_SERIAL_U16550=y
CONFIG_SND_MPU401=y
#
# ISA devices
#
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_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_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_AC97_BUS=y
#
# PCI devices
#
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
CONFIG_SND_CS46XX=y
CONFIG_SND_CS46XX_NEW_DSP=y
# CONFIG_SND_CS4281 is not set
CONFIG_SND_EMU10K1=y
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_ICE1712=y
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_HDA_INTEL is not set
#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_OBSOLETE_OSS_USB_DRIVER is not set
CONFIG_USB_BLUETOOTH_TTY=y
CONFIG_USB_ACM=y
CONFIG_USB_PRINTER=y
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
CONFIG_USB_STORAGE_DEBUG=y
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
# CONFIG_USB_STORAGE_USBAT is not set
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
# CONFIG_USB_STORAGE_ONETOUCH is not set
#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
CONFIG_HID_FF=y
CONFIG_HID_PID=y
CONFIG_LOGITECH_FF=y
CONFIG_THRUSTMASTER_FF=y
CONFIG_USB_HIDDEV=y
CONFIG_USB_AIPTEK=y
CONFIG_USB_WACOM=y
# CONFIG_USB_ACECAD is not set
CONFIG_USB_KBTAB=y
CONFIG_USB_POWERMATE=y
CONFIG_USB_MTOUCH=y
# CONFIG_USB_ITMTOUCH is not set
CONFIG_USB_EGALAX=y
# CONFIG_USB_YEALINK is not set
CONFIG_USB_XPAD=y
CONFIG_USB_ATI_REMOTE=y
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
#
# USB Imaging devices
#
CONFIG_USB_MDC800=y
CONFIG_USB_MICROTEK=y
#
# USB Multimedia devices
#
CONFIG_USB_DABUSB=y
CONFIG_USB_VICAM=y
CONFIG_USB_DSBR=y
CONFIG_USB_IBMCAM=y
CONFIG_USB_KONICAWC=y
CONFIG_USB_OV511=y
CONFIG_USB_SE401=y
CONFIG_USB_SN9C102=y
CONFIG_USB_STV680=y
CONFIG_USB_W9968CF=y
# CONFIG_USB_PWC is not set
#
# USB Network Adapters
#
CONFIG_USB_CATC=y
CONFIG_USB_KAWETH=y
CONFIG_USB_PEGASUS=y
CONFIG_USB_RTL8150=y
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
CONFIG_USB_NET_CDCETHER=y
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=y
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
# CONFIG_USB_NET_CDC_SUBSET is not set
CONFIG_USB_NET_ZAURUS=y
CONFIG_USB_MON=y
#
# USB port drivers
#
CONFIG_USB_USS720=y
#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=y
# CONFIG_USB_SERIAL_CONSOLE is not set
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRPRIME is not set
CONFIG_USB_SERIAL_BELKIN=y
# CONFIG_USB_SERIAL_WHITEHEAT is not set
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=y
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
CONFIG_USB_SERIAL_EMPEG=y
CONFIG_USB_SERIAL_FTDI_SIO=y
CONFIG_USB_SERIAL_VISOR=y
CONFIG_USB_SERIAL_IPAQ=y
CONFIG_USB_SERIAL_IR=y
CONFIG_USB_SERIAL_EDGEPORT=y
CONFIG_USB_SERIAL_EDGEPORT_TI=y
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
CONFIG_USB_SERIAL_KEYSPAN_PDA=y
CONFIG_USB_SERIAL_KEYSPAN=y
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
# CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19QW is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19QI is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA49WLC is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set
CONFIG_USB_EZUSB=y
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# SN Devices
#
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# 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=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=860
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-15"
# 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_RELAYFS_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 is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-15"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
CONFIG_NLS_CODEPAGE_860=y
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
#
# Profiling support
#
# CONFIG_PROFILING is not set
CONFIG_PROFILE_NMI=y
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_PRINTK_IGNORE_LOGLEVEL is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP 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_DEADLOCKS is not set
# CONFIG_DEBUG_RT_LOCKING_MODE 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_USE_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_KGDB=y
# CONFIG_KGDB_9600BAUD is not set
# CONFIG_KGDB_19200BAUD is not set
# CONFIG_KGDB_38400BAUD is not set
# CONFIG_KGDB_57600BAUD is not set
CONFIG_KGDB_115200BAUD=y
CONFIG_KGDB_PORT=0x3f8
CONFIG_KGDB_IRQ=4
# CONFIG_KGDB_MORE is not set
# CONFIG_STACK_OVERFLOW_TEST is not set
# CONFIG_TRAP_BAD_SYSCALL_EXITS is not set
CONFIG_KGDB_CONSOLE=y
CONFIG_KGDB_SYSRQ=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=y
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES_586=y
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_KHAZAD=y
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_TEST=y
#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set
#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y
Ingo Molnar wrote:
> * George Anzinger <[email protected]> wrote:
>
>
>>For those using kgdb on the rt kernel, I have just updated the patches at:
>>http://source.mvista.com/~ganzinger/
>
>
> i tried your kgdb-ga-rt.patch patch on the -rt tree, and it doesnt seem
> to work: i get up to the initial breakpoint, but after the 'cont' the
> target system hangs indefinitely. Does it work for you? Config attached.
Uh, I used it with 2.6.14-rt9 yesterday and it seemed to work. I will look more on Monday, using
your config.
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/