2005-10-11 11:14:31

by Ingo Molnar

[permalink] [raw]
Subject: 2.6.14-rc4-rt1


i have released the 2.6.14-rc4-rt1 tree, which can be downloaded from
the usual place:

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

lots of fixes all across the spectrum. x64 support and debugging
features on x64 should be in a much better shape now. Same for ARM.

Ingo

Changes since 2.6.14-rc3-rt2:

- fix nasty memory corruption and crash caused by PREEMPT_DEBUG's
lock tracing functionality (Thomas Gleixner)

- ARM updates (Thomas Gleixner)

- get rid of bit_spinlock via ->b_state_lock (Steven Rostedt)

- ACPI flags mismatch fix (Steven Rostedt)

- softlockup false positive fix (Daniel Walker)

- robust/PI futex updates (David Singleton)

- timesource/ktimer updates (Thomas Gleixner)

- pcmcia shutdown hang fix (Steven Rostedt)

- fix missing checks for resched

- merge to 2.6.14-rc4

- vprintk non-preempt fix

- various x64 fixes

- netfilter build fixes

- various latency tracer fixes

- use exact BP stackframes when printing stack-overflow debugging info,
if x86 and x64, if possible.

- ide-floppy irq flags fix

- gameport irq flags fix

- stack footprint debugging fixes

- small MIPS updates

- reduce zlib stack footprint

- got rid of the last remains of the tlb-simple stuff

- various build fixes of non-PREEMPT_RT preemption models

- Kconfig tweak

- export tsc_c3_compensate

to build a 2.6.14-rc4-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-rc4.bz2
http://redhat.com/~mingo/realtime-preempt/patch-2.6.14-rc4-rt1

Ingo


2005-10-11 16:03:47

by Mark Knecht

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On 10/11/05, Ingo Molnar <[email protected]> wrote:
>
> i have released the 2.6.14-rc4-rt1 tree, which can be downloaded from
> the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> lots of fixes all across the spectrum. x64 support and debugging
> features on x64 should be in a much better shape now. Same for ARM.
>
> Ingo

2.6.14-rc4-rt1 is up and running here. I'm starting without debug
disabled to look at whether I get xruns at all. It's been a while
since I've done that so I want to get a baseline. I'll do some latency
testing no matter what later this morning (a kernel recompile) to make
sure your fix for 64-bit processors is working.

I am seeing one strange thing in the 1394 area. dmesg didn't tell me
what device a newly mounted 1394 drive became. This makes it harder to
mount drives with partitions that cannot be labeled.

ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
ACPI: PCI Interrupt 0000:05:08.0[A] -> Link [APC3] -> GSI 18 (level,
low) -> IRQ 66
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[66]
MMIO=[da014000-da0147ff] Max Packet=[4096]
sbp2: $Rev: 1306 $ Ben Collins <[email protected]>
ieee1394: Host added: ID:BUS[0-00:1023] GUID[0800286410000f43]
eth0: no IPv6 routers present
ieee1394: Error parsing configrom for node 0-00:1023
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
ieee1394: Node added: ID:BUS[0-00:1023] GUID[0050c504e0006463]
scsi4 : SCSI emulation for IEEE-1394 SBP-2 Devices
lightning ~ #

I believe it used to say after a mount that the partition became
/dev/sdb2, etc. This makes it harder to mount drives with partitions
that cannot be labeled. For mounted partitions I can find it in df:

lightning ~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 9614148 7967288 1158484 88% /
udev 255228 304 254924 1% /dev
shm 255228 0 255228 0% /dev/shm
myth14:/video 225373664 142751296 71174080 67% /video
/dev/sdb2 48070504 42864832 2763792 94% /home/mark/Gigs
/dev/sdc1 57685532 47539424 7215856 87% /home/mark/music
lightning ~ #

Thanks. Everything else looks great so far.

Cheers,
Mark

2005-10-11 20:56:38

by Fernando Lopez-Lezcano

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Tue, 2005-10-11 at 13:14 +0200, Ingo Molnar wrote:
> i have released the 2.6.14-rc4-rt1 tree, which can be downloaded from
> the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> lots of fixes all across the spectrum. x64 support and debugging
> features on x64 should be in a much better shape now. Same for ARM.

Hi Ingo, just a heads up, I'm still seeing the same problems I reported
with rt13. After about 10 to 15 minutes of up time I see the usual
warnings from Jack, keyboard repeat problems (repeats keys too fast) and
random screensaver triggers. The last two seem to be "clustered" in
time, for a little while things work, then both happen and so on and so
forth.

Sorry to not have any traces that could help, I'm still too busy to be
able to sit down quietly and gather data.
-- Fernando


2005-10-11 21:09:01

by Mark Knecht

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On 10/11/05, Fernando Lopez-Lezcano <[email protected]> wrote:
> On Tue, 2005-10-11 at 13:14 +0200, Ingo Molnar wrote:
> > i have released the 2.6.14-rc4-rt1 tree, which can be downloaded from
> > the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
> > lots of fixes all across the spectrum. x64 support and debugging
> > features on x64 should be in a much better shape now. Same for ARM.
>
> Hi Ingo, just a heads up, I'm still seeing the same problems I reported
> with rt13. After about 10 to 15 minutes of up time I see the usual
> warnings from Jack, keyboard repeat problems (repeats keys too fast) and
> random screensaver triggers. The last two seem to be "clustered" in
> time, for a little while things work, then both happen and so on and so
> forth.
>
> Sorry to not have any traces that could help, I'm still too busy to be
> able to sit down quietly and gather data.
> -- Fernando

Very strange. I've had Jack running at 64/2 since 8:52AM this morning.
Not a single xrun. I've had Ardour looping a session as well as
Aqualung playing a long playlist. No changes in the config file form
the one I sent you off line a couple of days ago.

Guess I'm lucky.

2005-10-11 21:13:28

by Mark Knecht

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On 10/11/05, Mark Knecht <[email protected]> wrote:
> On 10/11/05, Fernando Lopez-Lezcano <[email protected]> wrote:
> > Hi Ingo, just a heads up, I'm still seeing the same problems I reported
> > with rt13. After about 10 to 15 minutes of up time I see the usual
> > warnings from Jack, keyboard repeat problems (repeats keys too fast) and
> > random screensaver triggers. The last two seem to be "clustered" in
> > time, for a little while things work, then both happen and so on and so
> > forth.
> >
> > Sorry to not have any traces that could help, I'm still too busy to be
> > able to sit down quietly and gather data.
> > -- Fernando
>
> Very strange. I've had Jack running at 64/2 since 8:52AM this morning.
> Not a single xrun. I've had Ardour looping a session as well as
> Aqualung playing a long playlist. No changes in the config file form
> the one I sent you off line a couple of days ago.
>
> Guess I'm lucky.
>
Absolutely amazing!!! Not two minutes after sending the previous email
I got two xruns clustered together:

nperiods = 2 for capture
nperiods = 2 for playback
08:52:03.281 Server configuration saved to "/home/mark/.jackdrc".
08:52:03.282 Statistics reset.
08:52:03.437 Client activated.
08:52:03.438 Audio connection change.
08:52:03.441 Audio connection graph change.
08:52:10.264 Audio connection graph change.
08:52:10.271 Audio connection change.
08:52:10.277 Audio connection graph change.
08:52:10.472 Audio connection change.
08:52:12.562 Audio connection graph change.
09:07:40.707 MIDI connection graph change.
09:07:40.714 MIDI connection change.
09:07:41.517 Audio connection graph change.
09:12:35.216 Audio connection graph change.
09:12:35.272 Audio connection change.
10:28:05.229 Audio connection graph change.
10:28:05.429 Audio connection change.
10:29:08.091 Audio connection graph change.
10:29:08.159 Audio connection change.
10:29:15.992 Audio connection graph change.
10:29:16.020 Audio connection change.
10:29:16.020 Audio connection graph change.
10:29:16.268 Audio connection change.
10:29:16.307 Audio connection graph change.
10:29:16.519 Audio connection change.
subgraph starting at ardour timed out (subgraph_wait_fd=20, status =
0, state = Finished)
14:06:43.636 XRUN callback (1).
14:06:43.637 XRUN callback (2).
**** alsa_pcm: xrun of at least 0.728 msecs
**** alsa_pcm: xrun of at least 5.548 msecs

The machine had been essentially 'User space idle' for the previous
two hours. The screen saver had kicked in. Audio was running and the
machine was busy. I woke it up, gave xscreensaver my password, read
email, sent the previous mail, then picked up the telephone to make a
call. Not 2 seconds later the xruns occurred!

Bizarre!!!

- Mark

2005-10-11 22:06:29

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Tue, 2005-10-11 at 14:13 -0700, Mark Knecht wrote:
> The machine had been essentially 'User space idle' for the previous
> two hours. The screen saver had kicked in. Audio was running and the
> machine was busy. I woke it up, gave xscreensaver my password, read
> email, sent the previous mail, then picked up the telephone to make a
> call. Not 2 seconds later the xruns occurred!

So what does /proc/latency_trace report?

Lee

2005-10-11 22:23:56

by Mark Knecht

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On 10/11/05, Lee Revell <[email protected]> wrote:
> On Tue, 2005-10-11 at 14:13 -0700, Mark Knecht wrote:
> > The machine had been essentially 'User space idle' for the previous
> > two hours. The screen saver had kicked in. Audio was running and the
> > machine was busy. I woke it up, gave xscreensaver my password, read
> > email, sent the previous mail, then picked up the telephone to make a
> > call. Not 2 seconds later the xruns occurred!
>
> So what does /proc/latency_trace report?
>
> Lee

I have to rebuild the kernel. That just completed but I haven't
rebooted yet. I wanted to base line test just in case all this latency
testing capability built into the kernel was the root cause of my
xruns. Now I know it wasn't.

2005-10-12 06:14:45

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


* Fernando Lopez-Lezcano <[email protected]> wrote:

> Hi Ingo, just a heads up, I'm still seeing the same problems I
> reported with rt13. After about 10 to 15 minutes of up time I see the
> usual warnings from Jack, keyboard repeat problems (repeats keys too
> fast) and random screensaver triggers. The last two seem to be
> "clustered" in time, for a little while things work, then both happen
> and so on and so forth.
>
> Sorry to not have any traces that could help, I'm still too busy to be
> able to sit down quietly and gather data.

i'm not sure latency traces will uncover anything useful for this bug.
Your problems could be timer issues: timers going off too fast cause
high keyboard repeat rates, and the same goes for the screensaver. Does
'sleep 1' work as expected, or is that timing out in an "accelerated"
way too?

one tweak would be to turn off SMP support in the .config for testing
purposes. Another tweak would be to turn HIGH_RES_TIMERS on in the
.config - it is the common operating mode and the default, so non-HRT
timers could have attracted some bug we didnt notice yet.

Ingo

2005-10-12 06:16:30

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


* Ingo Molnar <[email protected]> wrote:

> one tweak would be to turn off SMP support in the .config for testing
> purposes. Another tweak would be to turn HIGH_RES_TIMERS on in the
> .config - it is the common operating mode and the default, so non-HRT
> timers could have attracted some bug we didnt notice yet.

a quicker tweak for your existing kernel images would be to try booting
with maxcpus=1. This is not equivalent to turning off SMP support in the
.config, but might make a difference already.

Ingo

2005-10-12 06:39:49

by Steven Rostedt

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


On Wed, 12 Oct 2005, Ingo Molnar wrote:

>
> i'm not sure latency traces will uncover anything useful for this bug.
> Your problems could be timer issues: timers going off too fast cause
> high keyboard repeat rates, and the same goes for the screensaver. Does
> 'sleep 1' work as expected, or is that timing out in an "accelerated"
> way too?
>

I usually recommend doing a 'sleep 10'. It really shows you if things are
wrong. If a sleep 1 returns 2 seconds, or 0.5 seconds later it may not be
detected. But a sleep 10 returning 20 seconds or 5 seconds later is
obvious.

Just my 20 cents (inflation - and like my comment I multiplied by 10 ;-)

-- Steve

2005-10-12 07:10:20

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


another thing: might be worth trying PREEMPT_RT too, maybe it makes a
difference.

Also, i noticed an unrelated .config thing: while you have
PREEMPT_DESKTOP, PREEMPT_BKL and irq/softirq threading turned on, you
dont have PREEMPT_RCU enabled. PREEMPT_RCU is pretty useful, it can get
rid of a number of latency sources. Might be worth a try for your
kernel.

Ingo

2005-10-12 16:37:50

by Mark Knecht

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On 10/11/05, Lee Revell <[email protected]> wrote:
> On Tue, 2005-10-11 at 14:13 -0700, Mark Knecht wrote:
> > The machine had been essentially 'User space idle' for the previous
> > two hours. The screen saver had kicked in. Audio was running and the
> > machine was busy. I woke it up, gave xscreensaver my password, read
> > email, sent the previous mail, then picked up the telephone to make a
> > call. Not 2 seconds later the xruns occurred!
>
> So what does /proc/latency_trace report?
>
> Lee

Well, unfortunately it doesn't appear to report anythign helpful. The
maximum latency report did not change when the xrun occurred. This was
the last one reported and it happened long before the xrun:

( ardour-8101 |#0): new 22 us maximum-latency critical section.
=> started at timestamp 1104476939: <do_IRQ+0x29/0x50>
=> ended at timestamp 1104476962: <do_IRQ+0x39/0x50>

Call Trace: <IRQ> <ffffffff8014c42c>{check_critical_timing+492}
<ffffffff8014c64b>{sub_preempt_count_ti+75} <ffffffff80110159>{do_IRQ+57}
<ffffffff8010e16c>{ret_from_intr+0} <EOI>
<ffffffff8014c64b>{sub_preempt_count_ti+75}
<ffffffff80249a37>{clear_page+7} <ffffffff8015b75a>{buffered_rmqueue+634}
<ffffffff8015b963>{__alloc_pages+243} <ffffffff80167018>{do_no_page+264}
<ffffffff801674ee>{__handle_mm_fault+414}
<ffffffff8014c64b>{sub_preempt_count_ti+75}
<ffffffff80167c1b>{get_user_pages+971}
<ffffffff80167e00>{make_pages_present+176}
<ffffffff8016aa0c>{do_mmap_pgoff+1756} <ffffffff801139d6>{sys_mmap+150}
<ffffffff8010dbc6>{system_call+126}
=> dump-end timestamp 1104477102

mark@lightning ~ $

What next? IRQ-off possibly? I think it may be broken for AMD64 right now.

- Mark

2005-10-12 17:48:30

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Wed, 2005-10-12 at 09:37 -0700, Mark Knecht wrote:
> On 10/11/05, Lee Revell <[email protected]> wrote:
> > On Tue, 2005-10-11 at 14:13 -0700, Mark Knecht wrote:
> > > The machine had been essentially 'User space idle' for the previous
> > > two hours. The screen saver had kicked in. Audio was running and the
> > > machine was busy. I woke it up, gave xscreensaver my password, read
> > > email, sent the previous mail, then picked up the telephone to make a
> > > call. Not 2 seconds later the xruns occurred!
> >
> > So what does /proc/latency_trace report?
> >
> > Lee
>
> Well, unfortunately it doesn't appear to report anythign helpful. The
> maximum latency report did not change when the xrun occurred. This was
> the last one reported and it happened long before the xrun:

Sounds like an application bug (some JACK client doing something not RT
safe). Can you reproduce the xruns if you just run jackd with no
clients?

Lee

2005-10-12 18:00:01

by Mark Knecht

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On 10/12/05, Lee Revell <[email protected]> wrote:
> On Wed, 2005-10-12 at 09:37 -0700, Mark Knecht wrote:
> > On 10/11/05, Lee Revell <[email protected]> wrote:
> > > On Tue, 2005-10-11 at 14:13 -0700, Mark Knecht wrote:
> > > > The machine had been essentially 'User space idle' for the previous
> > > > two hours. The screen saver had kicked in. Audio was running and the
> > > > machine was busy. I woke it up, gave xscreensaver my password, read
> > > > email, sent the previous mail, then picked up the telephone to make a
> > > > call. Not 2 seconds later the xruns occurred!
> > >
> > > So what does /proc/latency_trace report?
> > >
> > > Lee
> >
> > Well, unfortunately it doesn't appear to report anythign helpful. The
> > maximum latency report did not change when the xrun occurred. This was
> > the last one reported and it happened long before the xrun:
>
> Sounds like an application bug (some JACK client doing something not RT
> safe). Can you reproduce the xruns if you just run jackd with no
> clients?

I don't know. These xruns take hours to generate. I'd probably have to
dedicate a whole day of doing nothing on the machine to try, and then
if I didn't produce anything I'm not sure what it proves. If I do get
one then we get to see if there's data.

I'd really like to do the IRQ-off tests that you do before I go that
direction but unfortunately it's broken very badly since yesterday's
-rt1 release.

Maybe a better path to take would just be pushing the machine harder.
Do some real work in Ardour. Build up a big session and let it rip for
a while and see what that produces?

I don't know really.

- Mark

2005-10-12 18:25:53

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Wed, 2005-10-12 at 11:00 -0700, Mark Knecht wrote:
> On 10/12/05, Lee Revell <[email protected]> wrote:
> > Sounds like an application bug (some JACK client doing something not RT
> > safe). Can you reproduce the xruns if you just run jackd with no
> > clients?
>
> I don't know. These xruns take hours to generate. I'd probably have to
> dedicate a whole day of doing nothing on the machine to try, and then
> if I didn't produce anything I'm not sure what it proves. If I do get
> one then we get to see if there's data.

A much easier solution is to recompile JACK with the
--enable-preemption-check option. This activates the in-kernel
debugging mechanism that causes a stack dump when an RT task schedules.
It has been used to find tricky bugs in Hydrogen and Freqtweak already.

Lee

2005-10-12 18:38:09

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Wed, 2005-10-12 at 14:25 -0400, Lee Revell wrote:
> On Wed, 2005-10-12 at 11:00 -0700, Mark Knecht wrote:
> > On 10/12/05, Lee Revell <[email protected]> wrote:
> > > Sounds like an application bug (some JACK client doing something not RT
> > > safe). Can you reproduce the xruns if you just run jackd with no
> > > clients?
> >
> > I don't know. These xruns take hours to generate. I'd probably have to
> > dedicate a whole day of doing nothing on the machine to try, and then
> > if I didn't produce anything I'm not sure what it proves. If I do get
> > one then we get to see if there's data.
>
> A much easier solution is to recompile JACK with the
> --enable-preemption-check option. This activates the in-kernel
> debugging mechanism that causes a stack dump when an RT task schedules.
> It has been used to find tricky bugs in Hydrogen and Freqtweak already.

I should also remind you that if you pursue the
--enable-preemption-check option, then we'll be well outside of kernel
land so you might want to take it up on the JACK list.

Lee

2005-10-12 19:11:32

by Mark Knecht

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On 10/12/05, Lee Revell <[email protected]> wrote:
> On Wed, 2005-10-12 at 14:25 -0400, Lee Revell wrote:
> > On Wed, 2005-10-12 at 11:00 -0700, Mark Knecht wrote:
> > > On 10/12/05, Lee Revell <[email protected]> wrote:
> > > > Sounds like an application bug (some JACK client doing something not RT
> > > > safe). Can you reproduce the xruns if you just run jackd with no
> > > > clients?
> > >
> > > I don't know. These xruns take hours to generate. I'd probably have to
> > > dedicate a whole day of doing nothing on the machine to try, and then
> > > if I didn't produce anything I'm not sure what it proves. If I do get
> > > one then we get to see if there's data.
> >
> > A much easier solution is to recompile JACK with the
> > --enable-preemption-check option. This activates the in-kernel
> > debugging mechanism that causes a stack dump when an RT task schedules.
> > It has been used to find tricky bugs in Hydrogen and Freqtweak already.
>
> I should also remind you that if you pursue the
> --enable-preemption-check option, then we'll be well outside of kernel
> land so you might want to take it up on the JACK list.
>
Good point.

I've just built with this feature. I'll try it out for a while and ask
questions on that list while I'm configured this way.

Thanks for the idea.

Cheers,
Mark

2005-10-12 19:41:40

by Mark Knecht

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On 10/12/05, Mark Knecht <[email protected]> wrote:
> On 10/12/05, Lee Revell <[email protected]> wrote:

> I've just built with this feature. I'll try it out for a while and ask
> questions on that list while I'm configured this way.
>
> Thanks for the idea.
>
> Cheers,
> Mark
>
Ardour just segfaulted immediately when talking to jack-0.100.5 built
this way. I think I'll stick with the kernel stuff.

Any ideas on when someone might look at the IRQ-off problem in rc4-rt1
that I've reported?

Thanks,
Mark

2005-10-12 19:45:08

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Wed, 2005-10-12 at 12:41 -0700, Mark Knecht wrote:
> On 10/12/05, Mark Knecht <[email protected]> wrote:
> > On 10/12/05, Lee Revell <[email protected]> wrote:
>
> > I've just built with this feature. I'll try it out for a while and ask
> > questions on that list while I'm configured this way.
> >
> > Thanks for the idea.
> >
> > Cheers,
> > Mark
> >
> Ardour just segfaulted immediately when talking to jack-0.100.5 built
> this way. I think I'll stick with the kernel stuff.

I think this is a dead end as it does not seem to be a kernel problem.

Did anything appear in dmesg at the time of the segfault? And did you
rebuild ardour against the new JACK?

Lee



2005-10-12 19:53:53

by Lee Revell

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Wed, 2005-10-12 at 12:41 -0700, Mark Knecht wrote:
> Any ideas on when someone might look at the IRQ-off problem in rc4-rt1
> that I've reported?

This is almost certainly not related to your xruns. Presumably it will
be fixed as soon as someone with some amd64 hardware gets a chance to
look at it. I don't have any.

Lee

2005-10-12 20:50:10

by Badari Pulavarty

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

Hi Ingo,


I am getting similar segfault on boot problem on 2.6.14-rc4-rt1
on my x86-64 box (with LATENCY_TRACE).

Is there a resolution to this problem ?

Thanks,
Badari

EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
umount: devfs: not mounted
INIT: version 2.86 booting
hotplug[877]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
00007fffff8bee68 error 15
hotplug[878]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
00007fffffb1a408 error 15
hotplug[879]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
00007fffff878408 error 15
hotplug[880]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
00007fffffad36d8 error 15
init[1]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
00007fffffc00b10 error 15
init[1]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
00007fffffc003b8 error 15
rcS[882]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
00007fffff967428 error 15
init[1]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
00007fffffc003b8 error 15
init[1]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
00007fffffc003b8 error 15
</snip>

Thanks,
Badari

2005-10-12 22:10:09

by George Anzinger

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

Steven Rostedt wrote:
> On Wed, 12 Oct 2005, Ingo Molnar wrote:
>
>
>>i'm not sure latency traces will uncover anything useful for this bug.
>>Your problems could be timer issues: timers going off too fast cause
>>high keyboard repeat rates, and the same goes for the screensaver. Does
>>'sleep 1' work as expected, or is that timing out in an "accelerated"
>>way too?
>>
>
>
> I usually recommend doing a 'sleep 10'. It really shows you if things are
> wrong. If a sleep 1 returns 2 seconds, or 0.5 seconds later it may not be
> detected. But a sleep 10 returning 20 seconds or 5 seconds later is
> obvious.

Or maybe:
'time sleep 10'

Lets the machine time it.


--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/

2005-10-12 23:41:40

by Fernando Lopez-Lezcano

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Wed, 2005-10-12 at 15:08 -0700, George Anzinger wrote:
> Steven Rostedt wrote:
> > On Wed, 12 Oct 2005, Ingo Molnar wrote:
> >
> >
> >>i'm not sure latency traces will uncover anything useful for this bug.
> >>Your problems could be timer issues: timers going off too fast cause
> >>high keyboard repeat rates, and the same goes for the screensaver. Does
> >>'sleep 1' work as expected, or is that timing out in an "accelerated"
> >>way too?
> >>
> >
> >
> > I usually recommend doing a 'sleep 10'. It really shows you if things are
> > wrong. If a sleep 1 returns 2 seconds, or 0.5 seconds later it may not be
> > detected. But a sleep 10 returning 20 seconds or 5 seconds later is
> > obvious.
>
> Or maybe:
> 'time sleep 10'
>
> Lets the machine time it.

My first thought was "this can't work" as I imagined the same timing
services would be used and you would get always 10 secs or so...

Ingo: I tried with PREEMPT_RCU=y and it made no difference.

When the system starts to misbehave I tried 'time sleep 10' and got
really wild results:

# time sleep 10

real 0m10.007s
user 0m0.001s
sys 0m0.003s
# time sleep 10

real 0m10.006s
user 0m0.000s
sys 0m0.003s
# time sleep 10
[the return key "autorepeated" here :-]



real 0m10.006s
user 0m0.001s
sys 0m0.003s
#
#
#
# time sleep 10

real 0m0.016s
user 0m0.002s
sys 0m0.001s
[yes I really got the prompt back that fast!]
#
#
# time sleep 10

real 73m18.087s
user 0m0.000s
sys 0m0.003s
[this last one was also very fast, it did not take 73 minutes...]
# time sleep 10

real 73m18.089s
user 0m0.000s
sys 0m0.003s
#
#
# time sleep 10

real 0m10.006s
user 0m0.000s
sys 0m0.004s
# time sleep 10

real 73m18.069s
user 0m0.000s
sys 0m0.003s
# time sleep 10

And so on and so forth. At least this shows the problem clearly.
I still have to test with a up kernel and try again PREEMPT_RT.

-- Fernando


2005-10-12 23:53:42

by George Anzinger

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

Fernando Lopez-Lezcano wrote:
> On Wed, 2005-10-12 at 15:08 -0700, George Anzinger wrote:
>
>>Steven Rostedt wrote:
>>
>>>On Wed, 12 Oct 2005, Ingo Molnar wrote:
>>>
>>>
>>>
>>>>i'm not sure latency traces will uncover anything useful for this bug.
>>>>Your problems could be timer issues: timers going off too fast cause
>>>>high keyboard repeat rates, and the same goes for the screensaver. Does
>>>>'sleep 1' work as expected, or is that timing out in an "accelerated"
>>>>way too?
>>>>
>>>
>>>
>>>I usually recommend doing a 'sleep 10'. It really shows you if things are
>>>wrong. If a sleep 1 returns 2 seconds, or 0.5 seconds later it may not be
>>>detected. But a sleep 10 returning 20 seconds or 5 seconds later is
>>>obvious.
>>
>>Or maybe:
>>'time sleep 10'
>>
>>Lets the machine time it.
>
>
> My first thought was "this can't work" as I imagined the same timing
> services would be used and you would get always 10 secs or so...
>
> Ingo: I tried with PREEMPT_RCU=y and it made no difference.
>
> When the system starts to misbehave I tried 'time sleep 10' and got
> really wild results:
>
> # time sleep 10
>
> real 0m10.007s
> user 0m0.001s
> sys 0m0.003s
> # time sleep 10
>
> real 0m10.006s
> user 0m0.000s
> sys 0m0.003s
> # time sleep 10
> [the return key "autorepeated" here :-]
>
>
>
> real 0m10.006s
> user 0m0.001s
> sys 0m0.003s
> #
> #
> #
> # time sleep 10
>
> real 0m0.016s
> user 0m0.002s
> sys 0m0.001s
> [yes I really got the prompt back that fast!]
> #
> #
> # time sleep 10
>
> real 73m18.087s
> user 0m0.000s
> sys 0m0.003s
> [this last one was also very fast, it did not take 73 minutes...]

Uh... this implies that your system clock is not keeping very good time. Is that so? Try:
date
time sleep 10
date

~
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/

2005-10-13 21:15:20

by Esben Nielsen

[permalink] [raw]
Subject: 1.6ms jitter in rtc_wakeup (Re: 2.6.14-rc4-rt1)


On Tue, 11 Oct 2005, Ingo Molnar wrote:

>
> i have released the 2.6.14-rc4-rt1 tree, which can be downloaded from
> the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>

I set up rtc_wakeup and got a jitter up 1.6ms!
It came when I cd'en into a nfs-mount and typed ls.


Output from rtc_wakeup:
...
new max. jitter: 19.9% (48 usec)
threshold violated: 25.5% (62usec)
new max. jitter: 25.5% (62 usec)
threshold violated: 684.9% (1672usec)
new max. jitter: 684.9% (1672 usec)
threshold violated: 85.2% (207usec)
done.
total # of irqs: 3440126
missed irqs: 0
threshold violations: 3
max jitter: 684.9% (1672 usec)

/proc/latency_trace:
preemption latency trace v1.1.5 on 2.6.14-rc4-rt1
--------------------------------------------------------------------
latency: 1595 us, #20/20, CPU#0 | (M:rt VP:0, KP:0, SP:1 HP:1)
-----------------
| task: IRQ 8-775 (uid:0 nice:-5 policy:1 rt_prio:99)
-----------------

_------=> CPU#
/ _-----=> irqs-off
| / _----=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
|||| /
||||| delay
cmd pid ||||| time | caller
\ / ||||| \ | /
ls-11239 0D.h3 0us : __trace_start_sched_wakeup (try_to_wake_up)
ls-11239 0D.h3 0us : __trace_start_sched_wakeup <IRQ 8-775> (0 0)
ls-11239 0Dnh2 1us : try_to_wake_up <IRQ 8-775> (0 75)
ls-11239 0Dnh1 1us : preempt_schedule (try_to_wake_up)
ls-11239 0Dnh1 2us : wake_up_process (redirect_hardirq)
ls-11239 0Dnh. 2us : preempt_schedule (__do_IRQ)
ls-11239 0Dnh. 3us : irq_exit (do_IRQ)
ls-11239 0Dn.. 3us : preempt_schedule_irq (need_resched)
ls-11239 0Dn.. 3us : __schedule (preempt_schedule_irq)
ls-11239 0Dn.. 4us : profile_hit (__schedule)
ls-11239 0Dn.1 4us : sched_clock (__schedule)
ls-11239 0Dn.1 5us : check_tsc_unstable (sched_clock)
ls-11239 0Dn.1 5us : tsc_read_c3_time (sched_clock)
IRQ 8-775 0D..2 6us : __switch_to (__schedule)
IRQ 8-775 0D..2 7us!: __schedule <ls-11239> (75 0)
IRQ 8-775 0...1 1594us : trace_stop_sched_switched (__schedule)
IRQ 8-775 0D..2 1594us : trace_stop_sched_switched <IRQ 8-775> (0 0)
IRQ 8-775 0D..2 1595us : trace_stop_sched_switched (__schedule)


Esben


Attachments:
config (31.71 kB)

2005-10-13 22:30:36

by Fernando Lopez-Lezcano

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Wed, 2005-10-12 at 09:10 +0200, Ingo Molnar wrote:
> another thing: might be worth trying PREEMPT_RT too, maybe it makes a
> difference.

On "depmod -a" I'm getting:
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/jffs2/jffs2.ko needs unknown symbol __down_read
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/jffs2/jffs2.ko needs unknown symbol __up_write
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/jffs2/jffs2.ko needs unknown symbol __up_read
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/jffs2/jffs2.ko needs unknown symbol __down_write
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/jffs2/jffs2.ko needs unknown symbol compat_init_rwsem
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/xfs/xfs.ko needs unknown symbol __down_read
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/xfs/xfs.ko needs unknown symbol __down_write_trylock
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/xfs/xfs.ko needs unknown symbol __up_write
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/xfs/xfs.ko needs unknown symbol __up_read
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/xfs/xfs.ko needs unknown symbol __downgrade_write
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/xfs/xfs.ko needs unknown symbol __down_write
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/xfs/xfs.ko needs unknown symbol compat_init_rwsem
WARNING: /lib/modules/2.6.13-0.11.rdt.rhfc4.ccrmasmp/kernel/fs/xfs/xfs.ko needs unknown symbol __down_read_trylock

I'll report after I try to boot into it.

> Also, i noticed an unrelated .config thing: while you have
> PREEMPT_DESKTOP, PREEMPT_BKL and irq/softirq threading turned on, you
> dont have PREEMPT_RCU enabled. PREEMPT_RCU is pretty useful, it can get
> rid of a number of latency sources. Might be worth a try for your
> kernel.

I tried PREEMPT_RCU=y and then HIGH_RES_TIMERS=y with no effects. I also
turned off ntpd at Thomas's request (no change).

I could not boot the up version of the kernel, it hangs early, I'll try
to see why (weird).

-- Fernando


2005-10-14 02:29:26

by Fernando Lopez-Lezcano

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Thu, 2005-10-13 at 15:29 -0700, Fernando Lopez-Lezcano wrote:
> On Wed, 2005-10-12 at 09:10 +0200, Ingo Molnar wrote:
> > another thing: might be worth trying PREEMPT_RT too, maybe it makes a
> > difference.
[MUNCH]
> I'll report after I try to boot into it.

So, I'm using a PREEMPT_RT SMP kernel and I still get the same problem,
only much less frequently than with PREEMPT_DESKTOP. The problem does
not start right away after I boot, it takes around 5 or 10 minutes to
show up (with both options). Right now I'm not getting frequent screen
blank due to the screensaver and I'm typing this without autorepeats,
don't know for how long :-)

I left this running for a while:

#!/bin/bash
while true ; do
START=`date +"%s"`
sleep 10
END=`date +"%s"`
let DIFF=END-START
echo "$DIFF" >>time
echo "---"
done

I'm attaching what I found when I got back.
-- Fernando


Attachments:
time (3.36 kB)

2005-10-14 03:44:56

by Ingo Molnar

[permalink] [raw]
Subject: Re: 1.6ms jitter in rtc_wakeup (Re: 2.6.14-rc4-rt1)


* Esben Nielsen <[email protected]> wrote:

> I set up rtc_wakeup and got a jitter up 1.6ms!
> It came when I cd'en into a nfs-mount and typed ls.

> ls-11239 0Dn.. 4us : profile_hit (__schedule)
> ls-11239 0Dn.1 4us : sched_clock (__schedule)
> ls-11239 0Dn.1 5us : check_tsc_unstable (sched_clock)
> ls-11239 0Dn.1 5us : tsc_read_c3_time (sched_clock)
> IRQ 8-775 0D..2 6us : __switch_to (__schedule)
> IRQ 8-775 0D..2 7us!: __schedule <ls-11239> (75 0)
> IRQ 8-775 0...1 1594us : trace_stop_sched_switched (__schedule)
> IRQ 8-775 0D..2 1594us : trace_stop_sched_switched <IRQ 8-775> (0 0)
> IRQ 8-775 0D..2 1595us : trace_stop_sched_switched (__schedule)

ouch! This very much looks like a hardware induced latency, because the
codepath from those two __schedule points is extremely short and there
is no loop there. Have you tested this particular box before too? If
not, can you reproduce this latency with older versions of -rt too on
the same box, or is this completely new? Occasionally there are boxes
that show clear signs of hardware latencies - there's little the kernel
can do about those.

Wild shot in the dark: are there any power-saving modes enabled on the
box? Another shot in the dark: can you trigger these latencies if the
networking card is ifconfig down-ed? I.e. perhaps it's related to DMA
done by the networking device. Playing with BIOS settings / DMA/PCI
priorities might help reduce DMA related latencies ...

Ingo

2005-10-14 03:55:38

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


* Fernando Lopez-Lezcano <[email protected]> wrote:

> I could not boot the up version of the kernel, it hangs early, I'll
> try to see why (weird).

did you try the maxcpus=1 boot option? That will boot up using a single
CPU only. The bug is very likely somewhere in the APIC timer handling
code. How does /proc/interrupts look like - does the 'LOC' counter [this
represents local APIC interrupts] behave irregularly?

Ingo

2005-10-14 04:04:16

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


* Fernando Lopez-Lezcano <[email protected]> wrote:

> > Or maybe:
> > 'time sleep 10'
> >
> > Lets the machine time it.
>
> My first thought was "this can't work" as I imagined the same timing
> services would be used and you would get always 10 secs or so...

yeah, was my initial thought too. If you have an ssh login on any other
local box (and have ssh autologin enabled), then there's a good way to
script this:

time ssh otherbox "time ssh thisbox \"sleep 10\""

this way you'll get two time measurements of the same timeout, one on
the other box (which shouldnt be running the buggy kernel :-), one on
this box, while the timer runs on this box. Here it gives:

earth3:~> time ssh pluto "time ssh earth3 \"sleep 10\""

real 0m10.141s
user 0m0.012s
sys 0m0.008s

real 0m10.278s
user 0m0.024s
sys 0m0.004s

Ingo

2005-10-14 04:55:54

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


* Fernando Lopez-Lezcano <[email protected]> wrote:

> #!/bin/bash
> while true ; do
> START=`date +"%s"`
> sleep 10
> END=`date +"%s"`
> let DIFF=END-START
> echo "$DIFF" >>time
> echo "---"
> done
>
> I'm attaching what I found when I got back.

> 1
> 10
> 6
> 0
> 0

could you try:

strace -o log sleep 10

and wait for a failure, and send us the log? Is it perhaps nanosleep
unexpectedly returning with -EAGAIN or -512? There's a transient
nanosleep failure that happens on really fast boxes, which we havent
gotten to the bottom yet. That problem is very sporadic, but maybe your
box is just too fast and triggers it more likely :-)

Ingo

2005-10-14 06:21:50

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


* Badari Pulavarty <[email protected]> wrote:

> Hi Ingo,
>
>
> I am getting similar segfault on boot problem on 2.6.14-rc4-rt1 on my
> x86-64 box (with LATENCY_TRACE).

> INIT: version 2.86 booting
> hotplug[877]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
> 00007fffff8bee68 error 15

what does the ffffffff8010f588 RIP address map to? You can find out by
building the kernel via DEBUG_INFO, then doing 'gdb vmlinux' and 'list
*0xffffffff8010f588'. NOTE: the RIP might change in a DEBUG_INFO
compile, so you'll need to reboot.

Another method is to disassemble the vmlinux via 'objdump -d vmlinux >
vmlinux.asm', and to search for that RIP value in an editor - could you
send me the surrounding assembly code? (~20 lines are enough)

Ingo

2005-10-14 06:15:23

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


* Ingo Molnar <[email protected]> wrote:

> could you try:
>
> strace -o log sleep 10
>
> and wait for a failure, and send us the log? Is it perhaps nanosleep
> unexpectedly returning with -EAGAIN or -512? There's a transient
> nanosleep failure that happens on really fast boxes, which we havent
> gotten to the bottom yet. That problem is very sporadic, but maybe
> your box is just too fast and triggers it more likely :-)

is nanosleep returning -ERESTART_RESTARTBLOCK (-516) perhaps?

Ingo

2005-10-14 06:22:20

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


* Badari Pulavarty <[email protected]> wrote:

> Hi Ingo,
>
> I am getting similar segfault on boot problem on 2.6.14-rc4-rt1 on my
> x86-64 box (with LATENCY_TRACE).

also, could you send me your .config?

Ingo

2005-10-14 08:52:55

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


* Ingo Molnar <[email protected]> wrote:

> > could you try:
> >
> > strace -o log sleep 10
> >
> > and wait for a failure, and send us the log? Is it perhaps nanosleep
> > unexpectedly returning with -EAGAIN or -512? There's a transient
> > nanosleep failure that happens on really fast boxes, which we havent
> > gotten to the bottom yet. That problem is very sporadic, but maybe
> > your box is just too fast and triggers it more likely :-)
>
> is nanosleep returning -ERESTART_RESTARTBLOCK (-516) perhaps?

ok, i fixed the -ERESTART_RESTARTBLOCK bug that fast systems were
exhibiting. But this bug is limited to HIGH_RES_TIMERS kernels, so it
cannot explain your problems i think.

in any case, could you try the -rc4-rt3 patch i just uploaded - it also
includes more ktimer debugging code, perhaps one of them triggers on
your box.

Ingo

2005-10-14 09:57:11

by Andi Kleen

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

Ingo Molnar <[email protected]> writes:

> * Badari Pulavarty <[email protected]> wrote:
>
> > Hi Ingo,
> >
> >
> > I am getting similar segfault on boot problem on 2.6.14-rc4-rt1 on my
> > x86-64 box (with LATENCY_TRACE).
>
> > INIT: version 2.86 booting
> > hotplug[877]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
> > 00007fffff8bee68 error 15
>
> what does the ffffffff8010f588 RIP address map to? You can find out by

It could be any kernel address that someone injected into user space.
Most likely some problem with the vsyscall page with either signal
handling or gettimeofday. vsyscall code is tricky to hack because you
cannot add any new functions there, just inlines, otherwise the code
won't end up the right section.

-Andi

2005-10-14 13:12:35

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1


* Andi Kleen <[email protected]> wrote:

> > > I am getting similar segfault on boot problem on 2.6.14-rc4-rt1 on my
> > > x86-64 box (with LATENCY_TRACE).
> >
> > > INIT: version 2.86 booting
> > > hotplug[877]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
> > > 00007fffff8bee68 error 15
> >
> > what does the ffffffff8010f588 RIP address map to? You can find out by
>
> It could be any kernel address that someone injected into user space.
> Most likely some problem with the vsyscall page with either signal
> handling or gettimeofday. vsyscall code is tricky to hack because you
> cannot add any new functions there, just inlines, otherwise the code
> won't end up the right section.

ah, indeed - i completely forgot about vsyscalls - they must not be
traced. Badari, does the patch below help?

Ingo

Index: linux/arch/x86_64/kernel/vsyscall.c
===================================================================
--- linux.orig/arch/x86_64/kernel/vsyscall.c
+++ linux/arch/x86_64/kernel/vsyscall.c
@@ -34,7 +34,7 @@
#include <asm/errno.h>
#include <asm/io.h>

-#define __vsyscall(nr) __attribute__ ((unused,__section__(".vsyscall_" #nr)))
+#define __vsyscall(nr) __attribute__ ((unused,__section__(".vsyscall_" #nr))) notrace
#define force_inline __attribute__((always_inline)) inline

int __sysctl_vsyscall __section_sysctl_vsyscall = 1;

2005-10-14 18:02:28

by Fernando Lopez-Lezcano

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Fri, 2005-10-14 at 08:15 +0200, Ingo Molnar wrote:
> * Ingo Molnar <[email protected]> wrote:
>
> > could you try:
> >
> > strace -o log sleep 10
> >
> > and wait for a failure, and send us the log? Is it perhaps nanosleep
> > unexpectedly returning with -EAGAIN or -512? There's a transient
> > nanosleep failure that happens on really fast boxes, which we havent
> > gotten to the bottom yet. That problem is very sporadic, but maybe
> > your box is just too fast and triggers it more likely :-)
>
> is nanosleep returning -ERESTART_RESTARTBLOCK (-516) perhaps?

Yes, that is probably correct, I saw a few of these:
sleep: cannot read realtime clock: Unknown error 516

I left the kernel running overnight and this morning I've been using it
with no key repeats or screen blanks so far. Go figure. I imagine they
would come back if I reboot. I'm still seeing the Jack warnings but
that's probably a related but somewhat separate issue.

I'm building rt5 and will report later.

-- Fernando


2005-10-14 18:35:55

by Fernando Lopez-Lezcano

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Fri, 2005-10-14 at 11:01 -0700, Fernando Lopez-Lezcano wrote:
> On Fri, 2005-10-14 at 08:15 +0200, Ingo Molnar wrote:
> > * Ingo Molnar <[email protected]> wrote:
> >
> > > could you try:
> > >
> > > strace -o log sleep 10
> > >
> > > and wait for a failure, and send us the log? Is it perhaps nanosleep
> > > unexpectedly returning with -EAGAIN or -512? There's a transient
> > > nanosleep failure that happens on really fast boxes, which we havent
> > > gotten to the bottom yet. That problem is very sporadic, but maybe
> > > your box is just too fast and triggers it more likely :-)
> >
> > is nanosleep returning -ERESTART_RESTARTBLOCK (-516) perhaps?
>
> Yes, that is probably correct, I saw a few of these:
> sleep: cannot read realtime clock: Unknown error 516
>
> I'm building rt5 and will report later.

Sorry, still getting the same behavior from rt5 (including 516 errors).
I'm getting something out of rt5's debugging code, some examples follow:

crond/4144[CPU#1]: BUG in check_ktimer_signal at kernel/ktimers.c:1117
[<c0128277>] __WARN_ON+0x67/0x90 (8)
[<c01416e7>] check_ktimer_signal+0x127/0x130 (48)
[<c01417a1>] ktimer_nanosleep+0xb1/0xf0 (52)
[<c014181b>] ktimer_nanosleep_mono+0x3b/0x50 (60)
[<c0374f60>] nanosleep_restart_mono+0x0/0x30 (8)
[<c01415b0>] process_ktimer+0x0/0x10 (60)
[<c01418cc>] sys_nanosleep+0x4c/0x50 (36)
[<c0103481>] syscall_call+0x7/0xb (16)


expires: 1736/464432941
expired: 1721/862640520
at: 657
interval: 0/0
now: 1721/862641188
rem: 14/601792421
overrun: 0
getoffset: 00000000
crond/4144[CPU#1]: BUG in check_ktimer_signal at kernel/ktimers.c:1117
[<c0128277>] __WARN_ON+0x67/0x90 (8)
[<c01416e7>] check_ktimer_signal+0x127/0x130 (48)
[<c01417a1>] ktimer_nanosleep+0xb1/0xf0 (52)
[<c014181b>] ktimer_nanosleep_mono+0x3b/0x50 (60)
[<c0374f60>] nanosleep_restart_mono+0x0/0x30 (8)
[<c01415b0>] process_ktimer+0x0/0x10 (60)
[<c01418cc>] sys_nanosleep+0x4c/0x50 (36)
[<c0103481>] syscall_call+0x7/0xb (16)

expires: 6116/908892557
expired: 1721/862993769
at: 657
interval: 0/0
now: 1721/862994253
rem: 4395/45898788
overrun: 0
getoffset: 00000000
gpm/4136[CPU#1]: BUG in check_ktimer_signal at kernel/ktimers.c:1117
[<c0128277>] __WARN_ON+0x67/0x90 (8)
[<c01416e7>] check_ktimer_signal+0x127/0x130 (48)
[<c01417a1>] ktimer_nanosleep+0xb1/0xf0 (52)
[<c014181b>] ktimer_nanosleep_mono+0x3b/0x50 (60)
[<c0374f60>] nanosleep_restart_mono+0x0/0x30 (8)
[<c01415b0>] process_ktimer+0x0/0x10 (60)
[<c01418cc>] sys_nanosleep+0x4c/0x50 (36)
[<c0103481>] syscall_call+0x7/0xb (16)
expires: 1730/917836219
expired: 1721/862633260
at: 657
interval: 0/0
now: 1721/862633539
rem: 9/55202959
overrun: 0
getoffset: 00000000
sleep/5299[CPU#1]: BUG in check_ktimer_signal at kernel/ktimers.c:1117
[<c0128277>] __WARN_ON+0x67/0x90 (8)
[<c01416e7>] check_ktimer_signal+0x127/0x130 (48)
[<c01417a1>] ktimer_nanosleep+0xb1/0xf0 (52)
[<c014181b>] ktimer_nanosleep_mono+0x3b/0x50 (60)
[<c0374f60>] nanosleep_restart_mono+0x0/0x30 (8)
[<c01415b0>] process_ktimer+0x0/0x10 (60)
[<c01418cc>] sys_nanosleep+0x4c/0x50 (36)
[<c0103481>] syscall_call+0x7/0xb (16)

expires: 1739/273286972
expired: 1739/272964651
at: 657
interval: 0/0
now: 1739/272965670
rem: 0/322321
overrun: 0
getoffset: 00000000
hald-addon-stor/4229[CPU#1]: BUG in check_ktimer_signal at
kernel/ktimers.c:1117 [<c0128277>] __WARN_ON+0x67/0x90 (8)
[<c01416e7>] check_ktimer_signal+0x127/0x130 (48)
[<c01417a1>] ktimer_nanosleep+0xb1/0xf0 (52)
[<c014181b>] ktimer_nanosleep_mono+0x3b/0x50 (60)
[<c0374f60>] nanosleep_restart_mono+0x0/0x30 (8)
[<c01415b0>] process_ktimer+0x0/0x10 (60)
[<c01418cc>] sys_nanosleep+0x4c/0x50 (36)
[<c0103481>] syscall_call+0x7/0xb (16)

expires: 1751/956279550
expired: 1751/955896702
at: 657
interval: 0/0
now: 1751/955897242
rem: 0/382848
overrun: 0
getoffset: 00000000
sleep/5321[CPU#1]: BUG in check_ktimer_signal at kernel/ktimers.c:1117
[<c0128277>] __WARN_ON+0x67/0x90 (8)
[<c01416e7>] check_ktimer_signal+0x127/0x130 (48)
[<c01417a1>] ktimer_nanosleep+0xb1/0xf0 (52)
[<c014181b>] ktimer_nanosleep_mono+0x3b/0x50 (60)
[<c0374f60>] nanosleep_restart_mono+0x0/0x30 (8)
[<c01415b0>] process_ktimer+0x0/0x10 (60)
[<c01418cc>] sys_nanosleep+0x4c/0x50 (36)
[<c0103481>] syscall_call+0x7/0xb (16)

expires: 1753/316840062
expired: 1753/316460409
at: 657
interval: 0/0
now: 1753/316461329
rem: 0/379653
overrun: 0
getoffset: 00000000
hald-addon-stor/4229[CPU#1]: BUG in check_ktimer_signal at
kernel/ktimers.c:1117 [<c0128277>] __WARN_ON+0x67/0x90 (8)
[<c01416e7>] check_ktimer_signal+0x127/0x130 (48)
[<c01417a1>] ktimer_nanosleep+0xb1/0xf0 (52)
[<c014181b>] ktimer_nanosleep_mono+0x3b/0x50 (60)
[<c0374f60>] nanosleep_restart_mono+0x0/0x30 (8)
[<c01415b0>] process_ktimer+0x0/0x10 (60)
[<c01418cc>] sys_nanosleep+0x4c/0x50 (36)
[<c0103481>] syscall_call+0x7/0xb (16)

-- Fernando


2005-10-14 19:05:44

by Fernando Lopez-Lezcano

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Fri, 2005-10-14 at 06:56 +0200, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
>
> > #!/bin/bash
> > while true ; do
> > START=`date +"%s"`
> > sleep 10
> > END=`date +"%s"`
> > let DIFF=END-START
> > echo "$DIFF" >>time
> > echo "---"
> > done
> >
> > I'm attaching what I found when I got back.
>
> > 1
> > 10
> > 6
> > 0
> > 0
>
> could you try:
>
> strace -o log sleep 10
>
> and wait for a failure, and send us the log? Is it perhaps nanosleep
> unexpectedly returning with -EAGAIN or -512? There's a transient
> nanosleep failure that happens on really fast boxes, which we havent
> gotten to the bottom yet. That problem is very sporadic, but maybe your
> box is just too fast and triggers it more likely :-)

Arghh, now my computers are too fast!! :-) ;-) :-)

BTW, the behavior with rt5 is slightly different. The problem does not
take a while to appear but rather it is there from the time I first
login after a reboot (it does not take 10 minutes or so like before to
appear). In my first try (this is the second reboot into rt5) the
problem, at some point, seemed to dissapear completely.

Here's one strace for you:

execve("/bin/sleep", ["sleep", "10"], [/* 47 vars */]) = 0
brk(0) = 0x804d000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f83000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=116896, ...}) = 0
old_mmap(NULL, 116896, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f66000
close(3) = 0
open("/lib/libm.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20#\241"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=201040, ...}) = 0
old_mmap(0x4ba0f000, 147616, PROT_READ|PROT_EXEC, MAP_PRIVATE|
MAP_DENYWRITE, 3, 0) = 0x4ba0f000
old_mmap(0x4ba32000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x22000) = 0x4ba32000
close(3) = 0
open("/lib/librt.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\340"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=49428, ...}) = 0
old_mmap(0x4c6ac000, 81656, PROT_READ|PROT_EXEC, MAP_PRIVATE|
MAP_DENYWRITE, 3, 0) = 0x4c6ac000
old_mmap(0x4c6b4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x7000) = 0x4c6b4000
old_mmap(0x4c6b6000, 40696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0x4c6b6000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\212\216"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1485672, ...}) = 0
old_mmap(0x4b8e4000, 1215452, PROT_READ|PROT_EXEC, MAP_PRIVATE|
MAP_DENYWRITE, 3, 0) = 0x4b8e4000
old_mmap(0x4ba07000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x123000) = 0x4ba07000
old_mmap(0x4ba0b000, 7132, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0x4ba0b000
close(3) = 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\204W\245"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=101600, ...}) = 0
old_mmap(0x4ba51000, 70084, PROT_READ|PROT_EXEC, MAP_PRIVATE|
MAP_DENYWRITE, 3, 0) = 0x4ba51000
old_mmap(0x4ba5f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0xd000) = 0x4ba5f000
old_mmap(0x4ba61000, 4548, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0x4ba61000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f65000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f64000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f646c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x4ba32000, 4096, PROT_READ) = 0
mprotect(0x4c6b4000, 4096, PROT_READ) = 0
mprotect(0x4ba07000, 8192, PROT_READ) = 0
mprotect(0x4b8e0000, 4096, PROT_READ) = 0
mprotect(0x4ba5f000, 4096, PROT_READ) = 0
munmap(0xb7f66000, 116896) = 0
set_tid_address(0xb7f64708) = 5001
rt_sigaction(SIGRTMIN, {0x4ba55340, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x4ba553a8, [], SA_RESTART|SA_SIGINFO}, NULL, 8)
= 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) =
0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbfe833a0, 43, (nil), 0}) = 0
brk(0) = 0x804d000
brk(0x806e000) = 0x806e000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=49618736, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d64000
close(3) = 0
clock_gettime(CLOCK_REALTIME, {1129316227, 88832424}) = 0
nanosleep({10, 0}, 0) = ? ERESTART_RESTARTBLOCK (To be
restarted)
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f82000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2528
read(3, "", 4096) = 0
close(3) = 0
munmap(0xb7f82000, 4096) = 0
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY)
= -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY)
= -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
write(2, "sleep: ", 7) = 7
write(2, "cannot read realtime clock", 26) = 26
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
write(2, ": Unknown error 516", 19) = 19
write(2, "\n", 1) = 1
exit_group(1) = ?

-- Fernando


2005-10-14 19:25:09

by Badari Pulavarty

[permalink] [raw]
Subject: Re: 2.6.14-rc4-rt1

On Fri, 2005-10-14 at 15:12 +0200, Ingo Molnar wrote:
> * Andi Kleen <[email protected]> wrote:
>
> > > > I am getting similar segfault on boot problem on 2.6.14-rc4-rt1 on my
> > > > x86-64 box (with LATENCY_TRACE).
> > >
> > > > INIT: version 2.86 booting
> > > > hotplug[877]: segfault at ffffffff8010f588 rip ffffffff8010f588 rsp
> > > > 00007fffff8bee68 error 15
> > >
> > > what does the ffffffff8010f588 RIP address map to? You can find out by
> >
> > It could be any kernel address that someone injected into user space.
> > Most likely some problem with the vsyscall page with either signal
> > handling or gettimeofday. vsyscall code is tricky to hack because you
> > cannot add any new functions there, just inlines, otherwise the code
> > won't end up the right section.
>
> ah, indeed - i completely forgot about vsyscalls - they must not be
> traced. Badari, does the patch below help?
>
> Ingo
>
> Index: linux/arch/x86_64/kernel/vsyscall.c
> ===================================================================
> --- linux.orig/arch/x86_64/kernel/vsyscall.c
> +++ linux/arch/x86_64/kernel/vsyscall.c
> @@ -34,7 +34,7 @@
> #include <asm/errno.h>
> #include <asm/io.h>
>
> -#define __vsyscall(nr) __attribute__ ((unused,__section__(".vsyscall_" #nr)))
> +#define __vsyscall(nr) __attribute__ ((unused,__section__(".vsyscall_" #nr))) notrace
> #define force_inline __attribute__((always_inline)) inline
>
> int __sysctl_vsyscall __section_sysctl_vsyscall = 1;

The patch fixed my problem. Machine boots fine.

My next problem. I can't seem to compile the kernel on -rc4-rt1

elm3a242:/usr/src/linux-2.6.14-rc4 # make
CHK include/linux/version.h
SPLIT include/linux/autoconf.h -> include/config/*
CC arch/x86_64/kernel/asm-offsets.s
GEN include/asm-x86_64/asm-offsets.h
Trace/breakpoint trap
elm3a242:/usr/src/linux-2.6.14-rc4 # uname -a
Linux elm3a242 2.6.14-rc4-rt1 #4 SMP PREEMPT Fri Oct 14 05:16:35 PDT
2005 x86_64 x86_64 x86_64 GNU/Linux


Thanks,
Badari

2005-10-14 21:36:07

by Esben Nielsen

[permalink] [raw]
Subject: Re: 1.6ms jitter in rtc_wakeup (Re: 2.6.14-rc4-rt1)

On Fri, 14 Oct 2005, Ingo Molnar wrote:

>
> * Esben Nielsen <[email protected]> wrote:
>
> > I set up rtc_wakeup and got a jitter up 1.6ms!
> > It came when I cd'en into a nfs-mount and typed ls.
>
> > ls-11239 0Dn.. 4us : profile_hit (__schedule)
> > ls-11239 0Dn.1 4us : sched_clock (__schedule)
> > ls-11239 0Dn.1 5us : check_tsc_unstable (sched_clock)
> > ls-11239 0Dn.1 5us : tsc_read_c3_time (sched_clock)
> > IRQ 8-775 0D..2 6us : __switch_to (__schedule)
> > IRQ 8-775 0D..2 7us!: __schedule <ls-11239> (75 0)
> > IRQ 8-775 0...1 1594us : trace_stop_sched_switched (__schedule)
> > IRQ 8-775 0D..2 1594us : trace_stop_sched_switched <IRQ 8-775> (0 0)
> > IRQ 8-775 0D..2 1595us : trace_stop_sched_switched (__schedule)
>
> ouch! This very much looks like a hardware induced latency, because the
> codepath from those two __schedule points is extremely short and there
> is no loop there. Have you tested this particular box before too? If
> not, can you reproduce this latency with older versions of -rt too on
> the same box, or is this completely new?
I have been testing on this box before but never with such long latencies
before.
> Occasionally there are boxes
> that show clear signs of hardware latencies - there's little the kernel
> can do about those.
I actually felt like the box went to sleep.

>
> Wild shot in the dark: are there any power-saving modes enabled on the
> box?

I have had problems with power-saving before on this box. The effect is
usually the other way around: The rtdcs used to meassure the timing slows
down. I.e. it ought to meassure very short times, not very long times.

I'll try to disable power-management.

> Another shot in the dark: can you trigger these latencies if the
> networking card is ifconfig down-ed? I.e. perhaps it's related to DMA
> done by the networking device. Playing with BIOS settings / DMA/PCI
> priorities might help reduce DMA related latencies ...

Hmm. If it is a DMA transfer for the network device it ought to make bad
latencies for any network traffic not only NFS. I will have to test
various things during the weekend.

Esben

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

2005-10-19 07:52:53

by Esben Nielsen

[permalink] [raw]
Subject: Re: 1.6ms jitter in rtc_wakeup (Re: 2.6.14-rc4-rt1)

On Fri, 14 Oct 2005, Esben Nielsen wrote:

> On Fri, 14 Oct 2005, Ingo Molnar wrote:
>
> >
> > * Esben Nielsen <[email protected]> wrote:
> >
> > > I set up rtc_wakeup and got a jitter up 1.6ms!
> > > It came when I cd'en into a nfs-mount and typed ls.
> >
> > > ls-11239 0Dn.. 4us : profile_hit (__schedule)
> > > ls-11239 0Dn.1 4us : sched_clock (__schedule)
> > > ls-11239 0Dn.1 5us : check_tsc_unstable (sched_clock)
> > > ls-11239 0Dn.1 5us : tsc_read_c3_time (sched_clock)
> > > IRQ 8-775 0D..2 6us : __switch_to (__schedule)
> > > IRQ 8-775 0D..2 7us!: __schedule <ls-11239> (75 0)
> > > IRQ 8-775 0...1 1594us : trace_stop_sched_switched (__schedule)
> > > IRQ 8-775 0D..2 1594us : trace_stop_sched_switched <IRQ 8-775> (0 0)
> > > IRQ 8-775 0D..2 1595us : trace_stop_sched_switched (__schedule)
> >
> > ouch! This very much looks like a hardware induced latency, because the
> > codepath from those two __schedule points is extremely short and there
> > is no loop there. Have you tested this particular box before too? If
> > not, can you reproduce this latency with older versions of -rt too on
> > the same box, or is this completely new?
> I have been testing on this box before but never with such long latencies
> before.

I could not reproduce it on linux-2.6.14-rc3-rt10. The maximum meassured
rtc_wakeup is 146us with the same config options.
Running linux-2.6.14-rc4-rt1 with ethernet disabled gave a maximum latency
of 1468us while building the kernel:

preemption latency trace v1.1.5 on 2.6.14-rc4-rt1
--------------------------------------------------------------------
latency: 1468 us, #19/19, CPU#0 | (M:rt VP:0, KP:0, SP:1 HP:1)
-----------------
| task: IRQ 8-775 (uid:0 nice:-5 policy:1 rt_prio:99)
-----------------

_------=> CPU#
/ _-----=> irqs-off
| / _----=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
|||| /
||||| delay
cmd pid ||||| time | caller
\ / ||||| \ | /
cc1-8357 0D.h3 0us : __trace_start_sched_wakeup (try_to_wake_up)
cc1-8357 0D.h3 0us : __trace_start_sched_wakeup <IRQ 8-775> (0 0)
cc1-8357 0Dnh2 1us : try_to_wake_up <IRQ 8-775> (0 76)
cc1-8357 0Dnh1 1us : preempt_schedule (try_to_wake_up)
cc1-8357 0Dnh1 2us : wake_up_process (redirect_hardirq)
cc1-8357 0Dnh. 2us : preempt_schedule (__do_IRQ)
cc1-8357 0Dnh. 2us : irq_exit (do_IRQ)
cc1-8357 0Dn.. 3us : preempt_schedule_irq (need_resched)
cc1-8357 0Dn.. 3us : __schedule (preempt_schedule_irq)
cc1-8357 0Dn.. 4us : profile_hit (__schedule)
cc1-8357 0Dn.1 4us : sched_clock (__schedule)
cc1-8357 0Dn.1 4us : check_tsc_unstable (sched_clock)
IRQ 8-775 0D..2 6us : __switch_to (__schedule)
IRQ 8-775 0D..2 6us!: __schedule <cc1-8357> (76 0)
IRQ 8-775 0...1 1467us : trace_stop_sched_switched (__schedule)
IRQ 8-775 0D..2 1467us : trace_stop_sched_switched <IRQ 8-775> (0 0)
IRQ 8-775 0D..2 1468us : trace_stop_sched_switched (__schedule)

I have not yet got around to try without ACPI/APM/CPU frequency scaling.

Esben

2005-10-19 16:04:13

by Petr Vandrovec

[permalink] [raw]
Subject: Re: 1.6ms jitter in rtc_wakeup (Re: 2.6.14-rc4-rt1)

Esben Nielsen wrote:
> On Fri, 14 Oct 2005, Esben Nielsen wrote:
>>>>I set up rtc_wakeup and got a jitter up 1.6ms!
>>>>It came when I cd'en into a nfs-mount and typed ls.
>>>
>>>> ls-11239 0Dn.. 4us : profile_hit (__schedule)
>>>> ls-11239 0Dn.1 4us : sched_clock (__schedule)
>>>> ls-11239 0Dn.1 5us : check_tsc_unstable (sched_clock)
>>>> ls-11239 0Dn.1 5us : tsc_read_c3_time (sched_clock)
>>>> IRQ 8-775 0D..2 6us : __switch_to (__schedule)
>>>> IRQ 8-775 0D..2 7us!: __schedule <ls-11239> (75 0)
>>>> IRQ 8-775 0...1 1594us : trace_stop_sched_switched (__schedule)
>>>> IRQ 8-775 0D..2 1594us : trace_stop_sched_switched <IRQ 8-775> (0 0)
>>>> IRQ 8-775 0D..2 1595us : trace_stop_sched_switched (__schedule)
>>>
>>>ouch! This very much looks like a hardware induced latency, because the
>>>codepath from those two __schedule points is extremely short and there
>>>is no loop there. Have you tested this particular box before too? If
>>>not, can you reproduce this latency with older versions of -rt too on
>>>the same box, or is this completely new?
>>
>>I have been testing on this box before but never with such long latencies
>>before.
>
>
> I could not reproduce it on linux-2.6.14-rc3-rt10. The maximum meassured
> rtc_wakeup is 146us with the same config options.
> Running linux-2.6.14-rc4-rt1 with ethernet disabled gave a maximum latency
> of 1468us while building the kernel:

Hello,
I've just wrote to Randy that I'm seeing same on non-RT kernel when system
uses HPET. It makes it unusable for >512Hz, as when 1kHz timer is requested
we miss one tick and HPET interrupts stop for 5 minutes (32bit * 69.8ns).
Delay happens sometime after HPET programming - when frequency like 16kHz
is programmed, first ~6 interrupts arrive correctly, but 7th is delayed by
1 millisecond or so when compared with time on which it should arrive.

I've found it on VIA board, so I just assumed that VIA's hardware is
strange and went back to disabling HPET.

Maybe I should try -rt kernel sometime, but as I need working RTC interrupts
on that box for daily work, it is not simple to experiment with nohpet/hpet
options.
Petr

2005-10-19 18:07:43

by David Singleton

[permalink] [raw]
Subject: ktimer hiccup in rt11

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.14-rc4-rt11
# Wed Oct 19 08:37:53 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=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_EMBEDDED=y
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_CC_OPTIMIZE_FOR_SIZE is not set
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=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII 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=y
# 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=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_X86_MCE_P4THERMAL 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 is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
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=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

#
# 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_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE 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 is not set
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 is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_NETBIOS_NS is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# 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 is not set
# CONFIG_IP_NF_MATCH_REALM is not set
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_DCCP is not set
# CONFIG_IP_NF_MATCH_COMMENT 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 is not set
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=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=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 is not set

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

#
# Device Drivers
#

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

#
# 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 is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_1284 is not set

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

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

#
# 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 is not set
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_LBD=y
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=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_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX 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 is not set
# 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=y
# 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 is not set
# 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 is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
CONFIG_SCSI_DPT_I2O=m
# 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=y
# CONFIG_SCSI_SATA_AHCI is not set
# CONFIG_SCSI_SATA_SVW is not set
CONFIG_SCSI_ATA_PIIX=y
# CONFIG_SCSI_SATA_MV is not set
# CONFIG_SCSI_SATA_NV is not set
# CONFIG_SCSI_SATA_PROMISE is not set
# CONFIG_SCSI_SATA_QSTOR is not set
CONFIG_SCSI_SATA_SX4=m
# CONFIG_SCSI_SATA_SIL is not set
CONFIG_SCSI_SATA_SIS=m
# CONFIG_SCSI_SATA_ULI is not set
# CONFIG_SCSI_SATA_VIA is not set
# CONFIG_SCSI_SATA_VITESSE 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=m
# CONFIG_SCSI_IPR_TRACE is not set
# CONFIG_SCSI_IPR_DUMP 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 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 is not set
# CONFIG_IEEE1394_EXPORT_FULL_API is not set

#
# Device Drivers
#

#
# Texas Instruments PCILynx requires I2C
#
CONFIG_IEEE1394_OHCI1394=y

#
# Protocol Drivers
#
# CONFIG_IEEE1394_VIDEO1394 is not set
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394 is not set
# CONFIG_IEEE1394_DV1394 is not set
CONFIG_IEEE1394_RAWIO=y
# CONFIG_IEEE1394_CMP is not set

#
# I2O device support
#
# CONFIG_I2O is not set

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

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=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 is not set
# 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=y
CONFIG_8139TOO_8129=y
# 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 is not set
# 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 is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
CONFIG_S2IO=m
# CONFIG_S2IO_NAPI is not set
# CONFIG_2BUFF_MODE 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=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# 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 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 is not set
# 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_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=y
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
CONFIG_BLOCKER=y
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# 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_I810 is not set
# CONFIG_DRM_I830 is not set
# CONFIG_DRM_I915 is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# 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 is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
CONFIG_HWMON=y
# CONFIG_HWMON_VID 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 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_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# ISA devices
#
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
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 is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_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 is not set
# 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 is not set

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

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
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 is not set
# CONFIG_USB_ACM is not set
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 is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_ITMTOUCH is not set
CONFIG_USB_EGALAX=m
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set

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

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
CONFIG_USB_MON=y

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
CONFIG_USB_CYTHERM=m
# CONFIG_USB_PHIDGETKIT is not set
CONFIG_USB_PHIDGETSERVO=m
# 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 is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# 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=y
# 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=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_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=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
CONFIG_NFSD_TCP=y
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 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-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# 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 is not set
# 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 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# 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=14
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_SCHEDSTATS=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_IRQ_FLAGS=y
# CONFIG_WAKEUP_TIMING is not set
CONFIG_PREEMPT_TRACE=y
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
CONFIG_RT_DEADLOCK_DETECT=y
# CONFIG_DEBUG_RT_LOCKING_MODE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
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 is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y


Attachments:
config-rt11 (32.20 kB)