linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 2.6.14-rc4-rt7
@ 2005-10-17 16:05 Ingo Molnar
  2005-10-17 17:06 ` 2.6.14-rc4-rt7 Mark Knecht
                   ` (4 more replies)
  0 siblings, 5 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-17 16:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Thomas Gleixner, david singleton, Steven Rostedt,
	Rui Nuno Capela, Fernando Lopez-Lezcano, Mark Knecht


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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-17 16:05 2.6.14-rc4-rt7 Ingo Molnar
@ 2005-10-17 17:06 ` Mark Knecht
  2005-10-17 19:21 ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 117+ messages in thread
From: Mark Knecht @ 2005-10-17 17:06 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, david singleton, Steven Rostedt,
	Rui Nuno Capela, Fernando Lopez-Lezcano

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

On 10/17/05, Ingo Molnar <mingo@elte.hu> 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.

[-- Attachment #2: knecht.config-2.6.14-rc4-rt7.bz2 --]
[-- Type: application/x-bzip2, Size: 6245 bytes --]

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-17 16:05 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-17 17:06 ` 2.6.14-rc4-rt7 Mark Knecht
@ 2005-10-17 19:21 ` Fernando Lopez-Lezcano
  2005-10-18  1:30   ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  2005-10-17 21:43 ` 2.6.14-rc4-rt7 Daniel Walker
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-17 19:21 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: cc, nando, linux-kernel, Thomas Gleixner, david singleton,
	Steven Rostedt, Rui Nuno Capela, Mark Knecht

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-17 16:05 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-17 17:06 ` 2.6.14-rc4-rt7 Mark Knecht
  2005-10-17 19:21 ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
@ 2005-10-17 21:43 ` Daniel Walker
  2005-10-17 22:03   ` 2.6.14-rc4-rt7 Thomas Gleixner
  2005-10-18  6:42   ` 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-18  0:19 ` 2.6.14-rc4-rt7 Daniel Walker
  2005-10-20 19:54 ` 2.6.14-rc5-rt1 Ingo Molnar
  4 siblings, 2 replies; 117+ messages in thread
From: Daniel Walker @ 2005-10-17 21:43 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, david singleton, Steven Rostedt,
	Rui Nuno Capela, Fernando Lopez-Lezcano, Mark Knecht

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1794 bytes --]


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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 1377 bytes --]

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-17 21:43 ` 2.6.14-rc4-rt7 Daniel Walker
@ 2005-10-17 22:03   ` Thomas Gleixner
  2005-10-17 22:05     ` 2.6.14-rc4-rt7 Daniel Walker
  2005-10-18  6:42   ` 2.6.14-rc4-rt7 Ingo Molnar
  1 sibling, 1 reply; 117+ messages in thread
From: Thomas Gleixner @ 2005-10-17 22:03 UTC (permalink / raw)
  To: Daniel Walker
  Cc: Ingo Molnar, linux-kernel, david singleton, Steven Rostedt,
	Rui Nuno Capela, Fernando Lopez-Lezcano, Mark Knecht

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


^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-17 22:03   ` 2.6.14-rc4-rt7 Thomas Gleixner
@ 2005-10-17 22:05     ` Daniel Walker
  2005-10-17 22:15       ` 2.6.14-rc4-rt7 Thomas Gleixner
  0 siblings, 1 reply; 117+ messages in thread
From: Daniel Walker @ 2005-10-17 22:05 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Ingo Molnar, linux-kernel, david singleton, Steven Rostedt,
	Rui Nuno Capela, Fernando Lopez-Lezcano, Mark Knecht



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


^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-17 22:05     ` 2.6.14-rc4-rt7 Daniel Walker
@ 2005-10-17 22:15       ` Thomas Gleixner
  0 siblings, 0 replies; 117+ messages in thread
From: Thomas Gleixner @ 2005-10-17 22:15 UTC (permalink / raw)
  To: Daniel Walker
  Cc: Ingo Molnar, linux-kernel, david singleton, Steven Rostedt,
	Rui Nuno Capela, Fernando Lopez-Lezcano, Mark Knecht

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-17 16:05 2.6.14-rc4-rt7 Ingo Molnar
                   ` (2 preceding siblings ...)
  2005-10-17 21:43 ` 2.6.14-rc4-rt7 Daniel Walker
@ 2005-10-18  0:19 ` Daniel Walker
  2005-10-18  6:45   ` 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-20 19:54 ` 2.6.14-rc5-rt1 Ingo Molnar
  4 siblings, 1 reply; 117+ messages in thread
From: Daniel Walker @ 2005-10-18  0:19 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, david singleton, Steven Rostedt,
	Rui Nuno Capela, Fernando Lopez-Lezcano, Mark Knecht



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];
 




^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-17 19:21 ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
@ 2005-10-18  1:30   ` Fernando Lopez-Lezcano
  2005-10-18  1:50     ` 2.6.14-rc4-rt7 Mark Knecht
                       ` (2 more replies)
  0 siblings, 3 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-18  1:30 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, cc, linux-kernel, Thomas Gleixner, david singleton,
	Steven Rostedt, Rui Nuno Capela, Mark Knecht

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18  1:30   ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
@ 2005-10-18  1:50     ` Mark Knecht
  2005-10-18  6:54     ` 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-18  7:28     ` 2.6.14-rc4-rt7 Ingo Molnar
  2 siblings, 0 replies; 117+ messages in thread
From: Mark Knecht @ 2005-10-18  1:50 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Ingo Molnar, cc, linux-kernel, Thomas Gleixner, david singleton,
	Steven Rostedt, Rui Nuno Capela

On 10/17/05, Fernando Lopez-Lezcano <nando@ccrma.stanford.edu> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-17 21:43 ` 2.6.14-rc4-rt7 Daniel Walker
  2005-10-17 22:03   ` 2.6.14-rc4-rt7 Thomas Gleixner
@ 2005-10-18  6:42   ` Ingo Molnar
  2005-10-18 16:23     ` 2.6.14-rc4-rt7 Daniel Walker
  1 sibling, 1 reply; 117+ messages in thread
From: Ingo Molnar @ 2005-10-18  6:42 UTC (permalink / raw)
  To: Daniel Walker
  Cc: linux-kernel, Thomas Gleixner, david singleton, Steven Rostedt,
	Rui Nuno Capela, Fernando Lopez-Lezcano, Mark Knecht


* Daniel Walker <dwalker@mvista.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18  0:19 ` 2.6.14-rc4-rt7 Daniel Walker
@ 2005-10-18  6:45   ` Ingo Molnar
  0 siblings, 0 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-18  6:45 UTC (permalink / raw)
  To: Daniel Walker
  Cc: linux-kernel, Thomas Gleixner, david singleton, Steven Rostedt,
	Rui Nuno Capela, Fernando Lopez-Lezcano, Mark Knecht


* Daniel Walker <dwalker@mvista.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18  1:30   ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  2005-10-18  1:50     ` 2.6.14-rc4-rt7 Mark Knecht
@ 2005-10-18  6:54     ` Ingo Molnar
  2005-10-18  7:28     ` 2.6.14-rc4-rt7 Ingo Molnar
  2 siblings, 0 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-18  6:54 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: cc, linux-kernel, Thomas Gleixner, david singleton,
	Steven Rostedt, Rui Nuno Capela, Mark Knecht


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18  1:30   ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  2005-10-18  1:50     ` 2.6.14-rc4-rt7 Mark Knecht
  2005-10-18  6:54     ` 2.6.14-rc4-rt7 Ingo Molnar
@ 2005-10-18  7:28     ` Ingo Molnar
  2005-10-18 14:11       ` 2.6.14-rc4-rt7 K.R. Foley
  2005-10-18 21:04       ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  2 siblings, 2 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-18  7:28 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: cc, linux-kernel, Thomas Gleixner, david singleton,
	Steven Rostedt, Rui Nuno Capela, Mark Knecht


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18  7:28     ` 2.6.14-rc4-rt7 Ingo Molnar
@ 2005-10-18 14:11       ` K.R. Foley
  2005-10-18 14:49         ` 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-18 21:04       ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  1 sibling, 1 reply; 117+ messages in thread
From: K.R. Foley @ 2005-10-18 14:11 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Fernando Lopez-Lezcano, cc, linux-kernel, Thomas Gleixner,
	david singleton, Steven Rostedt, Rui Nuno Capela, Mark Knecht

[-- Attachment #1: Type: text/plain, Size: 120 bytes --]

Ingo Molnar wrote:

Ingo,

The attached patch is necessary to build -rt8 if high res timers are not
enabled.

-- 
   kr

[-- Attachment #2: ktimerfix.patch --]
[-- Type: text/x-patch, Size: 391 bytes --]

--- linux-2.6.14-rc4/kernel/ktimers.c.orig	2005-10-18 08:25:10.000000000 -0500
+++ linux-2.6.14-rc4/kernel/ktimers.c	2005-10-18 09:05:36.000000000 -0500
@@ -1222,7 +1222,9 @@
 		printk("rem:       %u/%u\n",
 			rem.tv.sec, rem.tv.nsec);
 		printk("overrun:   %d\n", timer->overrun);
+#ifdef CONFIG_HIGH_RES_TIMERS
 		printk("getoffset: %p\n", base->getoffset);
+#endif
 		WARN_ON(1);
 	}
 }

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18 14:11       ` 2.6.14-rc4-rt7 K.R. Foley
@ 2005-10-18 14:49         ` Ingo Molnar
  0 siblings, 0 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-18 14:49 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Fernando Lopez-Lezcano, cc, linux-kernel, Thomas Gleixner,
	david singleton, Steven Rostedt, Rui Nuno Capela, Mark Knecht


* K.R. Foley <kr@cybsft.com> wrote:

> Ingo,
> 
> The attached patch is necessary to build -rt8 if high res timers are 
> not enabled.

thanks - applied.

	Ingo

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18  6:42   ` 2.6.14-rc4-rt7 Ingo Molnar
@ 2005-10-18 16:23     ` Daniel Walker
  2005-10-18 20:26       ` 2.6.14-rc4-rt7 Ingo Molnar
  0 siblings, 1 reply; 117+ messages in thread
From: Daniel Walker @ 2005-10-18 16:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, david singleton, Steven Rostedt,
	Rui Nuno Capela, Fernando Lopez-Lezcano, Mark Knecht

On Tue, 2005-10-18 at 08:42 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> 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


^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18 16:23     ` 2.6.14-rc4-rt7 Daniel Walker
@ 2005-10-18 20:26       ` Ingo Molnar
  0 siblings, 0 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-18 20:26 UTC (permalink / raw)
  To: Daniel Walker
  Cc: linux-kernel, Thomas Gleixner, david singleton, Steven Rostedt,
	Rui Nuno Capela, Fernando Lopez-Lezcano, Mark Knecht


* Daniel Walker <dwalker@mvista.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18  7:28     ` 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-18 14:11       ` 2.6.14-rc4-rt7 K.R. Foley
@ 2005-10-18 21:04       ` Fernando Lopez-Lezcano
  2005-10-18 21:31         ` 2.6.14-rc4-rt7 William Weston
  1 sibling, 1 reply; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-18 21:04 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, cc, linux-kernel, Thomas Gleixner, david singleton,
	Steven Rostedt, Rui Nuno Capela, Mark Knecht

On Tue, 2005-10-18 at 09:28 +0200, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18 21:04       ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
@ 2005-10-18 21:31         ` William Weston
  2005-10-19  6:01           ` 2.6.14-rc4-rt7 Steven Rostedt
  2005-10-19 11:19           ` 2.6.14-rc4-rt7 Ingo Molnar
  0 siblings, 2 replies; 117+ messages in thread
From: William Weston @ 2005-10-18 21:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Fernando Lopez-Lezcano, cc, linux-kernel, Thomas Gleixner,
	david singleton, Steven Rostedt, Rui Nuno Capela, Mark Knecht

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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18 21:31         ` 2.6.14-rc4-rt7 William Weston
@ 2005-10-19  6:01           ` Steven Rostedt
  2005-10-19 11:19           ` 2.6.14-rc4-rt7 Ingo Molnar
  1 sibling, 0 replies; 117+ messages in thread
From: Steven Rostedt @ 2005-10-19  6:01 UTC (permalink / raw)
  To: William Weston
  Cc: Ingo Molnar, Fernando Lopez-Lezcano, cc, linux-kernel,
	Thomas Gleixner, david singleton, Rui Nuno Capela, Mark Knecht

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 <rostedt@goodmis.org>

-- Steve


^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-18 21:31         ` 2.6.14-rc4-rt7 William Weston
  2005-10-19  6:01           ` 2.6.14-rc4-rt7 Steven Rostedt
@ 2005-10-19 11:19           ` Ingo Molnar
  2005-10-20 19:12             ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  1 sibling, 1 reply; 117+ messages in thread
From: Ingo Molnar @ 2005-10-19 11:19 UTC (permalink / raw)
  To: William Weston
  Cc: Fernando Lopez-Lezcano, cc, linux-kernel, Thomas Gleixner,
	david singleton, Steven Rostedt, Rui Nuno Capela, Mark Knecht


* William Weston <weston@lysdexia.org> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-19 11:19           ` 2.6.14-rc4-rt7 Ingo Molnar
@ 2005-10-20 19:12             ` Fernando Lopez-Lezcano
  2005-10-20 19:16               ` 2.6.14-rc4-rt7 Ingo Molnar
  0 siblings, 1 reply; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-20 19:12 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, William Weston, cc, linux-kernel, Thomas Gleixner,
	david singleton, Steven Rostedt, Rui Nuno Capela, Mark Knecht

On Wed, 2005-10-19 at 13:19 +0200, Ingo Molnar wrote:
> * William Weston <weston@lysdexia.org> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-20 19:12             ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
@ 2005-10-20 19:16               ` Ingo Molnar
  2005-10-20 23:55                 ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  0 siblings, 1 reply; 117+ messages in thread
From: Ingo Molnar @ 2005-10-20 19:16 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: William Weston, cc, linux-kernel, Thomas Gleixner,
	david singleton, Steven Rostedt, Rui Nuno Capela, Mark Knecht


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* 2.6.14-rc5-rt1
  2005-10-17 16:05 2.6.14-rc4-rt7 Ingo Molnar
                   ` (3 preceding siblings ...)
  2005-10-18  0:19 ` 2.6.14-rc4-rt7 Daniel Walker
@ 2005-10-20 19:54 ` Ingo Molnar
  2005-10-20 23:33   ` 2.6.14-rc5-rt1 Felix Oxley
  2005-10-30 13:33   ` 2.6.14-rt1 Ingo Molnar
  4 siblings, 2 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-20 19:54 UTC (permalink / raw)
  To: linux-kernel; +Cc: Thomas Gleixner, Steven Rostedt, Fernando Lopez-Lezcano


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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc5-rt1
  2005-10-20 19:54 ` 2.6.14-rc5-rt1 Ingo Molnar
@ 2005-10-20 23:33   ` Felix Oxley
  2005-10-21  0:39     ` 2.6.14-rc5-rt1 Mark Knecht
  2005-10-21 10:01     ` 2.6.14-rc5-rt1 Felix Oxley
  2005-10-30 13:33   ` 2.6.14-rt1 Ingo Molnar
  1 sibling, 2 replies; 117+ messages in thread
From: Felix Oxley @ 2005-10-20 23:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt, Fernando Lopez-Lezcano


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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-20 19:16               ` 2.6.14-rc4-rt7 Ingo Molnar
@ 2005-10-20 23:55                 ` Fernando Lopez-Lezcano
  2005-10-21  8:05                   ` 2.6.14-rc4-rt7 Ingo Molnar
  0 siblings, 1 reply; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-20 23:55 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, William Weston, cc, linux-kernel, Thomas Gleixner,
	david singleton, Steven Rostedt, Rui Nuno Capela, Mark Knecht

On Thu, 2005-10-20 at 21:16 +0200, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc5-rt1
  2005-10-20 23:33   ` 2.6.14-rc5-rt1 Felix Oxley
@ 2005-10-21  0:39     ` Mark Knecht
  2005-10-21 13:47       ` 2.6.14-rc5-rt1 Mark Knecht
  2005-10-21 10:01     ` 2.6.14-rc5-rt1 Felix Oxley
  1 sibling, 1 reply; 117+ messages in thread
From: Mark Knecht @ 2005-10-21  0:39 UTC (permalink / raw)
  To: Felix Oxley
  Cc: Ingo Molnar, linux-kernel, Thomas Gleixner, Steven Rostedt,
	Fernando Lopez-Lezcano

On 10/20/05, Felix Oxley <lkml@oxley.org> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-20 23:55                 ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
@ 2005-10-21  8:05                   ` Ingo Molnar
  2005-10-21 23:25                     ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  0 siblings, 1 reply; 117+ messages in thread
From: Ingo Molnar @ 2005-10-21  8:05 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: William Weston, cc, linux-kernel, Thomas Gleixner,
	david singleton, Steven Rostedt, Rui Nuno Capela, Mark Knecht


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc5-rt1
  2005-10-20 23:33   ` 2.6.14-rc5-rt1 Felix Oxley
  2005-10-21  0:39     ` 2.6.14-rc5-rt1 Mark Knecht
@ 2005-10-21 10:01     ` Felix Oxley
  2005-10-21 10:16       ` 2.6.14-rc5-rt1 Ingo Molnar
  2005-10-21 10:18       ` 2.6.14-rc5-rt1 Felix Oxley
  1 sibling, 2 replies; 117+ messages in thread
From: Felix Oxley @ 2005-10-21 10:01 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt, Fernando Lopez-Lezcano


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 <lkml@oxley.org>
---
--- 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc5-rt1
  2005-10-21 10:01     ` 2.6.14-rc5-rt1 Felix Oxley
@ 2005-10-21 10:16       ` Ingo Molnar
  2005-10-21 10:18       ` 2.6.14-rc5-rt1 Felix Oxley
  1 sibling, 0 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-21 10:16 UTC (permalink / raw)
  To: Felix Oxley
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt, Fernando Lopez-Lezcano


* Felix Oxley <lkml@oxley.org> wrote:

> A second build error with make allyesconfig:

ah, indeed.

> Seems to be a probelm with definition ktimer_trace :
> 
> Signed-off-by: Felix Oxley <lkml@oxley.org>
> ---
> --- 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
 

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc5-rt1
  2005-10-21 10:01     ` 2.6.14-rc5-rt1 Felix Oxley
  2005-10-21 10:16       ` 2.6.14-rc5-rt1 Ingo Molnar
@ 2005-10-21 10:18       ` Felix Oxley
  2005-10-21 10:26         ` 2.6.14-rc5-rt1 Felix Oxley
  1 sibling, 1 reply; 117+ messages in thread
From: Felix Oxley @ 2005-10-21 10:18 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt, Fernando Lopez-Lezcano

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 <lkml@oxley.org>
> ---
> --- 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc5-rt1
  2005-10-21 10:18       ` 2.6.14-rc5-rt1 Felix Oxley
@ 2005-10-21 10:26         ` Felix Oxley
  2005-10-22 23:23           ` 2.6.14-rc5-rt1 Felix Oxley
  0 siblings, 1 reply; 117+ messages in thread
From: Felix Oxley @ 2005-10-21 10:26 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt, Fernando Lopez-Lezcano

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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc5-rt1
  2005-10-21  0:39     ` 2.6.14-rc5-rt1 Mark Knecht
@ 2005-10-21 13:47       ` Mark Knecht
  0 siblings, 0 replies; 117+ messages in thread
From: Mark Knecht @ 2005-10-21 13:47 UTC (permalink / raw)
  To: Felix Oxley
  Cc: Ingo Molnar, linux-kernel, Thomas Gleixner, Steven Rostedt,
	Fernando Lopez-Lezcano

On 10/20/05, Mark Knecht <markknecht@gmail.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-21  8:05                   ` 2.6.14-rc4-rt7 Ingo Molnar
@ 2005-10-21 23:25                     ` Fernando Lopez-Lezcano
  2005-10-22  0:20                       ` 2.6.14-rc4-rt7 Mark Knecht
  2005-10-22  3:58                       ` 2.6.14-rc4-rt7 Ingo Molnar
  0 siblings, 2 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-21 23:25 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, William Weston, cc, linux-kernel, Thomas Gleixner,
	david singleton, Steven Rostedt, Rui Nuno Capela, Mark Knecht

On Fri, 2005-10-21 at 10:05 +0200, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-21 23:25                     ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
@ 2005-10-22  0:20                       ` Mark Knecht
  2005-10-22  3:41                         ` 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-22  3:58                       ` 2.6.14-rc4-rt7 Ingo Molnar
  1 sibling, 1 reply; 117+ messages in thread
From: Mark Knecht @ 2005-10-22  0:20 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Ingo Molnar, William Weston, cc, linux-kernel, Thomas Gleixner,
	david singleton, Steven Rostedt, Rui Nuno Capela

On 10/21/05, Fernando Lopez-Lezcano <nando@ccrma.stanford.edu> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-22  0:20                       ` 2.6.14-rc4-rt7 Mark Knecht
@ 2005-10-22  3:41                         ` Ingo Molnar
  2005-10-22  5:12                           ` 2.6.14-rc4-rt7 Lee Revell
  0 siblings, 1 reply; 117+ messages in thread
From: Ingo Molnar @ 2005-10-22  3:41 UTC (permalink / raw)
  To: Mark Knecht
  Cc: Fernando Lopez-Lezcano, William Weston, cc, linux-kernel,
	Thomas Gleixner, david singleton, Steven Rostedt,
	Rui Nuno Capela


* Mark Knecht <markknecht@gmail.com> wrote:

> On 10/21/05, Fernando Lopez-Lezcano <nando@ccrma.stanford.edu> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-21 23:25                     ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  2005-10-22  0:20                       ` 2.6.14-rc4-rt7 Mark Knecht
@ 2005-10-22  3:58                       ` Ingo Molnar
  2005-10-24 19:28                         ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  1 sibling, 1 reply; 117+ messages in thread
From: Ingo Molnar @ 2005-10-22  3:58 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: William Weston, cc, linux-kernel, Thomas Gleixner,
	david singleton, Steven Rostedt, Rui Nuno Capela, Mark Knecht


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-22  3:41                         ` 2.6.14-rc4-rt7 Ingo Molnar
@ 2005-10-22  5:12                           ` Lee Revell
  2005-10-22 23:25                             ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  0 siblings, 1 reply; 117+ messages in thread
From: Lee Revell @ 2005-10-22  5:12 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Mark Knecht, Fernando Lopez-Lezcano, William Weston, cc,
	linux-kernel, Thomas Gleixner, david singleton, Steven Rostedt,
	Rui Nuno Capela

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


^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc5-rt1
  2005-10-21 10:26         ` 2.6.14-rc5-rt1 Felix Oxley
@ 2005-10-22 23:23           ` Felix Oxley
  2005-10-24 22:28             ` [ANNOUNCE] 2.6.14-rc5-rt5 kgdb update George Anzinger
  0 siblings, 1 reply; 117+ messages in thread
From: Felix Oxley @ 2005-10-22 23:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt, Fernando Lopez-Lezcano

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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-22  5:12                           ` 2.6.14-rc4-rt7 Lee Revell
@ 2005-10-22 23:25                             ` Fernando Lopez-Lezcano
  0 siblings, 0 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-22 23:25 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, Mark Knecht, William Weston, cc, linux-kernel,
	Thomas Gleixner, nando, david singleton, Steven Rostedt,
	Rui Nuno Capela

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-22  3:58                       ` 2.6.14-rc4-rt7 Ingo Molnar
@ 2005-10-24 19:28                         ` Fernando Lopez-Lezcano
  2005-10-24 19:38                           ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  0 siblings, 1 reply; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-24 19:28 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Mark Knecht, Rui Nuno Capela, Steven Rostedt, david singleton,
	Thomas Gleixner, linux-kernel, cc, William Weston, nando

On Sat, 2005-10-22 at 05:58 +0200, Ingo Molnar wrote: 
> * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-24 19:28                         ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
@ 2005-10-24 19:38                           ` Fernando Lopez-Lezcano
  2005-10-24 19:46                             ` 2.6.14-rc4-rt7 john stultz
  2005-10-24 20:39                             ` 2.6.14-rc4-rt7 Steven Rostedt
  0 siblings, 2 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-24 19:38 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, Mark Knecht, Rui Nuno Capela, Steven Rostedt,
	david singleton, Thomas Gleixner, linux-kernel, cc,
	William Weston

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 <nando@ccrma.Stanford.EDU> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-24 19:38                           ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
@ 2005-10-24 19:46                             ` john stultz
  2005-10-25  9:17                               ` 2.6.14-rc4-rt7 Antonio
  2005-10-25 15:44                               ` 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-24 20:39                             ` 2.6.14-rc4-rt7 Steven Rostedt
  1 sibling, 2 replies; 117+ messages in thread
From: john stultz @ 2005-10-24 19:46 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Ingo Molnar, Mark Knecht, Rui Nuno Capela, Steven Rostedt,
	david singleton, Thomas Gleixner, linux-kernel, cc,
	William Weston

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 <nando@ccrma.Stanford.EDU> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-24 19:38                           ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  2005-10-24 19:46                             ` 2.6.14-rc4-rt7 john stultz
@ 2005-10-24 20:39                             ` Steven Rostedt
  2005-10-24 21:00                               ` 2.6.14-rc4-rt7 Lee Revell
  1 sibling, 1 reply; 117+ messages in thread
From: Steven Rostedt @ 2005-10-24 20:39 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: john stultz, Ingo Molnar, Mark Knecht, Rui Nuno Capela,
	david singleton, Thomas Gleixner, linux-kernel, cc,
	William Weston

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 <nando@ccrma.Stanford.EDU> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-24 20:39                             ` 2.6.14-rc4-rt7 Steven Rostedt
@ 2005-10-24 21:00                               ` Lee Revell
  0 siblings, 0 replies; 117+ messages in thread
From: Lee Revell @ 2005-10-24 21:00 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Fernando Lopez-Lezcano, john stultz, Ingo Molnar, Mark Knecht,
	Rui Nuno Capela, david singleton, Thomas Gleixner, linux-kernel,
	cc, William Weston

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


^ permalink raw reply	[flat|nested] 117+ messages in thread

* [ANNOUNCE] 2.6.14-rc5-rt5 kgdb update
  2005-10-22 23:23           ` 2.6.14-rc5-rt1 Felix Oxley
@ 2005-10-24 22:28             ` George Anzinger
  2005-11-12 15:32               ` Ingo Molnar
  0 siblings, 1 reply; 117+ messages in thread
From: George Anzinger @ 2005-10-24 22:28 UTC (permalink / raw)
  To: Felix Oxley
  Cc: Ingo Molnar, linux-kernel, Thomas Gleixner, Steven Rostedt,
	Fernando Lopez-Lezcano

For those using kgdb on the rt kernel, I have just updated the patches at:
http://source.mvista.com/~ganzinger/
-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-24 19:46                             ` 2.6.14-rc4-rt7 john stultz
@ 2005-10-25  9:17                               ` Antonio
  2005-10-25 15:44                               ` 2.6.14-rc4-rt7 Ingo Molnar
  1 sibling, 0 replies; 117+ messages in thread
From: Antonio @ 2005-10-25  9:17 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-24 19:46                             ` 2.6.14-rc4-rt7 john stultz
  2005-10-25  9:17                               ` 2.6.14-rc4-rt7 Antonio
@ 2005-10-25 15:44                               ` Ingo Molnar
  2005-10-25 15:58                                 ` 2.6.14-rc4-rt7 linux-os (Dick Johnson)
                                                   ` (2 more replies)
  1 sibling, 3 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-25 15:44 UTC (permalink / raw)
  To: john stultz
  Cc: Fernando Lopez-Lezcano, Mark Knecht, Rui Nuno Capela,
	Steven Rostedt, david singleton, Thomas Gleixner, linux-kernel,
	cc, William Weston


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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-25 15:44                               ` 2.6.14-rc4-rt7 Ingo Molnar
@ 2005-10-25 15:58                                 ` linux-os (Dick Johnson)
  2005-10-25 17:35                                 ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  2005-10-25 18:16                                 ` 2.6.14-rc4-rt7 john stultz
  2 siblings, 0 replies; 117+ messages in thread
From: linux-os (Dick Johnson) @ 2005-10-25 15:58 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: john stultz, Fernando Lopez-Lezcano, Mark Knecht,
	Rui Nuno Capela, Steven Rostedt, david singleton,
	Thomas Gleixner, linux-kernel, cc, William Weston


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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-25 15:44                               ` 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-25 15:58                                 ` 2.6.14-rc4-rt7 linux-os (Dick Johnson)
@ 2005-10-25 17:35                                 ` Fernando Lopez-Lezcano
  2005-10-25 18:16                                 ` 2.6.14-rc4-rt7 john stultz
  2 siblings, 0 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-25 17:35 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, john stultz, Mark Knecht, Rui Nuno Capela, Steven Rostedt,
	david singleton, Thomas Gleixner, linux-kernel, cc,
	William Weston

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-25 15:44                               ` 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-25 15:58                                 ` 2.6.14-rc4-rt7 linux-os (Dick Johnson)
  2005-10-25 17:35                                 ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
@ 2005-10-25 18:16                                 ` john stultz
  2005-10-25 20:12                                   ` 2.6.14-rc4-rt7 George Anzinger
  2 siblings, 1 reply; 117+ messages in thread
From: john stultz @ 2005-10-25 18:16 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Fernando Lopez-Lezcano, Mark Knecht, Rui Nuno Capela,
	Steven Rostedt, david singleton, Thomas Gleixner, linux-kernel,
	cc, William Weston

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




^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-25 18:16                                 ` 2.6.14-rc4-rt7 john stultz
@ 2005-10-25 20:12                                   ` George Anzinger
  2005-10-26  8:28                                     ` 2.6.14-rc4-rt7 Ingo Molnar
  0 siblings, 1 reply; 117+ messages in thread
From: George Anzinger @ 2005-10-25 20:12 UTC (permalink / raw)
  To: john stultz
  Cc: Ingo Molnar, Fernando Lopez-Lezcano, Mark Knecht,
	Rui Nuno Capela, Steven Rostedt, david singleton,
	Thomas Gleixner, linux-kernel, cc, William Weston

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   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-25 20:12                                   ` 2.6.14-rc4-rt7 George Anzinger
@ 2005-10-26  8:28                                     ` Ingo Molnar
  2005-10-26 16:03                                       ` 2.6.14-rc4-rt7 George Anzinger
  2005-11-03 22:13                                       ` 2.6.14-rc4-rt7 - [PATCH] improved boot time TSC synchronization Jim Houston
  0 siblings, 2 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-26  8:28 UTC (permalink / raw)
  To: George Anzinger
  Cc: john stultz, Fernando Lopez-Lezcano, Mark Knecht,
	Rui Nuno Capela, Steven Rostedt, david singleton,
	Thomas Gleixner, linux-kernel, cc, William Weston


* George Anzinger <george@mvista.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26  8:28                                     ` 2.6.14-rc4-rt7 Ingo Molnar
@ 2005-10-26 16:03                                       ` George Anzinger
  2005-10-26 17:17                                         ` 2.6.14-rc4-rt7 George Anzinger
  2005-11-03 22:13                                       ` 2.6.14-rc4-rt7 - [PATCH] improved boot time TSC synchronization Jim Houston
  1 sibling, 1 reply; 117+ messages in thread
From: George Anzinger @ 2005-10-26 16:03 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: john stultz, Fernando Lopez-Lezcano, Mark Knecht,
	Rui Nuno Capela, Steven Rostedt, david singleton,
	Thomas Gleixner, linux-kernel, cc, William Weston

Ingo Molnar wrote:
> * George Anzinger <george@mvista.com> 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   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 16:03                                       ` 2.6.14-rc4-rt7 George Anzinger
@ 2005-10-26 17:17                                         ` George Anzinger
  2005-10-26 20:45                                           ` 2.6.14-rc4-rt7 Rui Nuno Capela
  0 siblings, 1 reply; 117+ messages in thread
From: George Anzinger @ 2005-10-26 17:17 UTC (permalink / raw)
  To: george
  Cc: Ingo Molnar, john stultz, Fernando Lopez-Lezcano, Mark Knecht,
	Rui Nuno Capela, Steven Rostedt, david singleton,
	Thomas Gleixner, linux-kernel, cc, William Weston

George Anzinger wrote:
> Ingo Molnar wrote:
> 
>> * George Anzinger <george@mvista.com> 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   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 17:17                                         ` 2.6.14-rc4-rt7 George Anzinger
@ 2005-10-26 20:45                                           ` Rui Nuno Capela
  2005-10-26 22:07                                             ` 2.6.14-rc4-rt7 William Weston
  0 siblings, 1 reply; 117+ messages in thread
From: Rui Nuno Capela @ 2005-10-26 20:45 UTC (permalink / raw)
  To: george
  Cc: Ingo Molnar, john stultz, Fernando Lopez-Lezcano, Mark Knecht,
	Steven Rostedt, david singleton, Thomas Gleixner, linux-kernel,
	cc, William Weston

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

Hi all,

Just noticed a couple or more of this on dmesg. Maybe its old news and 
being discussed already. Otherwise my P4@2.53Ghz/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
rncbc@rncbc.org



[-- Attachment #2: config-2.6.14-rc5-rt7.0.gz --]
[-- Type: application/gzip, Size: 9603 bytes --]

[-- Attachment #3: dmesg-2.6.14-rc5-rt7.0.gz --]
[-- Type: application/gzip, Size: 4947 bytes --]

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 20:45                                           ` 2.6.14-rc4-rt7 Rui Nuno Capela
@ 2005-10-26 22:07                                             ` William Weston
  2005-10-26 23:33                                               ` 2.6.14-rc4-rt7 john stultz
  2005-10-26 23:57                                               ` 2.6.14-rc4-rt7 Steven Rostedt
  0 siblings, 2 replies; 117+ messages in thread
From: William Weston @ 2005-10-26 22:07 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: george, Ingo Molnar, john stultz, Fernando Lopez-Lezcano,
	Mark Knecht, Steven Rostedt, david singleton, Thomas Gleixner,
	linux-kernel, cc

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6729 bytes --]

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 P4@2.53Ghz/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

[-- Attachment #2: Type: APPLICATION/x-gzip, Size: 8173 bytes --]

[-- Attachment #3: Type: APPLICATION/x-gzip, Size: 7436 bytes --]

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 22:07                                             ` 2.6.14-rc4-rt7 William Weston
@ 2005-10-26 23:33                                               ` john stultz
  2005-10-26 23:54                                                 ` 2.6.14-rc4-rt7 William Weston
                                                                   ` (2 more replies)
  2005-10-26 23:57                                               ` 2.6.14-rc4-rt7 Steven Rostedt
  1 sibling, 3 replies; 117+ messages in thread
From: john stultz @ 2005-10-26 23:33 UTC (permalink / raw)
  To: William Weston
  Cc: Rui Nuno Capela, george, Ingo Molnar, Fernando Lopez-Lezcano,
	Mark Knecht, Steven Rostedt, david singleton, Thomas Gleixner,
	linux-kernel, cc

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 P4@2.53Ghz/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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 23:33                                               ` 2.6.14-rc4-rt7 john stultz
@ 2005-10-26 23:54                                                 ` William Weston
  2005-10-26 23:58                                                 ` 2.6.14-rc4-rt7 Steven Rostedt
  2005-10-27  0:34                                                 ` 2.6.14-rc4-rt7 William Weston
  2 siblings, 0 replies; 117+ messages in thread
From: William Weston @ 2005-10-26 23:54 UTC (permalink / raw)
  To: john stultz
  Cc: Rui Nuno Capela, george, Ingo Molnar, Fernando Lopez-Lezcano,
	Mark Knecht, Steven Rostedt, david singleton, Thomas Gleixner,
	linux-kernel, cc

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 P4@2.53Ghz/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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 22:07                                             ` 2.6.14-rc4-rt7 William Weston
  2005-10-26 23:33                                               ` 2.6.14-rc4-rt7 john stultz
@ 2005-10-26 23:57                                               ` Steven Rostedt
  2005-10-27  0:02                                                 ` 2.6.14-rc4-rt7 William Weston
                                                                   ` (2 more replies)
  1 sibling, 3 replies; 117+ messages in thread
From: Steven Rostedt @ 2005-10-26 23:57 UTC (permalink / raw)
  To: William Weston
  Cc: Rui Nuno Capela, george, Ingo Molnar, john stultz,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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 P4@2.53Ghz/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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 23:33                                               ` 2.6.14-rc4-rt7 john stultz
  2005-10-26 23:54                                                 ` 2.6.14-rc4-rt7 William Weston
@ 2005-10-26 23:58                                                 ` Steven Rostedt
  2005-10-27  0:11                                                   ` 2.6.14-rc4-rt7 john stultz
  2005-10-27  0:34                                                 ` 2.6.14-rc4-rt7 William Weston
  2 siblings, 1 reply; 117+ messages in thread
From: Steven Rostedt @ 2005-10-26 23:58 UTC (permalink / raw)
  To: john stultz
  Cc: William Weston, Rui Nuno Capela, george, Ingo Molnar,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 23:57                                               ` 2.6.14-rc4-rt7 Steven Rostedt
@ 2005-10-27  0:02                                                 ` William Weston
  2005-10-27  0:45                                                 ` 2.6.14-rc4-rt7 john stultz
  2005-10-27  8:01                                                 ` 2.6.14-rc4-rt7 Rui Nuno Capela
  2 siblings, 0 replies; 117+ messages in thread
From: William Weston @ 2005-10-27  0:02 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Rui Nuno Capela, george, Ingo Molnar, john stultz,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 23:58                                                 ` 2.6.14-rc4-rt7 Steven Rostedt
@ 2005-10-27  0:11                                                   ` john stultz
  0 siblings, 0 replies; 117+ messages in thread
From: john stultz @ 2005-10-27  0:11 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: William Weston, Rui Nuno Capela, george, Ingo Molnar,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 23:33                                               ` 2.6.14-rc4-rt7 john stultz
  2005-10-26 23:54                                                 ` 2.6.14-rc4-rt7 William Weston
  2005-10-26 23:58                                                 ` 2.6.14-rc4-rt7 Steven Rostedt
@ 2005-10-27  0:34                                                 ` William Weston
  2 siblings, 0 replies; 117+ messages in thread
From: William Weston @ 2005-10-27  0:34 UTC (permalink / raw)
  To: john stultz
  Cc: Rui Nuno Capela, george, Ingo Molnar, Fernando Lopez-Lezcano,
	Mark Knecht, Steven Rostedt, david singleton, Thomas Gleixner,
	linux-kernel, cc

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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 23:57                                               ` 2.6.14-rc4-rt7 Steven Rostedt
  2005-10-27  0:02                                                 ` 2.6.14-rc4-rt7 William Weston
@ 2005-10-27  0:45                                                 ` john stultz
  2005-10-27  1:07                                                   ` 2.6.14-rc4-rt7 Steven Rostedt
  2005-10-27  8:01                                                 ` 2.6.14-rc4-rt7 Rui Nuno Capela
  2 siblings, 1 reply; 117+ messages in thread
From: john stultz @ 2005-10-27  0:45 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: William Weston, Rui Nuno Capela, george, Ingo Molnar,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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 P4@2.53Ghz/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




^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-27  0:45                                                 ` 2.6.14-rc4-rt7 john stultz
@ 2005-10-27  1:07                                                   ` Steven Rostedt
  2005-10-27  1:22                                                     ` 2.6.14-rc4-rt7 john stultz
  2005-10-27  1:26                                                     ` 2.6.14-rc4-rt7 Steven Rostedt
  0 siblings, 2 replies; 117+ messages in thread
From: Steven Rostedt @ 2005-10-27  1:07 UTC (permalink / raw)
  To: john stultz
  Cc: William Weston, Rui Nuno Capela, george, Ingo Molnar,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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;



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-27  1:07                                                   ` 2.6.14-rc4-rt7 Steven Rostedt
@ 2005-10-27  1:22                                                     ` john stultz
  2005-10-27  1:37                                                       ` 2.6.14-rc4-rt7 Steven Rostedt
  2005-10-27  1:26                                                     ` 2.6.14-rc4-rt7 Steven Rostedt
  1 sibling, 1 reply; 117+ messages in thread
From: john stultz @ 2005-10-27  1:22 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: William Weston, Rui Nuno Capela, george, Ingo Molnar,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-27  1:07                                                   ` 2.6.14-rc4-rt7 Steven Rostedt
  2005-10-27  1:22                                                     ` 2.6.14-rc4-rt7 john stultz
@ 2005-10-27  1:26                                                     ` Steven Rostedt
  1 sibling, 0 replies; 117+ messages in thread
From: Steven Rostedt @ 2005-10-27  1:26 UTC (permalink / raw)
  To: john stultz
  Cc: cc, linux-kernel, Thomas Gleixner, david singleton, Mark Knecht,
	Fernando Lopez-Lezcano, Ingo Molnar, george, Rui Nuno Capela,
	William Weston

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)) {



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-27  1:22                                                     ` 2.6.14-rc4-rt7 john stultz
@ 2005-10-27  1:37                                                       ` Steven Rostedt
  2005-10-27  1:52                                                         ` 2.6.14-rc4-rt7 john stultz
  0 siblings, 1 reply; 117+ messages in thread
From: Steven Rostedt @ 2005-10-27  1:37 UTC (permalink / raw)
  To: john stultz
  Cc: William Weston, Rui Nuno Capela, george, Ingo Molnar,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-27  1:37                                                       ` 2.6.14-rc4-rt7 Steven Rostedt
@ 2005-10-27  1:52                                                         ` john stultz
  2005-10-27  2:11                                                           ` 2.6.14-rc4-rt7 Steven Rostedt
  0 siblings, 1 reply; 117+ messages in thread
From: john stultz @ 2005-10-27  1:52 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: William Weston, Rui Nuno Capela, george, Ingo Molnar,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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


^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-27  1:52                                                         ` 2.6.14-rc4-rt7 john stultz
@ 2005-10-27  2:11                                                           ` Steven Rostedt
  2005-10-27 22:01                                                             ` 2.6.14-rc4-rt7 William Weston
  0 siblings, 1 reply; 117+ messages in thread
From: Steven Rostedt @ 2005-10-27  2:11 UTC (permalink / raw)
  To: john stultz
  Cc: William Weston, Rui Nuno Capela, george, Ingo Molnar,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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();
 }
 



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-26 23:57                                               ` 2.6.14-rc4-rt7 Steven Rostedt
  2005-10-27  0:02                                                 ` 2.6.14-rc4-rt7 William Weston
  2005-10-27  0:45                                                 ` 2.6.14-rc4-rt7 john stultz
@ 2005-10-27  8:01                                                 ` Rui Nuno Capela
  2005-10-27 17:44                                                   ` 2.6.14-rc4-rt7 Steven Rostedt
  2 siblings, 1 reply; 117+ messages in thread
From: Rui Nuno Capela @ 2005-10-27  8:01 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: William Weston, george, Ingo Molnar, john stultz,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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 P4@2.53Ghz/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
rncbc@rncbc.org



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-27  8:01                                                 ` 2.6.14-rc4-rt7 Rui Nuno Capela
@ 2005-10-27 17:44                                                   ` Steven Rostedt
  2005-10-27 23:18                                                     ` 2.6.14-rc4-rt7 Rui Nuno Capela
  2005-10-28 17:13                                                     ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  0 siblings, 2 replies; 117+ messages in thread
From: Steven Rostedt @ 2005-10-27 17:44 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: William Weston, george, Ingo Molnar, john stultz,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-27  2:11                                                           ` 2.6.14-rc4-rt7 Steven Rostedt
@ 2005-10-27 22:01                                                             ` William Weston
  2005-10-27 22:32                                                               ` 2.6.14-rc4-rt7 Steven Rostedt
  0 siblings, 1 reply; 117+ messages in thread
From: William Weston @ 2005-10-27 22:01 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: john stultz, Rui Nuno Capela, george, Ingo Molnar,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-27 22:01                                                             ` 2.6.14-rc4-rt7 William Weston
@ 2005-10-27 22:32                                                               ` Steven Rostedt
  0 siblings, 0 replies; 117+ messages in thread
From: Steven Rostedt @ 2005-10-27 22:32 UTC (permalink / raw)
  To: William Weston
  Cc: john stultz, Rui Nuno Capela, george, Ingo Molnar,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

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;
}



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-27 17:44                                                   ` 2.6.14-rc4-rt7 Steven Rostedt
@ 2005-10-27 23:18                                                     ` Rui Nuno Capela
  2005-10-28 17:13                                                     ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
  1 sibling, 0 replies; 117+ messages in thread
From: Rui Nuno Capela @ 2005-10-27 23:18 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: William Weston, george, Ingo Molnar, john stultz,
	Fernando Lopez-Lezcano, Mark Knecht, david singleton,
	Thomas Gleixner, linux-kernel, cc

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

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
rncbc@rncbc.org

[-- Attachment #2: patch-2.6.14-rc5-rt7_timeofday.patch --]
[-- Type: text/x-patch, Size: 1014 bytes --]

--- linux-2.6.14-rc5-rt7.0/kernel/time/timeofday.c	2005-10-26 16:57:03.000000000 -0400
+++ linux-2.6.14-rc5-rt7.1/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();
 }
 


^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7
  2005-10-27 17:44                                                   ` 2.6.14-rc4-rt7 Steven Rostedt
  2005-10-27 23:18                                                     ` 2.6.14-rc4-rt7 Rui Nuno Capela
@ 2005-10-28 17:13                                                     ` Fernando Lopez-Lezcano
  1 sibling, 0 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-28 17:13 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: nando, Rui Nuno Capela, William Weston, george, Ingo Molnar,
	john stultz, Mark Knecht, david singleton, Thomas Gleixner,
	linux-kernel, cc

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* 2.6.14-rt1
  2005-10-20 19:54 ` 2.6.14-rc5-rt1 Ingo Molnar
  2005-10-20 23:33   ` 2.6.14-rc5-rt1 Felix Oxley
@ 2005-10-30 13:33   ` Ingo Molnar
  2005-10-30 14:58     ` 2.6.14-rt1 K.R. Foley
                       ` (5 more replies)
  1 sibling, 6 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-30 13:33 UTC (permalink / raw)
  To: linux-kernel
  Cc: Thomas Gleixner, Steven Rostedt, Fernando Lopez-Lezcano,
	Mark Knecht, john stultz, Florian Schmidt, K.R. Foley,
	Rui Nuno Capela


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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-10-30 13:33   ` 2.6.14-rt1 Ingo Molnar
@ 2005-10-30 14:58     ` K.R. Foley
  2005-10-30 15:41       ` 2.6.14-rt1 Steven Rostedt
  2005-10-30 17:19       ` 2.6.14-rt1 Ingo Molnar
  2005-10-30 16:30     ` 2.6.14-rt1 Mark Knecht
                       ` (4 subsequent siblings)
  5 siblings, 2 replies; 117+ messages in thread
From: K.R. Foley @ 2005-10-30 14:58 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt,
	Fernando Lopez-Lezcano, Mark Knecht, john stultz,
	Florian Schmidt, Rui Nuno Capela

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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-10-30 14:58     ` 2.6.14-rt1 K.R. Foley
@ 2005-10-30 15:41       ` Steven Rostedt
  2005-10-30 17:17         ` 2.6.14-rt1 Ingo Molnar
  2005-10-30 17:19       ` 2.6.14-rt1 Ingo Molnar
  1 sibling, 1 reply; 117+ messages in thread
From: Steven Rostedt @ 2005-10-30 15:41 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, linux-kernel, Thomas Gleixner,
	Fernando Lopez-Lezcano, Mark Knecht, john stultz,
	Florian Schmidt, Rui Nuno Capela


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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-10-30 13:33   ` 2.6.14-rt1 Ingo Molnar
  2005-10-30 14:58     ` 2.6.14-rt1 K.R. Foley
@ 2005-10-30 16:30     ` Mark Knecht
  2005-10-31 18:13     ` 2.6.14-rt1 Fernando Lopez-Lezcano
                       ` (3 subsequent siblings)
  5 siblings, 0 replies; 117+ messages in thread
From: Mark Knecht @ 2005-10-30 16:30 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt,
	Fernando Lopez-Lezcano, john stultz, Florian Schmidt, K.R. Foley,
	Rui Nuno Capela

On 10/30/05, Ingo Molnar <mingo@elte.hu> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-10-30 15:41       ` 2.6.14-rt1 Steven Rostedt
@ 2005-10-30 17:17         ` Ingo Molnar
  0 siblings, 0 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-30 17:17 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: K.R. Foley, linux-kernel, Thomas Gleixner,
	Fernando Lopez-Lezcano, Mark Knecht, john stultz,
	Florian Schmidt, Rui Nuno Capela


* Steven Rostedt <rostedt@goodmis.org> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-10-30 14:58     ` 2.6.14-rt1 K.R. Foley
  2005-10-30 15:41       ` 2.6.14-rt1 Steven Rostedt
@ 2005-10-30 17:19       ` Ingo Molnar
  1 sibling, 0 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-10-30 17:19 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt,
	Fernando Lopez-Lezcano, Mark Knecht, john stultz,
	Florian Schmidt, Rui Nuno Capela


* K.R. Foley <kr@cybsft.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-10-30 13:33   ` 2.6.14-rt1 Ingo Molnar
  2005-10-30 14:58     ` 2.6.14-rt1 K.R. Foley
  2005-10-30 16:30     ` 2.6.14-rt1 Mark Knecht
@ 2005-10-31 18:13     ` Fernando Lopez-Lezcano
  2005-11-01 20:18     ` 2.6.14-rt1 Fernando Lopez-Lezcano
                       ` (2 subsequent siblings)
  5 siblings, 0 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-10-31 18:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, linux-kernel, Thomas Gleixner, Steven Rostedt,
	Mark Knecht, john stultz, Florian Schmidt, K.R. Foley,
	Rui Nuno Capela

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-10-30 13:33   ` 2.6.14-rt1 Ingo Molnar
                       ` (2 preceding siblings ...)
  2005-10-31 18:13     ` 2.6.14-rt1 Fernando Lopez-Lezcano
@ 2005-11-01 20:18     ` Fernando Lopez-Lezcano
  2005-11-02  2:47       ` 2.6.14-rt1 Fernando Lopez-Lezcano
  2005-11-02  7:02       ` 2.6.14-rt1 Ingo Molnar
  2005-11-02 21:41     ` 2.6.14-rt4: __get_nsec_offset() false positives john stultz
  2005-11-05  2:35     ` 2.6.14-rt1 (now rt6) Fernando Lopez-Lezcano
  5 siblings, 2 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-11-01 20:18 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, K.R. Foley, Florian Schmidt, john stultz,
	Mark Knecht, Steven Rostedt, Thomas Gleixner, linux-kernel,
	nando

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-01 20:18     ` 2.6.14-rt1 Fernando Lopez-Lezcano
@ 2005-11-02  2:47       ` Fernando Lopez-Lezcano
  2005-11-02  2:55         ` 2.6.14-rt1 Carlos Antunes
  2005-11-02  7:02       ` 2.6.14-rt1 Ingo Molnar
  1 sibling, 1 reply; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-11-02  2:47 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, Rui Nuno Capela, K.R. Foley, Florian Schmidt, john stultz,
	Mark Knecht, Steven Rostedt, Thomas Gleixner, linux-kernel

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02  2:47       ` 2.6.14-rt1 Fernando Lopez-Lezcano
@ 2005-11-02  2:55         ` Carlos Antunes
  2005-11-02  3:05           ` 2.6.14-rt1 Steven Rostedt
  2005-11-02 18:13           ` 2.6.14-rt1 Fernando Lopez-Lezcano
  0 siblings, 2 replies; 117+ messages in thread
From: Carlos Antunes @ 2005-11-02  2:55 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Ingo Molnar, Rui Nuno Capela, K.R. Foley, Florian Schmidt,
	john stultz, Mark Knecht, Steven Rostedt, Thomas Gleixner,
	linux-kernel

On 11/1/05, Fernando Lopez-Lezcano <nando@ccrma.stanford.edu> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02  2:55         ` 2.6.14-rt1 Carlos Antunes
@ 2005-11-02  3:05           ` Steven Rostedt
  2005-11-02  3:26             ` 2.6.14-rt1 Carlos Antunes
  2005-11-02 18:13           ` 2.6.14-rt1 Fernando Lopez-Lezcano
  1 sibling, 1 reply; 117+ messages in thread
From: Steven Rostedt @ 2005-11-02  3:05 UTC (permalink / raw)
  To: Carlos Antunes
  Cc: Fernando Lopez-Lezcano, Ingo Molnar, Rui Nuno Capela, K.R. Foley,
	Florian Schmidt, john stultz, Mark Knecht, Thomas Gleixner,
	linux-kernel

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02  3:05           ` 2.6.14-rt1 Steven Rostedt
@ 2005-11-02  3:26             ` Carlos Antunes
  2005-11-02  3:32               ` 2.6.14-rt1 Steven Rostedt
  0 siblings, 1 reply; 117+ messages in thread
From: Carlos Antunes @ 2005-11-02  3:26 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Fernando Lopez-Lezcano, Ingo Molnar, Rui Nuno Capela, K.R. Foley,
	Florian Schmidt, john stultz, Mark Knecht, Thomas Gleixner,
	linux-kernel

On 11/1/05, Steven Rostedt <rostedt@goodmis.org> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02  3:26             ` 2.6.14-rt1 Carlos Antunes
@ 2005-11-02  3:32               ` Steven Rostedt
  2005-11-02  3:36                 ` 2.6.14-rt1 Carlos Antunes
  2005-11-02  4:05                 ` 2.6.14-rt1 Carlos Antunes
  0 siblings, 2 replies; 117+ messages in thread
From: Steven Rostedt @ 2005-11-02  3:32 UTC (permalink / raw)
  To: Carlos Antunes
  Cc: Fernando Lopez-Lezcano, Ingo Molnar, Rui Nuno Capela, K.R. Foley,
	Florian Schmidt, john stultz, Mark Knecht, Thomas Gleixner,
	linux-kernel

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02  3:32               ` 2.6.14-rt1 Steven Rostedt
@ 2005-11-02  3:36                 ` Carlos Antunes
  2005-11-02  4:05                 ` 2.6.14-rt1 Carlos Antunes
  1 sibling, 0 replies; 117+ messages in thread
From: Carlos Antunes @ 2005-11-02  3:36 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Fernando Lopez-Lezcano, Ingo Molnar, Rui Nuno Capela, K.R. Foley,
	Florian Schmidt, john stultz, Mark Knecht, Thomas Gleixner,
	linux-kernel

On 11/1/05, Steven Rostedt <rostedt@goodmis.org> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02  3:32               ` 2.6.14-rt1 Steven Rostedt
  2005-11-02  3:36                 ` 2.6.14-rt1 Carlos Antunes
@ 2005-11-02  4:05                 ` Carlos Antunes
  2005-11-02  9:21                   ` 2.6.14-rt1 Florian Schmidt
  1 sibling, 1 reply; 117+ messages in thread
From: Carlos Antunes @ 2005-11-02  4:05 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Fernando Lopez-Lezcano, Ingo Molnar, Rui Nuno Capela, K.R. Foley,
	Florian Schmidt, john stultz, Mark Knecht, Thomas Gleixner,
	linux-kernel

On 11/1/05, Steven Rostedt <rostedt@goodmis.org> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-01 20:18     ` 2.6.14-rt1 Fernando Lopez-Lezcano
  2005-11-02  2:47       ` 2.6.14-rt1 Fernando Lopez-Lezcano
@ 2005-11-02  7:02       ` Ingo Molnar
  2005-11-02 18:13         ` 2.6.14-rt1 Fernando Lopez-Lezcano
  2005-11-04  7:04         ` 2.6.14-rt1 Fernando Lopez-Lezcano
  1 sibling, 2 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-11-02  7:02 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Rui Nuno Capela, K.R. Foley, Florian Schmidt, john stultz,
	Mark Knecht, Steven Rostedt, Thomas Gleixner, linux-kernel


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02  4:05                 ` 2.6.14-rt1 Carlos Antunes
@ 2005-11-02  9:21                   ` Florian Schmidt
  2005-11-02 14:35                     ` 2.6.14-rt1 Carlos Antunes
  0 siblings, 1 reply; 117+ messages in thread
From: Florian Schmidt @ 2005-11-02  9:21 UTC (permalink / raw)
  To: Carlos Antunes
  Cc: Steven Rostedt, Fernando Lopez-Lezcano, Ingo Molnar,
	Rui Nuno Capela, K.R. Foley, john stultz, Mark Knecht,
	Thomas Gleixner, linux-kernel

On Tue, 1 Nov 2005 23:05:09 -0500
Carlos Antunes <cmantunes@gmail.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02  9:21                   ` 2.6.14-rt1 Florian Schmidt
@ 2005-11-02 14:35                     ` Carlos Antunes
  2005-11-02 14:40                       ` 2.6.14-rt1 Ingo Molnar
  0 siblings, 1 reply; 117+ messages in thread
From: Carlos Antunes @ 2005-11-02 14:35 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Steven Rostedt, Fernando Lopez-Lezcano, Ingo Molnar,
	Rui Nuno Capela, K.R. Foley, john stultz, Mark Knecht,
	Thomas Gleixner, linux-kernel

On 11/2/05, Florian Schmidt <mista.tapas@gmx.net> wrote:
> On Tue, 1 Nov 2005 23:05:09 -0500
> Carlos Antunes <cmantunes@gmail.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02 14:35                     ` 2.6.14-rt1 Carlos Antunes
@ 2005-11-02 14:40                       ` Ingo Molnar
  2005-11-02 14:45                         ` 2.6.14-rt1 Carlos Antunes
  0 siblings, 1 reply; 117+ messages in thread
From: Ingo Molnar @ 2005-11-02 14:40 UTC (permalink / raw)
  To: Carlos Antunes
  Cc: Florian Schmidt, Steven Rostedt, Fernando Lopez-Lezcano,
	Rui Nuno Capela, K.R. Foley, john stultz, Mark Knecht,
	Thomas Gleixner, linux-kernel


* Carlos Antunes <cmantunes@gmail.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02 14:40                       ` 2.6.14-rt1 Ingo Molnar
@ 2005-11-02 14:45                         ` Carlos Antunes
  2005-11-02 15:37                           ` 2.6.14-rt1 Steven Rostedt
  0 siblings, 1 reply; 117+ messages in thread
From: Carlos Antunes @ 2005-11-02 14:45 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Florian Schmidt, Steven Rostedt, Fernando Lopez-Lezcano,
	Rui Nuno Capela, K.R. Foley, john stultz, Mark Knecht,
	Thomas Gleixner, linux-kernel

On 11/2/05, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Carlos Antunes <cmantunes@gmail.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02 14:45                         ` 2.6.14-rt1 Carlos Antunes
@ 2005-11-02 15:37                           ` Steven Rostedt
  2005-11-02 16:07                             ` 2.6.14-rt1 Carlos Antunes
  0 siblings, 1 reply; 117+ messages in thread
From: Steven Rostedt @ 2005-11-02 15:37 UTC (permalink / raw)
  To: Carlos Antunes
  Cc: Ingo Molnar, Florian Schmidt, Fernando Lopez-Lezcano,
	Rui Nuno Capela, K.R. Foley, john stultz, Mark Knecht,
	Thomas Gleixner, linux-kernel

On Wed, 2005-11-02 at 09:45 -0500, Carlos Antunes wrote:
> On 11/2/05, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Carlos Antunes <cmantunes@gmail.com> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02 15:37                           ` 2.6.14-rt1 Steven Rostedt
@ 2005-11-02 16:07                             ` Carlos Antunes
  2005-11-02 16:24                               ` 2.6.14-rt1 Steven Rostedt
  2005-11-02 16:37                               ` 2.6.14-rt1 Steven Rostedt
  0 siblings, 2 replies; 117+ messages in thread
From: Carlos Antunes @ 2005-11-02 16:07 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, Florian Schmidt, Fernando Lopez-Lezcano,
	Rui Nuno Capela, K.R. Foley, john stultz, Mark Knecht,
	Thomas Gleixner, linux-kernel

On 11/2/05, Steven Rostedt <rostedt@goodmis.org> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02 16:07                             ` 2.6.14-rt1 Carlos Antunes
@ 2005-11-02 16:24                               ` Steven Rostedt
  2005-11-02 16:53                                 ` 2.6.14-rt1 Carlos Antunes
  2005-11-02 16:37                               ` 2.6.14-rt1 Steven Rostedt
  1 sibling, 1 reply; 117+ messages in thread
From: Steven Rostedt @ 2005-11-02 16:24 UTC (permalink / raw)
  To: Carlos Antunes
  Cc: Ingo Molnar, Florian Schmidt, Fernando Lopez-Lezcano,
	Rui Nuno Capela, K.R. Foley, john stultz, Mark Knecht,
	Thomas Gleixner, linux-kernel

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


^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02 16:07                             ` 2.6.14-rt1 Carlos Antunes
  2005-11-02 16:24                               ` 2.6.14-rt1 Steven Rostedt
@ 2005-11-02 16:37                               ` Steven Rostedt
  1 sibling, 0 replies; 117+ messages in thread
From: Steven Rostedt @ 2005-11-02 16:37 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: john stultz, Thomas Gleixner, linux-kernel

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02 16:24                               ` 2.6.14-rt1 Steven Rostedt
@ 2005-11-02 16:53                                 ` Carlos Antunes
  0 siblings, 0 replies; 117+ messages in thread
From: Carlos Antunes @ 2005-11-02 16:53 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, Florian Schmidt, Fernando Lopez-Lezcano,
	Rui Nuno Capela, K.R. Foley, john stultz, Mark Knecht,
	Thomas Gleixner, linux-kernel

On 11/2/05, Steven Rostedt <rostedt@goodmis.org> 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 <paulmck@us.ibm.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02  2:55         ` 2.6.14-rt1 Carlos Antunes
  2005-11-02  3:05           ` 2.6.14-rt1 Steven Rostedt
@ 2005-11-02 18:13           ` Fernando Lopez-Lezcano
  1 sibling, 0 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-11-02 18:13 UTC (permalink / raw)
  To: Carlos Antunes
  Cc: Ingo Molnar, Rui Nuno Capela, K.R. Foley, Florian Schmidt,
	john stultz, Mark Knecht, Steven Rostedt, Thomas Gleixner,
	linux-kernel

On Tue, 2005-11-01 at 21:55 -0500, Carlos Antunes wrote:
> On 11/1/05, Fernando Lopez-Lezcano <nando@ccrma.stanford.edu> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02  7:02       ` 2.6.14-rt1 Ingo Molnar
@ 2005-11-02 18:13         ` Fernando Lopez-Lezcano
  2005-11-04  7:04         ` 2.6.14-rt1 Fernando Lopez-Lezcano
  1 sibling, 0 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-11-02 18:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, K.R. Foley, Florian Schmidt, john stultz,
	Mark Knecht, Steven Rostedt, Thomas Gleixner, linux-kernel

On Wed, 2005-11-02 at 08:02 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* 2.6.14-rt4:  __get_nsec_offset() false positives
  2005-10-30 13:33   ` 2.6.14-rt1 Ingo Molnar
                       ` (3 preceding siblings ...)
  2005-11-01 20:18     ` 2.6.14-rt1 Fernando Lopez-Lezcano
@ 2005-11-02 21:41     ` john stultz
  2005-11-03  6:53       ` Ingo Molnar
  2005-11-05  2:35     ` 2.6.14-rt1 (now rt6) Fernando Lopez-Lezcano
  5 siblings, 1 reply; 117+ messages in thread
From: john stultz @ 2005-11-02 21:41 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt,
	Fernando Lopez-Lezcano, Mark Knecht, Florian Schmidt, K.R. Foley,
	Rui Nuno Capela

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







^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt4:  __get_nsec_offset() false positives
  2005-11-02 21:41     ` 2.6.14-rt4: __get_nsec_offset() false positives john stultz
@ 2005-11-03  6:53       ` Ingo Molnar
  0 siblings, 0 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-11-03  6:53 UTC (permalink / raw)
  To: john stultz
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt,
	Fernando Lopez-Lezcano, Mark Knecht, Florian Schmidt, K.R. Foley,
	Rui Nuno Capela


* john stultz <johnstul@us.ibm.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rc4-rt7 - [PATCH] improved boot time TSC synchronization
  2005-10-26  8:28                                     ` 2.6.14-rc4-rt7 Ingo Molnar
  2005-10-26 16:03                                       ` 2.6.14-rc4-rt7 George Anzinger
@ 2005-11-03 22:13                                       ` Jim Houston
  1 sibling, 0 replies; 117+ messages in thread
From: Jim Houston @ 2005-11-03 22:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: George Anzinger, john stultz, Fernando Lopez-Lezcano,
	Mark Knecht, Rui Nuno Capela, Steven Rostedt, david singleton,
	Thomas Gleixner, linux-kernel, cc, William Weston

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);
 




^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1
  2005-11-02  7:02       ` 2.6.14-rt1 Ingo Molnar
  2005-11-02 18:13         ` 2.6.14-rt1 Fernando Lopez-Lezcano
@ 2005-11-04  7:04         ` Fernando Lopez-Lezcano
  1 sibling, 0 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-11-04  7:04 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, Rui Nuno Capela, K.R. Foley, Florian Schmidt, john stultz,
	Mark Knecht, Steven Rostedt, Thomas Gleixner, linux-kernel

On Wed, 2005-11-02 at 08:02 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1 (now rt6)
  2005-10-30 13:33   ` 2.6.14-rt1 Ingo Molnar
                       ` (4 preceding siblings ...)
  2005-11-02 21:41     ` 2.6.14-rt4: __get_nsec_offset() false positives john stultz
@ 2005-11-05  2:35     ` Fernando Lopez-Lezcano
  2005-11-05  3:46       ` Mark Knecht
                         ` (2 more replies)
  5 siblings, 3 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-11-05  2:35 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, linux-kernel, Thomas Gleixner, Steven Rostedt,
	Mark Knecht, john stultz, Florian Schmidt, K.R. Foley,
	Rui Nuno Capela

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



^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1 (now rt6)
  2005-11-05  2:35     ` 2.6.14-rt1 (now rt6) Fernando Lopez-Lezcano
@ 2005-11-05  3:46       ` Mark Knecht
  2005-11-09 11:22       ` Ingo Molnar
  2005-11-10 12:15       ` Ingo Molnar
  2 siblings, 0 replies; 117+ messages in thread
From: Mark Knecht @ 2005-11-05  3:46 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Ingo Molnar, linux-kernel, Thomas Gleixner, Steven Rostedt,
	john stultz, Florian Schmidt, K.R. Foley, Rui Nuno Capela

On 11/4/05, Fernando Lopez-Lezcano <nando@ccrma.stanford.edu> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1 (now rt6)
  2005-11-05  2:35     ` 2.6.14-rt1 (now rt6) Fernando Lopez-Lezcano
  2005-11-05  3:46       ` Mark Knecht
@ 2005-11-09 11:22       ` Ingo Molnar
  2005-11-10 12:15       ` Ingo Molnar
  2 siblings, 0 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-11-09 11:22 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt, Mark Knecht,
	john stultz, Florian Schmidt, K.R. Foley, Rui Nuno Capela


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1 (now rt6)
  2005-11-05  2:35     ` 2.6.14-rt1 (now rt6) Fernando Lopez-Lezcano
  2005-11-05  3:46       ` Mark Knecht
  2005-11-09 11:22       ` Ingo Molnar
@ 2005-11-10 12:15       ` Ingo Molnar
  2005-11-10 22:10         ` Fernando Lopez-Lezcano
  2 siblings, 1 reply; 117+ messages in thread
From: Ingo Molnar @ 2005-11-10 12:15 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: linux-kernel, Thomas Gleixner, Steven Rostedt, Mark Knecht,
	john stultz, Florian Schmidt, K.R. Foley, Rui Nuno Capela


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: 2.6.14-rt1 (now rt6)
  2005-11-10 12:15       ` Ingo Molnar
@ 2005-11-10 22:10         ` Fernando Lopez-Lezcano
  0 siblings, 0 replies; 117+ messages in thread
From: Fernando Lopez-Lezcano @ 2005-11-10 22:10 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: nando, linux-kernel, Thomas Gleixner, Steven Rostedt,
	Mark Knecht, john stultz, Florian Schmidt, K.R. Foley,
	Rui Nuno Capela

[-- Attachment #1: Type: text/plain, Size: 1961 bytes --]

On Thu, 2005-11-10 at 13:15 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> 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


[-- Attachment #2: kernel-2.6.14-i686-smp.ccrma.config --]
[-- Type: text/plain, Size: 60121 bytes --]

# i386
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.14-rc4-rt1
# Tue Oct 11 12:46:58 2005
#
CONFIG_X86=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_GENERICTOD=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_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_CPUSETS is not set
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
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=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_MODULE_SIG=y
# CONFIG_MODULE_SIG_FORCE is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_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_PPRO_FENCE=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=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_KTIME_SCALAR is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=32
CONFIG_SCHED_SMT=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT_DESKTOP=y
# CONFIG_PREEMPT_RT is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
# CONFIG_SPINLOCK_BKL is not set
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STATS=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_ASM_SEMAPHORES=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_IOAPIC_FAST is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_TOSHIBA=m
CONFIG_I8K=m
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
CONFIG_EDD=m
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
# CONFIG_IRQBALANCE 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
CONFIG_SUSPEND_SMP=y

#
# 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=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_HOTKEY=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_IBM=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_ACPI_BLACKLIST_YEAR=2001
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_POWERNOW_K6=m
CONFIG_X86_POWERNOW_K7=y
CONFIG_X86_POWERNOW_K7_ACPI=y
CONFIG_X86_POWERNOW_K8=m
CONFIG_X86_POWERNOW_K8_ACPI=y
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
# CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE is not set
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_X86_SPEEDSTEP_SMI=m
CONFIG_X86_P4_CLOCKMOD=m
CONFIG_X86_CPUFREQ_NFORCE2=m
CONFIG_X86_LONGRUN=y
CONFIG_X86_LONGHAUL=y

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_X86_SPEEDSTEP_LIB=y
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK 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=y
CONFIG_HOTPLUG_PCI_PCIE=m
# CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY_PROC=y
# 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
CONFIG_HOTPLUG_CPU=y

#
# PCCARD (PCMCIA/CardBus) support
#
CONFIG_PCCARD=m
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=m
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=m
CONFIG_PD6729=m
CONFIG_I82092=m
CONFIG_I82365=m
CONFIG_TCIC=m
CONFIG_PCMCIA_PROBE=y
CONFIG_PCCARD_NONSTATIC=m

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
CONFIG_HOTPLUG_PCI_COMPAQ=m
# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
CONFIG_HOTPLUG_PCI_IBM=m
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_SHPC=m
CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE=y

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y

#
# IP: Virtual Server Configuration
#
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_INET6_TUNNEL=m
CONFIG_IPV6_TUNNEL=m
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
CONFIG_IP_NF_CONNTRACK_NETLINK=m
CONFIG_IP_NF_CT_PROTO_SCTP=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_NETBIOS_NS=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_PPTP=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_PHYSDEV=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
CONFIG_IP_NF_MATCH_SCTP=m
CONFIG_IP_NF_MATCH_DCCP=m
CONFIG_IP_NF_MATCH_COMMENT=m
CONFIG_IP_NF_MATCH_CONNMARK=m
CONFIG_IP_NF_MATCH_CONNBYTES=m
CONFIG_IP_NF_MATCH_HASHLIMIT=m
CONFIG_IP_NF_MATCH_STRING=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_TARGET_NFQUEUE=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_NAT_PPTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_TARGET_CONNMARK=m
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_MATCH_PHYSDEV=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_TARGET_NFQUEUE=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_RAW=m

#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m

#
# DCCP Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m

#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP_CCID3=m
CONFIG_IP_DCCP_TFRC_LIB=m

#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
# CONFIG_IP_DCCP_UNLOAD_HACK is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
# CONFIG_ATM_MPOA is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=y
CONFIG_LTPC=m
CONFIG_COPS=m
CONFIG_COPS_DAYNA=y
CONFIG_COPS_TANGENT=y
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
CONFIG_NET_DIVERT=y
# CONFIG_ECONET is not set
CONFIG_WAN_ROUTER=m
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_ATM=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_NET_CLS_IND=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
# CONFIG_NET_EMATCH_TEXT is not set
CONFIG_NET_CLS_ACT=y
# CONFIG_NET_ACT_POLICE is not set
CONFIG_NET_ACT_GACT=m
# CONFIG_GACT_PROB is not set
CONFIG_NET_ACT_MIRRED=m
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
CONFIG_IRDA=m

#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
# CONFIG_IRDA_ULTRA is not set

#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m

#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
CONFIG_LITELINK_DONGLE=m
CONFIG_MA600_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_MCP2120_DONGLE=m
CONFIG_OLD_BELKIN_DONGLE=m
CONFIG_ACT200L_DONGLE=m

#
# Old SIR device drivers
#

#
# Old Serial dongle support
#

#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_SIGMATEL_FIR=m
CONFIG_NSC_FIR=m
# CONFIG_WINBOND_FIR is not set
# CONFIG_TOSHIBA_FIR is not set
# CONFIG_SMC_IRCC_FIR is not set
# CONFIG_ALI_FIR is not set
# CONFIG_VLSI_FIR is not set
# CONFIG_VIA_FIR is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_CMTP=m
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_BCSP_TXCRC=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
CONFIG_IEEE80211=m
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=m
CONFIG_IEEE80211_CRYPT_CCMP=m
CONFIG_IEEE80211_CRYPT_TKIP=m

#
# Device Drivers
#

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

#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=m

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=m
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
# CONFIG_MTD_REDBOOT_PARTS_READONLY is not set
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
CONFIG_INFTL=m

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_AMDSTD_RETRY=3
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_CFI_UTIL=m
CONFIG_MTD_RAM=m
CONFIG_MTD_ROM=m
CONFIG_MTD_ABSENT=m

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PNC2000 is not set
CONFIG_MTD_SC520CDP=m
CONFIG_MTD_NETSC520=m
CONFIG_MTD_TS5500=m
CONFIG_MTD_SBC_GXX=m
CONFIG_MTD_AMD76XROM=m
# CONFIG_MTD_ICHXROM is not set
CONFIG_MTD_SCB2_FLASH=m
# CONFIG_MTD_NETtel is not set
# CONFIG_MTD_DILNETPC is not set
CONFIG_MTD_L440GX=m
CONFIG_MTD_PCI=m
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
CONFIG_MTD_PMC551=m
# CONFIG_MTD_PMC551_BUGFIX is not set
# CONFIG_MTD_PMC551_DEBUG is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
CONFIG_MTD_MTDRAM=m
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
# CONFIG_MTD_BLKMTD is not set
CONFIG_MTD_BLOCK2MTD=m

#
# Disk-On-Chip Device Drivers
#
CONFIG_MTD_DOC2000=m
# CONFIG_MTD_DOC2001 is not set
CONFIG_MTD_DOC2001PLUS=m
CONFIG_MTD_DOCPROBE=m
CONFIG_MTD_DOCECC=m
# CONFIG_MTD_DOCPROBE_ADVANCED is not set
CONFIG_MTD_DOCPROBE_ADDRESS=0

#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
CONFIG_MTD_NAND_IDS=m
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_NANDSIM is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
CONFIG_PARPORT_PC_PCMCIA=m
CONFIG_PARPORT_NOT_PC=y
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_SX8=m
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_INITRD=y
CONFIG_LBD=y
CONFIG_CDROM_PKTCDVD=m
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=m

#
# 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_IDECS=m
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPNP=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_BLK_DEV_ATIIXP=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_TRIFLEX=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_CS5520=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT34X=y
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_BLK_DEV_HPT366=y
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
CONFIG_BLK_DEV_PDC202XX_OLD=y
# CONFIG_PDC202XX_BURST is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_PDC202XX_FORCE=y
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIIMAGE=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y

#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m

#
# SCSI low-level drivers
#
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_3W_9XXX=m
# CONFIG_SCSI_7000FASST is not set
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=4
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=4
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_ENABLE_RD_STRM is not set
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_DPT_I2O is not set
CONFIG_SCSI_IN2000=m
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
CONFIG_MEGARAID_MAILBOX=m
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_SATA=m
CONFIG_SCSI_SATA_AHCI=m
CONFIG_SCSI_SATA_SVW=m
CONFIG_SCSI_ATA_PIIX=m
CONFIG_SCSI_SATA_MV=m
CONFIG_SCSI_SATA_NV=m
CONFIG_SCSI_SATA_PROMISE=m
CONFIG_SCSI_SATA_QSTOR=m
CONFIG_SCSI_SATA_SX4=m
CONFIG_SCSI_SATA_SIL=m
CONFIG_SCSI_SATA_SIS=m
CONFIG_SCSI_SATA_ULI=m
CONFIG_SCSI_SATA_VIA=m
CONFIG_SCSI_SATA_VITESSE=m
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT 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=m
CONFIG_SCSI_GDTH=m
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
# CONFIG_SCSI_NCR53C406A is not set
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
CONFIG_SCSI_QLOGIC_FAS=m
# CONFIG_SCSI_QLOGIC_FC is not set
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_QLOGIC_1280_1040=y
CONFIG_SCSI_QLA2XXX=m
CONFIG_SCSI_QLA21XX=m
CONFIG_SCSI_QLA22XX=m
CONFIG_SCSI_QLA2300=m
CONFIG_SCSI_QLA2322=m
CONFIG_SCSI_QLA6312=m
# CONFIG_SCSI_QLA24XX is not set
CONFIG_SCSI_LPFC=m
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
CONFIG_SCSI_DC390T=m
# 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

#
# PCMCIA SCSI adapter support
#
CONFIG_PCMCIA_AHA152X=m
CONFIG_PCMCIA_FDOMAIN=m
CONFIG_PCMCIA_NINJA_SCSI=m
CONFIG_PCMCIA_QLOGIC=m
CONFIG_PCMCIA_SYM53C500=m

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID5=m
CONFIG_MD_RAID6=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=m
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_EMC=m

#
# Fusion MPT device support
#
CONFIG_FUSION=y
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=128

#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_OUI_DB=y
# CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set
# CONFIG_IEEE1394_EXPORT_FULL_API is not set

#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_CMP=m
CONFIG_IEEE1394_AMDTP=m

#
# I2O device support
#
CONFIG_I2O=m
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_EXT_ADAPTEC_DMA64=y
CONFIG_I2O_CONFIG=m
CONFIG_I2O_CONFIG_OLD_IOCTL=y
# CONFIG_I2O_BUS is not set
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m

#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_NET_SB1000=m

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
CONFIG_PHYLIB=m
CONFIG_PHYCONTROL=y

#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
# CONFIG_CASSINI is not set
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL1=m
CONFIG_EL2=m
CONFIG_ELPLUS=m
CONFIG_EL16=m
CONFIG_EL3=m
CONFIG_3C515=m
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
CONFIG_LANCE=m
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=m
CONFIG_ULTRA=m
CONFIG_SMC9194=m
CONFIG_NET_VENDOR_RACAL=y
CONFIG_NI52=m
CONFIG_NI65=m

#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_ULI526X=m
CONFIG_PCMCIA_XIRCOM=m
# CONFIG_AT1700 is not set
CONFIG_DEPCA=m
CONFIG_HP100=m
CONFIG_NET_ISA=y
CONFIG_E2100=m
# CONFIG_EWRK3 is not set
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
CONFIG_HPLAN_PLUS=m
CONFIG_HPLAN=m
CONFIG_LP486E=m
CONFIG_ETH16I=m
CONFIG_NE2000=m
CONFIG_ZNET=m
CONFIG_SEEQ8005=m
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_AMD8111_ETH=m
CONFIG_AMD8111E_NAPI=y
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_ADAPTEC_STARFIRE_NAPI=y
CONFIG_AC3200=m
CONFIG_APRICOT=m
CONFIG_B44=m
CONFIG_FORCEDETH=m
CONFIG_CS89x0=m
CONFIG_DGRS=m
CONFIG_EEPRO100=m
CONFIG_E100=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m

#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=m
CONFIG_E1000_NAPI=y
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
CONFIG_R8169_NAPI=y
CONFIG_R8169_VLAN=y
CONFIG_SIS190=m
CONFIG_SKGE=m
CONFIG_SK98LIN=m
CONFIG_VIA_VELOCITY=m
CONFIG_TIGON3=m
CONFIG_BNX2=m

#
# Ethernet (10000 Mbit)
#
CONFIG_CHELSIO_T1=m
CONFIG_IXGB=m
CONFIG_IXGB_NAPI=y
CONFIG_S2IO=m
CONFIG_S2IO_NAPI=y
# CONFIG_2BUFF_MODE is not set

#
# Token Ring devices
#
CONFIG_TR=y
CONFIG_IBMTR=m
CONFIG_IBMOL=m
CONFIG_IBMLS=m
CONFIG_3C359=m
CONFIG_TMS380TR=m
CONFIG_TMSPCI=m
CONFIG_SKISA=m
CONFIG_PROTEON=m
CONFIG_ABYSS=m
CONFIG_SMCTR=m

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
CONFIG_WAVELAN=m
CONFIG_PCMCIA_WAVELAN=m
CONFIG_PCMCIA_NETWAVE=m

#
# Wireless 802.11 Frequency Hopping cards support
#
CONFIG_PCMCIA_RAYCS=m

#
# Wireless 802.11b ISA/PCI cards support
#
CONFIG_IPW2100=m
CONFIG_IPW2100_MONITOR=y
# CONFIG_IPW_DEBUG is not set
CONFIG_IPW2200=m
CONFIG_AIRO=m
CONFIG_HERMES=m
CONFIG_PLX_HERMES=m
CONFIG_TMD_HERMES=m
CONFIG_NORTEL_HERMES=m
CONFIG_PCI_HERMES=m
CONFIG_ATMEL=m
CONFIG_PCI_ATMEL=m

#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
CONFIG_PCMCIA_HERMES=m
CONFIG_PCMCIA_SPECTRUM=m
CONFIG_AIRO_CS=m
CONFIG_PCMCIA_ATMEL=m
CONFIG_PCMCIA_WL3501=m

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
CONFIG_PRISM54=m
CONFIG_HOSTAP=m
CONFIG_HOSTAP_FIRMWARE=y
CONFIG_HOSTAP_PLX=m
CONFIG_HOSTAP_PCI=m
CONFIG_HOSTAP_CS=m
CONFIG_NET_WIRELESS=y

#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_FMVJ18X=m
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_PCMCIA_SMC91C92=m
CONFIG_PCMCIA_XIRC2PS=m
CONFIG_PCMCIA_AXNET=m
CONFIG_PCMCIA_IBMTR=m

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# ATM drivers
#
CONFIG_ATM_TCP=m
CONFIG_ATM_LANAI=m
CONFIG_ATM_ENI=m
# CONFIG_ATM_ENI_DEBUG is not set
# CONFIG_ATM_ENI_TUNE_BURST is not set
CONFIG_ATM_FIRESTREAM=m
# CONFIG_ATM_ZATM is not set
CONFIG_ATM_NICSTAR=m
# CONFIG_ATM_NICSTAR_USE_SUNI is not set
# CONFIG_ATM_NICSTAR_USE_IDT77105 is not set
CONFIG_ATM_IDT77252=m
# CONFIG_ATM_IDT77252_DEBUG is not set
# CONFIG_ATM_IDT77252_RCV_ALL is not set
CONFIG_ATM_IDT77252_USE_SUNI=y
CONFIG_ATM_AMBASSADOR=m
# CONFIG_ATM_AMBASSADOR_DEBUG is not set
CONFIG_ATM_HORIZON=m
# CONFIG_ATM_HORIZON_DEBUG is not set
# CONFIG_ATM_IA is not set
CONFIG_ATM_FORE200E_MAYBE=m
# CONFIG_ATM_FORE200E_PCA is not set
CONFIG_ATM_HE=m
# CONFIG_ATM_HE_USE_SUNI is not set
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
CONFIG_SKFP=m
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
# CONFIG_PPP_BSDCOMP is not set
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
CONFIG_NET_FC=y
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=m
CONFIG_NETPOLL=y
CONFIG_NETPOLL_RX=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y

#
# ISDN subsystem
#
CONFIG_ISDN=m

#
# Old ISDN4Linux
#
CONFIG_ISDN_I4L=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_IPPP_FILTER=y
# CONFIG_ISDN_PPP_BSDCOMP is not set
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y

#
# ISDN feature submodules
#
CONFIG_ISDN_DIVERSION=m

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
CONFIG_ISDN_DRV_HISAX=m

#
# D-channel protocol features
#
CONFIG_HISAX_EURO=y
CONFIG_DE_AOC=y
CONFIG_HISAX_NO_SENDCOMPLETE=y
CONFIG_HISAX_NO_LLC=y
CONFIG_HISAX_NO_KEYPAD=y
CONFIG_HISAX_1TR6=y
CONFIG_HISAX_NI1=y
CONFIG_HISAX_MAX_CARDS=8

#
# HiSax supported cards
#
CONFIG_HISAX_16_0=y
CONFIG_HISAX_16_3=y
CONFIG_HISAX_TELESPCI=y
CONFIG_HISAX_S0BOX=y
CONFIG_HISAX_AVM_A1=y
CONFIG_HISAX_FRITZPCI=y
CONFIG_HISAX_AVM_A1_PCMCIA=y
CONFIG_HISAX_ELSA=y
CONFIG_HISAX_IX1MICROR2=y
CONFIG_HISAX_DIEHLDIVA=y
CONFIG_HISAX_ASUSCOM=y
CONFIG_HISAX_TELEINT=y
CONFIG_HISAX_HFCS=y
CONFIG_HISAX_SEDLBAUER=y
CONFIG_HISAX_SPORTSTER=y
CONFIG_HISAX_MIC=y
CONFIG_HISAX_NETJET=y
CONFIG_HISAX_NETJET_U=y
CONFIG_HISAX_NICCY=y
CONFIG_HISAX_ISURF=y
CONFIG_HISAX_HSTSAPHIR=y
CONFIG_HISAX_BKM_A4T=y
CONFIG_HISAX_SCT_QUADRO=y
CONFIG_HISAX_GAZEL=y
CONFIG_HISAX_HFC_PCI=y
CONFIG_HISAX_W6692=y
CONFIG_HISAX_HFC_SX=y
CONFIG_HISAX_ENTERNOW_PCI=y
# CONFIG_HISAX_DEBUG is not set

#
# HiSax PCMCIA card service modules
#
CONFIG_HISAX_SEDLBAUER_CS=m
CONFIG_HISAX_ELSA_CS=m
CONFIG_HISAX_AVM_A1_CS=m
CONFIG_HISAX_TELES_CS=m

#
# HiSax sub driver modules
#
CONFIG_HISAX_ST5481=m
CONFIG_HISAX_HFCUSB=m
CONFIG_HISAX_HFC4S8S=m
CONFIG_HISAX_FRITZ_PCIPNP=m
CONFIG_HISAX_HDLC=y

#
# Active cards
#
CONFIG_ISDN_DRV_ICN=m
CONFIG_ISDN_DRV_PCBIT=m
CONFIG_ISDN_DRV_SC=m
CONFIG_ISDN_DRV_ACT2000=m

#
# CAPI subsystem
#
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_CAPIFS_BOOL=y
CONFIG_ISDN_CAPI_CAPIFS=m
CONFIG_ISDN_CAPI_CAPIDRV=m

#
# CAPI hardware drivers
#

#
# Active AVM cards
#
CONFIG_CAPI_AVM=y
CONFIG_ISDN_DRV_AVMB1_B1ISA=m
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
# CONFIG_ISDN_DRV_AVMB1_T1ISA is not set
# CONFIG_ISDN_DRV_AVMB1_B1PCMCIA is not set
# CONFIG_ISDN_DRV_AVMB1_T1PCI is not set
# CONFIG_ISDN_DRV_AVMB1_C4 is not set

#
# Active Eicon DIVA Server cards
#
CONFIG_CAPI_EICON=y
CONFIG_ISDN_DIVAS=m
CONFIG_ISDN_DIVAS_BRIPCI=y
CONFIG_ISDN_DIVAS_PRIPCI=y
CONFIG_ISDN_DIVAS_DIVACAPI=m
CONFIG_ISDN_DIVAS_USERIDI=m
CONFIG_ISDN_DIVAS_MAINT=m

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# 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=m
CONFIG_MOUSE_INPORT=m
CONFIG_MOUSE_ATIXL=y
CONFIG_MOUSE_LOGIBM=m
CONFIG_MOUSE_PC110PAD=m
CONFIG_MOUSE_VSXXXAA=m
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
CONFIG_JOYSTICK_IFORCE_USB=y
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
CONFIG_JOYSTICK_TWIDJOY=m
CONFIG_JOYSTICK_DB9=m
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
CONFIG_JOYSTICK_JOYDUMP=m
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
CONFIG_TOUCHSCREEN_MTOUCH=m
CONFIG_TOUCHSCREEN_MK712=m
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_UINPUT=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# 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=m
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_FM801=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_ROCKETPORT=m
# CONFIG_CYCLADES is not set
CONFIG_DIGIEPCA=m
# CONFIG_MOXA_SMARTIO is not set
CONFIG_ISI=m
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_N_HDLC=m
CONFIG_SPECIALIX=m
CONFIG_SPECIALIX_RTSCTS=y
CONFIG_SX=y
CONFIG_STALDRV=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_CS=m
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=y
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
CONFIG_TIPAR=m

#
# IPMI
#
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
CONFIG_SC520_WDT=m
CONFIG_EUROTECH_WDT=m
CONFIG_IB700_WDT=m
CONFIG_IBMASR=m
CONFIG_WAFER_WDT=m
CONFIG_I6300ESB_WDT=m
CONFIG_I8XX_TCO=m
CONFIG_SC1200_WDT=m
# CONFIG_60XX_WDT is not set
CONFIG_SBC8360_WDT=m
CONFIG_CPU5_WDT=m
CONFIG_W83627HF_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m

#
# ISA-based Watchdog Cards
#
CONFIG_PCWATCHDOG=m
# CONFIG_MIXCOMWD is not set
CONFIG_WDT=m
# CONFIG_WDT_501 is not set

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
CONFIG_WDT_501_PCI=y

#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
CONFIG_HW_RANDOM=m
CONFIG_NVRAM=m
CONFIG_RTC=y
CONFIG_RTC_HISTOGRAM=m
CONFIG_BLOCKER=m
# CONFIG_LPPTEST is not set
CONFIG_DTLK=m
CONFIG_R3964=m
# CONFIG_APPLICOM is not set
CONFIG_SONYPI=m

#
# Ftape, the floppy tape device driver
#
CONFIG_AGP=y
CONFIG_AGP_ALI=y
CONFIG_AGP_ATI=y
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_NVIDIA=y
CONFIG_AGP_SIS=y
CONFIG_AGP_SWORKS=y
CONFIG_AGP_VIA=y
CONFIG_AGP_EFFICEON=y
CONFIG_DRM=y
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
# CONFIG_DRM_VIA is not set
CONFIG_DRM_SAVAGE=m

#
# PCMCIA character devices
#
CONFIG_SYNCLINK_CS=m
CONFIG_MWAVE=m
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=m

#
# TPM devices
#
# CONFIG_TCG_TPM is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
# CONFIG_SCx200_ACB is not set
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
CONFIG_I2C_STUB=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
CONFIG_I2C_PCA_ISA=m

#
# Miscellaneous I2C Chip support
#
CONFIG_SENSORS_DS1337=m
# CONFIG_SENSORS_DS1374 is not set
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
# CONFIG_SENSORS_PCA9539 is not set
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# 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=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
# CONFIG_SENSORS_ADM1026 is not set
CONFIG_SENSORS_ADM1031=m
# CONFIG_SENSORS_ADM9240 is not set
CONFIG_SENSORS_ASB100=m
# CONFIG_SENSORS_ATXP1 is not set
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_FSCPOS=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_SIS5595=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47B397=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_SENSORS_HDAPS=m
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Misc devices
#
CONFIG_IBM_ASM=m

#
# Multimedia Capabilities Port drivers
#

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_SAA6588=m
CONFIG_VIDEO_PMS=m
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_SAA5246A=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZORAN_LML33R10=m
# CONFIG_VIDEO_MEYE is not set
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_SAA7134_DVB=m
CONFIG_VIDEO_MXB=m
CONFIG_VIDEO_DPC=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_CX88=m
# CONFIG_VIDEO_CX88_DVB is not set
CONFIG_VIDEO_OVCAMCHIP=m

#
# Radio Adapters
#
CONFIG_RADIO_CADET=m
CONFIG_RADIO_RTRACK=m
CONFIG_RADIO_RTRACK2=m
CONFIG_RADIO_AZTECH=m
CONFIG_RADIO_GEMTEK=m
CONFIG_RADIO_GEMTEK_PCI=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m
CONFIG_RADIO_SF16FMI=m
CONFIG_RADIO_SF16FMR2=m
CONFIG_RADIO_TERRATEC=m
CONFIG_RADIO_TRUST=m
CONFIG_RADIO_TYPHOON=m
CONFIG_RADIO_TYPHOON_PROC_FS=y
CONFIG_RADIO_ZOLTRIX=m

#
# Digital Video Broadcasting Devices
#
CONFIG_DVB=y
CONFIG_DVB_CORE=m

#
# Supported SAA7146 based PCI Adapters
#
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m

#
# Supported USB Adapters
#
# CONFIG_DVB_USB is not set
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_DVB_CINERGYT2=m
CONFIG_DVB_CINERGYT2_TUNING=y
CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT=32
CONFIG_DVB_CINERGYT2_STREAM_BUF_SIZE=512
CONFIG_DVB_CINERGYT2_QUERY_INTERVAL=250
# CONFIG_DVB_CINERGYT2_ENABLE_RC_INPUT_DEVICE is not set

#
# Supported FlexCopII (B2C2) Adapters
#
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
CONFIG_DVB_B2C2_FLEXCOP_USB=m
# CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set

#
# Supported BT878 Adapters
#
CONFIG_DVB_BT8XX=m

#
# Supported Pluto2 Adapters
#
# CONFIG_DVB_PLUTO2 is not set

#
# Supported DVB Frontends
#

#
# Customise DVB Frontends
#

#
# DVB-S (satellite) frontends
#
CONFIG_DVB_STV0299=m
CONFIG_DVB_CX24110=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_TDA80XX=m
CONFIG_DVB_MT312=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_S5H1420=m

#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m

#
# DVB-C (cable) frontends
#
CONFIG_DVB_ATMEL_AT76C651=m
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_STV0297=m

#
# ATSC (North American/Korean Terresterial DTV) frontends
#
CONFIG_DVB_NXT2002=m
CONFIG_DVB_OR51211=m
CONFIG_DVB_OR51132=m
CONFIG_DVB_BCM3510=m
# CONFIG_DVB_LGDT330X is not set
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_VIDEO_VIDEOBUF=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BUF_DVB=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m
CONFIG_VIDEO_TVEEPROM=m

#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SOFT_CURSOR=y
# CONFIG_FB_MACMODES is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_CIRRUS=m
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_HGA=m
CONFIG_FB_HGA_ACCEL=y
# CONFIG_FB_NVIDIA is not set
CONFIG_FB_RIVA=m
# CONFIG_FB_RIVA_I2C is not set
# CONFIG_FB_RIVA_DEBUG is not set
CONFIG_FB_I810=m
CONFIG_FB_I810_GTF=y
CONFIG_FB_I810_I2C=y
CONFIG_FB_INTEL=m
# CONFIG_FB_INTEL_DEBUG is not set
CONFIG_FB_MATROX=m
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
CONFIG_FB_MATROX_I2C=m
CONFIG_FB_MATROX_MAVEN=m
CONFIG_FB_MATROX_MULTIHEAD=y
# CONFIG_FB_RADEON_OLD is not set
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
# CONFIG_FB_RADEON_DEBUG is not set
CONFIG_FB_ATY128=m
CONFIG_FB_ATY=m
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GENERIC_LCD=y
# CONFIG_FB_ATY_XL_INIT is not set
CONFIG_FB_ATY_GX=y
CONFIG_FB_SAVAGE=m
# CONFIG_FB_SAVAGE_I2C is not set
# CONFIG_FB_SAVAGE_ACCEL is not set
# CONFIG_FB_SIS is not set
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=m
CONFIG_FB_3DFX_ACCEL=y
CONFIG_FB_VOODOO1=m
CONFIG_FB_CYBLA=m
CONFIG_FB_TRIDENT=m
CONFIG_FB_TRIDENT_ACCEL=y
# CONFIG_FB_GEODE is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_MDA_CONSOLE=m
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_BACKLIGHT_DEVICE=y
CONFIG_LCD_CLASS_DEVICE=m
CONFIG_LCD_DEVICE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_GENERIC_DRIVER=y

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_OPL4_LIB=m
CONFIG_SND_VX_LIB=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m

#
# ISA devices
#
CONFIG_SND_AD1848_LIB=m
CONFIG_SND_CS4231_LIB=m
CONFIG_SND_AD1816A=m
CONFIG_SND_AD1848=m
CONFIG_SND_CS4231=m
CONFIG_SND_CS4232=m
CONFIG_SND_CS4236=m
CONFIG_SND_ES968=m
CONFIG_SND_ES1688=m
CONFIG_SND_ES18XX=m
CONFIG_SND_GUS_SYNTH=m
CONFIG_SND_GUSCLASSIC=m
CONFIG_SND_GUSEXTREME=m
CONFIG_SND_GUSMAX=m
CONFIG_SND_INTERWAVE=m
CONFIG_SND_INTERWAVE_STB=m
CONFIG_SND_OPTI92X_AD1848=m
CONFIG_SND_OPTI92X_CS4231=m
CONFIG_SND_OPTI93X=m
CONFIG_SND_SB8=m
CONFIG_SND_SB16=m
CONFIG_SND_SBAWE=m
CONFIG_SND_SB16_CSP=y
# CONFIG_SND_WAVEFRONT is not set
CONFIG_SND_ALS100=m
CONFIG_SND_AZT2320=m
CONFIG_SND_CMI8330=m
CONFIG_SND_DT019X=m
CONFIG_SND_OPL3SA2=m
CONFIG_SND_SGALAXY=m
CONFIG_SND_SSCAPE=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_AC97_BUS=m

#
# PCI devices
#
CONFIG_SND_ALI5451=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
CONFIG_SND_AZT3328=m
CONFIG_SND_BT87X=m
CONFIG_SND_BT87X_OVERCLOCK=y
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CS4281=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_CA0106=m
CONFIG_SND_KORG1212=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
CONFIG_SND_HDSP=m
# CONFIG_SND_HDSPM is not set
CONFIG_SND_TRIDENT=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_AD1889=m
CONFIG_SND_ALS4000=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_FM801=m
CONFIG_SND_FM801_TEA575X=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_SONICVIBES=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VX222=m
# CONFIG_SND_HDA_INTEL is not set

#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m

#
# PCMCIA devices
#
CONFIG_SND_VXPOCKET=m
CONFIG_SND_PDAUDIOCF=m

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

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_OBSOLETE_OSS_USB_DRIVER is not set

#
# USB Bluetooth TTY can only be used with disabled Bluetooth subsystem
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
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=y

#
# 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=m
CONFIG_USB_WACOM=m
# CONFIG_USB_ACECAD is not set
CONFIG_USB_KBTAB=m
CONFIG_USB_POWERMATE=m
CONFIG_USB_MTOUCH=m
# CONFIG_USB_ITMTOUCH is not set
CONFIG_USB_EGALAX=m
CONFIG_USB_YEALINK=m
CONFIG_USB_XPAD=m
CONFIG_USB_ATI_REMOTE=m
# CONFIG_USB_KEYSPAN_REMOTE is not set
CONFIG_USB_APPLETOUCH=m

#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m

#
# USB Multimedia devices
#
CONFIG_USB_DABUSB=m
CONFIG_USB_VICAM=m
CONFIG_USB_DSBR=m
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_OV511=m
CONFIG_USB_SE401=m
CONFIG_USB_SN9C102=m
CONFIG_USB_STV680=m
CONFIG_USB_W9968CF=m
# CONFIG_USB_PWC is not set

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_CDCETHER=m
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
# CONFIG_USB_NET_RNDIS_HOST is not set
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_NET_ZAURUS=m
# CONFIG_USB_ZD1201 is not set
CONFIG_USB_MON=y

#
# USB port drivers
#
CONFIG_USB_USS720=m

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_AIRPRIME=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
# CONFIG_USB_SERIAL_CP2101 is not set
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
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=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_HP4X=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
# CONFIG_USB_SERIAL_TI is not set
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_EZUSB=y

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_AUERSWALD=m
CONFIG_USB_RIO500=m
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
CONFIG_USB_LED=m
# CONFIG_USB_CYTHERM is not set
CONFIG_USB_PHIDGETKIT=m
CONFIG_USB_PHIDGETSERVO=m
CONFIG_USB_IDMOUSE=m
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
CONFIG_USB_TEST=m

#
# USB DSL modem support
#
CONFIG_USB_ATM=m
CONFIG_USB_SPEEDTOUCH=m
# CONFIG_USB_CXACRU is not set
# CONFIG_USB_XUSBATM is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_BLOCK is not set
CONFIG_MMC_WBSD=m

#
# 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=m
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
# CONFIG_JFS_SECURITY is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=m
CONFIG_XFS_EXPORT=y
CONFIG_XFS_QUOTA=m
CONFIG_XFS_SECURITY=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_INOTIFY=y
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
CONFIG_RELAYFS_FS=m

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
CONFIG_AFFS_FS=m
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
CONFIG_BEFS_FS=m
# CONFIG_BEFS_DEBUG is not set
CONFIG_BFS_FS=m
CONFIG_EFS_FS=m
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
CONFIG_CRAMFS=m
CONFIG_VXFS_FS=m
# CONFIG_HPFS_FS is not set
CONFIG_QNX4FS_FS=m
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_EXPERIMENTAL is not set
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=m

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_EFI_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_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=y
CONFIG_WAKEUP_TIMING=y
# CONFIG_WAKEUP_LATENCY_HIST is not set
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
CONFIG_LATENCY_TIMING=y
# CONFIG_LATENCY_TRACE is not set
# CONFIG_DEBUG_DEADLOCKS is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
# CONFIG_USE_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_KPROBES is not set
CONFIG_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
# CONFIG_SECURITY_SECLVL is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_TEST is not set
CONFIG_CRYPTO_SIGNATURE=y
CONFIG_CRYPTO_SIGNATURE_DSA=y
CONFIG_CRYPTO_MPILIB=y

#
# Hardware crypto devices
#
CONFIG_CRYPTO_DEV_PADLOCK=y
CONFIG_CRYPTO_DEV_PADLOCK_AES=y

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: [ANNOUNCE] 2.6.14-rc5-rt5 kgdb update
  2005-10-24 22:28             ` [ANNOUNCE] 2.6.14-rc5-rt5 kgdb update George Anzinger
@ 2005-11-12 15:32               ` Ingo Molnar
  2005-11-12 15:33                 ` Ingo Molnar
  2005-11-12 16:10                 ` George Anzinger
  0 siblings, 2 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-11-12 15:32 UTC (permalink / raw)
  To: George Anzinger
  Cc: Felix Oxley, linux-kernel, Thomas Gleixner, Steven Rostedt,
	Fernando Lopez-Lezcano


* George Anzinger <george@mvista.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: [ANNOUNCE] 2.6.14-rc5-rt5 kgdb update
  2005-11-12 15:32               ` Ingo Molnar
@ 2005-11-12 15:33                 ` Ingo Molnar
  2005-11-12 16:10                 ` George Anzinger
  1 sibling, 0 replies; 117+ messages in thread
From: Ingo Molnar @ 2005-11-12 15:33 UTC (permalink / raw)
  To: George Anzinger
  Cc: Felix Oxley, linux-kernel, Thomas Gleixner, Steven Rostedt,
	Fernando Lopez-Lezcano


* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * George Anzinger <george@mvista.com> 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

^ permalink raw reply	[flat|nested] 117+ messages in thread

* Re: [ANNOUNCE] 2.6.14-rc5-rt5 kgdb update
  2005-11-12 15:32               ` Ingo Molnar
  2005-11-12 15:33                 ` Ingo Molnar
@ 2005-11-12 16:10                 ` George Anzinger
  1 sibling, 0 replies; 117+ messages in thread
From: George Anzinger @ 2005-11-12 16:10 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Felix Oxley, linux-kernel, Thomas Gleixner, Steven Rostedt,
	Fernando Lopez-Lezcano

Ingo Molnar wrote:
> * George Anzinger <george@mvista.com> 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   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

^ permalink raw reply	[flat|nested] 117+ messages in thread

end of thread, other threads:[~2005-11-12 16:11 UTC | newest]

Thread overview: 117+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-10-17 16:05 2.6.14-rc4-rt7 Ingo Molnar
2005-10-17 17:06 ` 2.6.14-rc4-rt7 Mark Knecht
2005-10-17 19:21 ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
2005-10-18  1:30   ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
2005-10-18  1:50     ` 2.6.14-rc4-rt7 Mark Knecht
2005-10-18  6:54     ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-18  7:28     ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-18 14:11       ` 2.6.14-rc4-rt7 K.R. Foley
2005-10-18 14:49         ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-18 21:04       ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
2005-10-18 21:31         ` 2.6.14-rc4-rt7 William Weston
2005-10-19  6:01           ` 2.6.14-rc4-rt7 Steven Rostedt
2005-10-19 11:19           ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-20 19:12             ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
2005-10-20 19:16               ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-20 23:55                 ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
2005-10-21  8:05                   ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-21 23:25                     ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
2005-10-22  0:20                       ` 2.6.14-rc4-rt7 Mark Knecht
2005-10-22  3:41                         ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-22  5:12                           ` 2.6.14-rc4-rt7 Lee Revell
2005-10-22 23:25                             ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
2005-10-22  3:58                       ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-24 19:28                         ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
2005-10-24 19:38                           ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
2005-10-24 19:46                             ` 2.6.14-rc4-rt7 john stultz
2005-10-25  9:17                               ` 2.6.14-rc4-rt7 Antonio
2005-10-25 15:44                               ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-25 15:58                                 ` 2.6.14-rc4-rt7 linux-os (Dick Johnson)
2005-10-25 17:35                                 ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
2005-10-25 18:16                                 ` 2.6.14-rc4-rt7 john stultz
2005-10-25 20:12                                   ` 2.6.14-rc4-rt7 George Anzinger
2005-10-26  8:28                                     ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-26 16:03                                       ` 2.6.14-rc4-rt7 George Anzinger
2005-10-26 17:17                                         ` 2.6.14-rc4-rt7 George Anzinger
2005-10-26 20:45                                           ` 2.6.14-rc4-rt7 Rui Nuno Capela
2005-10-26 22:07                                             ` 2.6.14-rc4-rt7 William Weston
2005-10-26 23:33                                               ` 2.6.14-rc4-rt7 john stultz
2005-10-26 23:54                                                 ` 2.6.14-rc4-rt7 William Weston
2005-10-26 23:58                                                 ` 2.6.14-rc4-rt7 Steven Rostedt
2005-10-27  0:11                                                   ` 2.6.14-rc4-rt7 john stultz
2005-10-27  0:34                                                 ` 2.6.14-rc4-rt7 William Weston
2005-10-26 23:57                                               ` 2.6.14-rc4-rt7 Steven Rostedt
2005-10-27  0:02                                                 ` 2.6.14-rc4-rt7 William Weston
2005-10-27  0:45                                                 ` 2.6.14-rc4-rt7 john stultz
2005-10-27  1:07                                                   ` 2.6.14-rc4-rt7 Steven Rostedt
2005-10-27  1:22                                                     ` 2.6.14-rc4-rt7 john stultz
2005-10-27  1:37                                                       ` 2.6.14-rc4-rt7 Steven Rostedt
2005-10-27  1:52                                                         ` 2.6.14-rc4-rt7 john stultz
2005-10-27  2:11                                                           ` 2.6.14-rc4-rt7 Steven Rostedt
2005-10-27 22:01                                                             ` 2.6.14-rc4-rt7 William Weston
2005-10-27 22:32                                                               ` 2.6.14-rc4-rt7 Steven Rostedt
2005-10-27  1:26                                                     ` 2.6.14-rc4-rt7 Steven Rostedt
2005-10-27  8:01                                                 ` 2.6.14-rc4-rt7 Rui Nuno Capela
2005-10-27 17:44                                                   ` 2.6.14-rc4-rt7 Steven Rostedt
2005-10-27 23:18                                                     ` 2.6.14-rc4-rt7 Rui Nuno Capela
2005-10-28 17:13                                                     ` 2.6.14-rc4-rt7 Fernando Lopez-Lezcano
2005-11-03 22:13                                       ` 2.6.14-rc4-rt7 - [PATCH] improved boot time TSC synchronization Jim Houston
2005-10-24 20:39                             ` 2.6.14-rc4-rt7 Steven Rostedt
2005-10-24 21:00                               ` 2.6.14-rc4-rt7 Lee Revell
2005-10-17 21:43 ` 2.6.14-rc4-rt7 Daniel Walker
2005-10-17 22:03   ` 2.6.14-rc4-rt7 Thomas Gleixner
2005-10-17 22:05     ` 2.6.14-rc4-rt7 Daniel Walker
2005-10-17 22:15       ` 2.6.14-rc4-rt7 Thomas Gleixner
2005-10-18  6:42   ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-18 16:23     ` 2.6.14-rc4-rt7 Daniel Walker
2005-10-18 20:26       ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-18  0:19 ` 2.6.14-rc4-rt7 Daniel Walker
2005-10-18  6:45   ` 2.6.14-rc4-rt7 Ingo Molnar
2005-10-20 19:54 ` 2.6.14-rc5-rt1 Ingo Molnar
2005-10-20 23:33   ` 2.6.14-rc5-rt1 Felix Oxley
2005-10-21  0:39     ` 2.6.14-rc5-rt1 Mark Knecht
2005-10-21 13:47       ` 2.6.14-rc5-rt1 Mark Knecht
2005-10-21 10:01     ` 2.6.14-rc5-rt1 Felix Oxley
2005-10-21 10:16       ` 2.6.14-rc5-rt1 Ingo Molnar
2005-10-21 10:18       ` 2.6.14-rc5-rt1 Felix Oxley
2005-10-21 10:26         ` 2.6.14-rc5-rt1 Felix Oxley
2005-10-22 23:23           ` 2.6.14-rc5-rt1 Felix Oxley
2005-10-24 22:28             ` [ANNOUNCE] 2.6.14-rc5-rt5 kgdb update George Anzinger
2005-11-12 15:32               ` Ingo Molnar
2005-11-12 15:33                 ` Ingo Molnar
2005-11-12 16:10                 ` George Anzinger
2005-10-30 13:33   ` 2.6.14-rt1 Ingo Molnar
2005-10-30 14:58     ` 2.6.14-rt1 K.R. Foley
2005-10-30 15:41       ` 2.6.14-rt1 Steven Rostedt
2005-10-30 17:17         ` 2.6.14-rt1 Ingo Molnar
2005-10-30 17:19       ` 2.6.14-rt1 Ingo Molnar
2005-10-30 16:30     ` 2.6.14-rt1 Mark Knecht
2005-10-31 18:13     ` 2.6.14-rt1 Fernando Lopez-Lezcano
2005-11-01 20:18     ` 2.6.14-rt1 Fernando Lopez-Lezcano
2005-11-02  2:47       ` 2.6.14-rt1 Fernando Lopez-Lezcano
2005-11-02  2:55         ` 2.6.14-rt1 Carlos Antunes
2005-11-02  3:05           ` 2.6.14-rt1 Steven Rostedt
2005-11-02  3:26             ` 2.6.14-rt1 Carlos Antunes
2005-11-02  3:32               ` 2.6.14-rt1 Steven Rostedt
2005-11-02  3:36                 ` 2.6.14-rt1 Carlos Antunes
2005-11-02  4:05                 ` 2.6.14-rt1 Carlos Antunes
2005-11-02  9:21                   ` 2.6.14-rt1 Florian Schmidt
2005-11-02 14:35                     ` 2.6.14-rt1 Carlos Antunes
2005-11-02 14:40                       ` 2.6.14-rt1 Ingo Molnar
2005-11-02 14:45                         ` 2.6.14-rt1 Carlos Antunes
2005-11-02 15:37                           ` 2.6.14-rt1 Steven Rostedt
2005-11-02 16:07                             ` 2.6.14-rt1 Carlos Antunes
2005-11-02 16:24                               ` 2.6.14-rt1 Steven Rostedt
2005-11-02 16:53                                 ` 2.6.14-rt1 Carlos Antunes
2005-11-02 16:37                               ` 2.6.14-rt1 Steven Rostedt
2005-11-02 18:13           ` 2.6.14-rt1 Fernando Lopez-Lezcano
2005-11-02  7:02       ` 2.6.14-rt1 Ingo Molnar
2005-11-02 18:13         ` 2.6.14-rt1 Fernando Lopez-Lezcano
2005-11-04  7:04         ` 2.6.14-rt1 Fernando Lopez-Lezcano
2005-11-02 21:41     ` 2.6.14-rt4: __get_nsec_offset() false positives john stultz
2005-11-03  6:53       ` Ingo Molnar
2005-11-05  2:35     ` 2.6.14-rt1 (now rt6) Fernando Lopez-Lezcano
2005-11-05  3:46       ` Mark Knecht
2005-11-09 11:22       ` Ingo Molnar
2005-11-10 12:15       ` Ingo Molnar
2005-11-10 22:10         ` Fernando Lopez-Lezcano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).