linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [patch] CONFIG_PREEMPT_REALTIME, 'Fully Preemptible Kernel', VP-2.6.9-rc4-mm1-T4
@ 2004-10-11 18:23 Mark_H_Johnson
  2004-10-11 21:59 ` [patch] VP-2.6.9-rc4-mm1-T5 Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Mark_H_Johnson @ 2004-10-11 18:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, Daniel Walker, K.R. Foley, linux-kernel,
	Florian Schmidt, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela

>i've released the -T4 VP patch:
>
>
http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T4


I would have to say this is "very rough" at this point. I had the following
problems in the build:
 [1] kernel/ksyms.c - undefined symbols
 [2] kernel/mutex.c - obvious cut / paste problems
 [3] XFS has incompatible mutex definition
 [4] suspicious warnings
 [5] missing symbols for modules
Details at the end.

I booted w/ SMP and the machine threw a lot of error messages about
sleeping in
an invalid context. For example:

include/linux/rwsem.h:43
in_atomic():1 [00010001], irqs_disabled():1
[<c011f0ea>] __might_sleep+0xca/0xe0
[<c01390d4>] rw_mutex_read_lock+0x34/0x50
[<c0122dbd>] profile_hook+0x1d/0x50
[<c0123338>] profile_tick+0x68/0x70
[<c01150ad>] smp_apic_timer_interrupt+0x5d/0xf0
[<c0105820>] default_idle+0x0/0x40
[<c010854a>] apic_timer_interrupt+0x1a/0x20
[<c0105820>] default_idle+0x0/0x40
[<c011007b>] dmi_get_system_info+0xb/0x20
[<c010585a>] default_idle+0x3a/0x40
[<c03b4a4d>] start_kernel+0x19d/0x1e0
[<c03b4440>] unknown_bootoption+0x0/0x180

(somehow managed to stop the scrolling console with the above message
displayed...)

Finally died with a kernel BUG
kernel BUG at kernel/latenc.c:419!
invalid operand: 0000 [#1]
PREEMPT SMP
Modules linked in microcode dm_mod uhci_hcd ext3 jbd
CPU:     1
EIP:    0001:[<00000000>]    Not tainted VLI
EFLAGS: c1663f38  (2.6.9-rc4-mm1-VP-T4)
EIP is at 0x0
eax: 00000000   ebx: c1663f54   ecx: c0109a8c   edx: c1663f78
esi: 0000000c   edi: c1663f28   ebp: c1663f3c   esp: c1663f78
ds: 007b   es: 07b   ss: 4f03   preempt: 00000001
Process swapper (pid: 0, threadinfo=c1662000 task=c165e550)
 <0> Kernel panic - not syncing: Attempted to kill the idle task!

Rebooting with num_cpus=1 and appeared to make it farther but then the
console scrolled like crazy and finally said "console shuts up ..."
and the machine appeared to be hung. Could not scroll the window up
or down to see the full message. Had to power off / on to get the
machine back up. Going back to -T3 until I see some fixes.

If the machine managed to record some good data in /var/log/messages
I will send them separately to you for reference.

--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>

Details on build problems / work arounds follow:

[1] ksyms.c - I commented these lines out, to get a complete build, but
there appears to
be code that expects rtc_lock to be defined. See #5.

arch/i386/kernel/i386_ksyms.c:166 error: `rtc_lock' undeclared here (not in
a function)
arch/i386/kernel/i386_ksyms.c:166 error: initializer element is not
constant
arch/i386/kernel/i386_ksyms.c:166 error: (near initialization for
`__ksymtab_rtc_lock.value')
followed by a similar error for atomic_dec_and_lock at line 177.

[2] mutex.c - several symbols were defined twice, fixed by changing the
names to
the functions preceeding them. See lines 108, 201, 213, 297.

[3] XFS compile failed as follows:
  CC [M]  fs/xfs/quota/xfs_dquot.o
In file included from fs/xfs/linux-2.6/xfs_linux.h:63,
                 from fs/xfs/xfs.h:35,
                 from fs/xfs/quota/xfs_dquot.c:33:
fs/xfs/linux-2.6/mutex.h:45: error: conflicting types for `mutex_t'
include/asm/spinlock.h:79: error: previous declaration of `mutex_t'
In file included from fs/xfs/linux-2.6/xfs_linux.h:102,
                 from fs/xfs/xfs.h:35,
                 from fs/xfs/quota/xfs_dquot.c:33:
fs/xfs/linux-2.6/xfs_vnode.h:578:30: macro "mutex_lock" requires 2
arguments, but only 1 given
fs/xfs/linux-2.6/xfs_vnode.h:585:30: macro "mutex_lock" requires 2
arguments, but only 1 given
fs/xfs/quota/xfs_dquot.c:1327:23: macro "mutex_lock" requires 2 arguments,
but only 1 given
fs/xfs/quota/xfs_dquot.c:1390:41: macro "mutex_lock" requires 2 arguments,
but only 1 given
fs/xfs/linux-2.6/xfs_vnode.h: In function `vn_flagset':
fs/xfs/linux-2.6/xfs_vnode.h:578: warning: statement with no effect
fs/xfs/linux-2.6/xfs_vnode.h: In function `vn_flagclr':
fs/xfs/linux-2.6/xfs_vnode.h:585: warning: statement with no effect
Turned off XFS in the build.

[4] I considered the following warnings to be "suspicious" but am not sure
if they are really problems or not.

  CC      security/selinux/ss/policydb.o
fs/dcache.c: In function `prune_dcache':
fs/dcache.c:391: warning: passing arg 1 of `cond_resched_lock' from
incompatible pointer type
  CC      security/selinux/ss/services.o
  CC      fs/inode.o
fs/inode.c: In function `invalidate_list':
fs/inode.c:317: warning: passing arg 1 of `cond_resched_lock' from
incompatible pointer type

[5] Several modules had undefined symbols. The messages were...

Kernel: arch/i386/boot/bzImage is ready
*** Warning: "mutex_trylock_bh" [drivers/net/ppp_synctty.ko] undefined!
*** Warning: "del_mtd_partitions" [drivers/mtd/maps/scx200_docflash.ko]
undefined!
*** Warning: "add_mtd_partitions" [drivers/mtd/maps/scx200_docflash.ko]
undefined!
*** Warning: "i2o_msg_in_to_virt" [drivers/message/i2o/i2o_scsi.ko]
undefined!
*** Warning: "i2o_msg_out_to_virt" [drivers/message/i2o/i2o_core.ko]
undefined!
*** Warning: "i2o_msg_in_to_virt" [drivers/message/i2o/i2o_core.ko]
undefined!
*** Warning: "i2o_msg_in_to_virt" [drivers/message/i2o/i2o_block.ko]
undefined!
*** Warning: "rtc_lock" [drivers/char/nvram.ko] undefined!
*** Warning: "rtc_lock" [drivers/char/mwave/mwave.ko] undefined!
*** Warning: "rtc_lock" [drivers/block/floppy.ko] undefined!
...
if [ -r System.map ]; then /sbin/depmod -ae -F System.map -b
/var/tmp/kernel-2.6.9rc4mm1VPT4-root -r 2.6.9-rc4-mm1-VP-T4; fi
WARNING: /var/tmp/kernel-2.6.9
rc4mm1VPT4-root/lib/modules/2.6.9-rc4-mm1-VP-T4/kernel/drivers/net/ppp_synctty.ko
 needs unknown symbol mutex_trylock_bh
WARNING: /var/tmp/kernel-2.6.9
rc4mm1VPT4-root/lib/modules/2.6.9-rc4-mm1-VP-T4/kernel/drivers/mtd/maps/scx200_docflash.ko
 needs unknown symbol del_mtd_partitions
WARNING: /var/tmp/kernel-2.6.9
rc4mm1VPT4-root/lib/modules/2.6.9-rc4-mm1-VP-T4/kernel/drivers/mtd/maps/scx200_docflash.ko
 needs unknown symbol add_mtd_partitions
WARNING: /var/tmp/kernel-2.6.9
rc4mm1VPT4-root/lib/modules/2.6.9-rc4-mm1-VP-T4/kernel/drivers/message/i2o/i2o_scsi.ko
 needs unknown symbol i2o_msg_in_to_virt
WARNING: /var/tmp/kernel-2.6.9
rc4mm1VPT4-root/lib/modules/2.6.9-rc4-mm1-VP-T4/kernel/drivers/message/i2o/i2o_core.ko
 needs unknown symbol i2o_msg_in_to_virt
WARNING: /var/tmp/kernel-2.6.9
rc4mm1VPT4-root/lib/modules/2.6.9-rc4-mm1-VP-T4/kernel/drivers/message/i2o/i2o_core.ko
 needs unknown symbol i2o_msg_out_to_virt
WARNING: /var/tmp/kernel-2.6.9
rc4mm1VPT4-root/lib/modules/2.6.9-rc4-mm1-VP-T4/kernel/drivers/message/i2o/i2o_block.ko
 needs unknown symbol i2o_msg_in_to_virt
WARNING: /var/tmp/kernel-2.6.9
rc4mm1VPT4-root/lib/modules/2.6.9-rc4-mm1-VP-T4/kernel/drivers/char/nvram.ko
 needs unknown symbol rtc_lock
WARNING: /var/tmp/kernel-2.6.9
rc4mm1VPT4-root/lib/modules/2.6.9-rc4-mm1-VP-T4/kernel/drivers/char/mwave/mwave.ko
 needs unknown symbol rtc_lock
WARNING: /var/tmp/kernel-2.6.9
rc4mm1VPT4-root/lib/modules/2.6.9-rc4-mm1-VP-T4/kernel/drivers/block/floppy.ko
 needs unknown symbol rtc_lock




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

* [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-11 18:23 [patch] CONFIG_PREEMPT_REALTIME, 'Fully Preemptible Kernel', VP-2.6.9-rc4-mm1-T4 Mark_H_Johnson
@ 2004-10-11 21:59 ` Ingo Molnar
  2004-10-11 22:57   ` Florian Schmidt
                     ` (4 more replies)
  0 siblings, 5 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-11 21:59 UTC (permalink / raw)
  To: Mark_H_Johnson
  Cc: Andrew Morton, Daniel Walker, K.R. Foley, linux-kernel,
	Florian Schmidt, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela


* Mark_H_Johnson@Raytheon.com <Mark_H_Johnson@Raytheon.com> wrote:

> I would have to say this is "very rough" at this point. I had the
> following problems in the build:

i've uploaded -T5 which should fix most of the build issues:

 http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T5

CONFIG_PREEMPT_REALTIME is still an experimental feature and defaults to
'n'.

-T5 will likely not fix the exit.c warnings, which, unless they are
accompanied by real crashes, should be mostly harmless. (famous last
words.) (The zombie task and self-reaping thread handling is a really
hard nut to crack, and i have nobody but me to blame for that code ...)

	Ingo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-11 21:59 ` [patch] VP-2.6.9-rc4-mm1-T5 Ingo Molnar
@ 2004-10-11 22:57   ` Florian Schmidt
  2004-10-11 23:14     ` Florian Schmidt
  2004-10-12  0:11   ` Rui Nuno Capela
                     ` (3 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-11 22:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Mark_H_Johnson, Andrew Morton, Daniel Walker, K.R. Foley,
	linux-kernel, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela

On Mon, 11 Oct 2004 23:59:09 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> i've uploaded -T5 which should fix most of the build issues:
> 
>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T5
> 

hi,

i still can't build it. Fist i reverse applied T4, then applied T5 and tried
a make bzImage. I'll try from scratch though to make sure, cause these
errors look identical to the T4 ones.

  CLEAN   .tmp_versions
  CHK     include/linux/version.h
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/split-include
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/genksyms/genksyms.o
  HOSTCC  scripts/genksyms/lex.o
  HOSTCC  scripts/genksyms/parse.o
  HOSTLD  scripts/genksyms/genksyms
  CC      scripts/mod/empty.o
  HOSTCC  scripts/mod/mk_elfconfig
  MKELF   scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/file2alias.o
  HOSTCC  scripts/mod/modpost.o
  HOSTCC  scripts/mod/sumversion.o
  HOSTLD  scripts/mod/modpost
  HOSTCC  scripts/kallsyms
  HOSTCC  scripts/conmakehash
  HOSTCC  scripts/bin2c
  CC      arch/i386/kernel/asm-offsets.s
In file included from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/spinlock.h:419: error: parse error before '*' token
include/linux/spinlock.h:419: warning: function declaration isn't a prototype
include/linux/spinlock.h:420: error: parse error before '*' token
include/linux/spinlock.h:420: warning: function declaration isn't a prototype
include/linux/spinlock.h:421: error: parse error before '*' token
include/linux/spinlock.h:421: warning: function declaration isn't a prototype
include/linux/spinlock.h:422: error: parse error before '*' token
include/linux/spinlock.h:422: warning: function declaration isn't a prototype
include/linux/spinlock.h:423: error: parse error before '*' token
include/linux/spinlock.h:423: warning: function declaration isn't a prototype
include/linux/spinlock.h:424: error: parse error before '*' token
include/linux/spinlock.h:424: warning: function declaration isn't a prototype
include/linux/spinlock.h:425: error: parse error before '*' token
include/linux/spinlock.h:425: warning: function declaration isn't a prototype
include/linux/spinlock.h:426: error: parse error before '*' token
include/linux/spinlock.h:426: warning: function declaration isn't a prototype
include/linux/spinlock.h:427: error: parse error before '*' token
include/linux/spinlock.h:427: warning: function declaration isn't a prototype
include/linux/spinlock.h:428: error: parse error before '*' token
include/linux/spinlock.h:428: warning: function declaration isn't a prototype
include/linux/spinlock.h:429: error: parse error before '*' token
include/linux/spinlock.h:429: warning: function declaration isn't a prototype
include/linux/spinlock.h:430: error: parse error before '*' token
include/linux/spinlock.h:430: warning: function declaration isn't a prototype
include/linux/spinlock.h:431: error: parse error before '*' token
include/linux/spinlock.h:431: warning: function declaration isn't a prototype
include/linux/spinlock.h:467: error: parse error before '*' token
include/linux/spinlock.h:467: warning: function declaration isn't a prototype
include/linux/spinlock.h:468: error: parse error before '*' token
include/linux/spinlock.h:468: warning: function declaration isn't a prototype
include/linux/spinlock.h:469: error: parse error before '*' token
include/linux/spinlock.h:469: warning: function declaration isn't a prototype
include/linux/spinlock.h:470: error: parse error before '*' token
include/linux/spinlock.h:470: warning: function declaration isn't a prototype
include/linux/spinlock.h:471: error: parse error before '*' token
include/linux/spinlock.h:471: warning: function declaration isn't a prototype
include/linux/spinlock.h:472: error: parse error before '*' token
include/linux/spinlock.h:472: warning: function declaration isn't a prototype
include/linux/spinlock.h:473: error: parse error before '*' token
include/linux/spinlock.h:473: warning: function declaration isn't a prototype
include/linux/spinlock.h:474: error: parse error before '*' token
include/linux/spinlock.h:474: warning: function declaration isn't a prototype
include/linux/spinlock.h:475: error: parse error before '*' token
include/linux/spinlock.h:475: warning: function declaration isn't a prototype
include/linux/spinlock.h:476: error: parse error before '*' token
include/linux/spinlock.h:476: warning: function declaration isn't a prototype
include/linux/spinlock.h:477: error: parse error before '*' token
include/linux/spinlock.h:477: warning: function declaration isn't a prototype
include/linux/spinlock.h:478: error: parse error before '*' token
include/linux/spinlock.h:478: warning: function declaration isn't a prototype
include/linux/spinlock.h:479: error: parse error before '*' token
include/linux/spinlock.h:479: warning: function declaration isn't a prototype
include/linux/spinlock.h:480: error: parse error before '*' token
include/linux/spinlock.h:480: warning: function declaration isn't a prototype
include/linux/spinlock.h:481: error: parse error before '*' token
include/linux/spinlock.h:481: warning: function declaration isn't a prototype
include/linux/spinlock.h:482: error: parse error before '*' token
include/linux/spinlock.h:482: warning: function declaration isn't a prototype
include/linux/spinlock.h:483: error: parse error before '*' token
include/linux/spinlock.h:483: warning: function declaration isn't a prototype
include/linux/spinlock.h:484: error: parse error before '*' token
include/linux/spinlock.h:484: warning: function declaration isn't a prototype
include/linux/spinlock.h:485: error: parse error before '*' token
include/linux/spinlock.h:485: warning: function declaration isn't a prototype
include/linux/spinlock.h:486: error: parse error before '*' token
include/linux/spinlock.h:486: warning: function declaration isn't a prototype
In file included from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/spinlock.h:543:1: warning: "spin_lock_init" redefined
include/linux/spinlock.h:208:1: warning: this is the location of the previous definition
include/linux/spinlock.h:548:1: warning: "rwlock_init" redefined
include/linux/spinlock.h:226:1: warning: this is the location of the previous definition
include/linux/spinlock.h:553:1: warning: "spin_is_locked" redefined
include/linux/spinlock.h:210:1: warning: this is the location of the previous definition
include/linux/spinlock.h:563:1: warning: "spin_unlock_wait" redefined
include/linux/spinlock.h:212:1: warning: this is the location of the previous definition
In file included from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/spinlock.h:669: error: parse error before "raw_spinlock_t"
include/linux/spinlock.h:669: warning: function declaration isn't a prototype
In file included from include/linux/time.h:7,
                 from include/linux/timex.h:58,
                 from include/linux/sched.h:11,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/seqlock.h:35: error: parse error before "raw_spinlock_t"
include/linux/seqlock.h:35: warning: no semicolon at end of struct or union
include/linux/seqlock.h:36: warning: type defaults to `int' in declaration of `seqlock_t'
include/linux/seqlock.h:36: warning: data definition has no type or storage class
include/linux/seqlock.h:50: error: parse error before '*' token
include/linux/seqlock.h:51: warning: function declaration isn't a prototype
include/linux/seqlock.h: In function `write_seqlock':
include/linux/seqlock.h:52: error: `sl' undeclared (first use in this function)
include/linux/seqlock.h:52: error: (Each undeclared identifier is reported only once
include/linux/seqlock.h:52: error: for each function it appears in.)
include/linux/seqlock.h:52: error: parse error before "raw_spinlock_t"
include/linux/seqlock.h:52: error: `raw_spinlock_t' undeclared (first use in this function)
include/linux/seqlock.h:52: error: parse error before ')' token
include/linux/seqlock.h: At top level:
include/linux/seqlock.h:52: error: parse error before "while"
include/linux/seqlock.h:57: error: parse error before '*' token
include/linux/seqlock.h:58: warning: function declaration isn't a prototype
include/linux/seqlock.h: In function `write_sequnlock':
include/linux/seqlock.h:60: error: `sl' undeclared (first use in this function)
include/linux/seqlock.h:61: error: parse error before "raw_spinlock_t"
include/linux/seqlock.h: At top level:
include/linux/seqlock.h:61: error: parse error before "while"
include/linux/seqlock.h:64: error: parse error before '*' token
include/linux/seqlock.h:65: warning: function declaration isn't a prototype
include/linux/seqlock.h: In function `write_tryseqlock':
include/linux/seqlock.h:66: error: `sl' undeclared (first use in this function)
include/linux/seqlock.h:66: error: parse error before "raw_spinlock_t"
include/linux/seqlock.h:66: warning: unused variable `__ret'
include/linux/seqlock.h:66: error: parse error before "while"
include/linux/seqlock.h:66: error: `raw_spinlock_t' undeclared (first use in this function)
include/linux/seqlock.h:66: error: parse error before ')' token
include/linux/seqlock.h:66: warning: left-hand operand of comma expression has no effect
include/linux/seqlock.h:66: warning: unused variable `ret'
include/linux/seqlock.h:66: warning: no return statement in function returning non-void
include/linux/seqlock.h: At top level:
include/linux/seqlock.h:66: error: parse error before ')' token
include/linux/seqlock.h:66: warning: type defaults to `int' in declaration of `__ret'
include/linux/seqlock.h:66: warning: data definition has no type or storage class
include/linux/seqlock.h:66: error: parse error before '}' token
include/linux/seqlock.h:76: warning: type defaults to `int' in declaration of `seqlock_t'
include/linux/seqlock.h:76: error: parse error before '*' token
include/linux/seqlock.h:77: warning: function declaration isn't a prototype
include/linux/seqlock.h: In function `read_seqbegin':
include/linux/seqlock.h:78: error: `sl' undeclared (first use in this function)
include/linux/seqlock.h: At top level:
include/linux/seqlock.h:91: warning: type defaults to `int' in declaration of `seqlock_t'
include/linux/seqlock.h:91: error: parse error before '*' token
include/linux/seqlock.h:92: warning: function declaration isn't a prototype
include/linux/seqlock.h: In function `read_seqretry':
include/linux/seqlock.h:94: error: `iv' undeclared (first use in this function)
include/linux/seqlock.h:94: error: `sl' undeclared (first use in this function)
In file included from include/linux/timex.h:58,
                 from include/linux/sched.h:11,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/time.h: At top level:
include/linux/time.h:83: error: parse error before "xtime_lock"
include/linux/time.h:83: warning: type defaults to `int' in declaration of `xtime_lock'
include/linux/time.h:83: warning: data definition has no type or storage class
In file included from include/asm/semaphore.h:41,
                 from include/linux/sched.h:19,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/wait.h:82: error: parse error before '*' token
include/linux/wait.h:83: warning: function declaration isn't a prototype
include/linux/wait.h: In function `init_waitqueue_head':
include/linux/wait.h:84: error: `q' undeclared (first use in this function)
include/linux/wait.h:84: error: `RAW_SPIN_LOCK_UNLOCKED' undeclared (first use in this function)
include/linux/wait.h: At top level:
include/linux/wait.h:103: error: parse error before '*' token
include/linux/wait.h:104: warning: function declaration isn't a prototype
include/linux/wait.h: In function `waitqueue_active':
include/linux/wait.h:105: error: `q' undeclared (first use in this function)
include/linux/wait.h: At top level:
include/linux/wait.h:117: error: parse error before '*' token
include/linux/wait.h:117: warning: function declaration isn't a prototype
include/linux/wait.h:118: error: parse error before '*' token
include/linux/wait.h:118: warning: function declaration isn't a prototype
include/linux/wait.h:119: error: parse error before '*' token
include/linux/wait.h:119: warning: function declaration isn't a prototype
include/linux/wait.h:121: error: parse error before '*' token
include/linux/wait.h:122: warning: function declaration isn't a prototype
include/linux/wait.h: In function `__add_wait_queue':
include/linux/wait.h:123: error: `new' undeclared (first use in this function)
include/linux/wait.h:123: error: `head' undeclared (first use in this function)
include/linux/wait.h: At top level:
include/linux/wait.h:129: error: parse error before '*' token
include/linux/wait.h:131: warning: function declaration isn't a prototype
include/linux/wait.h: In function `__add_wait_queue_tail':
include/linux/wait.h:132: error: `new' undeclared (first use in this function)
include/linux/wait.h:132: error: `head' undeclared (first use in this function)
include/linux/wait.h: At top level:
include/linux/wait.h:135: error: parse error before '*' token
include/linux/wait.h:137: warning: function declaration isn't a prototype
include/linux/wait.h: In function `__remove_wait_queue':
include/linux/wait.h:138: error: `old' undeclared (first use in this function)
include/linux/wait.h: At top level:
include/linux/wait.h:141: error: parse error before '*' token
include/linux/wait.h:141: warning: function declaration isn't a prototype
include/linux/wait.h:142: error: parse error before '*' token
include/linux/wait.h:142: warning: function declaration isn't a prototype
include/linux/wait.h:143: error: parse error before '*' token
include/linux/wait.h:143: warning: function declaration isn't a prototype
include/linux/wait.h:144: error: parse error before '*' token
include/linux/wait.h:144: warning: function declaration isn't a prototype
include/linux/wait.h:145: error: parse error before '*' token
include/linux/wait.h:145: error: `__wait_on_bit' declared as function returning a function
include/linux/wait.h:145: warning: function declaration isn't a prototype
include/linux/wait.h:145: error: parse error before "unsigned"
include/linux/wait.h:146: error: parse error before '*' token
include/linux/wait.h:146: error: `__wait_on_bit_lock' declared as function returning a function
include/linux/wait.h:146: warning: function declaration isn't a prototype
include/linux/wait.h:146: error: parse error before "unsigned"
include/linux/wait.h:150: error: parse error before '*' token
include/linux/wait.h:150: warning: type defaults to `int' in declaration of `bit_waitqueue'
include/linux/wait.h:150: warning: data definition has no type or storage class
include/linux/wait.h:288: error: parse error before '*' token
include/linux/wait.h:290: warning: function declaration isn't a prototype
include/linux/wait.h: In function `add_wait_queue_exclusive_locked':
include/linux/wait.h:291: error: `wait' undeclared (first use in this function)
include/linux/wait.h:292: error: `q' undeclared (first use in this function)
include/linux/wait.h: At top level:
include/linux/wait.h:298: error: parse error before '*' token
include/linux/wait.h:300: warning: function declaration isn't a prototype
include/linux/wait.h: In function `remove_wait_queue_locked':
include/linux/wait.h:301: error: `q' undeclared (first use in this function)
include/linux/wait.h:301: error: `wait' undeclared (first use in this function)
include/linux/wait.h: At top level:
include/linux/wait.h:309: error: parse error before '*' token
include/linux/wait.h:309: warning: function declaration isn't a prototype
include/linux/wait.h:310: error: parse error before '*' token
include/linux/wait.h:310: warning: function declaration isn't a prototype
include/linux/wait.h:312: error: parse error before '*' token
include/linux/wait.h:312: warning: function declaration isn't a prototype
include/linux/wait.h:313: error: parse error before '*' token
include/linux/wait.h:313: warning: function declaration isn't a prototype
include/linux/wait.h:319: error: parse error before '*' token
include/linux/wait.h:319: warning: function declaration isn't a prototype
include/linux/wait.h:321: error: parse error before '*' token
include/linux/wait.h:321: warning: function declaration isn't a prototype
include/linux/wait.h:323: error: parse error before '*' token
include/linux/wait.h:323: warning: function declaration isn't a prototype
In file included from include/asm/rwsem.h:42,
                 from include/linux/rwsem.h:27,
                 from include/asm/semaphore.h:42,
                 from include/linux/sched.h:19,
                 from arch/i386/kernel/asm-offsets.c:7:
include/asm/spinlock.h:26: error: `raw_spinlock_t' used prior to declaration
In file included from include/asm/rwsem.h:42,
                 from include/linux/rwsem.h:27,
                 from include/asm/semaphore.h:42,
                 from include/linux/sched.h:19,
                 from arch/i386/kernel/asm-offsets.c:7:
include/asm/spinlock.h:80:1: warning: "SPIN_LOCK_UNLOCKED" redefined
In file included from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/spinlock.h:199:1: warning: this is the location of the previous definition
include/asm/spinlock.h:86: error: conflicting types for `spinlock_t'
include/linux/spinlock.h:198: error: previous declaration of `spinlock_t'
In file included from include/asm/rwsem.h:42,
                 from include/linux/rwsem.h:27,
                 from include/asm/semaphore.h:42,
                 from include/linux/sched.h:19,
                 from arch/i386/kernel/asm-offsets.c:7:
include/asm/spinlock.h:93:1: warning: "RW_LOCK_UNLOCKED" redefined
In file included from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/spinlock.h:220:1: warning: this is the location of the previous definition
include/asm/spinlock.h:99: error: conflicting types for `rwlock_t'
include/linux/spinlock.h:219: error: previous declaration of `rwlock_t'
include/asm/spinlock.h:165: error: parse error before "do"
include/asm/spinlock.h:197: error: parse error before "void"
include/asm/spinlock.h:207: error: parse error before "do"
include/asm/spinlock.h:259: error: parse error before "do"
include/asm/spinlock.h:267: error: parse error before "do"
In file included from include/asm/rwsem.h:42,
                 from include/linux/rwsem.h:27,
                 from include/asm/semaphore.h:42,
                 from include/linux/sched.h:19,
                 from arch/i386/kernel/asm-offsets.c:7:
include/asm/spinlock.h:275:1: warning: "_raw_read_unlock" redefined
In file included from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/spinlock.h:228:1: warning: this is the location of the previous definition
In file included from include/asm/rwsem.h:42,
                 from include/linux/rwsem.h:27,
                 from include/asm/semaphore.h:42,
                 from include/linux/sched.h:19,
                 from arch/i386/kernel/asm-offsets.c:7:
include/asm/spinlock.h:276:1: warning: "_raw_write_unlock" redefined
In file included from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/spinlock.h:230:1: warning: this is the location of the previous definition
include/asm/spinlock.h:278: error: parse error before '{' token
include/asm/spinlock.h:281: warning: type defaults to `int' in declaration of `atomic_dec'
include/asm/spinlock.h:281: warning: parameter names (without types) in function declaration
include/asm/spinlock.h:281: error: conflicting types for `atomic_dec'
include/asm/atomic.h:116: error: previous declaration of `atomic_dec'
include/asm/spinlock.h:281: warning: data definition has no type or storage class
include/asm/spinlock.h:282: error: parse error before "if"
include/asm/spinlock.h:284: warning: type defaults to `int' in declaration of `atomic_inc'
include/asm/spinlock.h:284: warning: parameter names (without types) in function declaration
include/asm/spinlock.h:284: error: conflicting types for `atomic_inc'
include/asm/atomic.h:102: error: previous declaration of `atomic_inc'
include/asm/spinlock.h:284: warning: data definition has no type or storage class
include/asm/spinlock.h:285: error: parse error before "return"
include/asm/spinlock.h:288: error: parse error before '{' token
include/asm/spinlock.h:293: error: parse error before numeric constant
include/asm/spinlock.h:293: warning: type defaults to `int' in declaration of `atomic_add'
include/asm/spinlock.h:293: warning: function declaration isn't a prototype
include/asm/spinlock.h:293: error: conflicting types for `atomic_add'
include/asm/atomic.h:53: error: previous declaration of `atomic_add'
include/asm/spinlock.h:293: warning: data definition has no type or storage class
In file included from arch/i386/kernel/asm-offsets.c:7:
include/linux/sched.h:847:56: macro "_spin_lock_irqsave" requires 2 arguments, but only 1 given
In file included from arch/i386/kernel/asm-offsets.c:7:
include/linux/sched.h: In function `dequeue_signal_lock':
include/linux/sched.h:847: error: `_spin_lock_irqsave' undeclared (first use in this function)
include/linux/seqlock.h: In function `write_tryseqlock':
include/linux/seqlock.h:66: warning: statement with no effect
make[1]: *** [arch/i386/kernel/asm-offsets.s] Error 1
make: *** [arch/i386/kernel/asm-offsets.s] Error 2

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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-11 22:57   ` Florian Schmidt
@ 2004-10-11 23:14     ` Florian Schmidt
  2004-10-12  0:52       ` Lee Revell
  2004-10-12  6:12       ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-11 23:14 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, Mark_H_Johnson, Andrew Morton, Daniel Walker,
	K.R. Foley, linux-kernel, Fernando Pablo Lopez-Lezcano,
	Lee Revell, Rui Nuno Capela

On Tue, 12 Oct 2004 00:57:54 +0200
Florian Schmidt <mista.tapas@gmx.net> wrote:

> hi,
> 
> i still can't build it. Fist i reverse applied T4, then applied T5 and tried
> a make bzImage. I'll try from scratch though to make sure, cause these
> errors look identical to the T4 ones.
> 

same errors.. Both with the preemptible real time thingy and without..

flo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-11 21:59 ` [patch] VP-2.6.9-rc4-mm1-T5 Ingo Molnar
  2004-10-11 22:57   ` Florian Schmidt
@ 2004-10-12  0:11   ` Rui Nuno Capela
  2004-10-12  0:57   ` Lee Revell
                     ` (2 subsequent siblings)
  4 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-12  0:11 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: mark_h_johnson, Andrew Morton, Daniel Walker, K.R. Foley,
	linux-kernel, Florian Schmidt, Fernando Pablo Lopez-Lezcano,
	Lee Revell

Ingo Molnar wrote:
>
> i've uploaded -T5 which should fix most of the build issues:
>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T5
>

Sharp roughness is the name of the game ;)

Built fine here, for P4 SMP/HT, and CONFIG_PREEMPT_REALTIME=y.

But, not surprisingly, booting/initing gives me lots of fireworks. This is
just some (tiny) sample taken from syslog:

Oct 12 00:15:26 gamma-suse1 kernel: Debug: sleeping function called from
invalid context pdflush(120) at kernel/mutex.c:23
Oct 12 00:15:26 gamma-suse1 kernel: in_atomic():1 [00000001],
irqs_disabled():1
Oct 12 00:15:26 gamma-suse1 kernel:  [__might_sleep+193/212]
__might_sleep+0xc1/0xd4
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0118fca>] __might_sleep+0xc1/0xd4
Oct 12 00:15:26 gamma-suse1 kernel:  [_mutex_lock+39/96]
_mutex_lock+0x27/0x60
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0130d0c>] _mutex_lock+0x27/0x60
Oct 12 00:15:26 gamma-suse1 kernel:  [_mutex_lock_irqsave+22/26]
_mutex_lock_irqsave+0x16/0x1a
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0130d7d>]
_mutex_lock_irqsave+0x16/0x1a
Oct 12 00:15:26 gamma-suse1 kernel:  [page_address+78/158]
page_address+0x4e/0x9e
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0149c97>] page_address+0x4e/0x9e
Oct 12 00:15:26 gamma-suse1 kernel:  [bio_hw_segments+12/48]
bio_hw_segments+0xc/0x30
Oct 12 00:15:26 gamma-suse1 kernel:  [<c01617ca>] bio_hw_segments+0xc/0x30
Oct 12 00:15:26 gamma-suse1 kernel:  [__make_request+1010/1251]
__make_request+0x3f2/0x4e3
Oct 12 00:15:26 gamma-suse1 kernel:  [<c023db69>] __make_request+0x3f2/0x4e3
Oct 12 00:15:26 gamma-suse1 kernel:  [generic_make_request+298/662]
generic_make_request+0x12a/0x296
Oct 12 00:15:26 gamma-suse1 kernel:  [<c023dee4>]
generic_make_request+0x12a/0x296
...

Oct 12 00:15:26 gamma-suse1 kernel: Debug: sleeping function called from
invalid context modprobe(1666) at kernel/mutex.c:23
Oct 12 00:15:26 gamma-suse1 kernel: in_atomic():1 [00000001],
irqs_disabled():1
Oct 12 00:15:26 gamma-suse1 kernel:  [__might_sleep+193/212]
__might_sleep+0xc1/0xd4
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0118fca>] __might_sleep+0xc1/0xd4
Oct 12 00:15:26 gamma-suse1 kernel:  [_mutex_lock+39/96]
_mutex_lock+0x27/0x60
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0130d0c>] _mutex_lock+0x27/0x60
Oct 12 00:15:26 gamma-suse1 kernel:  [_mutex_lock_irqsave+22/26]
_mutex_lock_irqsave+0x16/0x1a
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0130d7d>]
_mutex_lock_irqsave+0x16/0x1a
Oct 12 00:15:26 gamma-suse1 kernel:  [page_address+78/158]
page_address+0x4e/0x9e
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0149c97>] page_address+0x4e/0x9e
Oct 12 00:15:26 gamma-suse1 kernel:  [bio_hw_segments+12/48]
bio_hw_segments+0xc/0x30
Oct 12 00:15:26 gamma-suse1 kernel:  [<c01617ca>] bio_hw_segments+0xc/0x30
Oct 12 00:15:26 gamma-suse1 kernel:  [__make_request+1010/1251]
__make_request+0x3f2/0x4e3
Oct 12 00:15:26 gamma-suse1 kernel:  [<c023db69>] __make_request+0x3f2/0x4e3
Oct 12 00:15:26 gamma-suse1 kernel:  [generic_make_request+298/662]
generic_make_request+0x12a/0x296
Oct 12 00:15:26 gamma-suse1 kernel:  [<c023dee4>]
generic_make_request+0x12a/0x296
...

Oct 12 00:15:26 gamma-suse1 kernel: Debug: sleeping function called from
invalid context blogd(1851) at kernel/mutex.c:23
Oct 12 00:15:26 gamma-suse1 kernel: in_atomic():1 [00000001],
irqs_disabled():1
Oct 12 00:15:26 gamma-suse1 kernel:  [__might_sleep+193/212]
__might_sleep+0xc1/0xd4
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0118fca>] __might_sleep+0xc1/0xd4
Oct 12 00:15:26 gamma-suse1 kernel:  [_mutex_lock+39/96]
_mutex_lock+0x27/0x60
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0130d0c>] _mutex_lock+0x27/0x60
Oct 12 00:15:26 gamma-suse1 kernel:  [_mutex_lock_irqsave+22/26]
_mutex_lock_irqsave+0x16/0x1a
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0130d7d>]
_mutex_lock_irqsave+0x16/0x1a
Oct 12 00:15:26 gamma-suse1 kernel:  [page_address+78/158]
page_address+0x4e/0x9e
Oct 12 00:15:26 gamma-suse1 kernel:  [<c0149c97>] page_address+0x4e/0x9e
Oct 12 00:15:26 gamma-suse1 kernel:  [bio_hw_segments+12/48]
bio_hw_segments+0xc/0x30
Oct 12 00:15:26 gamma-suse1 kernel:  [<c01617ca>] bio_hw_segments+0xc/0x30
Oct 12 00:15:26 gamma-suse1 kernel:  [__make_request+1010/1251]
__make_request+0x3f2/0x4e3
Oct 12 00:15:26 gamma-suse1 kernel:  [<c023db69>] __make_request+0x3f2/0x4e3
Oct 12 00:15:26 gamma-suse1 kernel:  [generic_make_request+298/662]
generic_make_request+0x12a/0x296
Oct 12 00:15:26 gamma-suse1 kernel:  [<c023dee4>]
generic_make_request+0x12a/0x296
...

An so on, and so on...
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-11 23:14     ` Florian Schmidt
@ 2004-10-12  0:52       ` Lee Revell
  2004-10-12  8:22         ` Wen-chien Jesse Sung
  2004-10-12  6:12       ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-12  0:52 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, Mark_H_Johnson, Andrew Morton, Daniel Walker,
	K.R. Foley, linux-kernel, Fernando Pablo Lopez-Lezcano,
	Rui Nuno Capela

On Mon, 2004-10-11 at 19:14, Florian Schmidt wrote:
> On Tue, 12 Oct 2004 00:57:54 +0200
> Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > hi,
> > 
> > i still can't build it. Fist i reverse applied T4, then applied T5 and tried
> > a make bzImage. I'll try from scratch though to make sure, cause these
> > errors look identical to the T4 ones.
> > 
> 
> same errors.. Both with the preemptible real time thingy and without..
> 

Try building for SMP.  I suspect this is a UP build problem.

Lee


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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-11 21:59 ` [patch] VP-2.6.9-rc4-mm1-T5 Ingo Molnar
  2004-10-11 22:57   ` Florian Schmidt
  2004-10-12  0:11   ` Rui Nuno Capela
@ 2004-10-12  0:57   ` Lee Revell
  2004-10-12  6:37     ` Ingo Molnar
  2004-10-12  3:51   ` K.R. Foley
  2004-10-12  9:15   ` [patch] VP-2.6.9-rc4-mm1-T6 Ingo Molnar
  4 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-12  0:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Mark_H_Johnson, Andrew Morton, Daniel Walker, K.R. Foley,
	linux-kernel, Florian Schmidt, Fernando Pablo Lopez-Lezcano,
	Rui Nuno Capela, thewade

On Mon, 2004-10-11 at 17:59, Ingo Molnar wrote:
> * Mark_H_Johnson@Raytheon.com <Mark_H_Johnson@Raytheon.com> wrote:
> 
> > I would have to say this is "very rough" at this point. I had the
> > following problems in the build:
> 
> i've uploaded -T5 which should fix most of the build issues:
> 
>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T5
> 

Ingo, are any of the VP patches known to work on x64?  Here is thewade's
latest report:

--

I applied the patch and the kernel built, but like 2.6.9-mm2-VP-S9 it
crashed before it could load. The last bit of the message was a lot of
what I guess are frame pointers, but there was a few lines that had
info.
For example an RIP message having to do with add_preempt_count+16

But it all ended with Aieee...

I have yet to get any VP kernel to run on my x86_64. I suppose I should
try just the mm3 or mm4 patches without the VP portion, so that is what
I will do.

--

Lee


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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-11 21:59 ` [patch] VP-2.6.9-rc4-mm1-T5 Ingo Molnar
                     ` (2 preceding siblings ...)
  2004-10-12  0:57   ` Lee Revell
@ 2004-10-12  3:51   ` K.R. Foley
  2004-10-12  6:02     ` Ingo Molnar
  2004-10-12  9:15   ` [patch] VP-2.6.9-rc4-mm1-T6 Ingo Molnar
  4 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-12  3:51 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Mark_H_Johnson, Andrew Morton, Daniel Walker, linux-kernel,
	Florian Schmidt, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela

Ingo Molnar wrote:
> * Mark_H_Johnson@Raytheon.com <Mark_H_Johnson@Raytheon.com> wrote:
> 
> 
>>I would have to say this is "very rough" at this point. I had the
>>following problems in the build:
> 
> 
> i've uploaded -T5 which should fix most of the build issues:
> 

This fixed the build problems for me (SMP). I did get one unresolved 
symbol when building this with REALTIME enabled. Also got error messages 
scrolling up the screen when I tried to boot it (looked very much like 
Mark's problem with T4) and it never made it. :( If I had to guess, it 
might be related to APICs? I always have to use "noapic" boot parameter. 
Ingo what are you running this on? I don't have the exact error 
messages, but I'm rebuilding it now to try to get those. Without RT 
Preemption it seems to be running very nicely.

kr

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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-12  3:51   ` K.R. Foley
@ 2004-10-12  6:02     ` Ingo Molnar
  2004-10-12 11:08       ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12  6:02 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Mark_H_Johnson, Andrew Morton, Daniel Walker, linux-kernel,
	Florian Schmidt, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela


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

> >i've uploaded -T5 which should fix most of the build issues:
> >
> 
> This fixed the build problems for me (SMP). I did get one unresolved
> symbol when building this with REALTIME enabled.

(which symbol was this?)

> [...] Also got error messages scrolling up the screen when I tried to
> boot it (looked very much like Mark's problem with T4) and it never
> made it. :( If I had to guess, it might be related to APICs? I always
> have to use "noapic" boot parameter.  Ingo what are you running this
> on? I don't have the exact error messages, but I'm rebuilding it now
> to try to get those. Without RT Preemption it seems to be running very
> nicely.

dont worry about it not booting on your setup with PREEMPT_REALTIME, as
long as it boots with !PREEMPT_REALTIME - i only really converted my
testsystems which are basically IDE + e100/e1000/rtl8139, ext3 and the
bare minimum that is needed to run Fedora. It might be useful to send me
a bootlog if you have any easy way to capture it - if not it's not a big
problem either.

	Ingo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-11 23:14     ` Florian Schmidt
  2004-10-12  0:52       ` Lee Revell
@ 2004-10-12  6:12       ` Ingo Molnar
  2004-10-12 10:45         ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12  6:12 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Mark_H_Johnson, Andrew Morton, Daniel Walker, K.R. Foley,
	linux-kernel, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> On Tue, 12 Oct 2004 00:57:54 +0200
> Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > hi,
> > 
> > i still can't build it. Fist i reverse applied T4, then applied T5 and tried
> > a make bzImage. I'll try from scratch though to make sure, cause these
> > errors look identical to the T4 ones.
> > 
> 
> same errors.. Both with the preemptible real time thingy and without..

could you send me your .config? Had to do some wacky include file magic
to be able to use semaphores in spinlocks, but could easily have missed
some .config variations.

	Ingo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-12  0:57   ` Lee Revell
@ 2004-10-12  6:37     ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12  6:37 UTC (permalink / raw)
  To: Lee Revell
  Cc: Mark_H_Johnson, Andrew Morton, Daniel Walker, K.R. Foley,
	linux-kernel, Florian Schmidt, Fernando Pablo Lopez-Lezcano,
	Rui Nuno Capela, thewade


* Lee Revell <rlrevell@joe-job.com> wrote:

> On Mon, 2004-10-11 at 17:59, Ingo Molnar wrote:
> > * Mark_H_Johnson@Raytheon.com <Mark_H_Johnson@Raytheon.com> wrote:
> > 
> > > I would have to say this is "very rough" at this point. I had the
> > > following problems in the build:
> > 
> > i've uploaded -T5 which should fix most of the build issues:
> > 
> >  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T5
> > 
> 
> Ingo, are any of the VP patches known to work on x64?  Here is
> thewade's latest report:

i have two x64 boxes which i tested with S* -VP and i also did a quick
testboot of -T3 on one of them but YMMV. (There's one caveat: latency
tracing must not be enabled, x64 gcc has a nastiness that makes -pg
unusable for tracing purposes on x64.)

-T4 and upwards will likely not even compile on x64 - i'll fix it up
once the rate of PREEMPT_REALTIME changes calms down.

	Ingo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-12  0:52       ` Lee Revell
@ 2004-10-12  8:22         ` Wen-chien Jesse Sung
  0 siblings, 0 replies; 951+ messages in thread
From: Wen-chien Jesse Sung @ 2004-10-12  8:22 UTC (permalink / raw)
  To: Lee Revell
  Cc: Florian Schmidt, Ingo Molnar, Mark_H_Johnson, Andrew Morton,
	Daniel Walker, K.R. Foley, linux-kernel,
	Fernando Pablo Lopez-Lezcano, Rui Nuno Capela

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

Lee Revell wrote:
> On Mon, 2004-10-11 at 19:14, Florian Schmidt wrote:
> > On Tue, 12 Oct 2004 00:57:54 +0200
> > Florian Schmidt <mista.tapas@gmx.net> wrote:
> > 
> > > hi,
> > > 
> > > i still can't build it. Fist i reverse applied T4, then applied T5 and tried
> > > a make bzImage. I'll try from scratch though to make sure, cause these
> > > errors look identical to the T4 ones.
> > > 
> > 
> > same errors.. Both with the preemptible real time thingy and without..
> > 
> 
> Try building for SMP.  I suspect this is a UP build problem.

I got same errors...
Struct mutex_t is defined in include/asm-i386/spinlock.h. It's only
included in include/linux/spinlock.h if CONFIG_SMP is set, but mutex_t
is used at include/linux/spinlock.h:419. Set CONFIG_SMP=y then kernel
builds successfully here.

-- 
Best Regards,
Wen-chien Jesse Sung

[-- Attachment #2: 這是數位加簽的郵件 --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

* [patch] VP-2.6.9-rc4-mm1-T6
  2004-10-11 21:59 ` [patch] VP-2.6.9-rc4-mm1-T5 Ingo Molnar
                     ` (3 preceding siblings ...)
  2004-10-12  3:51   ` K.R. Foley
@ 2004-10-12  9:15   ` Ingo Molnar
  2004-10-12  9:31     ` Wen-chien Jesse Sung
                       ` (2 more replies)
  4 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12  9:15 UTC (permalink / raw)
  To: linux-kernel
  Cc: Daniel Walker, K.R. Foley, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Wen-chien Jesse Sung, Mark_H_Johnson


i've uploaded -T6:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T6

this should fix the UP build issues reported by many. -T6 also brings
back the ->break_lock framework and converts a few more locks to raw.

SMP is still expected to be flaky due to the zombie-task problem(s). But
UP is not out of the 'extremely experimental' status either.

to create a -T6 tree from scratch the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T6

	Ingo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T6
  2004-10-12  9:15   ` [patch] VP-2.6.9-rc4-mm1-T6 Ingo Molnar
@ 2004-10-12  9:31     ` Wen-chien Jesse Sung
  2004-10-12 10:35       ` Ingo Molnar
  2004-10-12  9:42     ` Ingo Molnar
  2004-10-12 12:33     ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Wen-chien Jesse Sung @ 2004-10-12  9:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Daniel Walker, K.R. Foley, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson

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

Ingo Molnar wrote:
> i've uploaded -T6:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T6
> 
> this should fix the UP build issues reported by many. -T6 also brings
> back the ->break_lock framework and converts a few more locks to raw.

UP build is still failed: 
 arch/i386/kernel/vm86.c:707: error: `__RAW_SPIN_LOCK_UNLOCKED'
undeclared here (not in a function)

-- 
Best Regards,
Wen-chien Jesse Sung

[-- Attachment #2: 這是數位加簽的郵件 --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

* Re: [patch] VP-2.6.9-rc4-mm1-T6
  2004-10-12  9:15   ` [patch] VP-2.6.9-rc4-mm1-T6 Ingo Molnar
  2004-10-12  9:31     ` Wen-chien Jesse Sung
@ 2004-10-12  9:42     ` Ingo Molnar
  2004-10-12  9:53       ` Ingo Molnar
  2004-10-12 12:33     ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12  9:42 UTC (permalink / raw)
  To: linux-kernel
  Cc: Daniel Walker, K.R. Foley, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Wen-chien Jesse Sung, Mark_H_Johnson


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

> i've uploaded -T6:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T6
> 
> this should fix the UP build issues reported by many. -T6 also brings
> back the ->break_lock framework and converts a few more locks to raw.
> 
> SMP is still expected to be flaky due to the zombie-task problem(s).
> But UP is not out of the 'extremely experimental' status either.

one more warning wrt. PREEMPT_REALTIME: if this option is enabled then
it is not safe to make interrupts non-threaded via
/proc/irq/*/*/threaded. If you need to turn an interrupt into a
high-prio event then its irq thread should be set to RT priority via
'chrt'. (-T7 will turn off /proc/irq/*/*/threaded altogether, to make
sure it's not set accidentally.)

	Ingo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T6
  2004-10-12  9:42     ` Ingo Molnar
@ 2004-10-12  9:53       ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12  9:53 UTC (permalink / raw)
  To: linux-kernel
  Cc: Daniel Walker, K.R. Foley, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Wen-chien Jesse Sung, Mark_H_Johnson


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

> one more warning wrt. PREEMPT_REALTIME: if this option is enabled then
> it is not safe to make interrupts non-threaded via
> /proc/irq/*/*/threaded. If you need to turn an interrupt into a
> high-prio event then its irq thread should be set to RT priority via
> 'chrt'. (-T7 will turn off /proc/irq/*/*/threaded altogether, to make
> sure it's not set accidentally.)

in fact i've re-uploaded a new version of the -T6 patch to disable
direct interrupts under PREEMPT_REALTIME kernels. The only exception is
IRQ1 on PCs (the keyboard irq), which can be useful for debugging
purposes (SysRq, etc.). I turned the keyboard related locks into raw
spinlocks to make this safe.

	Ingo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T6
  2004-10-12  9:31     ` Wen-chien Jesse Sung
@ 2004-10-12 10:35       ` Ingo Molnar
  2004-10-12 11:32         ` Wen-chien Jesse Sung
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12 10:35 UTC (permalink / raw)
  To: Wen-chien Jesse Sung
  Cc: linux-kernel, Daniel Walker, K.R. Foley, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson


* Wen-chien Jesse Sung <jesse@cola.voip.idv.tw> wrote:

> > this should fix the UP build issues reported by many. -T6 also brings
> > back the ->break_lock framework and converts a few more locks to raw.
> 
> UP build is still failed: 
>  arch/i386/kernel/vm86.c:707: error: `__RAW_SPIN_LOCK_UNLOCKED'
> undeclared here (not in a function)

ok, fixed this one too and re-uploaded -T6 - please check whether it
builds for you now.

	Ingo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-12  6:12       ` Ingo Molnar
@ 2004-10-12 10:45         ` Florian Schmidt
  0 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-12 10:45 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Mark_H_Johnson, Andrew Morton, Daniel Walker, K.R. Foley,
	linux-kernel, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela

On Tue, 12 Oct 2004 08:12:01 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> > same errors.. Both with the preemptible real time thingy and without..
> 
> could you send me your .config? Had to do some wacky include file magic
> to be able to use semaphores in spinlocks, but could easily have missed
> some .config variations.

Sure,

you released T6 already, but here's my T5 config anyways (this one w/o CONFIG_PREEMPT_REALTIME, same result with it enabled though) Gonna try building T6 now:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-rc4-mm1-VP-T5
# Tue Oct 12 01:13:25 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION="-LT"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_PREEMPT_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

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

#
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=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_X86_USE_3DNOW=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
# CONFIG_PREEMPT_REALTIME is not set
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
# 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 is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

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

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

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

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD 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=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_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 is not set
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 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=y
# 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

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

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

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

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_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_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_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

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT 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_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM 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_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

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

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set

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

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

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

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_MEMORY is not set
# CONFIG_SND_DEBUG_DETECT 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

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

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY 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_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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=m
CONFIG_RXRPC=m

#
# 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=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
CONFIG_DEBUG_PREEMPT=y
# CONFIG_DEBUG_INFO is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set

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

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-12  6:02     ` Ingo Molnar
@ 2004-10-12 11:08       ` K.R. Foley
  2004-10-12 11:43         ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-12 11:08 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Mark_H_Johnson, Andrew Morton, Daniel Walker, linux-kernel,
	Florian Schmidt, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>>i've uploaded -T5 which should fix most of the build issues:
>>>
>>
>>This fixed the build problems for me (SMP). I did get one unresolved
>>symbol when building this with REALTIME enabled.
> 
> 
> (which symbol was this?)

WARNING: 
/lib/modules/2.6.9-rc4-mm1-VP-T5-RT/kernel/drivers/net/ppp_synctty.ko 
needs unknown symbol _mutex_trylock_bh

I shouldn't have even had ppp enabled and then wouldn't have noticed it, 
but...
> 
> 
>>[...] Also got error messages scrolling up the screen when I tried to
>>boot it (looked very much like Mark's problem with T4) and it never
>>made it. :( If I had to guess, it might be related to APICs? I always
>>have to use "noapic" boot parameter.  Ingo what are you running this
>>on? I don't have the exact error messages, but I'm rebuilding it now
>>to try to get those. Without RT Preemption it seems to be running very
>>nicely.
> 
> 
> dont worry about it not booting on your setup with PREEMPT_REALTIME, as
> long as it boots with !PREEMPT_REALTIME - i only really converted my
> testsystems which are basically IDE + e100/e1000/rtl8139, ext3 and the
> bare minimum that is needed to run Fedora. It might be useful to send me
> a bootlog if you have any easy way to capture it - if not it's not a big
> problem either.
> 
> 	Ingo
> 


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

* Re: [patch] VP-2.6.9-rc4-mm1-T6
  2004-10-12 10:35       ` Ingo Molnar
@ 2004-10-12 11:32         ` Wen-chien Jesse Sung
  0 siblings, 0 replies; 951+ messages in thread
From: Wen-chien Jesse Sung @ 2004-10-12 11:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Daniel Walker, K.R. Foley, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson

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

Ingo Molnar wrote:
> * Wen-chien Jesse Sung <jesse@cola.voip.idv.tw> wrote:
> 
> > > this should fix the UP build issues reported by many. -T6 also brings
> > > back the ->break_lock framework and converts a few more locks to raw.
> > 
> > UP build is still failed: 
> >  arch/i386/kernel/vm86.c:707: error: `__RAW_SPIN_LOCK_UNLOCKED'
> > undeclared here (not in a function)
> 
> ok, fixed this one too and re-uploaded -T6 - please check whether it
> builds for you now.

Yes, it works now! Thanks a lot! :)

-- 
Best Regards,
Wen-chien Jesse Sung

[-- Attachment #2: 這是數位加簽的郵件 --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

* Re: [patch] VP-2.6.9-rc4-mm1-T5
  2004-10-12 11:08       ` K.R. Foley
@ 2004-10-12 11:43         ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12 11:43 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Mark_H_Johnson, Andrew Morton, Daniel Walker, linux-kernel,
	Florian Schmidt, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela


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

> >(which symbol was this?)
> 
> WARNING: 
> /lib/modules/2.6.9-rc4-mm1-VP-T5-RT/kernel/drivers/net/ppp_synctty.ko 
> needs unknown symbol _mutex_trylock_bh

thx - fix will be in -T7.

	Ingo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T6
  2004-10-12  9:15   ` [patch] VP-2.6.9-rc4-mm1-T6 Ingo Molnar
  2004-10-12  9:31     ` Wen-chien Jesse Sung
  2004-10-12  9:42     ` Ingo Molnar
@ 2004-10-12 12:33     ` Ingo Molnar
  2004-10-12 13:59       ` VP-2.6.9-rc4-mm1-T7 Rui Nuno Capela
                         ` (2 more replies)
  2 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12 12:33 UTC (permalink / raw)
  To: linux-kernel
  Cc: Daniel Walker, K.R. Foley, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Wen-chien Jesse Sung, Mark_H_Johnson


i've uploaded -T7:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T7

Changes since -T6:

- further stabilization of PREEMPT_REALTIME: fixed the task-reaping
  problem by moving TASK_ZOMBIE out of p->state and thus completely
  separating preemption from the child-exit mechanism. This got rid of 
  the 'Badness in exit.c' warnings on my SMP testbox (and related
  crashes).

- fixed the _mutex_trylock_bh missing symbol problem reported by K.R. 
  Foley and Florian Schmidt.

- turned the sysrq lock into a raw spinlock, to enable direct keyboard
  irqs.

PREEMPT_REALTIME is still experimental, but it's already looking much
better on my testboxes.

to create a -T7 tree from scratch the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T7

	Ingo

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

* VP-2.6.9-rc4-mm1-T7
  2004-10-12 12:33     ` Ingo Molnar
@ 2004-10-12 13:59       ` Rui Nuno Capela
  2004-10-12 14:23         ` VP-2.6.9-rc4-mm1-T7 Ingo Molnar
  2004-10-12 15:12       ` [patch] VP-2.6.9-rc4-mm1-T6 K.R. Foley
  2004-10-12 19:54       ` [patch] VP-2.6.9-rc4-mm1-T8 Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-12 13:59 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Daniel Walker, K.R. Foley, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Wen-chien Jesse Sung,
	mark_h_johnson

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

Ingo Molnar wrote:
>
> i've uploaded -T7:
>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T7
>

OK. 2.6.9-rc4-mm1-T7 builds and runs on my laptop (P4/UP), apparently
fine. I know it's probably too early to complain, but I'm sending a couple
of dmesg's that I took right after init, showing some badness going on.

.config file is aldo attached.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: dmesg-2.6.9-rc4-mm1-T7.0.tar.gz --]
[-- Type: application/x-gzip-compressed, Size: 1951 bytes --]

[-- Attachment #3: config-2.6.9-rc4-mm1-T7.0.gz --]
[-- Type: application/x-gzip-compressed, Size: 8246 bytes --]

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

* Re: VP-2.6.9-rc4-mm1-T7
  2004-10-12 13:59       ` VP-2.6.9-rc4-mm1-T7 Rui Nuno Capela
@ 2004-10-12 14:23         ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12 14:23 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Daniel Walker, K.R. Foley, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Wen-chien Jesse Sung,
	mark_h_johnson


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> OK. 2.6.9-rc4-mm1-T7 builds and runs on my laptop (P4/UP), apparently
> fine. I know it's probably too early to complain, but I'm sending a
> couple of dmesg's that I took right after init, showing some badness
> going on.

does the patch below ontop of T7 fix these messages for you?

	Ingo

--- linux/sound/pci/ali5451/ali5451.c.orig
+++ linux/sound/pci/ali5451/ali5451.c
@@ -261,8 +261,8 @@ struct snd_stru_ali {
 	unsigned short	ac97_ext_id;
 	unsigned short	ac97_ext_status;
 
-	spinlock_t	reg_lock;
-	spinlock_t	voice_alloc;
+	raw_spinlock_t	reg_lock;
+	raw_spinlock_t	voice_alloc;
 
 #ifdef CONFIG_PM
 	ali_image_t *image;
--- linux/fs/fcntl.c.orig
+++ linux/fs/fcntl.c
@@ -541,7 +541,7 @@ int send_sigurg(struct fown_struct *fown
 	return ret;
 }
 
-static rwlock_t fasync_lock = RW_LOCK_UNLOCKED;
+static DECLARE_RAW_RWLOCK(fasync_lock);
 static kmem_cache_t *fasync_cache;
 
 /*

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

* Re: [patch] VP-2.6.9-rc4-mm1-T6
  2004-10-12 12:33     ` Ingo Molnar
  2004-10-12 13:59       ` VP-2.6.9-rc4-mm1-T7 Rui Nuno Capela
@ 2004-10-12 15:12       ` K.R. Foley
  2004-10-12 15:27         ` Ingo Molnar
  2004-10-12 19:54       ` [patch] VP-2.6.9-rc4-mm1-T8 Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-12 15:12 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Daniel Walker, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Wen-chien Jesse Sung, Mark_H_Johnson

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

Ingo Molnar wrote:
> i've uploaded -T7:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T7
> 
OK. This one builds just fine here. Again I tried booting preempt 
realtime. We were going along fine and then all hell broke loose on the 
console. Pressed Ctrl-s to stop the scrolling and it then bit the dust. 
It did manage to get into the logs this time and I am attaching that. 
This is a different SMP system that I use as a workstation at a client site.
Dual 2.6GHz Xeons (with HT)
512MB

kr


[-- Attachment #2: rtpreT7.dump --]
[-- Type: text/plain, Size: 75071 bytes --]

Oct 12 09:52:58 swdev14 syslogd 1.4.1: restart.
Oct 12 09:52:58 swdev14 syslog: syslogd startup succeeded
Oct 12 09:52:59 swdev14 kernel: klogd 1.4.1, log source = /proc/kmsg started.
Oct 12 09:52:59 swdev14 syslog: klogd startup succeeded
Oct 12 09:52:59 swdev14 kernel:  sys_init_module+0x68/0x1ce
Oct 12 09:52:59 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 09:52:59 swdev14 kernel: scheduling while atomic: usb.agent/0x04010000/1298
Oct 12 09:52:59 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:52:59 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:52:59 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:52:59 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:52:59 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0133b8e>] _rw_mutex_read_lock+0x24/0x39
Oct 12 09:52:59 swdev14 kernel:  [<c011f8f1>] profile_hook+0x1d/0x47
Oct 12 09:52:59 swdev14 irqbalance: irqbalance startup succeeded
Oct 12 09:52:59 swdev14 kernel:  [<c011fde3>] profile_tick+0x63/0x65
Oct 12 09:52:59 swdev14 kernel:  [<c0113d03>] smp_apic_timer_interrupt+0x60/0xe4
Oct 12 09:52:59 swdev14 kernel:  [<c0106bb6>] apic_timer_interrupt+0x1a/0x20
Oct 12 09:52:59 swdev14 kernel: EXT3 FS on hda6, internal journal
Oct 12 09:52:59 swdev14 kernel: device-mapper: 4.1.0-ioctl (2003-12-10) initialised: dm@uk.sistina.com
Oct 12 09:52:59 swdev14 kernel: Adding 2048216k swap on /dev/hda5.  Priority:-1 extents:1
Oct 12 09:52:59 swdev14 kernel: scheduling while atomic: rc.sysinit/0x04010001/1561
Oct 12 09:52:59 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:52:59 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:52:59 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:52:59 swdev14 portmap: portmap startup succeeded
Oct 12 09:52:59 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:52:59 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0133b8e>] _rw_mutex_read_lock+0x24/0x39
Oct 12 09:52:59 swdev14 kernel:  [<c011f8f1>] profile_hook+0x1d/0x47
Oct 12 09:52:59 swdev14 kernel:  [<c011fde3>] profile_tick+0x63/0x65
Oct 12 09:52:59 swdev14 kernel:  [<c0113d03>] smp_apic_timer_interrupt+0x60/0xe4
Oct 12 09:52:59 swdev14 kernel:  [<c0106bb6>] apic_timer_interrupt+0x1a/0x20
Oct 12 09:52:59 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 09:52:59 swdev14 kernel:  [<c029a35d>] _spin_unlock_irqrestore+0x10/0x36
Oct 12 09:52:59 swdev14 rpc.statd[2649]: Version 1.0.6 Starting
Oct 12 09:52:59 swdev14 kernel:  [<c0118895>] try_to_wake_up+0x1e8/0x270
Oct 12 09:52:59 swdev14 kernel:  [<c0118940>] wake_up_process+0x23/0x27
Oct 12 09:52:59 swdev14 kernel:  [<c011923d>] sched_migrate_task+0x7e/0x9d
Oct 12 09:52:59 swdev14 nfslock: rpc.statd startup succeeded
Oct 12 09:52:59 swdev14 kernel:  [<c01192e6>] sched_exec+0x8a/0xd4
Oct 12 09:52:59 swdev14 kernel:  [<c01192fb>] sched_exec+0x9f/0xd4
Oct 12 09:52:59 swdev14 kernel:  [<c0166f3b>] do_execve+0x3e/0x249
Oct 12 09:52:59 swdev14 kernel:  [<c0168881>] getname+0x91/0xbc
Oct 12 09:52:59 swdev14 kernel:  [<c0104d5d>] sys_execve+0x47/0x9a
Oct 12 09:52:59 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 09:52:59 swdev14 kernel: scheduling while atomic: grep/0x04010000/1569
Oct 12 09:52:59 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:52:59 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:52:59 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:52:59 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:00 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:00 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:00 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:00 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:00 swdev14 kernel:  [<c0133b8e>] _rw_mutex_read_lock+0x24/0x39
Oct 12 09:53:00 swdev14 kernel:  [<c011f8f1>] profile_hook+0x1d/0x47
Oct 12 09:53:00 swdev14 rpcidmapd: rpc.idmapd startup succeeded
Oct 12 09:53:00 swdev14 kernel:  [<c011fde3>] profile_tick+0x63/0x65
Oct 12 09:53:00 swdev14 kernel:  [<c0113d03>] smp_apic_timer_interrupt+0x60/0xe4
Oct 12 09:53:00 swdev14 kernel:  [<c0106bb6>] apic_timer_interrupt+0x1a/0x20
Oct 12 09:53:00 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 09:53:00 swdev14 kernel:  [<c02996c7>] cond_resched+0x14/0x83
Oct 12 09:53:00 swdev14 kernel:  [<c0133822>] _mutex_lock+0x19/0x3f
Oct 12 09:53:00 swdev14 kernel:  [<c014d347>] handle_mm_fault+0x54/0x18a
Oct 12 09:53:00 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:00 swdev14 random: Initializing random number generator:  succeeded
Oct 12 09:53:00 swdev14 kernel:  [<c0116fa8>] do_page_fault+0x20b/0x662
Oct 12 09:53:00 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:00 swdev14 kernel:  [<c02996c1>] cond_resched+0xe/0x83
Oct 12 09:53:00 swdev14 kernel:  [<c014e08f>] sys_brk+0x28/0x10f
Oct 12 09:53:00 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:00 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:00 swdev14 kernel:  [<c014e08f>] sys_brk+0x28/0x10f
Oct 12 09:53:00 swdev14 kernel:  [<c014fd3a>] sys_munmap+0x59/0x7b
Oct 12 09:53:00 swdev14 rc: Starting pcmcia:  succeeded
Oct 12 09:53:00 swdev14 kernel:  [<c0116d9d>] do_page_fault+0x0/0x662
Oct 12 09:53:00 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 09:53:00 swdev14 kernel: scheduling while atomic: cat/0x04010000/1752
Oct 12 09:53:00 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 09:53:00 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:00 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:00 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:00 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:00 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:00 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:00 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:00 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:00 swdev14 kernel:  [<c0133b8e>] _rw_mutex_read_lock+0x24/0x39
Oct 12 09:53:00 swdev14 kernel:  [<c011f8f1>] profile_hook+0x1d/0x47
Oct 12 09:53:00 swdev14 kernel:  [<c011fde3>] profile_tick+0x63/0x65
Oct 12 09:53:00 swdev14 kernel:  [<c0113d03>] smp_apic_timer_interrupt+0x60/0xe4
Oct 12 09:53:00 swdev14 kernel:  [<c0106bb6>] apic_timer_interrupt+0x1a/0x20
Oct 12 09:53:00 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 09:53:00 swdev14 kernel:  [<c015b55f>] vfs_read+0x0/0x134
Oct 12 09:53:00 swdev14 kernel:  [<c015b8ed>] sys_read+0x50/0x7a
Oct 12 09:53:00 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 09:53:00 swdev14 kernel: schedulingro0x603>] er_i> [ic_<4c0134_pre<4> pr<c01tr88>] checkpt1fd9>
Oct 12 09:53:00 swdev14 kernel:  [<c0299] 49/0x1pr19136>] pt_ [<mc4> _spore+0xb[<c7
Oct 12 09:53:00 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:00 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:00 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:00 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:00 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:00 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:00 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:00 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:00 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:00 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:00 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:00 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:00 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:00 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:00 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:00 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:00 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:01 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:01 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:01 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:01 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:01 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:01 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:01 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:01 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:01 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:01 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:01 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:01 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:01 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:01 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:01 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:01 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:01 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+0x4d6/0x108d
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel: ]97a>]6>0dae+0>+0c0+0xc0_wxumi5e+] v/t[x010xdux0>0c0>on> [o0c0/41cre46/nd_x8he> _mu+pd/ro03>e [i
Oct 12 09:53:01 swdev14 kernel:  [<]9/0r1936pt> [m4>_sre+[07
Oct 12 09:53:01 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:01 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:01 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:01 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:01 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:01 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:01 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:01 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:01 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:01 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:01 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:01 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:01 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:01 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:01 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:01 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:01 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:01 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:01 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:01 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:01 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:01 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:01 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:01 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:01 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:01 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:01 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:01 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:01 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:01 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:01 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:01 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:01 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:01 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+0x4d6/0x108d
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 last message repeated 2 times
Oct 12 09:53:01 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:01 swdev14 kernel:  [<c02764e0>] inet_sendmsg+0x50/0x5b
Oct 12 09:53:01 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:01 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:01 swdev14 kernel:  [<c015b73d>] do_sync_write+0xaa/0xd6
Oct 12 09:53:01 swdev14 kernel:  [<c01333e3>] autoremove_wake_function+0x0/0x57
Oct 12 09:53:01 swdev14 kernel:  [<c01a9bd8>] dummy_file_permiansm026chec> [_skb<4>x3c
Oct 12 09:53:01 swdev14 kernel: 3>] tc4a8eg+0[<nt+54sg+04aft_
Oct 12 09:53:01 swdev14 kernel:   su7
Oct 12 09:53:01 swdev14 kernel: ] x97
Oct 12 09:53:01 swdev14 kernel:  ref>] c01348_pr
Oct 12 09:53:01 swdev14 kernel:   pr<c01tra88>] check_pt1f9d9>7
Oct 12 09:53:01 swdev14 kernel:  [<c02992] 496/0x1pr19136>]pt_ [<mc4> _spore+0x[<7
Oct 12 09:53:01 swdev14 kernel:  [<c01136d4>] mcount+0x1>] ] dunc[<cwn_<c013.lo338ck_ [omec514d>c0unl02404f3>] qest[<c0nt+qdisc56/0>] de+outd1e
Oct 12 09:53:01 swdev14 kernel: ] 0x239>[<cout>] suntsub_pree+0xpin_unlox34 subt+0xpree2/0a2c7ck+134eem29a2clocc013nt+265end
Oct 12 09:53:01 swdev14 kernel: <4 tc [unttcp_v4_s+0x5fmit6>x3c>] +0x[<c025sen8d
Oct 12 09:53:01 swdev14 kernel: ] a65>] t+0x134ampt0134emp34apt_caio_x13>]x50a>e+0d4>0x1d>] e+01a9bile_cricrit<4> [<mco[<cwri10617_pa3>scle 2/27is /0x2674> [ondc0pre
Oct 12 09:53:01 swdev14 kernel: <4] c [<ck_
Oct 12 09:53:01 swdev14 kernel: <029<4con<4> [<c_rw+0c01/fde
Oct 12 09:53:01 swdev14 kernel: < smnter4
Oct 12 09:53:01 swdev14 kernel: <er_in/0xe_con9/fb2>]12cheing1e1d6edce+08>] _ti106fck+] 0xn+0x8a/[<ctimi9
Oct 12 09:53:01 swdev14 kernel: <_pr0x_mcount+0x11
Oct 12 09:53:01 swdev14 kernel: <] _sqrec0298491>] __d+0+0<c04def0x0/029+0x01ock.46
Oct 12 09:53:01 swdev14 kernel: mutexve+ boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:01 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:01 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:01 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:01 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:01 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:01 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:01 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:01 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:01 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:01 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:01 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:01 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:01 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:01 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:01 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:01 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:02 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:02 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:02 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:02 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:02 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:02 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:02 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:02 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:02 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:02 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:02 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:02 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:02 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:02 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:02 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+0x4d6/0x108d
Oct 12 09:53:02 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:02 swdev14 last message repeated 2 times
Oct 12 09:53:02 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:02 swdev14 kernel:  [<c02764e0>] inet_sendmsg+0x50/0x5b
Oct 12 09:53:02 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:02 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:02 swdev14 kernel:  [<c015b73d>] do_sync_write+0xaa/0xd6
Oct 12 09:53:02 swdev14 kernel:  [<c01333e3>] autoremove_wake_function+0x0/0x57
Oct 12 09:53:02 swdev14 kernel:  [<c01a9bd8>] dummy_file_permission+0x8/0xc
Oct 12 09:53:02 swdev14 kernel:  [<c015b80b>] vfs_write+0xa2/0x134
Oct 12 09:53:02 swdev14 kernel:  [<c015b869>] vfs_write+0x100/0x134
Oct 12 09:53:02 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:02 swdev14 kernel:  [<c015b967>] sys_write+0x50/0x7a
Oct 12 09:53:02 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 09:53:02 swdev14 kernel: scheduling while atomic: mount/0x04010002/2732
Oct 12 09:53:02 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 09:53:02 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:02 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:02 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:02 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:02 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:02 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:02 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:02 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:02 swdev14 kernel:  [<c0133b8e>] _rw_mutex_read_lock+0x24/0x39
Oct 12 09:53:02 swdev14 kernel:  [<c011f8f1>] profile_hook+0x1d/0x47
Oct 12 09:53:02 swdev14 kernel:  [<c011fde3>] profile_tick+0x63/0x65
Oct 12 09:53:02 swdev14 kernel:  [<c0113d03>] smp_apic_timer_interrupt+0x60/0xe4
Oct 12 09:53:02 swdev14 kernel:  [<c0106bb6>] apic_timer_interrupt+0x1a/0x20
Oct 12 09:53:02 swdev14 kernel:  [<c011f0b2>] release_console_sem+0x59/0xcf
Oct 12 09:53:02 swdev14 kernel:  [<c011efb2>] vprintk+0x128/0x16f
Oct 12 09:53:02 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:02 swdev14 kernel:  [<c011ee86>] printk+0x1d/0x21
Oct 12 09:53:02 swdev14 kernel:  [<c0106edc>] show_trace+0x4e/0x8d
Oct 12 09:53:02 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:02 swdev14 kernel:  [<c0106fd9>] dump_stack+0x23/0x27
Oct 12 09:53:02 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:02 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:02 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:02 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:02 swdev14 kernel:  [<c01347
Oct 12 09:53:02 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:02 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:02 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:02 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:02 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:02 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:02 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:02 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:02 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:02 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:02 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:02 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:02 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:02 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:02 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:02 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:02 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:02 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:02 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:02 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:02 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:02 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:02 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:02 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:02 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:02 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:02 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:02 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:02 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:02 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:02 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:02 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:02 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:02 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:02 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:02 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:02 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:02 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:02 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:02 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+0x4d6/0x108d
Oct 12 09:53:02 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:02 swdev14 last message repeated 2 times
Oct 12 09:53:02 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:02 swdev14 kernel:  [<c02764e0>] inet_sendmsg+0x50/0x5b
Oct 12 09:53:02 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:02 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:02 swdev14 kernel:  [<c015b73d>] do_sync_write+0xaa/0xd6
Oct 12 09:53:02 swdev14 kernel:  [<c01333e3>] autoremove_wake_function+0x0/0x57
Oct 12 09:53:03 swdev14 kernel:  [<c01a9bd8>] dummy_file_permission+0x8/0xc
Oct 12 09:53:03 swdev14 kernel:  [<c015b80b>] vfs_write+0xa2/0x134
Oct 12 09:53:03 swdev14 kernel:  [<c015b869>] vfs_write+0x100/0x134
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c015b967>] sys_write+0x50/0x7a
Oct 12 09:53:03 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 09:53:03 swdev14 kernel: scheduling while atomic: mount/0x04010002/2732
Oct 12 09:53:03 swdev14 kernel: c0c>o4> [ou0c0/41c0r4d_xche> w_mu+pdo03>er i< ><4 c0t88>] cp1fd97
Oct 12 09:53:03 swdev14 kernel:  [<]49/0r136>p [m<4_sore+[7
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:03 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:03 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:03 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:03 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:03 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:03 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:03 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:03 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:03 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:03 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:03 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:03 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:03 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:03 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:03 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:03 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:03 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:03 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:03 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:03 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:03 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:03 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:03 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:03 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:03 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:03 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:03 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:03 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:03 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:03 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c0254sg4at<4 97
Oct 12 09:53:03 swdev14 kernel: >]97a6>xde+0>0c0xc_wx0mmi5e  p<c01tra88>] checkpt_x
Oct 12 09:53:03 swdev14 kernel:  [<] s96/0x1pr19936>]pt_> [<mc<4> _spore+0x[<07
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:03 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:03 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:03 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:03 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:03 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:03 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:03 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:03 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:03 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:03 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:03 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:03 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:03 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:03 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:03 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:03 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:03 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:03 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:03 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:03 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:03 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:03 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:03 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:03 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:03 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:03 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:03 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:03 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:03 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:03 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+0x4d6/0x108d
Oct 12 09:53:03 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:03 swdev14 last message repeated 2 times
Oct 12 09:53:03 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:03 swdev14 kernel:  [<c02764e0>] inet_sendmsg+0x50/0x5b
Oct 12 09:53:03 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c015b73d>] do_sync_write+0xaa/0xd6
Oct 12 09:53:03 swdev14 kernel:  [<c01333e3>] autoremove_wake_function+0x0/0x57
Oct 12 09:53:03 swdev14 kernel:  [<c01a9bd8>] dummy_file_permission+0x8/0xc
Oct 12 09:53:03 swdev14 kernel:  [<c015b80b>] vfs_write+0xa2/0x134
Oct 12 09:53:03 swdev14 kernel:  [<c015b869>] vfs_write+0x100/0x134
Oct 12 09:53:03 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:03 swdev14 kernel:  [<c015b967>] sys_write+0x50/0x7a
Oct 12 09:53:03 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 09:53:03 swdev14 kernel: scheduling while atomic: mount/0x04010002/2732
Oct 12 09:53:04 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 09:53:04 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:04 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:04 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:04 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:04 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:04 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:04 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:04 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:04 swdev14 kernel:  [<c0133b8e>] _rw_mutex_read_lock+0x24/0x39
Oct 12 09:53:04 swdev14 kernel:  [<c011f8f1>] profile_hook+0x1d/0x47
Oct 12 09:53:04 swdev14 kernel:  [ro0x603>] er_> [<ic_
Oct 12 09:53:04 swdev14 kernel:  recf>] <c013488_pr<4>  pr<c010tra888>] check_pt_x1f9d9>
Oct 12 09:53:04 swdev14 kernel:  [<c029926] s496/0xr19136>] pt [<mco<4> _spre+0xb[<7
Oct 12 09:53:04 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x1] dunc[<cwn_<c013.lo338ck_> [omec514dc0unl02404f3>] qest[<c0nt56/0>] de+0xecfa>outdst_oux2f4/0x18148
Oct 12 09:53:04 swdev14 kernel: <4 nf_11e
Oct 12 09:53:04 swdev14 kernel: 4>] 0x239>[<out>] suuntsub_pree+0xpin_unlox34 subt+0pre2/0a2c7ck+134eemp29a2clocc013nt+265end
Oct 12 09:53:04 swdev14 kernel: <4 tcp [unttcp_v4_s+0x5fmit>x3c>] +0x<c025sen8d
Oct 12 09:53:04 swdev14 kernel: ] a65>] t+0x34mpt13emp34apt_ciox1]x50>e+040x13d>] e+0>] aue_fritcri<4> [<mc<cwri1061_pa3>scle 2/27is /0267> ond0pre
Oct 12 09:53:04 swdev14 kernel: <] c [<ck_
Oct 12 09:53:04 swdev14 kernel: <4con<4> [<c_r0c0/fde
Oct 12 09:53:04 swdev14 kernel: < smter4
Oct 12 09:53:04 swdev14 kernel: <er_in/0_con9/efb2>]12cheing1e1d6edce+08>] _ti106fck] 0xb+0x8a/[<ctimi9
Oct 12 09:53:04 swdev14 kernel: _pr0x4__mcount+0x1
Oct 12 09:53:04 swdev14 kernel: <] _sqre0298491>] __+0x+0<c04de+0x0/029+0x01ck.46
Oct 12 09:53:04 swdev14 kernel: mutexve] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:04 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:04 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:04 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:04 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:04 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:04 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:04 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:04 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:04 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:04 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:04 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:04 swdev14 kernel:  [<cg[<nt4sgat<4 s7
Oct 12 09:53:04 swdev14 kernel: <>97a>6>]0xdte+0>0c00xce_wx0mi15e /0n[<x01xd0>+0c4>o> [ouc6/481cr46d_xhed>_mu+pd/ro03>e i< c>]c01_p
Oct 12 09:53:04 swdev14 kernel: <4 <c0tr81fd9
Oct 12 09:53:04 swdev14 kernel:  [<]9/0r1936pt [m4>_re+[<7
Oct 12 09:53:04 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:04 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:04 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:04 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:04 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:04 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:04 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:04 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:04 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:04 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:04 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:04 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:04 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:04 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:04 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:04 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:04 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:04 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:04 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:04 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:04 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:04 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:04 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:04 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:04 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:04 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:04 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:04 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:04 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:04 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:04 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:04 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:04 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:04 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:04 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:04 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:04 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:04 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:04 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:04 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+at<4 7
Oct 12 09:53:04 swdev14 kernel: <>x97a>6>xde+0>0c0xc_wx0ummio15e v/t[<x00xdx0>cc04>o4> [ou0c02/41cr4d_x8che>w_mu+pd/o> [<ic_
Oct 12 09:53:04 swdev14 kernel:  rec>]c01348_pre<4>  pr<c01tra88>] checkptx1f9d9>7
Oct 12 09:53:04 swdev14 kernel:  [<c02992] s49/0x10r191936>]pt [mc4>_re+[<07
Oct 12 09:53:04 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:04 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:04 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:04 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:04 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:04 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:04 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:04 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:04 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:04 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:04 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:04 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:04 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:04 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:04 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:04 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:04 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:04 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:04 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:04 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:04 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:04 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:04 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:04 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:04 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:05 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:05 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:05 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:05 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:05 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:05 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:05 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:05 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:05 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:05 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:05 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:05 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:05 swdev14 kernel:  [<c0254a65>] tcp_sgat<4> s97
Oct 12 09:53:05 swdev14 kernel: <>]97a>]6>xde+0> 0c00xc0mi5e] v/t[x010xd0>0c0>o> [o0c02/4x1cr46d_xched> _mut+pd/o03>er ic
Oct 12 09:53:05 swdev14 kernel: < f>c013_p<4 <c0t88>] cpx1d9
Oct 12 09:53:05 swdev14 kernel:  [<c]9/0136>p [mc4_sre+[7
Oct 12 09:53:05 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:05 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:05 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:05 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:05 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:05 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:05 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c5<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:05 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:05 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:05 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:05 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:05 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:05 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:05 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:05 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:05 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:05 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:05 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:05 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:05 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:05 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+0x4d6/0x108d
Oct 12 09:53:05 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 last message repeated 2 times
Oct 12 09:53:05 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:05 swdev14 kernel:  [<c02764e0>] inet_sendmsg+0x50/0x5b
Oct 12 09:53:05 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:05 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:05 swdev14 kernel:  [<c015b73d>] do_sync_write+0xaa/0xd6
Oct 12 09:53:05 swdev14 kernel:  [<c01333e3>] autoremove_wake_function+0x0/0x57
Oct 12 09:53:05 swdev14 kernel:  [<c01a9bd8>] dummy_file_permission+0x8/0xc
Oct 12 09:53:05 swdev14 kernel:  [<c015b80b>] vfs_write+0xa2/0x134
Oct 12 09:53:05 swdev14 kernel:  [<c015b869>] vfs_write+0x100/0x134
Oct 12 09:53:05 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:05 swdev14 kernel:  [<c015b967>] sys_write+0x50/0x7a
Oct 12 09:53:05 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 09:53:05 swdev14 kernel: scheduling while atomic: mount/0x04010002/2732
Oct 12 09:53:05 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 09:53:05 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:05 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:05 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:05 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:05 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:05 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:05 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:05 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:05 swdev14 kernel:  [<c0133b8e>] _rw_mutex_read_lock+0x24/0x39
Oct 12 09:53:05 swdev14 kernel:  [<c011f8f1>] profile_hook+0x1d/0x47
Oct 12 09:53:05 swdev14 kernel:  [<c011fde3>] profile_tick+0x63/0x65
Oct 12 09:53:05 swdev14 kernel:  [<c0113d03>] smp_apic_timer_interrupt+0x60/0xe4
Oct 12 09:53:05 swdev14 kernel:  [<c0106bb6>] apic_timer_interrupt+0x1a/0x20
Oct 12 09:53:05 swdev14 kernel:  [<c011f0b2>] release_console_sem+0x59/0xcf
Oct 12 09:53:05 swdev14 kernel:  [<c011efb2>] vprintk+0x128/0x16f
Oct 12 09:53:05 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:05 swdev14 kernel:  [<c011ee86>] printk+0x1d/0x21
Oct 12 09:53:05 swdev14 kernel:  [<c0106edc>] show_trace+0x4e/0x8d
Oct 12 09:53:05 swdev14 kernel: 134g+0 [<k+<c0<4__c01348_p91134ng[<21>] rqre6
Oct 12 09:53:05 swdev14 kernel: x85/001> [<cdo> [<cef1c
Oct 12 09:53:05 swdev14 kernel: >] <4.te0x5/001save> [rt_xeb _1
Oct 12 09:53:05 swdev14 kernel: ck+0xb/[<c0x132<c/0x15171e6
Oct 12 09:53:05 swdev14 kernel:  [<dd>it+0> [_output+0xd5/6
Oct 12 09:53:05 swdev14 kernel: </06d402pu023bf_s<c02ut> [<_q9e<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:05 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:05 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:05 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:05 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:05 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:05 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:05 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:05 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:05 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:05 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:05 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:05 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:05 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:05 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+0x4d6/0x108d
Oct 12 09:53:05 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:05 swdev14 last message repeated 2 times
Oct 12 09:53:05 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:05 swdev14 kernel:  [<c02764e0>] inet_sendmsg+0x50/0x5b
Oct 12 09:53:05 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:05 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:05 swdev14 kernel:  [<c015b73d>] do_sync_write+0xaa/0xd6
Oct 12 09:53:05 swdev14 kernel:  [<c01333e3>] autoremove_wake_function+0x0/0x57
Oct 12 09:53:05 swdev14 kernel:  [<c01a9bd8>] dummy_file_permission+0x8/0xc
Oct 12 09:53:05 swdev14 kernel:  [<c015b80b>] vfs_write+0xa2/0x134
Oct 12 09:53:05 swdev14 kernel:  [<c015b869>] vfs_write+0x100/0x134
Oct 12 09:53:05 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:05 swdev14 kernel:  [<c015b967>] sys_write+0x50/0x7a
Oct 12 09:53:05 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 09:53:05 swdev14 kernel: scheduling while atomic: mount/0x04010002/2732
Oct 12 09:53:05 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 09:53:05 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:05 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:06 swdev14 kernel:  [<c0134936>] touch_preempt_ti0x9 _spina/0] chimi
Oct 12 09:53:06 swdev14 kernel:  _s34
Oct 12 09:53:06 swdev14 kernel: <4d><c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:06 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:06 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:06 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:06 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:06 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:06 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:06 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:06 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:06 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+0x4d6/0x108d
Oct 12 09:53:06 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:06 swdev14 last message repeated 2 times
Oct 12 09:53:06 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:06 swdev14 kernel:  [<c02764e0>] inet_sendmsg+0x50/0x5b
Oct 12 09:53:06 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:06 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:06 swdev14 kernel:  [<c015b73d>] do_sync_write+0xaa/0xd6
Oct 12 09:53:06 swdev14 kernel:  [<c01333e3>] autoremove_wake_function+0x0/0x57
Oct 12 09:53:06 swdev14 kernel:  [<c01a9bd8>] dummy_file_permission+0x8/0xc
Oct 12 09:53:06 swdev14 kernel:  [<c015b80b>] vfs_write+0xa2/0x134
Oct 12 09:53:06 swdev14 kernel:  [<c015b869>] vfs_write+0x100/0x134
Oct 12 09:53:06 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:06 swdev14 kernel:  [<c015b967>] sys_write+0x50/0x7a
Oct 12 09:53:06 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 09:53:06 swdev14 kernel: scheduling while atomic: mount/0x04010002/2732
Oct 12 09:53:06 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 09:53:06 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:06 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:06 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:06 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:06 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:06 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:06 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:06 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:06 swdev14 kernel:  [<c0133b8e>] _rw_mutex_read_lock+0x24/0x39
Oct 12 09:53:06 swdev14 kernel:  [<c011f8f1>] profile_hook+0x1d/0x47
Oct 12 09:53:06 swdev14 kernel:  [<c011fde3>] profile_tick+0x63/0x65
Oct 12 09:53:06 swdev14 kernel:  [<c0113d03>] smp_apic_timer_interrupt+0x60/0xe4
Oct 12 09:53:06 swdev14 kernel:  [<c0106bb6>] apic_timer_interrupt+0x1a/0x20
Oct 12 09:53:06 swdev14 kernel:  [<c011f0b2>] release_console_sem+0x59/0xcf
Oct 12 09:53:06 swdev14 kernel:  [<c011efb2>] vprintk+0x128/0x16f
Oct 12 09:53:06 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:06 swdev14 kernel:  [<c011ee86>] printk+0x1d/0x21
Oct 12 09:53:06 swdev14 kernel:  [<c0106edc>] show_trace+0x4e/0x8d
Oct 12 09:53:06 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:06 swdev14 kernel:  [<c0106fd9>] dump_stack+0x23/0x27
Oct 12 09:53:06 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:06 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:06 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:06 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:06 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:06 swdev14 kernel:  [<c029a358>] _spin_unlock_irqrestore+0xb/0x36
Oct 12 09:53:06 swdev14 kernel:  [<c0298491>] __down+0x85/0x107
Oct 12 09:53:06 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:06 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:06 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:06 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:06 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:06 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:06 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:06 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:06 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:06 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:06 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:06 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:06 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:06 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:06 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:06 swdev14 kernel:  [<c01136d4>] mco[<c_obfow+while atfti<c02 i83
Oct 12 09:53:06 swdev14 kernel: t+0 schedule+0xxbe<4>t+0>]
Oct 12 09:53:06 swdev14 kernel:  cond_resed+out<c0ti[<cpreem2/0> co26/1>]
Oct 12 09:53:06 swdev14 kernel: pt<c0134<cing+0x191/0x1f9 _spin_unlock+0x1a/0x34
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c0134936>] [<c0134af1>] touch_preempt_timing+0x46/0x4a sub_preempt_count+0x82/0x97
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c02996d9>] [<c0134af1>] cond_resched+0x26/0x83 sub_preempt_count+0x82/0x97
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c029a2c7>] [<c0299716>] _spin_unlock+0x1a/0x34 cond_resched+0x63/0x83
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c0134888>] [<c0133b8e>] check_preempt_timing+0x191/0x1f9 _rw_mutex_read_lock+0x24/0x39
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c029a2c7>] [<c011f8f1>] _spin_unlock+0x1a/0x34 profile_hook+0x1d/0x47
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c013414d>] [<c011fde3>] __mcount+0x1d/0x21 profile_tick+0x63/0x65
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c0265d8c>] [<c0113d03>] tcp_v4_send_check+0xe/0xe2 smp_apic_timer_interrupt+0x60/0xe4
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c025fbf1>] [<c0106bb6>] tcp_transmit_skb+0x432/0x852 apic_timer_interrupt+0x1a/0x20
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c01136d4>] [<c029007b>] mcount+0x14/0x18 packet_sendmsg+0x210/0x280
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c0265d8c>] [<c0299fdb>] tcp_v4_send_check+0xe/0xe2 _spin_lock+0x56/0x78
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c025fc9d>] [<c02405a7>] tcp_transmit_skb+0x4de/0x852 dev_watchdog+0x0/0xb7
Oct 12 09:53:06 swdev14 kernel: 
Oct 12 09:53:06 swdev14 kernel:  [<c01b2056>] [<c02405c3>] memcpy+x2eb [3c59x]
Oct 12 09:53:06 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:06 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:06 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:06 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:06 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:06 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:06 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:06 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:06 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:06 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:06 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:06 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:06 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:06 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:06 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:06 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:06 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:06 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:06 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:06 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:06 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:06 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:06 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:07 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:07 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:07 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:07 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:07 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:07 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:07 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:07 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:07 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:07 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+0x4d6/0x108d
Oct 12 09:53:07 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:07 swdev14 last message repeated 2 times
Oct 12 09:53:07 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:07 swdev14 kernel:  [<c02764e0>] inet_sendmsg+0x50/0x5b
Oct 12 09:53:07 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:07 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:07 swdev14 kernel:  [<c015b73d>] do_sync_write+0xaa/0xd6
Oct 12 09:53:07 swdev14 kernel:  [<c01333e3>] autoremove_wake_function+0x0/0x57
Oct 12 09:53:07 swdev14 kernel:  [<c01a9bd8>] dummy_file_permission+0x8/0xc
Oct 12 09:53:07 swdev14 kernel:  [<c015b80b>] vfs_write+0xa2/0x134
Oct 12 09:53:07 swdev14 kernel:  [<c015b869>] vfs_write+0x100/0x134
Oct 12 09:53:07 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:07 swdev14 kernel:  [<c015b967>] sys_write+0x50/0x7a
Oct 12 09:53:07 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 09:53:07 swdev14 kernel: scheduling while atomic: mount/0x04010002/2732
Oct 12 09:53:07 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 09:53:07 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:07 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:07 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:07 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:07 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:07 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:07 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:07 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:07 swdev14 kernel:  [<c0133b8e>] _rw_mutex_read_lock+0x24/0x39
Oct 12 09:53:07 swdev14 kernel:  [<c011f8f1>] profile_hook+0x1d/0x47
Oct 12 09:53:07 swdev14 kernel:  [<c011fde3>] profile_tick+0x63/0x65
Oct 12 09:53:07 swdev14 kernel:  [<c0113d03>] smp_apic_timer_interrupt+0x60/0xe4
Oct 12 09:53:07 swdev14 kernel:  [<c0106bb6>] apic_timer_interrupt+0x1a/0x20
Oct 12 09:53:07 swdev14 kernel:  [<c011f0b2>] release_console_sem+0x59/0xcf
Oct 12 09:53:07 swdev14 kernel:  [<c011efb2>] vprintk+0x128/0x16f
Oct 12 09:53:07 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:07 swdev14 kernel:  [<c011ee86>] printk+0x1d/0x21
Oct 12 09:53:07 swdev14 kernel:  [<c0106edc>] show_trace+0x4e/0x8d
Oct 12 09:53:07 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:07 swdev14 kernel:  [<c0106fd9>] dump_stack+0x23/0x27
Oct 12 09:53:07 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:07 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:07 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:07 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:07 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:07 swdev14 kernel:  [<c029a358>] _spin_unlock_irqrestore+0xb/0x36
Oct 12 09:53:07 swdev14 kernel:  [<c0298491>] __down+0x85/0x107
Oct 12 09:53:07 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:07 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:07 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:07 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:07 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:07 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:07 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:07 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:07 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:07 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:07 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:07 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:07 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:07 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:07 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:07 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:07 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:07 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:07 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:07 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:07 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:07 swdev14 kernel:  [>] de+0xecfa>outpdst_ox2f4/0x18
Oct 12 09:53:07 swdev14 kernel: <148> [<c02_hoe
Oct 12 09:53:07 swdev14 kernel: <4] d539>it+> [t_o [<_pr134afmpt4> [spi
Oct 12 09:53:07 swdev14 kernel: +0x8c01/02c7> [<c0134eck0x<c04
Oct 12 09:53:07 swdev14 kernel: ] 1>] eck+0[<rans/0x14/0026che> [_skb<43c3>] 4a8g+0[<nt54sg+4at_c
Oct 12 09:53:07 swdev14 kernel:   su97
Oct 12 09:53:07 swdev14 kernel: >] x97
Oct 12 09:53:07 swdev14 kernel: <4a>36
Oct 12 09:53:07 swdev14 kernel: >] 0x5da>te+0x12> [0xc01+0xac01e_wakx0/ummyion15e+0] vf[<c0x500100x5dulx0>c+0xc02>on4> [<c0ouc+0c06/488x1c01pree46nd_rex8hed+0> w_mutex+0 prd/0ro0x603>] er_ [<ic_
Oct 12 09:53:07 swdev14 kernel:  rcf>]<c013488_pr
Oct 12 09:53:07 swdev14 kernel:   p<c010tra88>] check_pptx1f9d9>7
Oct 12 09:53:07 swdev14 kernel:  [<c0299267] s49/0xp36>]pt_> [<cmco4> _spiore+0xb[<07
Oct 12 09:53:07 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:07 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:07 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:07 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:07 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:07 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:07 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:07 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:07 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:07 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:07 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:07 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:07 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:07 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:07 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:07 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:07 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:07 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:07 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:07 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:07 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:07 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:07 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:07 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:08 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:08 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:08 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:08 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:08 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:08 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:08 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:08 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:08 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:08 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:08 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:08 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:08 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:08 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:08 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:08 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+0x4d6/0x108d
Oct 12 09:53:08 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:08 swdev14 last message repeated 2 times
Oct 12 09:53:08 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:08 swdev14 kernel:  [<c02764e0>] inet_sendmsg+0x50/0x5b
Oct 12 09:53:08 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:08 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:08 swdev14 kernel:  [<c015b73d>] do_sync_write+0xaa/0xd6
Oct 12 09:53:08 swdev14 kernel:  [<c01333e3>] autoremove_wake_function+0x0/0x57
Oct 12 09:53:08 swdev14 kernel: ummyio15e+0] vf/0xnt[<0x50100x5dux0>c+0c02>on> [<c0ou0c026/48x1c01re46/nd_rex8ched+> _mute+0 pd/0o0x03>] er [ic
Oct 12 09:53:08 swdev14 kernel: <4 rcf>]<c0134_pr
Oct 12 09:53:08 swdev14 kernel:   p<c01tra88>] check_pt_1fd97
Oct 12 09:53:08 swdev14 kernel:  [<c029996/0xpr191936>]pt_> [<mc<4> _spore+0x[<7
Oct 12 09:53:08 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:08 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:08 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:08 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:08 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:08 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:08 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:08 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:08 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:08 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:08 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:08 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:08 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:08 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:08 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:08 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:08 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:08 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:08 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:08 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:08 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:08 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:08 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:08 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:08 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:08 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:08 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:08 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:08 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:08 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:08 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:08 swdev14 kernel:  [<c025fbf1>] tcp_transmit_skb+0x432/0x852
Oct 12 09:53:08 swdev14 kernel:  [<c01136d4>cp_transmit_skb+0x432/0x852
Oct 12 09:53:08 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:08 swdev14 kernel:  [<c0265d8c>] tcp_v4_send_check+0xe/0xe2
Oct 12 09:53:08 swdev14 kernel:  [<c025fc9d>] tcp_transmit_skb+0x4de/0x852
Oct 12 09:53:08 swdev14 kernel:  [<c01b2056>] memcpy+0x12/0x3c
Oct 12 09:53:08 swdev14 kernel:  [<c0260a83>] tcp_write_xmit+0x149/0x2c0
Oct 12 09:53:08 swdev14 kernel:  [<c0254a8e>] tcp_sendmsg+0x4ff/0x108d
Oct 12 09:53:08 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:08 swdev14 kernel:  [<c0254a65>] tcp_sendmsg+0x4d6/0x108d
Oct 12 09:53:08 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:08 swdev14 last message repeated 2 times
Oct 12 09:53:08 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:08 swdev14 kernel:  [<c02764e0>] inet_sendmsg+0x50/0x5b
Oct 12 09:53:08 swdev14 kernel:  [<c0227bda>] sock_aio_write+0x124/0x136
Oct 12 09:53:08 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:08 swdev14 kernel:  [<c015b73d>] do_sync_write+0xaa/0xd6
Oct 12 09:53:08 swdev14 kernel:  [<c01333e3>] autoremove_wake_function+0x0/0x57
Oct 12 09:53:08 swdev14 kernel:  [<c01a9bd8>] dummy_file_permission+0x8/0xc
Oct 12 09:53:08 swdev14 kernel:  [<c015b80b>] vfs_write+0xa2/0x134
Oct 12 09:53:08 swdev14 kernel:  [<c015b869>] vfs_write+0x100/0x134
Oct 12 09:53:08 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:08 swdev14 kernel:  [<c015b967>] sys_write+0x50/0x7a
Oct 12 09:53:08 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 09:53:08 swdev14 kernel: scheduling while atomic: mount/0x04010002/2732
Oct 12 09:53:08 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 09:53:08 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:08 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:08 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:08 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:08 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:08 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:08 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:08 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:08 swdev14 kernel:  [<c0133b8e>] _rw_mutex_read_lock+0x24/0prx02> d91p[l>c.4av/p4> p> [/0x48e0x1a/023c/0x11514
Oct 12 09:53:08 swdev14 kernel:   i>st> b_p82/0134cou4> ock> [reem/0x_pre82/7+0xchecingc7+0x4d>d/0v4_/0ra/0 m
Oct 12 09:53:08 swdev14 kernel: <4ck<c0t_skb+0
Oct 12 09:53:08 swdev14 kernel: <4em4>i4>x4<c+0<c6/0x01x82/013pt_co97
Oct 12 09:53:08 swdev14 kernel: mpx97_a0xe0>]g+0>] m18
Oct 12 09:53:08 swdev14 kernel: wr4>ake_fun0x5_fil0x vfs0xrite+0x100/
Oct 12 09:53:08 swdev14 kernel: <4 mco
Oct 12 09:53:08 swdev14 kernel: <4ite+0x50/0x7a
Oct 12 09:53:08 swdev14 kernel:  [52/lin10lerx63/0299/0x99ed [<preemp46d_resched+0x26/0x83
Oct 12 09:53:08 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:08 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:08 swdev14 kernel:  [<c02996d9>] cond_resched+0x26/0x83
Oct 12 09:53:08 swdev14 kernel:  [<c0299716>] cond_resched+0x63/0x83
Oct 12 09:53:08 swdev14 kernel:  [<c0133b8e>] _rw_mutex_read_lock+0x24/0x39
Oct 12 09:53:08 swdev14 kernel:  [<c011f8f1>] profile_hook+0x1d/0x47
Oct 12 09:53:08 swdev14 kernel:  [<c011fde3>] profile_tick+0x63/0x65
Oct 12 09:53:08 swdev14 kernel:  [<c0113d03>] smp_apic_timer_interrupt+0x60/0xe4
Oct 12 09:53:08 swdev14 kernel:  [<c0106bb6>] apic_timer_interrupt+0x1a/0x20
Oct 12 09:53:08 swdev14 kernel:  [<c011f0b2>] release_console_sem+0x59/0xcf
Oct 12 09:53:08 swdev14 kernel:  [<c011efb2>] vprintk+0x128/0x16f
Oct 12 09:53:08 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:08 swdev14 kernel:  [<c011ee86>] printk+0x1d/0x21
Oct 12 09:53:09 swdev14 kernel:  [<c0106edc>] show_trace+0x4e/0x8d
Oct 12 09:53:09 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:09 swdev14 kernel:  [<c0106fd9>] dump_stack+0x23/0x27
Oct 12 09:53:09 swdev14 kernel:  [<c0299267>] schedule+0xbaf/0xbe2
Oct 12 09:53:09 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:09 swdev14 kernel:  [<c0134888>] check_preempt_timing+0x191/0x1f9
Oct 12 09:53:09 swdev14 kernel:  [<c0134936>] touch_preempt_timing+0x46/0x4a
Oct 12 09:53:09 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:09 swdev14 kernel:  [<c029a358>] _spin_unlock_irqrestore+0xb/0x36
Oct 12 09:53:09 swdev14 kernel:  [<c0298491>] __down+0x85/0x107
Oct 12 09:53:09 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:09 swdev14 kernel:  [<c0298496>] __down+0x8a/0x107
Oct 12 09:53:09 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 09:53:09 swdev14 kernel:  [<c029865c>] __down_failed+0x8/0xc
Oct 12 09:53:09 swdev14 kernel:  [<c0133ee3>] .text.lock.mutex+0x5/0x146
Oct 12 09:53:09 swdev14 kernel:  [<c0133884>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 09:53:09 swdev14 kernel:  [<e0840abe>] boomerang_start_xmit+0x123/0x2eb [3c59x]
Oct 12 09:53:09 swdev14 kernel:  [<c013414d>] __mcount+0x1d/0x21
Oct 12 09:53:09 swdev14 kernel:  [<c029a2b8>] _spin_unlock+0xb/0x34
Oct 12 09:53:09 swdev14 kernel:  [<c02404f3>] qdisc_restart+0x132/0x1e6
Oct 12 09:53:09 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:09 swdev14 kernel:  [<c0240517>] qdisc_restart+0x156/0x1e6
Oct 12 09:53:09 swdev14 kernel:  [<c02313dd>] dev_queue_xmit+0x239/0x2d9
Oct 12 09:53:09 swdev14 kernel:  [<c024ecfa>] ip_finish_output+0xd5/0x216
Oct 12 09:53:09 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:09 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 09:53:09 swdev14 kernel:  [<c025148e>] dst_output+0x1a/0x2f
Oct 12 09:53:09 swdev14 kernel:  [<c023bf2c>] nf_hook_slow+0xec/0x11e
Oct 12 09:53:09 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:09 swdev14 kernel:  [<c024f539>] ip_queue_xmit+0x495/0x59e
Oct 12 09:53:09 swdev14 kernel:  [<c0251474>] dst_output+0x0/0x2f
Oct 12 09:53:09 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:09 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:53:09 swdev14 kernel:  [<c029a2c7>] _spin_unlock+0x1a/0x34
Oct 12 09:53:09 swdev14 kernel:  [<c0134af1>] sub_preempt_count+0x82/0x97
Oct 12 09:56:00 swdev14 syslogd 1.4.1: restart.

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

* Re: [patch] VP-2.6.9-rc4-mm1-T6
  2004-10-12 15:12       ` [patch] VP-2.6.9-rc4-mm1-T6 K.R. Foley
@ 2004-10-12 15:27         ` Ingo Molnar
  2004-10-12 16:57           ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12 15:27 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Daniel Walker, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Wen-chien Jesse Sung, Mark_H_Johnson


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

> OK. This one builds just fine here. Again I tried booting preempt
> realtime. We were going along fine and then all hell broke loose on
> the console. Pressed Ctrl-s to stop the scrolling and it then bit the
> dust.  It did manage to get into the logs this time and I am attaching
> that.  This is a different SMP system that I use as a workstation at a
> client site. Dual 2.6GHz Xeons (with HT) 512MB

does the patch below make your system bootable? It should fix the two
most common messages you got.

	Ingo

--- linux/kernel/profile.c.orig
+++ linux/kernel/profile.c
@@ -169,7 +169,7 @@ int profile_event_unregister(enum profil
 }
 
 static struct notifier_block * profile_listeners;
-static rwlock_t profile_lock = RW_LOCK_UNLOCKED;
+static raw_rwlock_t profile_lock = RAW_RW_LOCK_UNLOCKED;
  
 int register_profile_notifier(struct notifier_block * nb)
 {
--- linux/drivers/net/3c59x.c.orig
+++ linux/drivers/net/3c59x.c
@@ -832,8 +832,8 @@ struct vortex_private {
 	u16 deferred;						/* Resend these interrupts when we
 										 * bale from the ISR */
 	u16 io_size;						/* Size of PCI region (for release_region) */
-	spinlock_t lock;					/* Serialise access to device & its vortex_private */
-	spinlock_t mdio_lock;				/* Serialise access to mdio hardware */
+	raw_spinlock_t lock;					/* Serialise access to device & its vortex_private */
+	raw_spinlock_t mdio_lock;				/* Serialise access to mdio hardware */
 	struct mii_if_info mii;				/* MII lib hooks/info */
 };
 

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

* Re: [patch] VP-2.6.9-rc4-mm1-T6
  2004-10-12 15:27         ` Ingo Molnar
@ 2004-10-12 16:57           ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-12 16:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Daniel Walker, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Wen-chien Jesse Sung, Mark_H_Johnson

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

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>OK. This one builds just fine here. Again I tried booting preempt
>>realtime. We were going along fine and then all hell broke loose on
>>the console. Pressed Ctrl-s to stop the scrolling and it then bit the
>>dust.  It did manage to get into the logs this time and I am attaching
>>that.  This is a different SMP system that I use as a workstation at a
>>client site. Dual 2.6GHz Xeons (with HT) 512MB
> 
> 
> does the patch below make your system bootable? It should fix the two
> most common messages you got.
> 
> 	Ingo
No. Attached log from this boot. Also worth noting: I have no keyboard 
while trying to boot this. This doesn't really surprise me, but I am 
seeing hit or miss on the keyboard (more times than not the keyboard is 
dead) with the T3 patch also. Doesn't seem to be an issue on my 933 SMP 
system at home. Is this a regression? Ideas?

kr

[-- Attachment #2: rtpreT7.dump2 --]
[-- Type: text/plain, Size: 46559 bytes --]

Oct 12 11:46:34 swdev14 syslogd 1.4.1: restart.
Oct 12 11:46:34 swdev14 syslog: syslogd startup succeeded
Oct 12 11:46:34 swdev14 kernel: klogd 1.4.1, log source = /proc/kmsg started.
Oct 12 11:46:34 swdev14 syslog: klogd startup succeeded
Oct 12 11:46:34 swdev14 kernel: 26/0x83>
Oct 12 11:46:34 swdev14 kernel:  => ended at:   <cond_resched+0x26/0x83>
Oct 12 11:46:34 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:34 swdev14 kernel:  [<c013484c>] check_preempt_timing+0x161/0x1f9
Oct 12 11:46:34 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:34 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:34 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:34 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:34 swdev14 kernel:  [<c0133816>] _mutex_lock+0x19/0x3f
Oct 12 11:46:34 swdev14 kernel:  [<c0133878>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 11:46:34 swdev14 kernel:  [<c01cbe88>] tty_register_ldisc+0x37/0xa4
Oct 12 11:46:34 swdev14 kernel:  [<c036be3e>] console_init+0x27/0x4a
Oct 12 11:46:34 swdev14 kernel:  [<c035487a>] start_kernel+0xd7/0x1c6
Oct 12 11:46:34 swdev14 kernel:  [<c03543b0>] unknown_bootoption+0x0/0x15d
Oct 12 11:46:34 swdev14 irqbalance: irqbalance startup succeeded
Oct 12 11:46:34 swdev14 kernel: Console: colour VGA+ 80x25
Oct 12 11:46:34 swdev14 kernel: Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Oct 12 11:46:34 swdev14 kernel: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Oct 12 11:46:34 swdev14 kernel: Memory: 513500k/523712k available (1645k kernel code, 9608k reserved, 726k data, 272k init, 0k highmem)
Oct 12 11:46:34 swdev14 kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok.
Oct 12 11:46:34 swdev14 kernel: Security Scaffold v1.0.0 initialized
Oct 12 11:46:34 swdev14 kernel: Capability LSM initialized
Oct 12 11:46:34 swdev14 kernel: Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Oct 12 11:46:34 swdev14 kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Oct 12 11:46:34 swdev14 portmap: portmap startup succeeded
Oct 12 11:46:34 swdev14 kernel: CPU: L2 cache: 512K
Oct 12 11:46:34 swdev14 kernel: CPU: Physical Processor ID: 0
Oct 12 11:46:34 swdev14 kernel: Intel machine check architecture supported.
Oct 12 11:46:34 swdev14 kernel: Intel machine check reporting enabled on CPU#0.
Oct 12 11:46:34 swdev14 kernel: CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
Oct 12 11:46:34 swdev14 kernel: Enabling fast FPU save and restore... done.
Oct 12 11:46:34 swdev14 kernel: Enabling unmasked SIMD FPU exception support... done.
Oct 12 11:46:34 swdev14 kernel: Checking 'hlt' instruction... OK.
Oct 12 11:46:34 swdev14 kernel: CPU0: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Oct 12 11:46:34 swdev14 kernel: per-CPU timeslice cutoff: 1462.71 usecs.
Oct 12 11:46:34 swdev14 kernel: task migration cache decay timeout: 2 msecs.
Oct 12 11:46:34 swdev14 kernel: Booting processor 1/1 eip 2000
Oct 12 11:46:34 swdev14 kernel: Initializing CPU#1
Oct 12 11:46:34 swdev14 rpc.statd[2649]: Version 1.0.6 Starting
Oct 12 11:46:34 swdev14 kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Oct 12 11:46:34 swdev14 kernel: CPU: L2 cache: 512K
Oct 12 11:46:34 swdev14 nfslock: rpc.statd startup succeeded
Oct 12 11:46:34 swdev14 kernel: CPU: Physical Processor ID: 0
Oct 12 11:46:34 swdev14 kernel: Intel machine check architecture supported.
Oct 12 11:46:34 swdev14 kernel: Intel machine check reporting enabled on CPU#1.
Oct 12 11:46:34 swdev14 kernel: CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
Oct 12 11:46:34 swdev14 kernel: CPU1: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Oct 12 11:46:34 swdev14 kernel: Booting processor 2/6 eip 2000
Oct 12 11:46:34 swdev14 kernel: Initializing CPU#2
Oct 12 11:46:34 swdev14 kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Oct 12 11:46:34 swdev14 kernel: CPU: L2 cache: 512K
Oct 12 11:46:34 swdev14 kernel: CPU: Physical Processor ID: 3
Oct 12 11:46:35 swdev14 kernel: Intel machine check architecture supported.
Oct 12 11:46:35 swdev14 kernel: Intel machine check reporting enabled on CPU#2.
Oct 12 11:46:35 swdev14 kernel: CPU2: Intel P4/Xeon Extended MCE MSRs (12) available
Oct 12 11:46:35 swdev14 kernel: CPU2: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Oct 12 11:46:35 swdev14 kernel: Booting processor 3/7 eip 2000
Oct 12 11:46:35 swdev14 kernel: Initializing CPU#3
Oct 12 11:46:35 swdev14 kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Oct 12 11:46:35 swdev14 rpcidmapd: rpc.idmapd startup succeeded
Oct 12 11:46:35 swdev14 kernel: CPU: L2 cache: 512K
Oct 12 11:46:35 swdev14 kernel: CPU: Physical Processor ID: 3
Oct 12 11:46:35 swdev14 kernel: Intel machine check architecture supported.
Oct 12 11:46:35 swdev14 kernel: Intel machine check reporting enabled on CPU#3.
Oct 12 11:46:35 swdev14 kernel: CPU3: Intel P4/Xeon Extended MCE MSRs (12) available
Oct 12 11:46:35 swdev14 kernel: CPU3: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Oct 12 11:46:35 swdev14 kernel: Total of 4 processors activated (20611.07 BogoMIPS).
Oct 12 11:46:35 swdev14 kernel: checking TSC synchronization across 4 CPUs: passed.
Oct 12 11:46:35 swdev14 kernel: ksoftirqd started up.
Oct 12 11:46:35 swdev14 last message repeated 2 times
Oct 12 11:46:35 swdev14 kernel: Brought up 4 CPUs
Oct 12 11:46:35 swdev14 random: Initializing random number generator:  succeeded
Oct 12 11:46:35 swdev14 kernel: ksoftirqd started up.
Oct 12 11:46:35 swdev14 rc: Starting pcmcia:  succeeded
Oct 12 11:46:35 swdev14 kernel: checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Oct 12 11:46:35 swdev14 kernel: Freeing initrd memory: 207k freed
Oct 12 11:46:35 swdev14 kernel: NET: Registered protocol family 16
Oct 12 11:46:35 swdev14 kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd915, last bus=5
Oct 12 11:46:35 swdev14 kernel: PCI: Using configuration type 1
Oct 12 11:46:35 swdev14 kernel: mtrr: v2.0 (20020519)
Oct 12 11:46:35 swdev14 kernel: Linux Plug and Play Support v0.97 (c) Adam Belay
Oct 12 11:46:35 swdev14 kernel: PCI: Probing PCI hardware
Oct 12 11:46:35 swdev14 kernel: PCI: Probing PCI hardware (bus 00)
Oct 12 11:46:35 swdev14 kernel: PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Oct 12 11:46:35 swdev14 kernel: PCI: Transparent bridge - 0000:00:1e.0
Oct 12 11:46:35 swdev14 kernel: Simple Boot Flag at 0x36 set to 0x1
Oct 12 11:46:35 swdev14 kernel: apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
Oct 12 11:46:35 swdev14 kernel: apm: disabled - APM is not SMP safe.
Oct 12 11:46:35 swdev14 kernel: VFS: Disk quotas dquot_6.5.1
Oct 12 11:46:35 swdev14 kernel: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Oct 12 11:46:35 swdev14 kernel: Initializing Cryptographic API
Oct 12 11:46:35 swdev14 kernel: vesafb: probe of vesafb0 failed with error -6
Oct 12 11:46:35 swdev14 kernel: isapnp: Scanning for PnP cards...
Oct 12 11:46:35 swdev14 kernel: isapnp: No Plug & Play device found
Oct 12 11:46:35 swdev14 kernel: scheduling while atomic: swapper/0x04000001/1
Oct 12 11:46:35 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 11:46:35 swdev14 kernel:  [<c029925b>] schedule+0xbaf/0xbe2
Oct 12 11:46:35 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:35 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:35 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:36 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:36 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:36 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:36 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:36 swdev14 kernel:  [<c0133b82>] _rw_mutex_read_lock+0x24/0x39
Oct 12 11:46:36 swdev14 kernel:  [<c011f62c>] profile_handoff_task+0x1a/0x52
Oct 12 11:46:36 swdev14 netfs: Mounting NFS filesystems:  succeeded
Oct 12 11:46:36 swdev14 kernel:  [<c011c508>] __put_task_struct+0x66/0x119
Oct 12 11:46:36 swdev14 kernel:  [<c0298a0b>] schedule+0x35f/0xbe2
Oct 12 11:46:36 swdev14 kernel:  [<c029a392>] _spin_unlock_irq+0x1b/0x35
Oct 12 11:46:36 swdev14 netfs: Mounting other filesystems:  succeeded
Oct 12 11:46:36 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:36 swdev14 kernel:  [<c0134ae5>] sub_preempt_count+0x82/0x97
Oct 12 11:46:36 swdev14 kernel:  [<c029a392>] _spin_unlock_irq+0x1b/0x35
Oct 12 11:46:36 swdev14 kernel:  [<c029938c>] wait_for_completion+0x84/0xe3
Oct 12 11:46:36 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 11:46:36 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 11:46:36 swdev14 kernel:  [<c012eab2>] queue_work+0x72/0xa0
Oct 12 11:46:36 swdev14 kernel:  [<c012e9cd>] call_usermodehelper+0xc7/0xce
Oct 12 11:46:36 swdev14 kernel:  [<c012e89d>] __call_usermodehelper+0x0/0x69
Oct 12 11:46:36 swdev14 kernel:  [<c01e54d5>] class_hotplug+0x0/0x44
Oct 12 11:46:36 swdev14 kernel:  [<c01aeeb4>] kobject_hotplug+0x27e/0x2e2
Oct 12 11:46:36 swdev14 kernel:  [<c01ae0f0>] create_dir+0x3e/0x4e
Oct 12 11:46:36 swdev14 autofs: automount startup succeeded
Oct 12 11:46:36 swdev14 kernel:  [<c01ae34e>] kobject_add+0x8c/0xfa
Oct 12 11:46:36 swdev14 kernel:  [<c01e56b7>] class_device_add+0x8d/0x15e
Oct 12 11:46:36 swdev14 kernel:  [<c01e5d0b>] class_simple_device_add+0xa3/0x104
Oct 12 11:46:36 swdev14 kernel:  [<c01cfb4d>] tty_register_device+0x73/0xdd
Oct 12 11:46:36 swdev14 kernel:  [<c01e64a8>] kobj_map+0xa0/0x136
Oct 12 11:46:36 swdev14 kernel:  [<c0164ba4>] cdev_add+0x4b/0x4f
Oct 12 11:46:36 swdev14 kernel:  [<c01cfe6a>] tty_register_driver+0x14c/0x243
Oct 12 11:46:36 swdev14 smartd[2807]: smartd version 5.21 Copyright (C) 2002-3 Bruce Allen 
Oct 12 11:46:36 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 11:46:36 swdev14 smartd[2807]: Home page is http://smartmontools.sourceforge.net/  
Oct 12 11:46:36 swdev14 kernel:  [<c036c34d>] legacy_pty_init+0x28a/0x2c8
Oct 12 11:46:36 swdev14 smartd[2807]: Opened configuration file /etc/smartd.conf 
Oct 12 11:46:36 swdev14 kernel:  [<c036c657>] pty_init+0xd/0x16
Oct 12 11:46:36 swdev14 smartd[2807]: Configuration file /etc/smartd.conf parsed. 
Oct 12 11:46:36 swdev14 kernel:  [<c03549b2>] do_initcalls+0x30/0xbd
Oct 12 11:46:36 swdev14 smartd[2807]: Device: /dev/hda, opened 
Oct 12 11:46:36 swdev14 kernel:  [<c0100541>] init+0x87/0x19a
Oct 12 11:46:36 swdev14 kernel:  [<c01004ba>] init+0x0/0x19a
Oct 12 11:46:36 swdev14 smartd[2807]: Device: /dev/hda, not found in smartd database. 
Oct 12 11:46:36 swdev14 kernel:  [<c01042c9>] kernel_thread_helper+0x5/0xb
Oct 12 11:46:36 swdev14 smartd[2807]: Device: /dev/hda, is SMART capable. Adding to "monitor" list. 
Oct 12 11:46:36 swdev14 kernel: scheduling while atomic: swapper/0x04000001/1
Oct 12 11:46:36 swdev14 smartd[2807]: Monitoring 1 ATA and 0 SCSI devices 
Oct 12 11:46:36 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 11:46:37 swdev14 smartd[2809]: smartd has fork()ed into background mode. New PID=2809. 
Oct 12 11:46:37 swdev14 kernel:  [<c029925b>] schedule+0xbaf/0xbe2
Oct 12 11:46:37 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:37 swdev14 smartd: smartd startup succeeded
Oct 12 11:46:37 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:37 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:37 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:37 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:37 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:37 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:37 swdev14 kernel:  [<c0133b82>] _rw_mutex_read_lock+0x24/0x39
Oct 12 11:46:37 swdev14 kernel:  [<c011f62c>] profile_handoff_task+0x1a/0x52
Oct 12 11:46:37 swdev14 kernel:  [<c011c508>] __put_task_struct+0x66/0x119
Oct 12 11:46:37 swdev14 kernel:  [<c0298a0b>] schedule+0x35f/0xbe2
Oct 12 11:46:37 swdev14 kernel:  [<c029a392>] _spin_unlock_irq+0x1b/0x35
Oct 12 11:46:37 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:37 swdev14 sshd:  succeeded
Oct 12 11:46:37 swdev14 kernel:  [<c0134ae5>] sub_preempt_count+0x82/0x97
Oct 12 11:46:37 swdev14 kernel:  [<c029a392>] _spin_unlock_irq+0x1b/0x35
Oct 12 11:46:37 swdev14 kernel:  [<c029938c>] wait_for_completion+0x84/0xe3
Oct 12 11:46:37 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 11:46:37 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 11:46:37 swdev14 kernel:  [<c012eab2>] queue_work+0x72/0xa0
Oct 12 11:46:37 swdev14 kernel:  [<c012e9cd>] call_usermodehelper+0xc7/0xce
Oct 12 11:46:37 swdev14 kernel:  [<c012e89d>] __call_usermodehelper+0x0/0x69
Oct 12 11:46:37 swdev14 kernel:  [<c01e54d5>] class_hotplug+0x0/0x44
Oct 12 11:46:37 swdev14 kernel:  [<c01aeeb4>.20
Oct 12 11:46:37 swdev14 xinetd: xinetd startup succeeded
Oct 12 11:46:37 swdev14 kernel: ip_tables: (C) 2000-2002 Netfilter core team
Oct 12 11:46:37 swdev14 kernel: NET: Registered protocol family 10
Oct 12 11:46:37 swdev14 kernel: using smp_processor_id() in preemptible [00000001] code: modprobe/2819
Oct 12 11:46:37 swdev14 kernel: caller is raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:37 swdev14 ntpdate[2873]: can't find host wizard 
Oct 12 11:46:37 swdev14 kernel:  [<c011a2aa>] smp_processor_id+0xa8/0xb9
Oct 12 11:46:37 swdev14 kernel:  [<e0b32f56>] raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:37 swdev14 kernel:  [<e0b32f56>] raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:37 swdev14 kernel:  [<e0b1d282>] inet6_create+0x26f/0x315 [ipv6]
Oct 12 11:46:37 swdev14 kernel:  [<c02284aa>] __sock_create+0xd5/0x19d
Oct 12 11:46:37 swdev14 kernel:  [<c02285dc>] sock_create_kern+0x33/0x37
Oct 12 11:46:37 swdev14 kernel:  [<e09bc824>] icmpv6_init+0xc4/0x110 [ipv6]
Oct 12 11:46:37 swdev14 kernel:  [<e09bc14b>] inet6_init+0xb9/0x20c [ipv6]
Oct 12 11:46:37 swdev14 kernel:  [<c0138c03>] sys_init_module+0x15c/0x1ce
Oct 12 11:46:37 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:38 swdev14 kernel: using smp_processor_id() in preemptible [00000001] code: modprobe/2819
Oct 12 11:46:38 swdev14 kernel: caller is raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c011a2aa>] smp_processor_id+0xa8/0xb9
Oct 12 11:46:38 swdev14 kernel:  [<e0b32fda>] raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b32fda>] raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc856>] icmpv6_init+0xf6/0x110 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc14b>] inet6_init+0xb9/0x20c [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c0138c03>] sys_init_module+0x15c/0x1ce
Oct 12 11:46:38 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:38 swdev14 kernel: using smp_processor_id() in preemptible [00000001] code: modprobe/2819
Oct 12 11:46:38 swdev14 kernel: caller is raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c011a2aa>] smp_processor_id+0xa8/0xb9
Oct 12 11:46:38 swdev14 kernel:  [<e0b32f56>] raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b32f56>] raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b1d282>] inet6_create+0x26f/0x315 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c02284aa>] __sock_create+0xd5/0x19d
Oct 12 11:46:38 swdev14 kernel:  [<c02285dc>] sock_create_kern+0x33/0x37
Oct 12 11:46:38 swdev14 kernel:  [<e09bc824>] icmpv6_init+0xc4/0x110 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc14b>] inet6_init+0xb9/0x20c [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c0138c03>] sys_init_module+0x15c/0x1ce
Oct 12 11:46:38 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:38 swdev14 kernel: using smp_processor_id() in preemptible [00000001] code: modprobe/2819
Oct 12 11:46:38 swdev14 kernel: caller is raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c011a2aa>] smp_processor_id+0xa8/0xb9
Oct 12 11:46:38 swdev14 kernel:  [<e0b32fda>] raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b32fda>] raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc856>] icmpv6_init+0xf6/0x110 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc14b>] inet6_init+0xb9/0x20c [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c0138c03>] sys_init_module+0x15c/0x1ce
Oct 12 11:46:38 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:38 swdev14 kernel: using smp_processor_id() in preemptible [00000001] code: modprobe/2819
Oct 12 11:46:38 swdev14 kernel: caller is raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c011a2aa>] smp_processor_id+0xa8/0xb9
Oct 12 11:46:38 swdev14 kernel:  [<e0b32f56>] raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b32f56>] raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b1d282>] inet6_create+0x26f/0x315 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c02284aa>] __sock_create+0xd5/0x19d
Oct 12 11:46:38 swdev14 kernel:  [<c02285dc>] sock_create_kern+0x33/0x37
Oct 12 11:46:38 swdev14 kernel:  [<e09bc824>] icmpv6_init+0xc4/0x110 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc14b>] inet6_init+0xb9/0x20c [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c0138c03>] sys_init_module+0x15c/0x1ce
Oct 12 11:46:38 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:38 swdev14 kernel: using smp_processor_id() in preemptible [00000001] code: modprobe/2819
Oct 12 11:46:38 swdev14 kernel: caller is raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c011a2aa>] smp_processor_id+0xa8/0xb9
Oct 12 11:46:38 swdev14 kernel:  [<e0b32fda>] raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b32fda>] raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc856>] icmpv6_init+0xf6/0x110 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc14b>] inet6_init+0xb9/0x20c [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c0138c03>] sys_init_module+0x15c/0x1ce
Oct 12 11:46:38 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:38 swdev14 kernel: using smp_processor_id() in preemptible [00000001] code: modprobe/2819
Oct 12 11:46:38 swdev14 kernel: caller is raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c011a2aa>] smp_processor_id+0xa8/0xb9
Oct 12 11:46:38 swdev14 kernel:  [<e0b32f56>] raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b32f56>] raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b1d282>] inet6_create+0x26f/0x315 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c02284aa>] __sock_create+0xd5/0x19d
Oct 12 11:46:38 swdev14 kernel:  [<c02285dc>] sock_create_kern+0x33/0x37
Oct 12 11:46:38 swdev14 kernel:  [<e09bc824>] icmpv6_init+0xc4/0x110 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc14b>] inet6_init+0xb9/0x20c [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c0138c03>] sys_init_module+0x15c/0x1ce
Oct 12 11:46:38 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:38 swdev14 kernel: using smp_processor_id() in preemptible [00000001] code: modprobe/2819
Oct 12 11:46:38 swdev14 kernel: caller is raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c011a2aa>] smp_processor_id+0xa8/0xb9
Oct 12 11:46:38 swdev14 kernel:  [<e0b32fda>] raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b32fda>] raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc856>] icmpv6_init+0xf6/0x110 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc14b>] inet6_init+0xb9/0x20c [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c0138c03>] sys_init_module+0x15c/0x1ce
Oct 12 11:46:38 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:38 swdev14 kernel: using smp_processor_id() in preemptible [00000001] code: modprobe/2819
Oct 12 11:46:38 swdev14 kernel: caller is raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c011a2aa>] smp_processor_id+0xa8/0xb9
Oct 12 11:46:38 swdev14 kernel:  [<e0b32f56>] raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b32f56>] raw_v6_hash+0x62/0x85 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b1d282>] inet6_create+0x26f/0x315 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c02284aa>] __sock_create+0xd5/0x19d
Oct 12 11:46:38 swdev14 kernel:  [<c02285dc>] sock_create_kern+0x33/0x37
Oct 12 11:46:38 swdev14 kernel:  [<e09bc60d>] ndisc_init+0x32/0xe9 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc161>] inet6_init+0xcf/0x20c [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c0138c03>] sys_init_module+0x15c/0x1ce
Oct 12 11:46:38 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:38 swdev14 kernel: using smp_processor_id() in preemptible [00000001] code: modprobe/2819
Oct 12 11:46:38 swdev14 kernel: caller is raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c011a2aa>] smp_processor_id+0xa8/0xb9
Oct 12 11:46:38 swdev14 kernel:  [<e0b32fda>] raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e0b32fda>] raw_v6_unhash+0x61/0xad [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc646>] ndisc_init+0x6b/0xe9 [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<e09bc161>] inet6_init+0xcf/0x20c [ipv6]
Oct 12 11:46:38 swdev14 kernel:  [<c0138c03>] sys_init_module+0x15c/0x1ce
Oct 12 11:46:38 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:38 swdev14 kernel: IPv6 over IPv4 tunneling driver
Oct 12 11:46:38 swdev14 kernel: ------------[ cut here ]------------
Oct 12 11:46:38 swdev14 kernel: kernel BUG at kernel/mutex.c:185!
Oct 12 11:46:38 swdev14 kernel: invalid operand: 0000 [#1]
Oct 12 11:46:38 swdev14 kernel: PREEMPT SMP 
Oct 12 11:46:38 swdev14 kernel: Modules linked in: ipv6 autofs4 nfs lockd sunrpc iptable_filter ip_tables ide_cd cdrom 3c59x mii tg3 floppy sg scsi_mod parport_pc parport microcode dm_mod evdev usbhid uhci_hcd usbcore ext3 jbd
Oct 12 11:46:38 swdev14 kernel: CPU:    2
Oct 12 11:46:38 swdev14 kernel: EIP:    0060:[<c0133bbc>]    Not tainted VLI
Oct 12 11:46:38 swdev14 kernel: EFLAGS: 00010246   (2.6.9-rc4-mm1-VP-T7) 
Oct 12 11:46:38 swdev14 kernel: EIP is at _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:38 swdev14 kernel: eax: 00000000   ebx: 00000000   ecx: c0350e00   edx: c1466b80
Oct 12 11:46:38 swdev14 kernel: esi: ddef3ac8   edi: dd878814   ebp: de5d7f18   esp: de5d7f18
Oct 12 11:46:38 swdev14 kernel: ds: 007b   es: 007b   ss: 0068   preempt: 00000002
Oct 12 11:46:38 swdev14 kernel: Process sshd (pid: 2849, threadinfo=de5d6000 task=de4a7a80)
Oct 12 11:46:38 swdev14 kernel: Stack: de5d7f44 c02537ec c0350e00 00000016 c029a3c6 dfe12a80 ddef3c94 ddef3bfc 
Oct 12 11:46:38 swdev14 kernel:        dfe12a80 ddef3a80 ffffffea de5d7f5c c0275b18 ddef3a80 00000005 dfe12a80 
Oct 12 11:46:38 swdev14 kernel:        00000003 de5d7f78 c022889e dfe12a80 00000005 00000000 00000004 08090bf0 
Oct 12 11:46:38 swdev14 kernel: Call Trace:
Oct 12 11:46:38 swdev14 kernel:  [<c02537ec>] tcp_listen_start+0x175/0x1d1
Oct 12 11:46:38 swdev14 kernel:  [<c029a3c6>] _spin_unlock_bh+0x1a/0x34
Oct 12 11:46:38 swdev14 kernel:  [<c0275b18>] inet_listen+0x65/0x7a
Oct 12 11:46:39 swdev14 kernel:  [<c022889e>] sys_listen+0x5c/0x74
Oct 12 11:46:39 swdev14 kernel:  [<c0229558>] sys_socketcall+0xb1/0x239
Oct 12 11:46:39 swdev14 kernel:  [<c015aeb9>] sys_close+0x75/0x91
Oct 12 11:46:39 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:39 swdev14 kernel: Code: 75 fc 89 ec 5d c3 55 89 e5 e8 21 fb fd ff 8b 4d 08 8b 01 85 c0 74 14 8d 41 04 ba ff ff 00 00 f0 0f c1 10 0f 85 6e 03 00 00 5d c3 <0f> 0b b9 00 1a c7 2a c0 eb e2 55 89 e5 e8 f2 fa fd ff 8b 4d 08 
Oct 12 11:46:39 swdev14 kernel:  <3>scheduling while atomic: sshd/0x04000001/2849
Oct 12 11:46:39 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c029925b>] schedule+0xbaf/0xbe2
Oct 12 11:46:39 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:39 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:39 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:39 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c011f5d4>] profile_task_exit+0x18/0x56
Oct 12 11:46:39 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 11:46:39 swdev14 kernel:  [<c01216f8>] do_exit+0x1f/0x3bd
Oct 12 11:46:39 swdev14 kernel:  [<c029929f>] preempt_schedule+0x11/0x7a
Oct 12 11:46:39 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 11:46:39 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 11:46:39 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 11:46:39 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 11:46:39 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:39 swdev14 kernel:  [<c0134141>] __mcount+0x1d/0x21
Oct 12 11:46:39 swdev14 kernel:  [<c029a1aa>] _write_lock+0x1b/0x76
Oct 12 11:46:39 swdev14 kernel:  [<c0264422>] tcp_listen_wlock+0x16/0xac
Oct 12 11:46:39 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 11:46:39 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 11:46:39 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:39 swdev14 kernel:  [<c02537ec>] tcp_listen_start+0x175/0x1d1
Oct 12 11:46:39 swdev14 kernel:  [<c029a3c6>] _spin_unlock_bh+0x1a/0x34
Oct 12 11:46:39 swdev14 kernel:  [<c0275b18>] inet_listen+0x65/0x7a
Oct 12 11:46:39 swdev14 kernel:  [<c022889e>] sys_listen+0x5c/0x74
Oct 12 11:46:39 swdev14 kernel:  [<c0229558>] sys_socketcall+0xb1/0x239
Oct 12 11:46:39 swdev14 kernel:  [<c015aeb9>] sys_close+0x75/0x91
Oct 12 11:46:39 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:39 swdev14 kernel: note: sshd[2849] exited with preempt_count 1
Oct 12 11:46:39 swdev14 kernel: scheduling while atomic: sshd/0x04000001/2849
Oct 12 11:46:39 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c029925b>] schedule+0xbaf/0xbe2
Oct 12 11:46:39 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:39 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:39 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:39 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c014b81d>] unmap_vmas+0x190/0x29b
Oct 12 11:46:39 swdev14 kernel:  [<c015006f>] exit_mmap+0xb2/0x1cc
Oct 12 11:46:39 swdev14 kernel:  [<c011c979>] mmput+0x3b/0xb9
Oct 12 11:46:39 swdev14 kernel:  [<c0121807>] do_exit+0x12e/0x3bd
Oct 12 11:46:39 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 11:46:39 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 11:46:39 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 11:46:39 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 11:46:39 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:39 swdev14 kernel:  [<c0134141>] __mcount+0x1d/0x21
Oct 12 11:46:39 swdev14 kernel:  [<c029a1aa>] _write_lock+0x1b/0x76
Oct 12 11:46:39 swdev14 kernel:  [<c0264422>] tcp_listen_wlock+0x16/0xac
Oct 12 11:46:39 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 11:46:39 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 11:46:39 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:39 swdev14 kernel:  [<c02537ec>] tcp_listen_start+0x175/0x1d1
Oct 12 11:46:39 swdev14 kernel:  [<c029a3c6>] _spin_unlock_bh+0x1a/0x34
Oct 12 11:46:39 swdev14 kernel:  [<c0275b18>] inet_listen+0x65/0x7a
Oct 12 11:46:39 swdev14 kernel:  [<c022889e>] sys_listen+0x5c/0x74
Oct 12 11:46:39 swdev14 kernel:  [<c0229558>] sys_socketcall+0xb1/0x239
Oct 12 11:46:39 swdev14 kernel:  [<c015aeb9>] sys_close+0x75/0x91
Oct 12 11:46:39 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:39 swdev14 kernel: scheduling while atomic: sshd/0x04000001/2849
Oct 12 11:46:39 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c029925b>] schedule+0xbaf/0xbe2
Oct 12 11:46:39 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:39 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:39 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:39 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c0133816>] _mutex_lock+0x19/0x3f
Oct 12 11:46:39 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c014dff0>] remove_vm_struct+0x34/0x9f
Oct 12 11:46:39 swdev14 kernel:  [<c015012f>] exit_mmap+0x172/0x1cc
Oct 12 11:46:39 swdev14 kernel:  [<c011c979>] mmput+0x3b/0xb9
Oct 12 11:46:39 swdev14 kernel:  [<c0121807>] do_exit+0x12e/0x3bd
Oct 12 11:46:39 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 11:46:39 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 11:46:39 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 11:46:39 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 11:46:39 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:39 swdev14 kernel:  [<c0134141>] __mcount+0x1d/0x21
Oct 12 11:46:39 swdev14 kernel:  [<c029a1aa>] _write_lock+0x1b/0x76
Oct 12 11:46:39 swdev14 kernel:  [<c0264422>] tcp_listen_wlock+0x16/0xac
Oct 12 11:46:39 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 11:46:39 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 11:46:39 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:39 swdev14 kernel:  [<c02537ec>] tcp_listen_start+0x175/0x1d1
Oct 12 11:46:39 swdev14 kernel:  [<c029a3c6>] _spin_unlock_bh+0x1a/0x34
Oct 12 11:46:39 swdev14 kernel:  [<c0275b18>] inet_listen+0x65/0x7a
Oct 12 11:46:39 swdev14 kernel:  [<c022889e>] sys_listen+0x5c/0x74
Oct 12 11:46:39 swdev14 kernel:  [<c0229558>] sys_socketcall+0xb1/0x239
Oct 12 11:46:39 swdev14 kernel:  [<c015aeb9>] sys_close+0x75/0x91
Oct 12 11:46:39 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:39 swdev14 kernel: scheduling while atomic: sshd/0x04000001/2849
Oct 12 11:46:39 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c029925b>] schedule+0xbaf/0xbe2
Oct 12 11:46:39 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:39 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:39 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:39 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:39 swdev14 kernel:  [<c0133816>] _mutex_lock+0x19/0x3f
Oct 12 11:46:39 swdev14 kernel:  [<c015197a>] anon_vma_unlink+0x23/0x90
Oct 12 11:46:39 swdev14 kernel:  [<c015c50e>] fput+0xe/0x1f
Oct 12 11:46:39 swdev14 kernel:  [<c014e032>] remove_vm_struct+0x76/0x9f
Oct 12 11:46:39 swdev14 kernel:  [<c015012f>] exit_mmap+0x172/0x1cc
Oct 12 11:46:39 swdev14 kernel:  [<c011c979>] mmput+0x3b/0xb9
Oct 12 11:46:39 swdev14 kernel:  [<c0121807>] do_exit+0x12e/0x3bd
Oct 12 11:46:39 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 11:46:39 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 11:46:39 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 11:46:40 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 11:46:40 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:40 swdev14 kernel:  [<c0134141>] __mcount+0x1d/0x21
Oct 12 11:46:40 swdev14 kernel:  [<c029a1aa>] _write_lock+0x1b/0x76
Oct 12 11:46:40 swdev14 kernel:  [<c0264422>] tcp_listen_wlock+0x16/0xac
Oct 12 11:46:40 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 11:46:40 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 11:46:40 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:40 swdev14 kernel:  [<c02537ec>] tcp_listen_start+0x175/0x1d1
Oct 12 11:46:40 swdev14 kernel:  [<c029a3c6>] _spin_unlock_bh+0x1a/0x34
Oct 12 11:46:40 swdev14 kernel:  [<c0275b18>] inet_listen+0x65/0x7a
Oct 12 11:46:40 swdev14 kernel:  [<c022889e>] sys_listen+0x5c/0x74
Oct 12 11:46:40 swdev14 kernel:  [<c0229558>] sys_socketcall+0xb1/0x239
Oct 12 11:46:40 swdev14 kernel:  [<c015aeb9>] sys_close+0x75/0x91
Oct 12 11:46:40 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:40 swdev14 kernel: scheduling while atomic: sshd/0x04000001/2849
Oct 12 11:46:40 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 11:46:40 swdev14 kernel:  [<c029925b>] schedule+0xbaf/0xbe2
Oct 12 11:46:40 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:40 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:40 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:40 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:40 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:40 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:40 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:40 swdev14 kernel:  [<c014dfdb>] remove_vm_struct+0x1f/0x9f
Oct 12 11:46:40 swdev14 kernel:  [<c015012f>] exit_mmap+0x172/0x1cc
Oct 12 11:46:40 swdev14 kernel:  [<c011c979>] mmput+0x3b/0xb9
Oct 12 11:46:40 swdev14 kernel:  [<c0121807>] do_exit+0x12e/0x3bd
Oct 12 11:46:40 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 11:46:40 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 11:46:40 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 11:46:40 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 11:46:40 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:40 swdev14 kernel:  [<c0134141>] __mcount+0x1d/0x21
Oct 12 11:46:40 swdev14 kernel:  [<c029a1aa>] _write_lock+0x1b/0x76
Oct 12 11:46:40 swdev14 kernel:  [<c0264422>] tcp_listen_wlock+0x16/0xac
Oct 12 11:46:40 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 11:46:40 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 11:46:40 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:40 swdev14 kernel:  [<c02537ec>] tcp_listen_start+0x175/0x1d1
Oct 12 11:46:40 swdev14 kernel:  [<c029a3c6>] _spin_unlock_bh+0x1a/0x34
Oct 12 11:46:40 swdev14 kernel:  [<c0275b18>] inet_listen+0x65/0x7a
Oct 12 11:46:40 swdev14 kernel:  [<c022889e>] sys_listen+0x5c/0x74
Oct 12 11:46:40 swdev14 kernel:  [<c0229558>] sys_socketcall+0xb1/0x239
Oct 12 11:46:40 swdev14 kernel:  [<c015aeb9>] sys_close+0x75/0x91
Oct 12 11:46:40 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:40 swdev14 kernel: scheduling while atomic: sshd/0x04000001/2849
Oct 12 11:46:40 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 11:46:40 swdev14 kernel:  [<c029925b>] schedule+0xbaf/0xbe2
Oct 12 11:46:40 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:40 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:40 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:40 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:40 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:40 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:40 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:40 swdev14 kernel:  [<c014dfdb>] remove_vm_struct+0x1f/0x9f
Oct 12 11:46:40 swdev14 kernel:  [<c015012f>] exit_mmap+0x172/0x1cc
Oct 12 11:46:40 swdev14 kernel:  [<c011c979>] mmput+0x3b/0xb9
Oct 12 11:46:40 swdev14 kernel:  [<c0121807>] do_exit+0x12e/0x3bd
Oct 12 11:46:40 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 11:46:40 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 11:46:40 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 11:46:40 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 11:46:40 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:40 swdev14 kernel:  [<c0134141>] __mcount+0x1d/0x21
Oct 12 11:46:40 swdev14 kernel:  [<c029a1aa>] _write_lock+0x1b/0x76
Oct 12 11:46:40 swdev14 kernel:  [<c0264422>] tcp_listen_wlock+0x16/0xac
Oct 12 11:46:40 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 11:46:40 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 11:46:40 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:40 swdev14 kernel:  [<c02537ec>] tcp_listen_start+0x175/0x1d1
Oct 12 11:46:40 swdev14 kernel:  [<c029a3c6>] _spin_unlock_bh+0x1a/0x34
Oct 12 11:46:40 swdev14 kernel:  [<c0275b18>] inet_listen+0x65/0x7a
Oct 12 11:46:40 swdev14 kernel:  [<c022889e>] sys_listen+0x5c/0x74
Oct 12 11:46:40 swdev14 kernel:  [<c0229558>] sys_socketcall+0xb1/0x239
Oct 12 11:46:40 swdev14 kernel:  [<c015aeb9>] sys_close+0x75/0x91
Oct 12 11:46:40 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:40 swdev14 kernel: scheduling while atomic: sshd/0x00000001/2849
Oct 12 11:46:40 swdev14 kernel: caller is __down+0x8a/0x107
Oct 12 11:46:40 swdev14 kernel:  [<c029925b>] schedule+0xbaf/0xbe2
Oct 12 11:46:40 swdev14 kernel:  [<c029848a>] __down+0x8a/0x107
Oct 12 11:46:40 swdev14 kernel:  [<c0134141>] __mcount+0x1d/0x21
Oct 12 11:46:40 swdev14 kernel:  [<c0134141>] __mcount+0x1d/0x21
Oct 12 11:46:40 swdev14 kernel:  [<c029a34c>] _spin_unlock_irqrestore+0xb/0x36
Oct 12 11:46:40 swdev14 kernel:  [<c0298485>] __down+0x85/0x107
Oct 12 11:46:40 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 11:46:40 swdev14 kernel:  [<c029848a>] __down+0x8a/0x107
Oct 12 11:46:40 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 11:46:40 swdev14 kernel:  [<c0298650>] __down_failed+0x8/0xc
Oct 12 11:46:40 swdev14 kernel:  [<c011c3d8>] .text.lock.sched+0x5/0x15
Oct 12 11:46:40 swdev14 kernel:  [<c01ccbc1>] disassociate_ctty+0x1d/0x16d
Oct 12 11:46:40 swdev14 kernel:  [<c01218f1>] do_exit+0x218/0x3bd
Oct 12 11:46:40 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 11:46:40 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 11:46:40 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 11:46:40 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 11:46:40 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:40 swdev14 kernel:  [<c0134141>] __mcount+0x1d/0x21
Oct 12 11:46:40 swdev14 kernel:  [<c029a1aa>] _write_lock+0x1b/0x76
Oct 12 11:46:40 swdev14 kernel:  [<c0264422>] tcp_listen_wlock+0x16/0xac
Oct 12 11:46:40 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 11:46:40 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 11:46:40 swdev14 kernel:  [<c0133bbc>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 11:46:40 swdev14 kernel:  [<c02537ec>] tcp_listen_start+0x175/0x1d1
Oct 12 11:46:40 swdev14 kernel:  [<c029a3c6>] _spin_unlock_bh+0x1a/0x34
Oct 12 11:46:40 swdev14 kernel:  [<c0275b18>] inet_listen+0x65/0x7a
Oct 12 11:46:40 swdev14 kernel:  [<c022889e>] sys_listen+0x5c/0x74
Oct 12 11:46:40 swdev14 kernel:  [<c0229558>] sys_socketcall+0xb1/0x239
Oct 12 11:46:40 swdev14 kernel:  [<c015aeb9>] sys_close+0x75/0x91
Oct 12 11:46:40 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:46 swdev14 ntpdate[2873]: step time server 159.82.80.104 offset -0.498445 sec
Oct 12 11:46:46 swdev14 ntpd:  succeeded
Oct 12 11:46:46 swdev14 ntpd[2877]: ntpd 4.2.0@1.1161-r Thu Mar 11 11:46:39 EST 2004 (1)
Oct 12 11:46:46 swdev14 ntpd: ntpd startup succeeded
Oct 12 11:46:46 swdev14 ntpd[2877]: precision = 1.000 usec
Oct 12 11:46:46 swdev14 ntpd[2877]: kernel time sync status 0040
Oct 12 11:46:46 swdev14 ntpd[2877]: configure: keyword "opus" unknown, line ignored
Oct 12 11:46:46 swdev14 ntpd[2877]: configure: keyword "hal" unknown, line ignored
Oct 12 11:46:46 swdev14 ntpd[2877]: configure: keyword "wizard" unknown, line ignored
Oct 12 11:46:46 swdev14 ntpd[2877]: configure: keyword "time1.utc.com" unknown, line ignored
Oct 12 11:46:46 swdev14 ntpd[2877]: configure: keyword "time2.utc.com" unknown, line ignored
Oct 12 11:46:46 swdev14 ntpd[2877]: configure: keyword "time3.utc.com" unknown, line ignored
Oct 12 11:46:46 swdev14 vsftpd: vsftpd vsftpd succeeded
Oct 12 11:46:46 swdev14 ntpd[2877]: frequency initialized 124.193 PPM from /var/lib/ntp/drift
Oct 12 11:46:46 swdev14 ntpd[2877]: configure: keyword "authenticate" unknown, line ignored
Oct 12 11:46:46 swdev14 gpm[2896]: *** info [startup.c(95)]: 
Oct 12 11:46:46 swdev14 gpm[2896]: Started gpm successfully. Entered daemon mode.
Oct 12 11:46:46 swdev14 gpm[2896]: *** info [mice.c(1766)]: 
Oct 12 11:46:46 swdev14 gpm[2896]: imps2: Auto-detected intellimouse PS/2
Oct 12 11:46:47 swdev14 gpm: gpm startup succeeded
Oct 12 11:46:47 swdev14 crond: crond startup succeeded
Oct 12 11:46:49 swdev14 kernel: lp0: using parport0 (polling).
Oct 12 11:46:49 swdev14 kernel: lp0: console ready
Oct 12 11:46:49 swdev14 kernel: scheduling while atomic: serial/0x04000001/2947
Oct 12 11:46:49 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 11:46:49 swdev14 kernel:  [<c029925b>] schedule+0xbaf/0xbe2
Oct 12 11:46:49 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:49 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:49 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:49 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:49 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:49 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:49 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:49 swdev14 kernel:  [<c0133b82>] _rw_mutex_read_lock+0x24/0x39
Oct 12 11:46:49 swdev14 kernel:  [<c011f62c>] profile_handoff_task+0x1a/0x52
Oct 12 11:46:49 swdev14 kernel:  [<c011c508>] __put_task_struct+0x66/0x119
Oct 12 11:46:49 swdev14 kernel:  [<c0298a0b>] schedule+0x35f/0xbe2
Oct 12 11:46:49 swdev14 kernel:  [<c029a392>] _spin_unlock_irq+0x1b/0x35
Oct 12 11:46:49 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:49 swdev14 kernel:  [<c0134ae5>] sub_preempt_count+0x82/0x97
Oct 12 11:46:49 swdev14 kernel:  [<c029a392>] _spin_unlock_irq+0x1b/0x35
Oct 12 11:46:49 swdev14 kernel:  [<c029938c>] wait_for_completion+0x84/0xe3
Oct 12 11:46:49 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 11:46:49 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 11:46:49 swdev14 kernel:  [<c012ead4>] queue_work+0x94/0xa0
Oct 12 11:46:49 swdev14 kernel:  [<c012e9cd>] call_usermodehelper+0xc7/0xce
Oct 12 11:46:49 swdev14 kernel:  [<c012e89d>] __call_usermodehelper+0x0/0x69
Oct 12 11:46:49 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 11:46:49 swdev14 kernel:  [<c012e6e1>] request_module+0xa1/0xe5
Oct 12 11:46:49 swdev14 kernel:  [<c0134141>] __mcount+0x1d/0x21
Oct 12 11:46:49 swdev14 kernel:  [<c0164d2c>] base_probe+0xe/0x52
Oct 12 11:46:49 swdev14 kernel:  [<c01e672b>] kobj_lookup+0xf8/0x105
Oct 12 11:46:49 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 11:46:49 swdev14 kernel:  [<c0164d50>] base_probe+0x32/0x52
Oct 12 11:46:49 swdev14 kernel:  [<c01e672b>] kobj_lookup+0xf8/0x105
Oct 12 11:46:49 swdev14 kernel:  [<c0164d1e>] base_probe+0x0/0x52
Oct 12 11:46:49 swdev14 kernel:  [<c01649ff>] chrdev_open+0xf2/0x16f
Oct 12 11:46:49 swdev14 kernel:  [<c016490d>] chrdev_open+0x0/0x16f
Oct 12 11:46:49 swdev14 kernel:  [<c015aafa>] dentry_open+0x106/0x180
Oct 12 11:46:49 swdev14 kernel:  [<c015a9f2>] filp_open+0x62/0x64
Oct 12 11:46:49 swdev14 kernel:  [<c013388c>] _mutex_unlock+0xe/0x5e
Oct 12 11:46:49 swdev14 kernel:  [<c01b1bfa>] find_next_zero_bit+0x14/0xa6
Oct 12 11:46:49 swdev14 kernel:  [<c015ac04>] get_unused_fd+0x90/0xe4
Oct 12 11:46:49 swdev14 kernel:  [<c015ad58>] sys_open+0x4b/0x88
Oct 12 11:46:49 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 11:46:50 swdev14 kernel: scheduling while atomic: khelper/0x04000001/14
Oct 12 11:46:50 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 11:46:50 swdev14 kernel:  [<c029925b>] schedule+0xbaf/0xbe2
Oct 12 11:46:50 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:50 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:50 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:50 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:50 swdev14 kernel:  [<c013492a>] touch_preempt_timing+0x46/0x4a
Oct 12 11:46:50 swdev14 kernel:  [<c02996cd>] cond_resched+0x26/0x83
Oct 12 11:46:50 swdev14 kernel:  [<c029970a>] cond_resched+0x63/0x83
Oct 12 11:46:50 swdev14 kernel:  [<c0133b82>] _rw_mutex_read_lock+0x24/0x39
Oct 12 11:46:50 swdev14 kernel:  [<c011f62c>] profile_handoff_task+0x1a/0x52
Oct 12 11:46:50 swdev14 kernel:  [<c011c508>] __put_task_struct+0x66/0x119
Oct 12 11:46:50 swdev14 kernel:  [<c0298a0b>] schedule+0x35f/0xbe2
Oct 12 11:46:50 swdev14 kernel:  [<c029a35d>] _spin_unlock_irqrestore+0x1c/0x36
Oct 12 11:46:50 swdev14 kernel:  [<c013487c>] check_preempt_timing+0x191/0x1f9
Oct 12 11:46:50 swdev14 kernel:  [<c0134ae5>] sub_preempt_count+0x82/0x97
Oct 12 11:46:50 swdev14 kernel:  [<c029a35d>] _spin_unlock_irqrestore+0x1c/0x36
Oct 12 11:46:50 swdev14 kernel:  [<c012edbf>] worker_thread+0x20c/0x22a
Oct 12 11:46:50 swdev14 kernel:  [<c012e89d>] __call_usermodehelper+0x0/0x69
Oct 12 11:46:50 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 11:46:50 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 11:46:50 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 11:46:50 swdev14 kernel:  [<c0132f2b>] kthread+0xbc/0xc1
Oct 12 11:46:50 swdev14 kernel:  [<c012ebb3>] worker_thread+0x0/0x22a
Oct 12 11:46:50 swdev14 kernel:  [<c0132e6f>] kthread+0x0/0xc1
Oct 12 11:46:50 swdev14 kernel:  [<c01042c9>] kernel_thread_helper+0x5/0xb
Oct 12 11:48:12 swdev14 syslogd 1.4.1: restart.

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

* [patch] VP-2.6.9-rc4-mm1-T8
  2004-10-12 12:33     ` Ingo Molnar
  2004-10-12 13:59       ` VP-2.6.9-rc4-mm1-T7 Rui Nuno Capela
  2004-10-12 15:12       ` [patch] VP-2.6.9-rc4-mm1-T6 K.R. Foley
@ 2004-10-12 19:54       ` Ingo Molnar
  2004-10-12 20:57         ` K.R. Foley
  2004-10-13  6:15         ` [patch] VP-2.6.9-rc4-mm1-T9 Ingo Molnar
  2 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-12 19:54 UTC (permalink / raw)
  To: linux-kernel
  Cc: Fernando Pablo Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Wen-chien Jesse Sung, Mark_H_Johnson, K.R. Foley


i've uploaded the -T8 VP patch:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T8

lots of stabilization of CONFIG_PREEMPT_REALTIME. It's still in
experimental status but general stability is improving.

Changes since -T7:

 - fixed a nasty category of bugs that were introduced by the use of 
   rwsems for rwlocks. rwsems are not read-recursive, while rwlocks are. 
   Fortunately it was not too hard to identify & fix recursive users of
   tasklist_lock, in fact each of these also qualifies as a cleanup. The 
   symptom of this bug was a soft-deadlocking of the system. 

 - fixed profiler locks, i believe this could resolve the bootup crash
   reported by K.R. Foley.

 - fixed VP / XFS namespace collision reported by Mark H. Johnson

 - fix one more final detail of the new zombie-task handling code

 - fixed 3c59x.c, fasync-handling, ipv6, module-loader runtime
   warnings reported by K.R. Foley.

 - fixed the ali5451 locking

to create a -T8 tree from scratch the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T8

	Ingo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T8
  2004-10-12 19:54       ` [patch] VP-2.6.9-rc4-mm1-T8 Ingo Molnar
@ 2004-10-12 20:57         ` K.R. Foley
  2004-10-13  5:45           ` Ingo Molnar
  2004-10-13  6:15         ` [patch] VP-2.6.9-rc4-mm1-T9 Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-12 20:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela, Wen-chien Jesse Sung, Mark_H_Johnson

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

Ingo Molnar wrote:
> i've uploaded the -T8 VP patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T8
> 
> lots of stabilization of CONFIG_PREEMPT_REALTIME. It's still in
> experimental status but general stability is improving.
> 

Booted part way this time but then soft locked. Mouse was still working 
but not KB. Any idea why the KB is not working with these? I am 
rebuilding with all of the pwr managment off because I am still getting 
acpi messages in the boot :-/ I have attached the log from the boot.

kr

[-- Attachment #2: rtpreT8.dump --]
[-- Type: text/plain, Size: 39527 bytes --]

Oct 12 15:33:34 swdev14 syslogd 1.4.1: restart.
Oct 12 15:33:34 swdev14 syslog: syslogd startup succeeded
Oct 12 15:33:34 swdev14 kernel: klogd 1.4.1, log source = /proc/kmsg started.
Oct 12 15:33:34 swdev14 syslog: klogd startup succeeded
Oct 12 15:33:34 swdev14 kernel: Linux version 2.6.9-rc4-mm1-VP-T8 (aaektkf@swdev14.rkd.snds.com) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #11 SMP Tue Oct 12 15:25:18 CDT 2004
Oct 12 15:33:34 swdev14 kernel: BIOS-provided physical RAM map:
Oct 12 15:33:34 swdev14 kernel:  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
Oct 12 15:33:34 swdev14 kernel:  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
Oct 12 15:33:34 swdev14 kernel:  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
Oct 12 15:33:34 swdev14 kernel:  BIOS-e820: 0000000000100000 - 000000001ff70000 (usable)
Oct 12 15:33:34 swdev14 kernel:  BIOS-e820: 000000001ff70000 - 000000001ff77000 (ACPI data)
Oct 12 15:33:34 swdev14 kernel:  BIOS-e820: 000000001ff77000 - 000000001ff80000 (ACPI NVS)
Oct 12 15:33:34 swdev14 kernel:  BIOS-e820: 000000001ff80000 - 0000000020000000 (reserved)
Oct 12 15:33:34 swdev14 kernel:  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
Oct 12 15:33:34 swdev14 kernel:  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
Oct 12 15:33:35 swdev14 kernel:  BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
Oct 12 15:33:35 swdev14 kernel:  BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
Oct 12 15:33:35 swdev14 kernel: 0MB HIGHMEM available.
Oct 12 15:33:35 swdev14 irqbalance: irqbalance startup succeeded
Oct 12 15:33:35 swdev14 kernel: 511MB LOWMEM available.
Oct 12 15:33:35 swdev14 kernel: found SMP MP-table at 000f6b00
Oct 12 15:33:35 swdev14 kernel: DMI present.
Oct 12 15:33:35 swdev14 portmap: portmap startup succeeded
Oct 12 15:33:35 swdev14 kernel: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Oct 12 15:33:35 swdev14 kernel: Processor #0 15:2 APIC version 20
Oct 12 15:33:35 swdev14 kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
Oct 12 15:33:35 swdev14 kernel: Processor #6 15:2 APIC version 20
Oct 12 15:33:35 swdev14 kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Oct 12 15:33:35 swdev14 kernel: Processor #1 15:2 APIC version 20
Oct 12 15:33:35 swdev14 kernel: ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
Oct 12 15:33:35 swdev14 kernel: Processor #7 15:2 APIC version 20
Oct 12 15:33:35 swdev14 kernel: ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
Oct 12 15:33:35 swdev14 kernel: ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
Oct 12 15:33:35 swdev14 kernel: ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
Oct 12 15:33:35 swdev14 kernel: ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
Oct 12 15:33:35 swdev14 kernel: Using ACPI for processor (LAPIC) configuration information
Oct 12 15:33:35 swdev14 kernel: Intel MultiProcessor Specification v1.4
Oct 12 15:33:35 swdev14 kernel:     Virtual Wire compatibility mode.
Oct 12 15:33:35 swdev14 kernel: OEM ID:   Product ID: PLACER CRB   APIC at: 0xFEE00000
Oct 12 15:33:35 swdev14 kernel: I/O APIC #2 Version 32 at 0xFEC00000.
Oct 12 15:33:35 swdev14 kernel: I/O APIC #3 Version 32 at 0xFEC80000.
Oct 12 15:33:35 swdev14 kernel: I/O APIC #4 Version 32 at 0xFEC80100.
Oct 12 15:33:35 swdev14 rpc.statd[2649]: Version 1.0.6 Starting
Oct 12 15:33:35 swdev14 kernel: Enabling APIC mode:  Flat.  Using 3 I/O APICs
Oct 12 15:33:35 swdev14 kernel: Processors: 4
Oct 12 15:33:35 swdev14 kernel: Built 1 zonelists
Oct 12 15:33:35 swdev14 kernel: Initializing CPU#0
Oct 12 15:33:35 swdev14 nfslock: rpc.statd startup succeeded
Oct 12 15:33:35 swdev14 kernel: Kernel command line: ro root=LABEL=/ noapic
Oct 12 15:33:35 swdev14 kernel: (swapper/0): new 324744 us maximum-latency critical section.
Oct 12 15:33:35 swdev14 kernel:  => started at: <start_kernel+0x48/0x1c6>
Oct 12 15:33:35 swdev14 kernel:  => ended at:   <cond_resched+0x26/0x83>
Oct 12 15:33:35 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:35 swdev14 kernel:  [<c0134834>] check_preempt_timing+0x161/0x1f9
Oct 12 15:33:35 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:35 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:35 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:35 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:35 swdev14 kernel:  [<c0135c0c>] register_cpu_notifier+0x18/0x58
Oct 12 15:33:36 swdev14 kernel:  [<c01301b4>] rcu_cpu_notify+0x36/0x38
Oct 12 15:33:36 swdev14 kernel:  [<c03646c7>] rcu_init+0x70/0x74
Oct 12 15:33:36 swdev14 kernel:  [<c035485c>] start_kernel+0xb9/0x1c6
Oct 12 15:33:36 swdev14 kernel:  [<c03543b0>] unknown_bootoption+0x0/0x15d
Oct 12 15:33:36 swdev14 kernel: PID hash table entries: 2048 (order: 11, 32768 bytes)
Oct 12 15:33:36 swdev14 kernel: (swapper/0): new 354276 us maximum-latency critical section.
Oct 12 15:33:36 swdev14 rpcidmapd: rpc.idmapd startup succeeded
Oct 12 15:33:36 swdev14 kernel:  => started at: <cond_resched+0x26/0x83>
Oct 12 15:33:36 swdev14 kernel:  => ended at:   <cond_resched+0x26/0x83>
Oct 12 15:33:36 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:36 swdev14 kernel:  [<c0134834>] check_preempt_timing+0x161/0x1f9
Oct 12 15:33:36 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:36 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:36 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:36 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:36 swdev14 random: Initializing random number generator:  succeeded
Oct 12 15:33:36 swdev14 kernel:  [<c0135c0c>] register_cpu_notifier+0x18/0x58
Oct 12 15:33:36 swdev14 kernel:  [<c0128433>] timer_cpu_notify+0x25/0x27
Oct 12 15:33:36 swdev14 kernel:  [<c03643cb>] init_timers+0x34/0x54
Oct 12 15:33:36 swdev14 kernel:  [<c035486b>] start_kernel+0xc8/0x1c6
Oct 12 15:33:36 swdev14 kernel:  [<c03543b0>] unknown_bootoption+0x0/0x15d
Oct 12 15:33:36 swdev14 kernel: Detected 2592.193 MHz processor.
Oct 12 15:33:36 swdev14 kernel: Using tsc for high-res timesource
Oct 12 15:33:36 swdev14 kernel: (swapper/0): new 705817 us maximum-latency critical section.
Oct 12 15:33:36 swdev14 rc: Starting pcmcia:  succeeded
Oct 12 15:33:36 swdev14 kernel:  => started at: <cond_resched+0x26/0x83>
Oct 12 15:33:36 swdev14 kernel:  => ended at:   <cond_resched+0x26/0x83>
Oct 12 15:33:36 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:36 swdev14 kernel:  [<c0134834>] check_preempt_timing+0x161/0x1f9
Oct 12 15:33:36 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:36 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:36 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:36 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:36 swdev14 kernel:  [<c01337fe>] _mutex_lock+0x19/0x3f
Oct 12 15:33:36 swdev14 kernel:  [<c0133860>] _mutex_lock_irqsave+0x16/0x1c
Oct 12 15:33:36 swdev14 kernel:  [<c01cbdd4>] tty_register_ldisc+0x37/0xa4
Oct 12 15:33:36 swdev14 kernel:  [<c036be3e>] console_init+0x27/0x4a
Oct 12 15:33:36 swdev14 kernel:  [<c035487a>] start_kernel+0xd7/0x1c6
Oct 12 15:33:36 swdev14 kernel:  [<c03543b0>] unknown_bootoption+0x0/0x15d
Oct 12 15:33:36 swdev14 kernel: Console: colour VGA+ 80x25
Oct 12 15:33:36 swdev14 kernel: Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Oct 12 15:33:36 swdev14 kernel: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Oct 12 15:33:36 swdev14 kernel: Memory: 513504k/523712k available (1645k kernel code, 9604k reserved, 726k data, 272k init, 0k highmem)
Oct 12 15:33:36 swdev14 netfs: Mounting NFS filesystems:  succeeded
Oct 12 15:33:36 swdev14 kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok.
Oct 12 15:33:36 swdev14 kernel: Security Scaffold v1.0.0 initialized
Oct 12 15:33:36 swdev14 netfs: Mounting other filesystems:  succeeded
Oct 12 15:33:36 swdev14 kernel: Capability LSM initialized
Oct 12 15:33:36 swdev14 kernel: Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Oct 12 15:33:37 swdev14 kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Oct 12 15:33:37 swdev14 kernel: CPU: L2 cache: 512K
Oct 12 15:33:37 swdev14 kernel: CPU: Physical Processor ID: 0
Oct 12 15:33:37 swdev14 kernel: Intel machine check architecture supported.
Oct 12 15:33:37 swdev14 kernel: Intel machine check reporting enabled on CPU#0.
Oct 12 15:33:37 swdev14 kernel: CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
Oct 12 15:33:37 swdev14 kernel: Enabling fast FPU save and restore... done.
Oct 12 15:33:37 swdev14 kernel: Enabling unmasked SIMD FPU exception support... done.
Oct 12 15:33:37 swdev14 kernel: Checking 'hlt' instruction... OK.
Oct 12 15:33:37 swdev14 kernel: CPU0: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Oct 12 15:33:37 swdev14 kernel: per-CPU timeslice cutoff: 1462.71 usecs.
Oct 12 15:33:37 swdev14 kernel: task migration cache decay timeout: 2 msecs.
Oct 12 15:33:37 swdev14 kernel: Booting processor 1/1 eip 2000
Oct 12 15:33:37 swdev14 autofs: automount startup succeeded
Oct 12 15:33:37 swdev14 kernel: Initializing CPU#1
Oct 12 15:33:37 swdev14 kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Oct 12 15:33:37 swdev14 kernel: CPU: L2 cache: 512K
Oct 12 15:33:37 swdev14 smartd[2807]: smartd version 5.21 Copyright (C) 2002-3 Bruce Allen 
Oct 12 15:33:37 swdev14 kernel: CPU: Physical Processor ID: 0
Oct 12 15:33:37 swdev14 smartd[2807]: Home page is http://smartmontools.sourceforge.net/  
Oct 12 15:33:37 swdev14 smartd[2807]: Opened configuration file /etc/smartd.conf 
Oct 12 15:33:37 swdev14 kernel: Intel machine check architecture supported.
Oct 12 15:33:37 swdev14 smartd[2807]: Configuration file /etc/smartd.conf parsed. 
Oct 12 15:33:37 swdev14 smartd[2807]: Device: /dev/hda, opened 
Oct 12 15:33:37 swdev14 kernel: Intel machine check reporting enabled on CPU#1.
Oct 12 15:33:37 swdev14 kernel: CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
Oct 12 15:33:37 swdev14 kernel: CPU1: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Oct 12 15:33:37 swdev14 kernel: Booting processor 2/6 eip 2000
Oct 12 15:33:37 swdev14 smartd[2807]: Device: /dev/hda, not found in smartd database. 
Oct 12 15:33:37 swdev14 kernel: Initializing CPU#2
Oct 12 15:33:37 swdev14 smartd[2807]: Device: /dev/hda, is SMART capable. Adding to "monitor" list. 
Oct 12 15:33:37 swdev14 smartd[2807]: Monitoring 1 ATA and 0 SCSI devices 
Oct 12 15:33:37 swdev14 kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Oct 12 15:33:37 swdev14 smartd[2809]: smartd has fork()ed into background mode. New PID=2809. 
Oct 12 15:33:37 swdev14 kernel: CPU: L2 cache: 512K
Oct 12 15:33:37 swdev14 smartd: smartd startup succeeded
Oct 12 15:33:37 swdev14 kernel: CPU: Physical Processor ID: 3
Oct 12 15:33:38 swdev14 kernel: Intel machine check architecture supported.
Oct 12 15:33:38 swdev14 kernel: Intel machine check reporting enabled on CPU#2.
Oct 12 15:33:38 swdev14 kernel: CPU2: Intel P4/Xeon Extended MCE MSRs (12) available
Oct 12 15:33:38 swdev14 kernel: CPU2: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Oct 12 15:33:38 swdev14 kernel: Booting processor 3/7 eip 2000
Oct 12 15:33:38 swdev14 kernel: Initializing CPU#3
Oct 12 15:33:38 swdev14 kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Oct 12 15:33:38 swdev14 sshd:  succeeded
Oct 12 15:33:38 swdev14 kernel: CPU: L2 cache: 512K
Oct 12 15:33:38 swdev14 kernel: CPU: Physical Processor ID: 3
Oct 12 15:33:38 swdev14 kernel: Intel machine check architecture supported.
Oct 12 15:33:38 swdev14 kernel: Intel machine check reporting enabled on CPU#3.
Oct 12 15:33:38 swdev14 kernel: CPU3: Intel P4/Xeon Extended MCE MSRs (12) available
Oct 12 15:33:38 swdev14 kernel: CPU3: Intel(R) Xeon(TM) CPU 2.60GHz stepping 07
Oct 12 15:33:38 swdev14 kernel: Total of 4 processors activated (20594.68 BogoMIPS).
Oct 12 15:33:38 swdev14 kernel: checking TSC synchronization across 4 CPUs: 
Oct 12 15:33:38 swdev14 kernel: CPU#0 had 0 usecs TSC skew, fixed it up.
Oct 12 15:33:38 swdev14 kernel: CPU#2 had 0 usecs TSC skeFlag at 0x36 set to 0x1
Oct 12 15:33:38 swdev14 kernel: apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
Oct 12 15:33:38 swdev14 xinetd: xinetd startup succeeded
Oct 12 15:33:38 swdev14 kernel: apm: disabled - APM is not SMP safe.
Oct 12 15:33:38 swdev14 kernel: VFS: Disk quotas dquot_6.5.1
Oct 12 15:33:38 swdev14 kernel: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Oct 12 15:33:38 swdev14 kernel: Initializing Cryptographic API
Oct 12 15:33:38 swdev14 kernel: vesafb: probe of vesafb0 failed with error -6
Oct 12 15:33:38 swdev14 kernel: isapnp: Scanning for PnP cards...
Oct 12 15:33:38 swdev14 kernel: isapnp: No Plug & Play device found
Oct 12 15:33:38 swdev14 kernel: requesting new irq thread for IRQ8...
Oct 12 15:33:38 swdev14 kernel: Real Time Clock Driver v1.12
Oct 12 15:33:38 swdev14 kernel: requesting new irq thread for IRQ12...
Oct 12 15:33:38 swdev14 kernel: Failed to disable AUX port, but continuing anyway... Is this a SiS?
Oct 12 15:33:38 swdev14 kernel: If AUX port is really absent please use the 'i8042.noaux' option.
Oct 12 15:33:38 swdev14 kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
Oct 12 15:33:38 swdev14 kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Oct 12 15:33:38 swdev14 ntpdate[2873]: can't find host wizard 
Oct 12 15:33:38 swdev14 kernel: io scheduler noop registered
Oct 12 15:33:39 swdev14 kernel: io scheduler anticipatory registered
Oct 12 15:33:39 swdev14 kernel: io scheduler deadline registered
Oct 12 15:33:39 swdev14 kernel: io scheduler cfq registered
Oct 12 15:33:39 swdev14 kernel: RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Oct 12 15:33:39 swdev14 kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
Oct 12 15:33:39 swdev14 kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Oct 12 15:33:39 swdev14 kernel: ICH4: IDE controller at PCI slot 0000:00:1f.1
Oct 12 15:33:39 swdev14 kernel: PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
Oct 12 15:33:39 swdev14 kernel: ICH4: chipset revision 2
Oct 12 15:33:39 swdev14 kernel: ICH4: not 100%% native mode: will probe irqs later
Oct 12 15:33:39 swdev14 kernel:     ide0: BM-DMA at 0x1460-0x1467, BIOS settings: hda:DMA, hdb:pio
Oct 12 15:33:39 swdev14 kernel:     ide1: BM-DMA at 0x1468-0x146f, BIOS settings: hdc:DMA, hdd:pio
Oct 12 15:33:39 swdev14 kernel: hda: WDC WD800BB-75CAA0, ATA DISK drive
Oct 12 15:33:39 swdev14 kernel: requesting new irq thread for IRQ14...
Oct 12 15:33:39 swdev14 kernel: elevator: using anticipatory as default io scheduler
Oct 12 15:33:39 swdev14 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Oct 12 15:33:39 swdev14 kernel: hdc: SONY DVD RW DW-U18A, ATAPI CD/DVD-ROM drive
Oct 12 15:33:39 swdev14 kernel: requesting new irq thread for IRQ15...
Oct 12 15:33:39 swdev14 kernel: ide1 at 0x170-0x177,0x376 on irq 15
Oct 12 15:33:39 swdev14 kernel: hda: max request size: 128KiB
Oct 12 15:33:39 swdev14 kernel: IRQ#14 thread started up.
Oct 12 15:33:39 swdev14 kernel: hda: Host Protected Area detected.
Oct 12 15:33:39 swdev14 kernel: ^Icurrent capacity is 156250000 sectors (80000 MB)
Oct 12 15:33:39 swdev14 kernel: ^Inative  capacity is 156301488 sectors (80026 MB)
Oct 12 15:33:39 swdev14 kernel: hda: Host Protected Area disabled.
Oct 12 15:33:39 swdev14 kernel: hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
Oct 12 15:33:39 swdev14 kernel:  hda: hda1 hda2 < hda5 hda6 hda7 >
Oct 12 15:33:39 swdev14 kernel: mice: PS/2 mouse device common for all mice
Oct 12 15:33:39 swdev14 kernel: IRQ#12 thread started up.
Oct 12 15:33:39 swdev14 kernel: requesting new irq thread for IRQ1...
Oct 12 15:33:39 swdev14 kernel: IRQ#1 thread started up.
Oct 12 15:33:39 swdev14 kernel: input: AT Translated Set 2 keyboard on isa0060/serio0
Oct 12 15:33:39 swdev14 kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
Oct 12 15:33:39 swdev14 kernel: NET: Registered protocol family 2
Oct 12 15:33:39 swdev14 kernel: IP: routing cache hash table of 2048 buckets, 32Kbytes
Oct 12 15:33:39 swdev14 kernel: TCP: Hash tables configured (established 16384 bind 21845)
Oct 12 15:33:39 swdev14 kernel: NET: Registered protocol family 1
Oct 12 15:33:39 swdev14 kernel: NET: Registered protocol family 17
Oct 12 15:33:39 swdev14 kernel: NET: Registered protocol family 8
Oct 12 15:33:39 swdev14 kernel: NET: Registered protocol family 20
Oct 12 15:33:39 swdev14 kernel: Starting balanced_irq
Oct 12 15:33:39 swdev14 kernel: md: Autodetecting RAID arrays.
Oct 12 15:33:39 swdev14 kernel: md: autorun ...
Oct 12 15:33:39 swdev14 kernel: md: ... autorun DONE.
Oct 12 15:33:39 swdev14 kernel: RAMDISK: Compressed image found at block 0
Oct 12 15:33:39 swdev14 kernel: VFS: Mounted root (ext2 filesystem).
Oct 12 15:33:39 swdev14 kernel: kjournald starting.  Commit interval 5 seconds
Oct 12 15:33:39 swdev14 kernel: EXT3-fs: mounted filesystem with ordered data mode.
Oct 12 15:33:39 swdev14 kernel: Freeing unused kernel memory: 272k freed
Oct 12 15:33:39 swdev14 kernel: IRQ#8 thread started up.
Oct 12 15:33:39 swdev14 kernel: usbcore: registered new driver usbfs
Oct 12 15:33:39 swdev14 kernel: usbcore: registered new driver hub
Oct 12 15:33:39 swdev14 kernel: USB Universal Host Controller Interface driver v2.2
Oct 12 15:33:39 swdev14 kernel: uhci_hcd 0000:00:1d.0: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1
Oct 12 15:33:39 swdev14 kernel: requesting new irq thread for IRQ11...
Oct 12 15:33:39 swdev14 kernel: uhci_hcd 0000:00:1d.0: irq 11, io base 0x1400
Oct 12 15:33:39 swdev14 kernel: uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
Oct 12 15:33:39 swdev14 kernel: hub 1-0:1.0: USB hub found
Oct 12 15:33:39 swdev14 kernel: hub 1-0:1.0: 2 ports detected
Oct 12 15:33:39 swdev14 kernel: uhci_hcd 0000:00:1d.1: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2
Oct 12 15:33:39 swdev14 kernel: requesting new irq thread for IRQ10...
Oct 12 15:33:39 swdev14 kernel: uhci_hcd 0000:00:1d.1: irq 10, io base 0x1420
Oct 12 15:33:39 swdev14 kernel: uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
Oct 12 15:33:39 swdev14 kernel: hub 2-0:1.0: USB hub found
Oct 12 15:33:39 swdev14 kernel: hub 2-0:1.0: 2 ports detected
Oct 12 15:33:39 swdev14 kernel: uhci_hcd 0000:00:1d.2: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3
Oct 12 15:33:39 swdev14 kernel: requesting new irq thread for IRQ5...
Oct 12 15:33:39 swdev14 kernel: uhci_hcd 0000:00:1d.2: irq 5, io base 0x1440
Oct 12 15:33:39 swdev14 kernel: uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
Oct 12 15:33:39 swdev14 kernel: hub 3-0:1.0: USB hub found
Oct 12 15:33:39 swdev14 kernel: hub 3-0:1.0: 2 ports detected
Oct 12 15:33:39 swdev14 kernel: usb 1-2: new low speed USB device using address 2
Oct 12 15:33:39 swdev14 kernel: IRQ#11 thread started up.
Oct 12 15:33:39 swdev14 kernel: input: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse® Optical] on usb-0000:00:1d.0-2
Oct 12 15:33:39 swdev14 kernel: usbcore: registered new driver usbhid
Oct 12 15:33:39 swdev14 kernel: drivers/usb/input/hid-core.c: v2.0:USB HID core driver
Oct 12 15:33:39 swdev14 kernel: EXT3 FS on hda6, internal journal
Oct 12 15:33:39 swdev14 kernel: device-mapper: 4.1.0-ioctl (2003-12-10) initialised: dm@uk.sistina.com
Oct 12 15:33:39 swdev14 kernel: Adding 2048216k swap on /dev/hda5.  Priority:-1 extents:1
Oct 12 15:33:39 swdev14 kernel: kjournald starting.  Commit interval 5 seconds
Oct 12 15:33:39 swdev14 kernel: EXT3 FS on hda1, internal journal
Oct 12 15:33:39 swdev14 kernel: EXT3-fs: mounted filesystem with ordered data mode.
Oct 12 15:33:39 swdev14 kernel: kjournald starting.  Commit interval 5 seconds
Oct 12 15:33:39 swdev14 kernel: EXT3 FS on hda7, internal journal
Oct 12 15:33:39 swdev14 kernel: EXT3-fs: mounted filesystem with ordered data mode.
Oct 12 15:33:39 swdev14 kernel: IA-32 Microcode Update Driver: v1.14 <tigran@veritas.com>
Oct 12 15:33:39 swdev14 kernel: microcode: No suitable data for CPU0
Oct 12 15:33:39 swdev14 kernel: microcode: No suitable data for CPU2
Oct 12 15:33:39 swdev14 kernel: microcode: No suitable data for CPU3
Oct 12 15:33:39 swdev14 kernel: microcode: No suitable data for CPU1
Oct 12 15:33:39 swdev14 kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
Oct 12 15:33:39 swdev14 kernel: parport0: irq 7 detected
Oct 12 15:33:39 swdev14 kernel: SCSI subsystem initialized
Oct 12 15:33:39 swdev14 kernel: inserting floppy driver for 2.6.9-rc4-mm1-VP-T8
Oct 12 15:33:39 swdev14 kernel: Floppy drive(s): fd0 is 1.44M
Oct 12 15:33:39 swdev14 kernel: requesting new irq thread for IRQ6...
Oct 12 15:33:39 swdev14 kernel: IRQ#6 thread started up.
Oct 12 15:33:39 swdev14 kernel: FDC 0 is a National Semiconductor PC87306
Oct 12 15:33:39 swdev14 kernel: tg3.c:v3.10 (September 14, 2004)
Oct 12 15:33:39 swdev14 kernel: eth0: Tigon3 [partno(BCM95702A20) rev 1002 PHY(5703)] (PCI:66MHz:32-bit) 10/100/1000BaseT Ethernet 00:50:45:00:9b:33
Oct 12 15:33:39 swdev14 kernel: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] 
Oct 12 15:33:39 swdev14 kernel: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
Oct 12 15:33:39 swdev14 kernel: 0000:05:01.0: 3Com PCI 3c905C Tornado at 0x2000. Vers LK1.1.19
Oct 12 15:33:39 swdev14 kernel: IRQ#15 thread started up.
Oct 12 15:33:39 swdev14 kernel: hdc: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Oct 12 15:33:39 swdev14 kernel: Uniform CD-ROM driver Revision: 3.20
Oct 12 15:33:39 swdev14 kernel: ip_tables: (C) 2000-2002 Netfilter core team
Oct 12 15:33:39 swdev14 kernel: NET: Registered protocol family 10
Oct 12 15:33:39 swdev14 kernel: IPv6 over IPv4 tunneling driver
Oct 12 15:33:40 swdev14 kernel: ------------[ cut here ]------------
Oct 12 15:33:40 swdev14 kernel: kernel BUG at kernel/mutex.c:185!
Oct 12 15:33:40 swdev14 kernel: invalid operand: 0000 [#1]
Oct 12 15:33:40 swdev14 kernel: PREEMPT SMP 
Oct 12 15:33:40 swdev14 kernel: Modules linked in: ipv6 autofs4 nfs lockd sunrpc iptable_filter ip_tables ide_cd cdrom 3c59x mii tg3 floppy sg scsi_mod parport_pc parport microcode dm_mod evdev usbhid uhci_hcd usbcore ext3 jbd
Oct 12 15:33:40 swdev14 kernel: CPU:    0
Oct 12 15:33:40 swdev14 kernel: EIP:    0060:[<c0133ba4>]    Not tainted VLI
Oct 12 15:33:40 swdev14 kernel: EFLAGS: 00010246   (2.6.9-rc4-mm1-VP-T8) 
Oct 12 15:33:40 swdev14 kernel: EIP is at _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:40 swdev14 kernel: eax: 00000000   ebx: 00000000   ecx: c0350f80   edx: c1406b80
Oct 12 15:33:40 swdev14 kernel: esi: da261ac8   edi: da7b1814   ebp: de661f18   esp: de661f18
Oct 12 15:33:40 swdev14 kernel: ds: 007b   es: 007b   ss: 0068   preempt: 00000002
Oct 12 15:33:40 swdev14 kernel: Process sshd (pid: 2835, threadinfo=de660000 task=debaea80)
Oct 12 15:33:40 swdev14 kernel: Stack: de661f44 c0253738 c0350f80 00000016 c029a33a c16caa80 da261c94 da261bfc 
Oct 12 15:33:40 swdev14 kernel:        c16caa80 da261a80 ffffffea de661f5c c0275a8c da261a80 00000005 c16caa80 
Oct 12 15:33:40 swdev14 kernel:        00000003 de661f78 c02287ea c16caa80 00000005 00000000 00000004 08090bf0 
Oct 12 15:33:40 swdev14 kernel: Call Trace:
Oct 12 15:33:40 swdev14 kernel:  [<c0253738>] tcp_listen_start+0x175/0x1d1
Oct 12 15:33:40 swdev14 kernel:  [<c029a33a>] _spin_unlock_bh+0x1a/0x34
Oct 12 15:33:40 swdev14 kernel:  [<c0275a8c>] inet_listen+0x65/0x7a
Oct 12 15:33:40 swdev14 kernel:  [<c02287ea>] sys_listen+0x5c/0x74
Oct 12 15:33:40 swdev14 kernel:  [<c02294a4>] sys_socketcall+0xb1/0x239
Oct 12 15:33:40 swdev14 kernel:  [<c015ae81>] sys_close+0x75/0x91
Oct 12 15:33:40 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 15:33:40 swdev14 kernel: Code: 75 fc 89 ec 5d c3 55 89 e5 e8 39 fb fd ff 8b 4d 08 8b 01 85 c0 74 14 8d 41 04 ba ff ff 00 00 f0 0f c1 10 0f 85 6e 03 00 00 5d c3 <0f> 0b b9 00 9a c6 2a c0 eb e2 55 89 e5 e8 0a fb fd ff 8b 4d 08 
Oct 12 15:33:40 swdev14 kernel:  <3>scheduling while atomic: sshd/0x04000001/2835
Oct 12 15:33:40 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c02991cf>] schedule+0xbaf/0xbe2
Oct 12 15:33:40 swdev14 kernel:  [<c029967e>] cond_resched+0x63/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:40 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c0134864>] check_preempt_timing+0x191/0x1f9
Oct 12 15:33:40 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:40 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c029967e>] cond_resched+0x63/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c011f5c8>] profile_task_exit+0x18/0x56
Oct 12 15:33:40 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 15:33:40 swdev14 kernel:  [<c01216e0>] do_exit+0x1f/0x3bd
Oct 12 15:33:40 swdev14 kernel:  [<c0299213>] preempt_schedule+0x11/0x7a
Oct 12 15:33:40 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 15:33:40 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 15:33:40 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 15:33:40 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 15:33:40 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:40 swdev14 kernel:  [<c0134129>] __mcount+0x1d/0x21
Oct 12 15:33:40 swdev14 kernel:  [<c029a11e>] _write_lock+0x1b/0x76
Oct 12 15:33:40 swdev14 kernel:  [<c026436e>] tcp_listen_wlock+0x16/0xac
Oct 12 15:33:40 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 15:33:40 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 15:33:40 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:40 swdev14 kernel:  [<c0253738>] tcp_listen_start+0x175/0x1d1
Oct 12 15:33:40 swdev14 kernel:  [<c029a33a>] _spin_unlock_bh+0x1a/0x34
Oct 12 15:33:40 swdev14 kernel:  [<c0275a8c>] inet_listen+0x65/0x7a
Oct 12 15:33:40 swdev14 kernel:  [<c02287ea>] sys_listen+0x5c/0x74
Oct 12 15:33:40 swdev14 kernel:  [<c02294a4>] sys_socketcall+0xb1/0x239
Oct 12 15:33:40 swdev14 kernel:  [<c015ae81>] sys_close+0x75/0x91
Oct 12 15:33:40 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 15:33:40 swdev14 kernel: note: sshd[2835] exited with preempt_count 1
Oct 12 15:33:40 swdev14 kernel: scheduling while atomic: sshd/0x04000001/2835
Oct 12 15:33:40 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c02991cf>] schedule+0xbaf/0xbe2
Oct 12 15:33:40 swdev14 kernel:  [<c029967e>] cond_resched+0x63/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:40 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c0134864>] check_preempt_timing+0x191/0x1f9
Oct 12 15:33:40 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:40 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c029967e>] cond_resched+0x63/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c014b7e5>] unmap_vmas+0x190/0x29b
Oct 12 15:33:40 swdev14 kernel:  [<c0150037>] exit_mmap+0xb2/0x1cc
Oct 12 15:33:40 swdev14 kernel:  [<c011c96d>] mmput+0x3b/0xb9
Oct 12 15:33:40 swdev14 kernel:  [<c01217ef>] do_exit+0x12e/0x3bd
Oct 12 15:33:40 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 15:33:40 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 15:33:40 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 15:33:40 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 15:33:40 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:40 swdev14 kernel:  [<c0134129>] __mcount+0x1d/0x21
Oct 12 15:33:40 swdev14 kernel:  [<c029a11e>] _write_lock+0x1b/0x76
Oct 12 15:33:40 swdev14 kernel:  [<c026436e>] tcp_listen_wlock+0x16/0xac
Oct 12 15:33:40 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 15:33:40 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 15:33:40 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:40 swdev14 kernel:  [<c0253738>] tcp_listen_start+0x175/0x1d1
Oct 12 15:33:40 swdev14 kernel:  [<c029a33a>] _spin_unlock_bh+0x1a/0x34
Oct 12 15:33:40 swdev14 kernel:  [<c0275a8c>] inet_listen+0x65/0x7a
Oct 12 15:33:40 swdev14 kernel:  [<c02287ea>] sys_listen+0x5c/0x74
Oct 12 15:33:40 swdev14 kernel:  [<c02294a4>] sys_socketcall+0xb1/0x239
Oct 12 15:33:40 swdev14 kernel:  [<c015ae81>] sys_close+0x75/0x91
Oct 12 15:33:40 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 15:33:40 swdev14 kernel: scheduling while atomic: sshd/0x04000001/2835
Oct 12 15:33:40 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c02991cf>] schedule+0xbaf/0xbe2
Oct 12 15:33:40 swdev14 kernel:  [<c029967e>] cond_resched+0x63/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:40 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c0134864>] check_preempt_timing+0x191/0x1f9
Oct 12 15:33:40 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:40 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c029967e>] cond_resched+0x63/0x83
Oct 12 15:33:40 swdev14 kernel:  [<c014b7e5>] unmap_vmas+0x190/0x29b
Oct 12 15:33:40 swdev14 kernel:  [<c0150037>] exit_mmap+0xb2/0x1cc
Oct 12 15:33:40 swdev14 kernel:  [<c011c96d>] mmput+0x3b/0xb9
Oct 12 15:33:40 swdev14 kernel:  [<c01217ef>] do_exit+0x12e/0x3bd
Oct 12 15:33:40 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 15:33:40 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 15:33:40 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 15:33:40 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 15:33:40 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:40 swdev14 kernel:  [<c0134129>] __mcount+0x1d/0x21
Oct 12 15:33:40 swdev14 kernel:  [<c029a11e>] _write_lock+0x1b/0x76
Oct 12 15:33:40 swdev14 kernel:  [<c026436e>] tcp_listen_wlock+0x16/0xac
Oct 12 15:33:40 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 15:33:40 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 15:33:40 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:40 swdev14 kernel:  [<c0253738>] tcp_listen_start+0x175/0x1d1
Oct 12 15:33:41 swdev14 kernel:  [<c029a33a>] _spin_unlock_bh+0x1a/0x34
Oct 12 15:33:41 swdev14 kernel:  [<c0275a8c>] inet_listen+0x65/0x7a
Oct 12 15:33:41 swdev14 kernel:  [<c02287ea>] sys_listen+0x5c/0x74
Oct 12 15:33:41 swdev14 kernel:  [<c02294a4>] sys_socketcall+0xb1/0x239
Oct 12 15:33:41 swdev14 kernel:  [<c015ae81>] sys_close+0x75/0x91
Oct 12 15:33:41 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 15:33:41 swdev14 kernel: scheduling while atomic: sshd/0x04000001/2835
Oct 12 15:33:41 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 15:33:41 swdev14 kernel:  [<c02991cf>] schedule+0xbaf/0xbe2
Oct 12 15:33:41 swdev14 kernel:  [<c029967e>] cond_resched+0x63/0x83
Oct 12 15:33:41 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:41 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:41 swdev14 kernel:  [<c0134864>] check_preempt_timing+0x191/0x1f9
Oct 12 15:33:41 swdev14 kernel:  [<c0134912>] touch_preempt_timing+0x46/0x4a
Oct 12 15:33:41 swdev14 kernel:  [<c0299641>] cond_resched+0x26/0x83
Oct 12 15:33:41 swdev14 kernel:  [<c029967e>] cond_resched+0x63/0x83
Oct 12 15:33:41 swdev14 kernel:  [<c014b7e5>] unmap_vmas+0x190/0x29b
Oct 12 15:33:41 swdev14 kernel:  [<c0150037>] exit_mmap+0xb2/0x1cc
Oct 12 15:33:41 swdev14 kernel:  [<c011c96d>] mmput+0x3b/0xb9
Oct 12 15:33:41 swdev14 kernel:  [<c01217ef>] do_exit+0x12e/0x3bd
Oct 12 15:33:41 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 15:33:41 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 15:33:41 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 15:33:41 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 15:33:41 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:41 swdev14 kernel:  [<c0134129>] __mcount+0x1d/0x21
Oct 12 15:33:41 swdev14 kernel:  [<c029a11e>] _write_lock+0x1b/0x76
Oct 12 15:33:41 swdev14 kernel:  [<c026436e>] tcp_listen_wlock+0x16/0xac
Oct 12 15:33:41 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 15:33:41 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 15:33:41 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:41 swdev14 kernel:  [<c0253738>] tcp_listen_start+0x175/0x1d1
Oct 12 15:33:41 swdev14 kernel:  [<c029a33a>] _spin_unlock_bh+0x1a/0x34
Oct 12 15:33:41 swdev14 kernel:  [<c0275a8c>] inet_listen+0x65/0x7a
Oct 12 15:33:41 swdev14 kernel:  [<c02287ea>] sys_listen+0x5c/0x74
Oct 12 15:33:41 swdev14 kernel:  [<c02294a4>] sys_socketcall+0xb1/0x239
Oct 12 15:33:41 swdev14 kernel:  [<c015ae81>] sys_close+0x75/0x91
Oct 12 15:33:41 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 15:33:41 swdev14 kernel: scheduling while atomic: sshd/0x04000001/2835
Oct 12 15:33:41 swdev14 kernel: caller is cond_resched+0x63/0x83
Oct 12 15:33:41 swdev14 kernel:  [<c02991cf>] schedule+0xbaf/0xbe2
Oct 12 15:33:41 swdev14 kernel:  [<c029967e>] cond_resched+0x63/0x83
Oct 12 15:33:41 swdev14 kernel:  [<c0113d1c>] smp_apic_timer_interrupt+0x79/0xe4
Oct 12 15:33:41 swdev14 kernel:  [<c0134914>] touch_preempt_timing+0x48/0x4a
Oct 12 15:33:41 swdev14 kernel:  [<c0106bb6>] apic_timer_interrupt+0x1a/0x20
Oct 12 15:33:41 swdev14 kernel:  [<c0134914>] touch_preempt_timing+0x48/0x4a
Oct 12 15:33:41 swdev14 kernel:  [<c029967e>] cond_resched+0x63/0x83
Oct 12 15:33:41 swdev14 kernel:  [<c014dfa3>] remove_vm_struct+0x1f/0x9f
Oct 12 15:33:41 swdev14 kernel:  [<c01500f7>] exit_mmap+0x172/0x1cc
Oct 12 15:33:41 swdev14 kernel:  [<c011c96d>] mmput+0x3b/0xb9
Oct 12 15:33:41 swdev14 kernel:  [<c01217ef>] do_exit+0x12e/0x3bd
Oct 12 15:33:41 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 15:33:41 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 15:33:41 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 15:33:41 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 15:33:41 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:41 swdev14 kernel:  [<c0134129>] __mcount+0x1d/0x21
Oct 12 15:33:41 swdev14 kernel:  [<c029a11e>] _write_lock+0x1b/0x76
Oct 12 15:33:41 swdev14 kernel:  [<c026436e>] tcp_listen_wlock+0x16/0xac
Oct 12 15:33:41 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 15:33:41 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 15:33:41 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:41 swdev14 kernel:  [<c0253738>] tcp_listen_start+0x175/0x1d1
Oct 12 15:33:41 swdev14 kernel:  [<c029a33a>] _spin_unlock_bh+0x1a/0x34
Oct 12 15:33:41 swdev14 kernel:  [<c0275a8c>] inet_listen+0x65/0x7a
Oct 12 15:33:41 swdev14 kernel:  [<c02287ea>] sys_listen+0x5c/0x74
Oct 12 15:33:41 swdev14 kernel:  [<c02294a4>] sys_socketcall+0xb1/0x239
Oct 12 15:33:41 swdev14 kernel:  [<c015ae81>] sys_close+0x75/0x91
Oct 12 15:33:41 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 15:33:41 swdev14 kernel: scheduling while atomic: sshd/0x00000001/2835
Oct 12 15:33:41 swdev14 kernel: caller is __down+0x8a/0x107
Oct 12 15:33:41 swdev14 kernel:  [<c02991cf>] schedule+0xbaf/0xbe2
Oct 12 15:33:41 swdev14 kernel:  [<c02983fe>] __down+0x8a/0x107
Oct 12 15:33:41 swdev14 kernel:  [<c0134129>] __mcount+0x1d/0x21
Oct 12 15:33:41 swdev14 kernel:  [<c0134129>] __mcount+0x1d/0x21
Oct 12 15:33:41 swdev14 kernel:  [<c029a2c0>] _spin_unlock_irqrestore+0xb/0x36
Oct 12 15:33:41 swdev14 kernel:  [<c02983f9>] __down+0x85/0x107
Oct 12 15:33:41 swdev14 kernel:  [<c01136d4>] mcount+0x14/0x18
Oct 12 15:33:41 swdev14 kernel:  [<c02983fe>] __down+0x8a/0x107
Oct 12 15:33:41 swdev14 kernel:  [<c011a368>] default_wake_function+0x0/0x1c
Oct 12 15:33:41 swdev14 kernel:  [<c02985c4>] __down_failed+0x8/0xc
Oct 12 15:33:41 swdev14 kernel:  [<c011c3cc>] .text.lock.sched+0x5/0x15
Oct 12 15:33:41 swdev14 kernel:  [<c01ccb0d>] disassociate_ctty+0x1d/0x16d
Oct 12 15:33:41 swdev14 kernel:  [<c01218d9>] do_exit+0x218/0x3bd
Oct 12 15:33:41 swdev14 kernel:  [<c0107780>] do_invalid_op+0x0/0x10b
Oct 12 15:33:41 swdev14 kernel:  [<c01073e2>] do_divide_error+0x0/0x131
Oct 12 15:33:41 swdev14 kernel:  [<c0117898>] fixup_exception+0x1c/0x38
Oct 12 15:33:41 swdev14 kernel:  [<c0107889>] do_invalid_op+0x109/0x10b
Oct 12 15:33:41 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:41 swdev14 kernel:  [<c0134129>] __mcount+0x1d/0x21
Oct 12 15:33:41 swdev14 kernel:  [<c029a11e>] _write_lock+0x1b/0x76
Oct 12 15:33:41 swdev14 kernel:  [<c026436e>] tcp_listen_wlock+0x16/0xac
Oct 12 15:33:41 swdev14 kernel:  [<c0106c31>] error_code+0x2d/0x38
Oct 12 15:33:41 swdev14 kernel:  [<c011007b>] generic_set_mtrr+0x68/0x9c
Oct 12 15:33:41 swdev14 kernel:  [<c0133ba4>] _rw_mutex_write_unlock+0x25/0x2f
Oct 12 15:33:41 swdev14 kernel:  [<c0253738>] tcp_listen_start+0x175/0x1d1
Oct 12 15:33:41 swdev14 kernel:  [<c029a33a>] _spin_unlock_bh+0x1a/0x34
Oct 12 15:33:41 swdev14 kernel:  [<c0275a8c>] inet_listen+0x65/0x7a
Oct 12 15:33:41 swdev14 kernel:  [<c02287ea>] sys_listen+0x5c/0x74
Oct 12 15:33:41 swdev14 kernel:  [<c02294a4>] sys_socketcall+0xb1/0x239
Oct 12 15:33:41 swdev14 kernel:  [<c015ae81>] sys_close+0x75/0x91
Oct 12 15:33:41 swdev14 kernel:  [<c0106175>] sysenter_past_esp+0x52/0x71
Oct 12 15:33:47 swdev14 ntpdate[2873]: step time server 159.82.80.54 offset -0.490683 sec
Oct 12 15:33:47 swdev14 ntpd:  succeeded
Oct 12 15:33:47 swdev14 ntpd[2877]: ntpd 4.2.0@1.1161-r Thu Mar 11 11:46:39 EST 2004 (1)
Oct 12 15:33:47 swdev14 ntpd: ntpd startup succeeded
Oct 12 15:33:47 swdev14 ntpd[2877]: precision = 1.000 usec
Oct 12 15:33:47 swdev14 ntpd[2877]: kernel time sync status 0040
Oct 12 15:33:47 swdev14 ntpd[2877]: configure: keyword "opus" unknown, line ignored
Oct 12 15:33:47 swdev14 ntpd[2877]: configure: keyword "hal" unknown, line ignored
Oct 12 15:33:47 swdev14 ntpd[2877]: configure: keyword "wizard" unknown, line ignored
Oct 12 15:33:47 swdev14 ntpd[2877]: configure: keyword "time1.utc.com" unknown, line ignored
Oct 12 15:33:47 swdev14 ntpd[2877]: configure: keyword "time2.utc.com" unknown, line ignored
Oct 12 15:33:47 swdev14 ntpd[2877]: configure: keyword "time3.utc.com" unknown, line ignored
Oct 12 15:33:47 swdev14 vsftpd: vsftpd vsftpd succeeded
Oct 12 15:33:47 swdev14 ntpd[2877]: frequency initialized 117.670 PPM from /var/lib/ntp/drift
Oct 12 15:33:47 swdev14 ntpd[2877]: configure: keyword "authenticate" unknown, line ignored
Oct 12 15:33:47 swdev14 gpm[2896]: *** info [startup.c(95)]: 
Oct 12 15:33:47 swdev14 gpm[2896]: Started gpm successfully. Entered daemon mode.
Oct 12 15:33:47 swdev14 gpm[2896]: *** info [mice.c(1766)]: 
Oct 12 15:33:47 swdev14 gpm[2896]: imps2: Auto-detected intellimouse PS/2
Oct 12 15:33:48 swdev14 gpm: gpm startup succeeded
Oct 12 15:33:48 swdev14 crond: crond startup succeeded
Oct 12 15:33:50 swdev14 kernel: lp0: using parport0 (polling).
Oct 12 15:33:50 swdev14 kernel: lp0: console ready
Oct 12 15:36:04 swdev14 syslogd 1.4.1: restart.

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

* Re: [patch] VP-2.6.9-rc4-mm1-T8
  2004-10-12 20:57         ` K.R. Foley
@ 2004-10-13  5:45           ` Ingo Molnar
  2004-10-13 14:00             ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-13  5:45 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela, Wen-chien Jesse Sung, Mark_H_Johnson


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

> Booted part way this time but then soft locked. [...]

the soft lock it seems was due to a mutex assert in the TCP code. Now i
see that you have the ipv6 module loaded. Would it be possible to
disable ipv6 briefly, to see whether there are other issues?

> Mouse was still working but not KB. Any idea why the KB is not working
> with these? I am rebuilding with all of the pwr managment off because
> I am still getting acpi messages in the boot :-/ [...]

hm, the keyboard should be working - i have not seen any specific
keyboard problems with PREEMPT_REALTIME enabled (except in the very
early stages of this feature). So it must be something else. Is this a
PS2 or an USB keyboard?

> Oct 12 15:33:39 swdev14 kernel: NET: Registered protocol family 10
> Oct 12 15:33:39 swdev14 kernel: IPv6 over IPv4 tunneling driver
> Oct 12 15:33:40 swdev14 kernel: ------------[ cut here ]------------
> Oct 12 15:33:40 swdev14 kernel: kernel BUG at kernel/mutex.c:185!

> Oct 12 15:33:40 swdev14 kernel: EIP is at _rw_mutex_write_unlock+0x25/0x2f

> Oct 12 15:33:40 swdev14 kernel: Call Trace:
> Oct 12 15:33:40 swdev14 kernel:  [<c0253738>] tcp_listen_start+0x175/0x1d1
> Oct 12 15:33:40 swdev14 kernel:  [<c029a33a>] _spin_unlock_bh+0x1a/0x34
> Oct 12 15:33:40 swdev14 kernel:  [<c0275a8c>] inet_listen+0x65/0x7a
> Oct 12 15:33:40 swdev14 kernel:  [<c02287ea>] sys_listen+0x5c/0x74
> Oct 12 15:33:40 swdev14 kernel:  [<c02294a4>] sys_socketcall+0xb1/0x239
> Oct 12 15:33:40 swdev14 kernel:  [<c015ae81>] sys_close+0x75/0x91

this assert says that a write_unlock() was done before the mutex was
initialized - which is a no-no. Note that the stock kernel does not do
this checking and there's a chance that it has a true bug here which it
ignores silently. The more likely scenario is that the kernel mutex code
somewhere changed an assumption which broke the code. I'll try to
reproduce this.

	Ingo

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

* [patch] VP-2.6.9-rc4-mm1-T9
  2004-10-12 19:54       ` [patch] VP-2.6.9-rc4-mm1-T8 Ingo Molnar
  2004-10-12 20:57         ` K.R. Foley
@ 2004-10-13  6:15         ` Ingo Molnar
  2004-10-13  9:15           ` Rui Nuno Capela
                             ` (3 more replies)
  1 sibling, 4 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-13  6:15 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Wen-chien Jesse Sung,
	Mark_H_Johnson, K.R. Foley


i've uploaded the -T9 VP patch:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T9

this is a bugfixes-only release that should fix the highmem-related
issues reported by K.R. Foley and Mark H. Johnson: 3 more locks had to
be converted to raw.

to create a -T9 tree from scratch the patching order is:
 
   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T9

	Ingo

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

* Re: [patch] VP-2.6.9-rc4-mm1-T9
  2004-10-13  6:15         ` [patch] VP-2.6.9-rc4-mm1-T9 Ingo Molnar
@ 2004-10-13  9:15           ` Rui Nuno Capela
  2004-10-13 14:52           ` K.R. Foley
                             ` (2 subsequent siblings)
  3 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-13  9:15 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Wen-chien Jesse Sung, mark_h_johnson,
	K.R. Foley

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

Ingo Molnar wrote:
>
> i've uploaded the -T9 VP patch:
>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T9
>

Built and running on my laptop (P4/UP). Usual dmesg info goes attached,
where some exposed traces need a look.

OTOH, my desktop (P4/SMP/HT) refuses to boot/init all the way up. I guess
you know the picture ;) Couldn't get anything out of the mess. Will try
later.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: dmesg-2.6.9-rc4-mm1-T9.0.tar.gz --]
[-- Type: application/x-gzip-compressed, Size: 3910 bytes --]

[-- Attachment #3: config-2.6.9-rc4-mm1-T9.0.gz --]
[-- Type: application/x-gzip-compressed, Size: 8244 bytes --]

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

* Re: [patch] VP-2.6.9-rc4-mm1-T8
  2004-10-13  5:45           ` Ingo Molnar
@ 2004-10-13 14:00             ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-13 14:00 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Fernando Pablo Lopez-Lezcano, Lee Revell,
	Rui Nuno Capela, Wen-chien Jesse Sung, Mark_H_Johnson

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>Booted part way this time but then soft locked. [...]
> 
> 
> the soft lock it seems was due to a mutex assert in the TCP code. Now i
> see that you have the ipv6 module loaded. Would it be possible to
> disable ipv6 briefly, to see whether there are other issues?

Yes. I don't need and will disable when building T9.

> 
> 
>>Mouse was still working but not KB. Any idea why the KB is not working
>>with these? I am rebuilding with all of the pwr managment off because
>>I am still getting acpi messages in the boot :-/ [...]
> 
> 
> hm, the keyboard should be working - i have not seen any specific
> keyboard problems with PREEMPT_REALTIME enabled (except in the very
> early stages of this feature). So it must be something else. Is this a
> PS2 or an USB keyboard?

PS2 keyboard. For clarification, I have intermittent problems with the 
keyboard on this machine with anything to do with preempt. Sometimes it 
works on boot sometimes it does not. Actually since it is so 
unpredictable, I can't even say for sure that it has to do with preempt, 
but it hasn't failed yet on rc4-mm1. I have tried to find a pattern and 
have yet to do so. Possibly pertinent info:

Iwill MB dual 2.6G Xeon 512 ram

00:00.0 Host bridge: Intel Corp. E7505 Memory Controller Hub (rev 03)
00:00.1 Class ff00: Intel Corp. E7000 Series RAS Controller (rev 03)
00:01.0 PCI bridge: Intel Corp. E7000 Series Processor to AGP Controller 
(rev 03)
00:02.0 PCI bridge: Intel Corp. E7000 Series Hub Interface B PCI-to-PCI 
Bridge (rev 03)
00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #2 (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller 
(rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to PCI 
Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corp. 82801DB (ICH4) LPC Bridge (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801DB (ICH4) Ultra ATA 100 Storage 
Controller (rev 02)
00:1f.3 SMBus: Intel Corp. 82801DB/DBM (ICH4) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 
440] (rev a3)
02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
04:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702X 
Gigabit Ethernet (rev 02)
05:01.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] 
(rev 78)


> 
> 
>>Oct 12 15:33:39 swdev14 kernel: NET: Registered protocol family 10
>>Oct 12 15:33:39 swdev14 kernel: IPv6 over IPv4 tunneling driver
>>Oct 12 15:33:40 swdev14 kernel: ------------[ cut here ]------------
>>Oct 12 15:33:40 swdev14 kernel: kernel BUG at kernel/mutex.c:185!
> 
> 
>>Oct 12 15:33:40 swdev14 kernel: EIP is at _rw_mutex_write_unlock+0x25/0x2f
> 
> 
>>Oct 12 15:33:40 swdev14 kernel: Call Trace:
>>Oct 12 15:33:40 swdev14 kernel:  [<c0253738>] tcp_listen_start+0x175/0x1d1
>>Oct 12 15:33:40 swdev14 kernel:  [<c029a33a>] _spin_unlock_bh+0x1a/0x34
>>Oct 12 15:33:40 swdev14 kernel:  [<c0275a8c>] inet_listen+0x65/0x7a
>>Oct 12 15:33:40 swdev14 kernel:  [<c02287ea>] sys_listen+0x5c/0x74
>>Oct 12 15:33:40 swdev14 kernel:  [<c02294a4>] sys_socketcall+0xb1/0x239
>>Oct 12 15:33:40 swdev14 kernel:  [<c015ae81>] sys_close+0x75/0x91
> 
> 
> this assert says that a write_unlock() was done before the mutex was
> initialized - which is a no-no. Note that the stock kernel does not do
> this checking and there's a chance that it has a true bug here which it
> ignores silently. The more likely scenario is that the kernel mutex code
> somewhere changed an assumption which broke the code. I'll try to
> reproduce this.
> 
> 	Ingo
> 


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

* Re: [patch] VP-2.6.9-rc4-mm1-T9
  2004-10-13  6:15         ` [patch] VP-2.6.9-rc4-mm1-T9 Ingo Molnar
  2004-10-13  9:15           ` Rui Nuno Capela
@ 2004-10-13 14:52           ` K.R. Foley
  2004-10-13 16:53           ` Radoslaw Szkodzinski
  2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
  3 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-13 14:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Wen-chien Jesse Sung,
	Mark_H_Johnson

Ingo Molnar wrote:
> i've uploaded the -T9 VP patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-T9
> 
OK. This one actually boots all the way into X and even shuts down 
cleanly (no errors either way). Still no keyboard, which is why I had to 
shut it down. :) Does this indicate that the keyboard is actually being 
detected or no?

Oct 13 09:29:59 swdev14 kernel: requesting new irq thread for IRQ1...
Oct 13 09:29:59 swdev14 kernel: IRQ#1 thread started up.
Oct 13 09:29:59 swdev14 kernel: input: AT Translated Set 2 keyboard on 
isa0060/serio0

We're getting there. This is with ipv6 disabled, btw.

kr

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

* Re: [patch] VP-2.6.9-rc4-mm1-T9
  2004-10-13  6:15         ` [patch] VP-2.6.9-rc4-mm1-T9 Ingo Molnar
  2004-10-13  9:15           ` Rui Nuno Capela
  2004-10-13 14:52           ` K.R. Foley
@ 2004-10-13 16:53           ` Radoslaw Szkodzinski
  2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
  3 siblings, 0 replies; 951+ messages in thread
From: Radoslaw Szkodzinski @ 2004-10-13 16:53 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Wen-chien Jesse Sung,
	mark_h_johnson, K.R. Foley

On Wed, 13 Oct 2004 08:15:18 +0200, Ingo Molnar <mingo@elte.hu> wrote:
> 
> i've uploaded the -T9 VP patch:
> 

There are lots of similar warnings in Reiser4:
  CC      fs/reiser4/plugin/node/node.o
In file included from include/linux/spinlock.h:16,
                 from include/linux/wait.h:25,
                 from include/linux/fs.h:12,
                 from fs/reiser4/plugin/node/../../reiser4.h:13,
                 from fs/reiser4/plugin/node/../../debug.h:9,
                 from fs/reiser4/plugin/node/node.c:47:
include/asm/mutex.h:75:5: warning: "RWSEM_DEBUG" is not defined

Also, there is an easy to fix compile error - redefinition of
inode_lock in fs/reiser4/plugin/object.c

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

* [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-13  6:15         ` [patch] VP-2.6.9-rc4-mm1-T9 Ingo Molnar
                             ` (2 preceding siblings ...)
  2004-10-13 16:53           ` Radoslaw Szkodzinski
@ 2004-10-14  0:24           ` Ingo Molnar
  2004-10-14  1:27             ` Adam Heath
                               ` (8 more replies)
  3 siblings, 9 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14  0:24 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton


i'm pleased to announce a significantly improved version of the
Real-Time Preemption (PREEMPT_REALTIME) feature that i have been working
towards in the past couple of weeks.

the patch (against 2.6.9-rc4-mm1) can be downloaded from:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U0

this is i believe the first correct conversion of the Linux kernel to a
fully preemptible (fully mutex-based) preemption model, while still
keeping all locking properties of Linux.

I also think that this feature can and should be integrated into the
upstream kernel sometime in the future. It will need improvements and
fixes and lots of testing, but i believe the basic concept is sound and
inclusion is manageable and desirable. So comments, testing and feedback
is more than welcome!

to recap the conceptual issues that needed solving: the previous patch
already converted a fair portion of spinlocks to mutexes, but that in a
fully preemptible kernel model the following locking primitives are
especially problematic:

	- RCU locking
	- per-cpu counters and per-cpu variables
	- tlb gather/release logic
	- seqlocks
	- atomic-kmaps
	- pte mapping

note that while we tend to think about these as SMP locking primitives,
in a fully preemptible model these locking rules are necessary for
correctness, even on a single-CPU embedded box.

Unfortunately none of the existing preemption patches solve these
problems: they concentrate on UP but these locking rules must not be
ignored on UP either!

(Bill Huey's mutex patch he just released is the one notable exception i
know about, which is also a correct implementation i believe, but it
doesnt attack these locking rules [yet]. Bill's locking hierarchy is i
believe quite similar to the -T9 patch - this i believe is roughly the
best one can get when only using spinlocks as a vehicle.)

In the previous (-T9) version of the Real-Time Preemption patch, the
above locking primitives kept large portions of kernel code
non-preemptable, causing a 'spreadout' of raw spinlocks and
non-preemptible sections to various kernel subsystems.

Another, even more problematic effect was that both network drivers and
block IO drivers got 'contaminated' by raw spinlocks, triggering lots of
per-driver changes and thus limiting testability. It is basically an
opt-in model to correctness which is bad from a maintainance and
upstream acceptance point of view. The -T9 patch was a prime example of
the problems the Linux locking primitives cause in a fully preemptible
kernel model.


To solve all these fundamental problems, i improved/fixed/changed all of
these locking methods to be preemption-friendly. Most of the time it was
necessary to introduce an additional API variant because e.g.
rcu_read_lock() is anonymous (it doesnt identify the data protected), so
i introduced a variant that takes the write-lock as an argument. In the
PREEMPT_REALTIME case we can thus properly serialize on that lock.

For per-cpu variables i introduced a new API variant that creates a
spinlock-array for the per-cpu-variable, and users must make sure the
cpu field doesnt change. Migration to another CPU can happen within the
critical section, but 'statistically' the variable is still per-CPU and
update correctness is fully preserved.

TLB shootdown was the source of another nasty type of critical section:
it keeps preemption disabled during much of the pagetable zapping and
also relies on a per-CPU variable to keep TLB state. The fix for
PREEMPT_REALTIME (on x86) was to implement a simpler but preemptible TLB
flushing method. This necessiated two minor API changes to the generic
TLB shootdown code - pretty straightforward ones.

Atomic kmaps were another source of non-preemptible sections:
pte_map/pte_unmap both used nontrivial functions within and ran for a
long time, creating a lock dependency and a latency problem as well. I
wrapped them via normal kmaps, which thus become preemptible. (The main
reason for atomic kmaps were non-preemptability constraints - but those
are not present in a fully preemptible model.)

seqlocks (used within the VFS and other places) were another problem:
the are now preemptible by default, the same auto-type-detection logic
applies to them as to preemptible/raw spinlocks: switching between a
preemptible and a non-preemptible type is done by changing the
prototype, the locking APIs stay the same.

The improvements to locking allowed the gradual 'pulling out' of all
raw-spinlocks from various kernel subsystems. In the -U0 patch i have
almost completely finished this 'pullout', and as a result the following
kernel subsystems are now completely spinlock-free and 100% mutex-based:

	- networking
	- IO subsystem
	- VFS and lowlevel filesystems
	- memory management (except the SLAB allocator lock)
	- signal code
	- all of drivers/* and sound/*

note: it is important that when PREEMPT_REALTIME is disabled, the old
locking rules apply and there is no performance impact whatsoever. So
what this implements is in essence a compile-time multi-tier locking
architecture enabling 4 types of preemption models:

  - stock                      (casual voluntary kernel preemption)
  - CONFIG_PREEMPT_VOLUNTARY   (lots of cond_resched() points)
  - CONFIG_PREEMPT             (involuntary preemption plus spinlocks)
  - CONFIG_PREEMPT_REALTIME    (everything is a mutex)

these models cover all the variants people are interested in: servers
with almost no latency worries, desktops with ~1msec needs and hard-RT
applications needing both microsecond-range latencies and provable
maximum latencies.

to quantitatively see the effects of these changes to the locking
landscape, here's the output of a script that disassembles the kernel
image and counts the number of actual spin lock/unlock function calls
done versus mutex lock/unlocks:

With PREEMPT_REALTIME disabled, all locks are spinlocks and old
semaphores:

        spinlock API calls:      5359  (71.6%)
        | old mutex API calls:   2120  (28.3%)
        | new mutex API calls:      2  (0%)
        all mutex API calls:     2122  (28.3%)
        --------------------------------------
        lock API calls:          7481 (100.0%)

with the -T9 kernel, which had the 'spread out' locking model, a
considerable portion of spinlocks were replaced by mutexes, but more
than 20% of usage was still spinlocks:

        spinlock API calls:      1835  (23.1%)
        | old mutex API calls:   2142  (26.9%)
        | new mutex API calls:   3961  (49.8%)
        all mutex API calls:     6103  (76.8%)
        --------------------------------------
        lock API calls:          7938 (100.0%)

here are some fresh numbers from Bill Huey's mmLinux kernel:

        spinlock API calls:      2452  (30.3%)
        all mutex API calls:     5614  (69.6%)
        --------------------------------------
        lock API calls:          8066 (100.0%)

(his mutex implementation directly falls back to up()/down() so the new
mutexes become part of the old mutexes.)

while i believe that the locking design is fundamentally incomplete in
the MontaVista kernel and thus is not directly comparable to
PREEMPT_REALTIME nor the mmLinux kernel, here are the stats from it
using a similar .config:

        spinlock API calls:      1444  (26.1%)
        | old mutex API calls:   2095  (37.9%)
        | new mutex API calls:   1981  (35.8%)
        all mutex API calls:     4076  (73.8%)
        --------------------------------------
        lock API calls:          5520 (100.0%)

(here it is visible that apparently a significant amount of [i believe
necessary] locking is missing from this kernel.)

finally, here are the stats from the new PREEMPT_REALTIME -U0 kernel:

        spinlock API calls:       491  (6.0%)
        | old mutex API calls:   2142  (26.2%)
        | new mutex API calls:   5536  (67.7%)
        all mutex API calls:     7678  (93.9%)
        --------------------------------------
        lock API calls:          8169 (100.0%)

note that almost all of the remaining spinlocks are held for a short
amount of time and have a finite maximum duration. They involve hardware
access, scheduling and interrupt handling and timers - almost all of
that code has O(1) characteristics.

what this means is that we are approaching hard-real-time domains ... 
using what is in essence the stock Linux kernel!

note that priority inheritance is still not part of this patch, but that
effort can now be centralized to the two basic Linux semaphore types,
solving the full spectrum of priority inheritance problems!

the code is still x86-only but only for practical reasons - other
architectures will be covered in the future as well.

to create a -U0 tree from scratch the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U0

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
@ 2004-10-14  1:27             ` Adam Heath
  2004-10-14  1:31               ` Ingo Molnar
  2004-10-14  1:36               ` Ingo Molnar
  2004-10-14  2:45             ` K.R. Foley
                               ` (7 subsequent siblings)
  8 siblings, 2 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-14  1:27 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

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

On Thu, 14 Oct 2004, Ingo Molnar wrote:

>
> i'm pleased to announce a significantly improved version of the
> Real-Time Preemption (PREEMPT_REALTIME) feature that i have been working
> towards in the past couple of weeks.

Tried this, it died.

During boot, I saw a message about scheduling while atomic for postgres, and a
stack dump.  It then continued, and got all the way into x.  I started to type
'ssh-'(add), and then userspace locked(ping still worked from remote.

It *was* able to save data to kern.log, which is helpful.

Also, I noticed that the swapper/0 had a high-latency critical section.

The bug that caused it to crash was in mm/highmem.c.

Attached you will find the kernel log, ksymoops output, and config.  I've been
running 2.6.9-rc4 since it came out earlier this week.  This is my first mm or
preempt kernel, however.

(note: I had to lowercase the version number, because make-kpkg doesn't like
uppercase)

[-- Attachment #2: Type: TEXT/PLAIN, Size: 6181 bytes --]

(swapper/0): new 485720 us maximum-latency critical section.
 => started at: <start_kernel+0x32/0x1b0>
 => ended at:   <cond_resched+0x19/0x70>
 [check_preempt_timing+200/304] check_preempt_timing+0xc8/0x130
 [touch_preempt_timing+43/48] touch_preempt_timing+0x2b/0x30
 [cond_resched+25/112] cond_resched+0x19/0x70
 [_mutex_lock+20/64] _mutex_lock+0x14/0x40
 [get_cmos_time+17/464] get_cmos_time+0x11/0x1d0
 [pidhash_init+193/256] pidhash_init+0xc1/0x100
 [time_init+8/128] time_init+0x8/0x80
 [timer_cpu_notify+23/32] timer_cpu_notify+0x17/0x20
 [softirq_init+17/32] softirq_init+0x11/0x20
 [start_kernel+179/432] start_kernel+0xb3/0x1b0
 [unknown_bootoption+0/352] unknown_bootoption+0x0/0x160
(swapper/0): new 608732 us maximum-latency critical section.
 => started at: <cond_resched+0x19/0x70>
 => ended at:   <cond_resched+0x19/0x70>
 [check_preempt_timing+200/304] check_preempt_timing+0xc8/0x130
 [touch_preempt_timing+43/48] touch_preempt_timing+0x2b/0x30
 [cond_resched+25/112] cond_resched+0x19/0x70
 [_mutex_lock+32/64] _mutex_lock+0x20/0x40
 [get_cmos_time+17/464] get_cmos_time+0x11/0x1d0
 [pidhash_init+193/256] pidhash_init+0xc1/0x100
 [time_init+8/128] time_init+0x8/0x80
 [timer_cpu_notify+23/32] timer_cpu_notify+0x17/0x20
 [softirq_init+17/32] softirq_init+0x11/0x20
 [start_kernel+179/432] start_kernel+0xb3/0x1b0
 [unknown_bootoption+0/352] unknown_bootoption+0x0/0x160
scheduling while atomic: postmaster/0x04000002/905
caller is cond_resched+0x53/0x70
 [schedule+1329/1392] schedule+0x531/0x570
 [check_preempt_timing+26/304] check_preempt_timing+0x1a/0x130
 [check_preempt_timing+26/304] check_preempt_timing+0x1a/0x130
 [cond_resched+83/112] cond_resched+0x53/0x70
 [_mutex_lock+20/64] _mutex_lock+0x14/0x40
 [_mutex_lock_irqsave+5/16] _mutex_lock_irqsave+0x5/0x10
 [avc_has_perm_noaudit+42/384] avc_has_perm_noaudit+0x2a/0x180
 [kmap_high+280/400] kmap_high+0x118/0x190
 [cond_resched+25/112] cond_resched+0x19/0x70
 [_mutex_lock+32/64] _mutex_lock+0x20/0x40
 [page_address+153/176] page_address+0x99/0xb0
 [avc_has_perm+58/120] avc_has_perm+0x3a/0x78
 [common_interrupt+24/32] common_interrupt+0x18/0x20
 [ipc_has_perm+112/144] ipc_has_perm+0x70/0x90
 [ipcperms+114/160] ipcperms+0x72/0xa0
 [semctl_main+119/944] semctl_main+0x77/0x3b0
 [check_preempt_timing+26/304] check_preempt_timing+0x1a/0x130
 [cond_resched+25/112] cond_resched+0x19/0x70
 [_rw_mutex_read_lock+25/48] _rw_mutex_read_lock+0x19/0x30
 [pg0+945317965/1070072832] dm_table_any_congested+0xd/0x50 [dm_mod]
 [cond_resched+25/112] cond_resched+0x19/0x70
 [check_preempt_timing+26/304] check_preempt_timing+0x1a/0x130
 [check_preempt_timing+26/304] check_preempt_timing+0x1a/0x130
 [cond_resched+25/112] cond_resched+0x19/0x70
 [_mutex_lock+32/64] _mutex_lock+0x20/0x40
 [page_address+153/176] page_address+0x99/0xb0
 [kmap_high+280/400] kmap_high+0x118/0x190
 [cond_resched+25/112] cond_resched+0x19/0x70
 [_mutex_lock+32/64] _mutex_lock+0x20/0x40
 [page_address+153/176] page_address+0x99/0xb0
 [kunmap_high+80/160] kunmap_high+0x50/0xa0
 [do_anonymous_page+63/384] do_anonymous_page+0x3f/0x180
 [do_no_page+97/800] do_no_page+0x61/0x320
 [cond_resched+25/112] cond_resched+0x19/0x70
 [handle_mm_fault+203/336] handle_mm_fault+0xcb/0x150
 [do_page_fault+436/1416] do_page_fault+0x1b4/0x588
 [unmap_vmas+229/368] unmap_vmas+0xe5/0x170
 [cond_resched+25/112] cond_resched+0x19/0x70
 [cond_resched+25/112] cond_resched+0x19/0x70
 [copy_to_user+64/96] copy_to_user+0x40/0x60
 [sys_semctl+189/192] sys_semctl+0xbd/0xc0
 [sys_ipc+188/640] sys_ipc+0xbc/0x280
 [do_page_fault+0/1416] do_page_fault+0x0/0x588
------------[ cut here ]------------
kernel BUG at mm/highmem.c:189!
invalid operand: 0000 [#1]
PREEMPT 
Modules linked in: nfsd exportfs snd_cmipci snd_opl3_lib snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device 8250 serial_core nfs lockd sunrpc raid5 xor md dm_mirror dm_mod aic7xxx sg sr_mod cdrom sd_mod scsi_mod snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snd_page_alloc soundcore 3c59x mii sis900 crc32 siimage
CPU:    0
EIP:    0060:[kunmap_high+30/160]    Not tainted VLI
EFLAGS: 00010246   (2.6.9-rc4-mm1-vp-u0) 
EIP is at kunmap_high+0x1e/0xa0
eax: 00000000   ebx: c2806360   ecx: c036586c   edx: 00000001
esi: f6b36000   edi: f68c97e0   ebp: f68c9818   esp: f68cec48
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process FvwmTaskBar (pid: 1249, threadinfo=f68ce000 task=f68cda80)
Stack: 00000001 00350025 c0144e53 f68c9818 00000001 f6888d2c f6b36000 00000000 
       f6888d2c f68c9818 c0144fe1 f68d2b68 00000001 b6800007 c027b329 f68c9818 
       00000000 00000000 b6800007 f68c97e0 00000001 f68c97e0 f68d2b68 b6800007 
Call Trace:
 [do_anonymous_page+83/384] do_anonymous_page+0x53/0x180
 [do_no_page+97/800] do_no_page+0x61/0x320
 [cond_resched+25/112] cond_resched+0x19/0x70
 [handle_mm_fault+203/336] handle_mm_fault+0xcb/0x150
 [do_page_fault+436/1416] do_page_fault+0x1b4/0x588
 [__pagevec_lru_add+165/192] __pagevec_lru_add+0xa5/0xc0
 [read_pages+315/336] read_pages+0x13b/0x150
 [ext3_get_block+0/160] ext3_get_block+0x0/0xa0
 [check_preempt_timing+26/304] check_preempt_timing+0x1a/0x130
 [cond_resched+25/112] cond_resched+0x19/0x70
 [cond_resched+25/112] cond_resched+0x19/0x70
 [do_page_fault+0/1416] do_page_fault+0x0/0x588
 [error_code+45/56] error_code+0x2d/0x38
 [file_read_actor+65/224] file_read_actor+0x41/0xe0
 [do_generic_mapping_read+368/1248] do_generic_mapping_read+0x170/0x4e0
 [__generic_file_aio_read+479/528] __generic_file_aio_read+0x1df/0x210
 [file_read_actor+0/224] file_read_actor+0x0/0xe0
 [generic_file_aio_read+71/112] generic_file_aio_read+0x47/0x70
 [do_sync_read+161/224] do_sync_read+0xa1/0xe0
 [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
 [vfs_read+205/288] vfs_read+0xcd/0x120
 [sys_read+71/128] sys_read+0x47/0x80
 [syscall_call+7/11] syscall_call+0x7/0xb
Code: fe ff ff 8d 76 00 8d bc 27 00 00 00 00 83 ec 08 89 5c 24 04 89 c3 b8 44 42 36 c0 e8 ad 9f fe ff 89 d8 e8 c6 05 00 00 85 c0 75 08 <0f> 0b bd 00 c0 a3 28 c0 05 00 00 80 00 31 db c1 e8 0c 8b 14 85 


[-- Attachment #3: Type: TEXT/PLAIN, Size: 3731 bytes --]

ksymoops 2.4.9 on i686 2.6.9-rc4.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.6.9-rc4-mm1-vp-u0/ (specified)
     -m /boot/System.map-2.6.9-rc4-mm1-vp-u0 (specified)

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
kernel BUG at mm/highmem.c:189!
invalid operand: 0000 [#1]
CPU:    0
EIP:    0060:[kunmap_high+30/160]    Not tainted VLI
EFLAGS: 00010246   (2.6.9-rc4-mm1-vp-u0) 
eax: 00000000   ebx: c2806360   ecx: c036586c   edx: 00000001
esi: f6b36000   edi: f68c97e0   ebp: f68c9818   esp: f68cec48
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Stack: 00000001 00350025 c0144e53 f68c9818 00000001 f6888d2c f6b36000 00000000 
       f6888d2c f68c9818 c0144fe1 f68d2b68 00000001 b6800007 c027b329 f68c9818 
       00000000 00000000 b6800007 f68c97e0 00000001 f68c97e0 f68d2b68 b6800007 
Call Trace:
Warning (Oops_read): Code line not seen, dumping what data is available


>>ebx; c2806360 <pg0+2488360/3fc80400>
>>ecx; c036586c <page_address_htable+5cc/1000>
>>esi; f6b36000 <pg0+367b8000/3fc80400>
>>edi; f68c97e0 <pg0+3654b7e0/3fc80400>
>>ebp; f68c9818 <pg0+3654b818/3fc80400>
>>esp; f68cec48 <pg0+36550c48/3fc80400>

Code: fe ff ff 8d 76 00 8d bc 27 00 00 00 00 83 ec 08 89 5c 24 04 89 c3 b8 44 42 36 c0 e8 ad 9f fe ff 89 d8 e8 c6 05 00 00 85 c0 75 08 <0f> 0b bd 00 c0 a3 28 c0 05 00 00 80 00 31 db c1 e8 0c 8b 14 85 
Using defaults from ksymoops -t elf32-i386 -a i386


Code;  ffffffd5 <__kernel_rt_sigreturn+1b95/????>
00000000 <_EIP>:
Code;  ffffffd5 <__kernel_rt_sigreturn+1b95/????>
   0:   fe                        (bad)  
Code;  ffffffd6 <__kernel_rt_sigreturn+1b96/????>
   1:   ff                        (bad)  
Code;  ffffffd7 <__kernel_rt_sigreturn+1b97/????>
   2:   ff 8d 76 00 8d bc         decl   0xbc8d0076(%ebp)
Code;  ffffffdd <__kernel_rt_sigreturn+1b9d/????>
   8:   27                        daa    
Code;  ffffffde <__kernel_rt_sigreturn+1b9e/????>
   9:   00 00                     add    %al,(%eax)
Code;  ffffffe0 <__kernel_rt_sigreturn+1ba0/????>
   b:   00 00                     add    %al,(%eax)
Code;  ffffffe2 <__kernel_rt_sigreturn+1ba2/????>
   d:   83 ec 08                  sub    $0x8,%esp
Code;  ffffffe5 <__kernel_rt_sigreturn+1ba5/????>
  10:   89 5c 24 04               mov    %ebx,0x4(%esp)
Code;  ffffffe9 <__kernel_rt_sigreturn+1ba9/????>
  14:   89 c3                     mov    %eax,%ebx
Code;  ffffffeb <__kernel_rt_sigreturn+1bab/????>
  16:   b8 44 42 36 c0            mov    $0xc0364244,%eax
Code;  fffffff0 <__kernel_rt_sigreturn+1bb0/????>
  1b:   e8 ad 9f fe ff            call   fffe9fcd <_EIP+0xfffe9fcd>
Code;  fffffff5 <__kernel_rt_sigreturn+1bb5/????>
  20:   89 d8                     mov    %ebx,%eax
Code;  fffffff7 <__kernel_rt_sigreturn+1bb7/????>
  22:   e8 c6 05 00 00            call   5ed <_EIP+0x5ed>
Code;  fffffffc <__kernel_rt_sigreturn+1bbc/????>
  27:   85 c0                     test   %eax,%eax
Code;  fffffffe <__kernel_rt_sigreturn+1bbe/????>
  29:   75 08                     jne    33 <_EIP+0x33>
Code;  00000000 Before first symbol
  2b:   0f 0b                     ud2a   
Code;  00000002 Before first symbol
  2d:   bd 00 c0 a3 28            mov    $0x28a3c000,%ebp
Code;  00000007 Before first symbol
  32:   c0 05 00 00 80 00 31      rolb   $0x31,0x800000
Code;  0000000e Before first symbol
  39:   db c1                     fcmovnb %st(1),%st
Code;  00000010 Before first symbol
  3b:   e8 0c 8b 14 85            call   85148b4c <_EIP+0x85148b4c>


1 warning and 1 error issued.  Results may not be reliable.

[-- Attachment #4: Type: TEXT/PLAIN, Size: 32296 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-rc4-mm1-vp-u0
# Wed Oct 13 19:45:17 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=""
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_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_PREEMPT_TIMING=y
# CONFIG_LATENCY_TRACE is not set
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=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_X86_USE_3DNOW=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
# 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 is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

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

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

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

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set

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

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 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 is not set
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 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=m
CONFIG_BLK_DEV_SIS5513=y
# 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_SCSI=m
CONFIG_SCSI_PROC_FS=y

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

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

#
# SCSI low-level drivers
#
CONFIG_BLK_DEV_3W_XXXX_RAID=m
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST 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=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_SCSI_SATA=y
# CONFIG_SCSI_SATA_SVW is not set
# CONFIG_SCSI_ATA_PIIX is not set
# CONFIG_SCSI_SATA_NV is not set
# CONFIG_SCSI_SATA_PROMISE is not set
# CONFIG_SCSI_SATA_SX4 is not set
CONFIG_SCSI_SATA_SIL=m
# CONFIG_SCSI_SATA_SIS is not set
# CONFIG_SCSI_SATA_ULI is not set
# CONFIG_SCSI_SATA_VIA is not set
# CONFIG_SCSI_SATA_VITESSE is not set
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
CONFIG_SCSI_GDTH=m
# 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_NCR53C406A is not set
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

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

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

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
# CONFIG_IP_PIMSM_V1 is not set
# CONFIG_IP_PIMSM_V2 is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m

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

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

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

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_CT_ACCT=y
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_PHYSDEV=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
CONFIG_IP_NF_MATCH_COMMENT=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_IP_NF_NAT_LOCAL=y
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set

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

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
CONFIG_BRIDGE=m
# 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_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
CONFIG_VORTEX=m
# CONFIG_TYPHOON 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 is not set
CONFIG_SIS900=m
# 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

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

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD64=m
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_INTEL_MCH is not set
CONFIG_AGP_NVIDIA=m
# 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=m
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

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

#
# Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set

#
# Other I2C Chip support
#
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set

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

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

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

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

#
# ISA devices
#
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_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_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
CONFIG_SND_CMIPCI=m
# 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=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_DEVPTS_FS_SECURITY=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS 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=m
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_NCP_FS is not set
CONFIG_CODA_FS=m
# CONFIG_CODA_FS_OLD_API is not set
# CONFIG_AFS_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=m
# 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=m
CONFIG_NLS_ISO8859_1=m
# 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=m

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
CONFIG_DEBUG_PREEMPT=y
# CONFIG_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

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

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

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  1:27             ` Adam Heath
@ 2004-10-14  1:31               ` Ingo Molnar
  2004-10-14  2:22                 ` Adam Heath
  2004-10-14  1:36               ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14  1:31 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


* Adam Heath <doogie@debian.org> wrote:

> The bug that caused it to crash was in mm/highmem.c.

could you disable HIGHMEM (or at least HIGHPTE) and try again? Some
last-minute bug slipped into that code.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  1:27             ` Adam Heath
  2004-10-14  1:31               ` Ingo Molnar
@ 2004-10-14  1:36               ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14  1:36 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


* Adam Heath <doogie@debian.org> wrote:

> Also, I noticed that the swapper/0 had a high-latency critical
> section.

this is normal during bootup - we spend many seconds with preemption
disabled - it's fair at that stage. After it has booted up you can reset
the maximum-latency searching via:

    echo 50 > /proc/sys/kernel/preempt_max_latency

i have that line in my rc.local.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  1:31               ` Ingo Molnar
@ 2004-10-14  2:22                 ` Adam Heath
  0 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-14  2:22 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Thu, 14 Oct 2004, Ingo Molnar wrote:

>
> * Adam Heath <doogie@debian.org> wrote:
>
> > The bug that caused it to crash was in mm/highmem.c.
>
> could you disable HIGHMEM (or at least HIGHPTE) and try again? Some
> last-minute bug slipped into that code.

Well, it's a little better, but it still died.  Just took longer.

However, this time, my kern.log got corrupted.  I saw 2 scheduling while
atomic errors in dmesg(before it locked up), but only one in kern.log, and a
bunch of random data(using ext3 data=writeback).  Symptoms this time around
were laggy keyboard handling, zombie processes(this may have been caused by
the scheduling while atomic problem), and ctrl-c not working.

I'll try again tomorrow, and hopefully get more data.

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
  2004-10-14  1:27             ` Adam Heath
@ 2004-10-14  2:45             ` K.R. Foley
  2004-10-14  3:59             ` K.R. Foley
                               ` (6 subsequent siblings)
  8 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-14  2:45 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Daniel Walker, Bill Huey, Andrew Morton

Ingo Molnar wrote:
> i'm pleased to announce a significantly improved version of the
> Real-Time Preemption (PREEMPT_REALTIME) feature that i have been working
> towards in the past couple of weeks.
> 
> the patch (against 2.6.9-rc4-mm1) can be downloaded from:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U0
> 

I have this built and running on my SMP system now and thus far it looks 
very promising. Numbers to follow.

kr

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
  2004-10-14  1:27             ` Adam Heath
  2004-10-14  2:45             ` K.R. Foley
@ 2004-10-14  3:59             ` K.R. Foley
  2004-10-14  8:57             ` Florian Schmidt
                               ` (5 subsequent siblings)
  8 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-14  3:59 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Daniel Walker, Bill Huey, Andrew Morton

Ingo Molnar wrote:
> i'm pleased to announce a significantly improved version of the
> Real-Time Preemption (PREEMPT_REALTIME) feature that i have been working
> towards in the past couple of weeks.
> 
> the patch (against 2.6.9-rc4-mm1) can be downloaded from:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U0
> 

Don't try to debug spinlocks as in CONFIG_DEBUG_SPINLOCK and 
CONFIG_PREEMPT_REALTIME at the same time. The two are currently 
incompatible.

kr

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
                               ` (2 preceding siblings ...)
  2004-10-14  3:59             ` K.R. Foley
@ 2004-10-14  8:57             ` Florian Schmidt
  2004-10-14  9:19               ` Ingo Molnar
  2004-10-14 14:31             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Ingo Molnar
                               ` (4 subsequent siblings)
  8 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-14  8:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton

On Thu, 14 Oct 2004 02:24:33 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> i'm pleased to announce a significantly improved version of the
> Real-Time Preemption (PREEMPT_REALTIME) feature that i have been working
> towards in the past couple of weeks.

Cool :)

Say, does it still apply that one should not use unthreaded IRQ handlers for
all IRQ's when using PREEMPT_REALTIME (Except maybe for the keyboard)?

flo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  8:57             ` Florian Schmidt
@ 2004-10-14  9:19               ` Ingo Molnar
  2004-10-14  9:42                 ` Florian Schmidt
                                   ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14  9:19 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> Cool :)
> 
> Say, does it still apply that one should not use unthreaded IRQ
> handlers for all IRQ's when using PREEMPT_REALTIME (Except maybe for
> the keyboard)?

yes - and this kernel simply does not allow the un-threading of
interrupt handlers anymore, so you cannot accidentally misconfigure it. 
(Not even the keyboard interrupt is an exception, it would have
lock-ripple-effects elsewhere.)

so the preferred (and only) interface to mark interrupts 'high prio' is
via process priorities. Starting from the -U1 kernel it will be possible
to do this:

   chrt -f 60 -p `ps -C 'IRQ:1' -o pid=`
   chrt -f 60 -p `ps -C 'IRQ:8' -o pid=`

this sets the keyboard and the RT-timer interrupt to FIFO:60.

In -U0 this is not possible because 'ps -C' does not handle kernel
threads with a space in their name. So there you'd need some wacky thing
like:

   chrt -f 60 -p `ps ax -o pid= -o comm= | grep "IRQ 1$" | cut -dI -f1`
   chrt -f 60 -p `ps ax -o pid= -o comm= | grep "IRQ 8$" | cut -dI -f1`

(someone should fix procps - or does it intentionally break with
whitespace command-strings?)

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  9:42                 ` Florian Schmidt
@ 2004-10-14  9:36                   ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14  9:36 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> btw: i use:
> 
> chrt -f -p 99 `pidof "IRQ 5"`

ah, indeed, pidof is more robust. Ok, i changed the format from IRQ:5
back to "IRQ 5" in my tree to not break scripts.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  9:19               ` Ingo Molnar
@ 2004-10-14  9:42                 ` Florian Schmidt
  2004-10-14  9:36                   ` Ingo Molnar
  2004-10-14 10:00                 ` Florian Schmidt
  2004-10-14 17:43                 ` Miquel van Smoorenburg
  2 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-14  9:42 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton

On Thu, 14 Oct 2004 11:19:53 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> In -U0 this is not possible because 'ps -C' does not handle kernel
> threads with a space in their name. So there you'd need some wacky thing
> like:
> 
>    chrt -f 60 -p `ps ax -o pid= -o comm= | grep "IRQ 1$" | cut -dI -f1`
>    chrt -f 60 -p `ps ax -o pid= -o comm= | grep "IRQ 8$" | cut -dI -f1`
> 
> (someone should fix procps - or does it intentionally break with
> whitespace command-strings?)

Hi,

thanks for the infos.

btw: i use:

chrt -f -p 99 `pidof "IRQ 5"`

for example (chrt commandline parsing is kinda braindead). It seems to work: 

~$ ps -cmL `pidof "IRQ 5"`
  PID   LWP CLS PRI TTY      STAT   TIME COMMAND
  110     - -     - ?        -      0:00 [IRQ 5]
    -   110 FF  139 -        S<     0:00 -

flo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  9:19               ` Ingo Molnar
  2004-10-14  9:42                 ` Florian Schmidt
@ 2004-10-14 10:00                 ` Florian Schmidt
  2004-10-14 10:22                   ` Rui Nuno Capela
  2004-10-14 17:43                 ` Miquel van Smoorenburg
  2 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-14 10:00 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton,
	jackit-devel


CC'ed jackit-devel mailing list, cause this might be interesting for them,
too.

Ah, btw: U0 booted fine here.. Seems to run allright, too (for everything
non jackd). Only thing is:

When starting jackd i get a floating point exception. Dunno where that comes from:

~$ jackd -d alsa -p 512
jackd 0.99.0
Copyright 2001-2003 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

loading driver ..
creating alsa driver ... hw:0|hw:0|512|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 512 frames, buffer = 2 periods
Couldn't open hw:0 for 32bit samples trying 24bit instead
Couldn't open hw:0 for 24bit samples trying 16bit instead
Couldn't open hw:0 for 32bit samples trying 24bit instead
Couldn't open hw:0 for 24bit samples trying 16bit instead
Floating point exception



running jackd in gdb locks up the gdb process i think [i'm not too
experienced in debugging stuff].

here;s partial strace and ltrace logs (only the end). I have no idea if this is a jack bug
exposed by your kernrel patches or a bug in your kernel patches exposed by
jackd :) But it seems to be a mutex/futex issue...


strace:

....
sched_get_priority_max(SCHED_FIFO)      = 99
sched_get_priority_max(SCHED_FIFO)      = 99
sched_get_priority_min(SCHED_FIFO)      = 1
mmap2(NULL, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6d42000
mprotect(0xb6d42000, 4096, PROT_NONE)   = 0
clone(child_stack=0xb7541b48, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0xb7541bf8, {entry_number:6, base_addr:0xb7541bb0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb7541bf8) = 1546
sched_setscheduler(1546, SCHED_OTHER, { 0 }) = 0
sched_setscheduler(1546, SCHED_FIFO, { 20 }) = 0
futex(0xb7541d94, FUTEX_WAKE, 1)        = 1
ioctl(7, 0x4140, 0x1)                   = 0
ioctl(7, 0x4142, 0x1)                   = 0
sched_get_priority_max(SCHED_FIFO)      = 99
sched_get_priority_min(SCHED_FIFO)      = 1
mmap2(NULL, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6542000
mprotect(0xb6542000, 4096, PROT_NONE)   = 0
clone(child_stack=0xb6d41b48, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0xb6d41bf8, {entry_number:6, base_addr:0xb6d41bb0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb6d41bf8) = 1547
sched_setscheduler(1547, SCHED_OTHER, { 0 }) = 0
sched_setscheduler(1547, SCHED_FIFO, { 10 }) = 0
futex(0xb6d41d94, FUTEX_WAKE, 1)        = 1
+++ killed by SIGFPE +++






ltrace:

....
jack_client_alloc_internal(0x8057800, 0x8063a78, 0xbfffe310, 0x80538b1, 0xbffff758) = 0x8064d20
pthread_mutex_unlock(0x8063abc, 0x8063a78, 0xbfffe310, 0x80538b1, 0xbffff758) = 0
creating alsa driver ... hw:0|hw:0|512|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 512 frames, buffer = 2 periods
Couldn't open hw:0 for 32bit samples trying 24bit instead
Couldn't open hw:0 for 24bit samples trying 16bit instead
Couldn't open hw:0 for 32bit samples trying 24bit instead
Couldn't open hw:0 for 24bit samples trying 16bit instead
free(0x8058658)                                  = <void>
snprintf("/jck-[32 bit float mono audio]", 64, "/jck-[%s]", "32 bit float mono audio") = 30
jack_shmalloc(0xbfffd140, 262144, 0x8063b80, 0xb7fdc21c, 0) = 0
jack_attach_shm(0x8063b80, 262144, 0x8063b80, 0xb7fdc21c, 0) = 0
pthread_mutex_lock(0x8063b00, 0x8063b80, 0x8063b00, 262144, 2048) = 0
malloc(1024)                                     = 0x806e830
malloc(8)                                        = 0x806dd80
malloc(8)                                        = 0x8058658
malloc(8 <unfinished ...>
+++ killed by SIGTRAP +++


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 10:00                 ` Florian Schmidt
@ 2004-10-14 10:22                   ` Rui Nuno Capela
  2004-10-14 10:48                     ` Florian Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-14 10:22 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton,
	jackit-devel

 Florian Schmidt wrote:
>
> CC'ed jackit-devel mailing list, cause this might be interesting for them,
> too.
>
> Ah, btw: U0 booted fine here.. Seems to run allright, too (for everything
> non jackd). Only thing is:
>
> When starting jackd i get a floating point exception. Dunno where that
> comes from:
>
> ~$ jackd -d alsa -p 512
> jackd 0.99.0
> Copyright 2001-2003 Paul Davis and others.
> jackd comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
>
> loading driver ..
> creating alsa driver ... hw:0|hw:0|512|2|48000|0|0|nomon|swmeter|-|32bit
> control device hw:0
> configuring for 48000Hz, period = 512 frames, buffer = 2 periods
> Couldn't open hw:0 for 32bit samples trying 24bit instead
> Couldn't open hw:0 for 24bit samples trying 16bit instead
> Couldn't open hw:0 for 32bit samples trying 24bit instead
> Couldn't open hw:0 for 24bit samples trying 16bit instead
> Floating point exception
>

This does not happen on my laptop.

Testing also 2.6.9-rc4-mm1-U0, but a slightly custom jack 0.99.5 (cvs)
patched with "my" max_delayed_usecs suite.

And jackd it's pumping while I'm writing this lines: jackd -R -d alsa,
against bundled crapsound (ali5451).

My laptop is a P4 2.53Ghz, running on Mandrake 10.1c (gcc 3.4.1, glibc
2.3.3 NPTL).

Take care.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 10:22                   ` Rui Nuno Capela
@ 2004-10-14 10:48                     ` Florian Schmidt
  2004-10-14 10:54                       ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-14 10:48 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton,
	jackit-devel

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

On Thu, 14 Oct 2004 11:22:30 +0100 (WEST)
"Rui Nuno Capela" <rncbc@rncbc.org> wrote:

> > Floating point exception
> >
> 
> This does not happen on my laptop.
> 
> Testing also 2.6.9-rc4-mm1-U0, but a slightly custom jack 0.99.5 (cvs)
> patched with "my" max_delayed_usecs suite.
> 
> And jackd it's pumping while I'm writing this lines: jackd -R -d alsa,
> against bundled crapsound (ali5451).
> 
> My laptop is a P4 2.53Ghz, running on Mandrake 10.1c (gcc 3.4.1, glibc
> 2.3.3 NPTL).

Hi,

hmm, it could, of course, be again debian's infamous glibc which bites me in
the ass (as it did with ignoring pthread attributes (which still isn't fixed
afaics)). Which direction should i go with investigating this further? I
will build cvs jackd for a start.

flo

P.S.: attached is my .config

[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 25939 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-rc4-mm1-VP-U0
# Thu Oct 14 10:59:52 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION="-LT"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_PREEMPT_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

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

#
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=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_X86_USE_3DNOW=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
# 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 is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

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

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

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

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD 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=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_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 is not set
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 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=y
# 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

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

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

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

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_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_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_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

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT 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_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM 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_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

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

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set

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

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

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

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_MEMORY is not set
# CONFIG_SND_DEBUG_DETECT 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

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

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY 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_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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=m
CONFIG_RXRPC=m

#
# 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=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
CONFIG_DEBUG_PREEMPT=y
# CONFIG_DEBUG_INFO is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set

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

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 10:48                     ` Florian Schmidt
@ 2004-10-14 10:54                       ` K.R. Foley
  2004-10-14 11:16                         ` Florian Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-14 10:54 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Rui Nuno Capela, Ingo Molnar, linux-kernel, Lee Revell,
	mark_h_johnson, Daniel Walker, Bill Huey, Andrew Morton,
	jackit-devel

Florian Schmidt wrote:
> On Thu, 14 Oct 2004 11:22:30 +0100 (WEST)
> "Rui Nuno Capela" <rncbc@rncbc.org> wrote:
> 
> 
>>>Floating point exception
>>>
>>
>>This does not happen on my laptop.
>>
>>Testing also 2.6.9-rc4-mm1-U0, but a slightly custom jack 0.99.5 (cvs)
>>patched with "my" max_delayed_usecs suite.
>>
>>And jackd it's pumping while I'm writing this lines: jackd -R -d alsa,
>>against bundled crapsound (ali5451).
>>
>>My laptop is a P4 2.53Ghz, running on Mandrake 10.1c (gcc 3.4.1, glibc
>>2.3.3 NPTL).
> 
> 
> Hi,
> 
> hmm, it could, of course, be again debian's infamous glibc which bites me in
> the ass (as it did with ignoring pthread attributes (which still isn't fixed
> afaics)). Which direction should i go with investigating this further? I
> will build cvs jackd for a start.
> 
> flo
> 
> P.S.: attached is my .config

Or maybe this:

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m

For me, anything that needs to use setcap/getcap fails if I don't
compile in security capabilities ie. CONFIG_SECURITY_CAPABILITIES=y.
Don't know if this is your problem or not.

kr


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 10:54                       ` K.R. Foley
@ 2004-10-14 11:16                         ` Florian Schmidt
  2004-10-14 11:23                           ` Florian Schmidt
  2004-10-14 11:42                           ` Florian Schmidt
  0 siblings, 2 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-14 11:16 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Rui Nuno Capela, Ingo Molnar, linux-kernel, Lee Revell,
	mark_h_johnson, Daniel Walker, Bill Huey, Andrew Morton,
	jackit-devel

On Thu, 14 Oct 2004 05:54:46 -0500
"K.R. Foley" <kr@cybsft.com> wrote:

> > P.S.: attached is my .config
> 
> Or maybe this:
> 
> #
> # Security options
> #
> # CONFIG_KEYS is not set
> CONFIG_SECURITY=y
> # CONFIG_SECURITY_NETWORK is not set
> CONFIG_SECURITY_CAPABILITIES=m
> 
> For me, anything that needs to use setcap/getcap fails if I don't
> compile in security capabilities ie. CONFIG_SECURITY_CAPABILITIES=y.
> Don't know if this is your problem or not.

nah, this worked very well for all other versions of the VP patches. right
now i'm building U0 w/o PREEMPT_REALTIME, to see if i still get the
exception.

flo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 11:16                         ` Florian Schmidt
@ 2004-10-14 11:23                           ` Florian Schmidt
  2004-10-14 11:42                           ` Florian Schmidt
  1 sibling, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-14 11:23 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: K.R. Foley, Rui Nuno Capela, Ingo Molnar, linux-kernel,
	Lee Revell, mark_h_johnson, Daniel Walker, Bill Huey,
	Andrew Morton, jackit-devel

> nah, this worked very well for all other versions of the VP patches. right
> now i'm building U0 w/o PREEMPT_REALTIME, to see if i still get the
> exception.
> 

jackd seems to work fine w/o PREEMPT_REALTIME (otherwise identical config).

flo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 11:16                         ` Florian Schmidt
  2004-10-14 11:23                           ` Florian Schmidt
@ 2004-10-14 11:42                           ` Florian Schmidt
  2004-10-14 13:33                             ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-14 11:42 UTC (permalink / raw)
  To: Florian Schmidt; +Cc: Ingo Molnar, linux-kernel, jackit-devel

> nah, this worked very well for all other versions of the VP patches. right
> now i'm building U0 w/o PREEMPT_REALTIME, to see if i still get the
> exception.
> 

jackd seems to work fine w/o PREEMPT_REALTIME (otherwise identical config).

flo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 11:42                           ` Florian Schmidt
@ 2004-10-14 13:33                             ` Florian Schmidt
  0 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-14 13:33 UTC (permalink / raw)
  To: Florian Schmidt; +Cc: Ingo Molnar, linux-kernel

On Thu, 14 Oct 2004 13:42:50 +0200
Florian Schmidt <mista.tapas@gmx.net> wrote:

> > nah, this worked very well for all other versions of the VP patches. right
> > now i'm building U0 w/o PREEMPT_REALTIME, to see if i still get the
> > exception.
> > 
> 
> jackd seems to work fine w/o PREEMPT_REALTIME (otherwise identical config).

err, sorry, shouldn't have cc'ed to jackit-devel as it's subscribers only.
sorry for that.. Ah, there's nothing better than making a complete ass out
of oneself :)

flo

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

* [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
                               ` (3 preceding siblings ...)
  2004-10-14  8:57             ` Florian Schmidt
@ 2004-10-14 14:31             ` Ingo Molnar
  2004-10-14 17:34               ` Adam Heath
                                 ` (7 more replies)
  2004-10-14 18:52             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Daniel Walker
                               ` (3 subsequent siblings)
  8 siblings, 8 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14 14:31 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Dipankar Sarma


i have released the -U1 PREEMPT_REALTIME patch:
 
  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U1

this is a strict bugfixes-only release. With -U1 i cannot reproduce any
of the bugs on my testsystems anymore, but take care nevertheless, this
is still experimental code.

Changes since -U0:

 - bugfix: fixed the highmem related crash reported by Adam Heath and i 
   think this could also fix the crash reported by Mark H Johnson.

 - bugfix: fixed a number of networking related soft-lockups, caused by
   a deadlock scenarios in the ipv4, netfilter and net-xmit locking
   code. This could fix the lockup reported by Lorenzo Allegrucci.

 - bugfix: enable interrupts in the int3 handler - gdb will otherwise
   trigger a kernel debug message.

 - cleanup: reworked the RCU API wrappers, we now have the following
   variants:
 
     rcu_read_[un]lock_spin(&spinlock)
     rcu_read_[un]lock_bh_spin(&spinlock)
     rcu_read_[un]lock_sem(&semaphore)

   this change was necessary for the network locking fixes.

 - debugging helper: SysRq-T will now print the stacktrace of currently
   running tasks too. (They might be a bit unreliable occasionally but
   very useful to debug deadlocks.)

 - configurability fix: disabled the /proc/kernel/softirq_preemption and
   hardirq_preemption runtime flags (and the softirq-preempt= and
   hardirq-preempt= boot flags) if PREEMPT_REALTIME is enabled - in the
   fully preemptible model these must always be on.

there are no known bugs at this moment, so please re-report any issues 
you might still encounter.

to create a -U1 tree from scratch the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U1

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-14 14:31             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Ingo Molnar
@ 2004-10-14 17:34               ` Adam Heath
  2004-10-14 22:16                 ` Adam Heath
  2004-10-14 19:42               ` Daniel Walker
                                 ` (6 subsequent siblings)
  7 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-14 17:34 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Thu, 14 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U1 PREEMPT_REALTIME patch:
>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U1
>
> Changes since -U0:
>
>  - bugfix: fixed the highmem related crash reported by Adam Heath and i
>    think this could also fix the crash reported by Mark H Johnson.

I've reenabled highmem(4g).

Seems to be working fine.  Has been running 11 minutes, without problems.

ps: Something that irks me.  During bootup, I get the high-latency traces for
    swapper/0.  These fill up the dmesg ring buffer, so the early messages get
    dropped.  Is there anything that can be done to fix that?

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  9:19               ` Ingo Molnar
  2004-10-14  9:42                 ` Florian Schmidt
  2004-10-14 10:00                 ` Florian Schmidt
@ 2004-10-14 17:43                 ` Miquel van Smoorenburg
  2 siblings, 0 replies; 951+ messages in thread
From: Miquel van Smoorenburg @ 2004-10-14 17:43 UTC (permalink / raw)
  To: linux-kernel

In article <20041014091953.GA21635@elte.hu>,
Ingo Molnar  <mingo@elte.hu> wrote:
>In -U0 this is not possible because 'ps -C' does not handle kernel
>threads with a space in their name. So there you'd need some wacky thing
>like:
>
>   chrt -f 60 -p `ps ax -o pid= -o comm= | grep "IRQ 1$" | cut -dI -f1`
>   chrt -f 60 -p `ps ax -o pid= -o comm= | grep "IRQ 8$" | cut -dI -f1`
>
>(someone should fix procps - or does it intentionally break with
>whitespace command-strings?)

Why not use ` pgrep -x 'IRQ 1' `. It's part of procps (at least
the version debian, even woody, is using), some kind of standard
(solaris has it too), and works.

Mike.
-- 
"In times of universal deceit, telling the truth becomes
 a revolutionary act." -- George Orwell.


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
                               ` (4 preceding siblings ...)
  2004-10-14 14:31             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Ingo Molnar
@ 2004-10-14 18:52             ` Daniel Walker
  2004-10-14 19:28               ` Ingo Molnar
  2004-10-14 20:30               ` Bill Huey
  2004-10-14 20:02             ` Daniel Walker
                               ` (2 subsequent siblings)
  8 siblings, 2 replies; 951+ messages in thread
From: Daniel Walker @ 2004-10-14 18:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Andrew Morton

On Wed, 2004-10-13 at 17:24, Ingo Molnar wrote:
> To solve all these fundamental problems, i improved/fixed/changed all of
> these locking methods to be preemption-friendly. Most of the time it was
> necessary to introduce an additional API variant because e.g.
> rcu_read_lock() is anonymous (it doesnt identify the data protected), so
> i introduced a variant that takes the write-lock as an argument. In the
> PREEMPT_REALTIME case we can thus properly serialize on that lock.

When I was reviewing this it seemed like it would be possible to keep
RCU anonymous by moving the callback processing out of the tasklet . The
reason it was moved into a tasklet was to reduce latency. But if you
serialize it like you have, aren't you removing all the benefits of the
RCU type lock in those section that are converted to the new API ?


> For per-cpu variables i introduced a new API variant that creates a
> spinlock-array for the per-cpu-variable, and users must make sure the
> cpu field doesnt change. Migration to another CPU can happen within the
> critical section, but 'statistically' the variable is still per-CPU and
> update correctness is fully preserved.

Why not have a per cpu mutex instead of a per variable per cpu mutex?
I'm not sure what the trade off are, except size.




Daniel


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 18:52             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Daniel Walker
@ 2004-10-14 19:28               ` Ingo Molnar
  2004-10-14 19:43                 ` Dipankar Sarma
  2004-10-14 20:30               ` Bill Huey
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14 19:28 UTC (permalink / raw)
  To: Daniel Walker
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Andrew Morton, Dipankar Sarma


* Daniel Walker <dwalker@mvista.com> wrote:

> When I was reviewing this it seemed like it would be possible to keep
> RCU anonymous by moving the callback processing out of the tasklet .
> The reason it was moved into a tasklet was to reduce latency. But if
> you serialize it like you have, aren't you removing all the benefits
> of the RCU type lock in those section that are converted to the new
> API ?

only if compiling for PREEMPT_REALTIME. Given the overhead of
PREEMPT_REALTIME i'm not sure RCU matters that much. But the nicest
would be Dipankar's preemptible-RCU patch.

> > For per-cpu variables i introduced a new API variant that creates a
> > spinlock-array for the per-cpu-variable, and users must make sure the
> > cpu field doesnt change. Migration to another CPU can happen within the
> > critical section, but 'statistically' the variable is still per-CPU and
> > update correctness is fully preserved.
> 
> Why not have a per cpu mutex instead of a per variable per cpu mutex?
> I'm not sure what the trade off are, except size.

well, nesting would be one issue. What if such a section gets preempted
on this CPU and another task tries to use the same mutex? 
Per-var-per-cpu mutexes seemed like the most orthogonal extension to the
existing concept. Keeping the original Linux locking semantics intact
seems like the primary mission, at least until the full scope is mapped.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-14 14:31             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Ingo Molnar
  2004-10-14 17:34               ` Adam Heath
@ 2004-10-14 19:42               ` Daniel Walker
  2004-10-14 19:57                 ` Ingo Molnar
       [not found]               ` <200410142216.23572.l_allegrucci@yahoo.it>
                                 ` (5 subsequent siblings)
  7 siblings, 1 reply; 951+ messages in thread
From: Daniel Walker @ 2004-10-14 19:42 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel


This was during NFS startup in init.



using smp_processor_id() in preemptible [00000001] code:
rpc.rquotad/2158
caller is ipt_do_table+0x7b/0x3a0
 [<c011aa15>] smp_processor_id+0x95/0xa0
 [<c038cbfb>] ipt_do_table+0x7b/0x3a0
 [<c038aa8b>] ip_ct_refresh_acct+0xb/0x80
 [<c038f1d4>] ipt_local_hook+0x74/0xc0
 [<c034d73a>] nf_iterate+0x5a/0xa0
 [<c035af00>] dst_output+0x0/0x40
 [<c034da3c>] nf_hook_slow+0x5c/0x100
 [<c035af00>] dst_output+0x0/0x40
 [<c035aaf4>] ip_push_pending_frames+0x414/0x480
 [<c035af00>] dst_output+0x0/0x40
 [<c0377c88>] udp_push_pending_frames+0x148/0x260
 [<c0378178>] udp_sendmsg+0x378/0x6e0
 [<c0134c73>] __mcount+0x13/0x20
 [<c037f7bc>] inet_sendmsg+0x3c/0x60
 [<c03397d8>] sock_sendmsg+0xb8/0xe0
 [<c0134c73>] __mcount+0x13/0x20
 [<c0134c73>] __mcount+0x13/0x20
 [<c0113d30>] mcount+0x14/0x18
 [<c020172a>] __copy_from_user_ll+0xa/0x40
 [<c0133d00>] autoremove_wake_function+0x0/0x60
 [<c03391ef>] move_addr_to_kernel+0x2f/0x60
 [<c033ab36>] sys_sendto+0xd6/0x100
 [<c033d144>] sock_common_setsockopt+0x24/0x40
 [<c0134c73>] __mcount+0x13/0x20
 [<c020172a>] __copy_from_user_ll+0xa/0x40
 [<c0201803>] copy_from_user+0x43/0x80
 [<c0113d30>] mcount+0x14/0x18
 [<c020172a>] __copy_from_user_ll+0xa/0x40
 [<c033b297>] sys_socketcall+0xf7/0x180
 [<c01176a0>] do_page_fault+0x0/0x62a
 [<c0105357>] syscall_call+0x7/0xb



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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 19:28               ` Ingo Molnar
@ 2004-10-14 19:43                 ` Dipankar Sarma
  0 siblings, 0 replies; 951+ messages in thread
From: Dipankar Sarma @ 2004-10-14 19:43 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Daniel Walker, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Andrew Morton

On Thu, Oct 14, 2004 at 09:28:04PM +0200, Ingo Molnar wrote:
> 
> * Daniel Walker <dwalker@mvista.com> wrote:
> 
> > When I was reviewing this it seemed like it would be possible to keep
> > RCU anonymous by moving the callback processing out of the tasklet .
> > The reason it was moved into a tasklet was to reduce latency. But if
> > you serialize it like you have, aren't you removing all the benefits
> > of the RCU type lock in those section that are converted to the new
> > API ?
> 
> only if compiling for PREEMPT_REALTIME. Given the overhead of
> PREEMPT_REALTIME i'm not sure RCU matters that much. But the nicest
> would be Dipankar's preemptible-RCU patch.
> 

I am swamped this week and racing against time to get some other
pending things done in time. I will look at the issue of RCU with
PREEMPT_REALTIME next week and try to help out.

Thanks
Dipankar

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-14 19:42               ` Daniel Walker
@ 2004-10-14 19:57                 ` Ingo Molnar
  2004-10-14 20:34                   ` Daniel Walker
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14 19:57 UTC (permalink / raw)
  To: Daniel Walker; +Cc: linux-kernel


* Daniel Walker <dwalker@mvista.com> wrote:

> This was during NFS startup in init.
> 
> using smp_processor_id() in preemptible [00000001] code:
> rpc.rquotad/2158
> caller is ipt_do_table+0x7b/0x3a0
>  [<c011aa15>] smp_processor_id+0x95/0xa0
>  [<c038cbfb>] ipt_do_table+0x7b/0x3a0

ugh, this is a nasty one - if you look at the TABLE_OFFSET trickery in
ipt_do_table it's basically an open-coded per-CPU variable in essence. 
(probably predating percpu.h so it's fair.) Could you try the quick hack
below? (it compiles but is otherwise untested)

The proper solution would be to change the code to use per-cpu variables
(and get that patch accepted upstream) and then trivially convert it to
get_cpu_var_locked().

	Ingo

--- linux/net/ipv4/netfilter/ip_tables.c.orig
+++ linux/net/ipv4/netfilter/ip_tables.c
@@ -287,10 +287,14 @@ ipt_do_table(struct sk_buff **pskb,
 	 * match it. */
 	offset = ntohs(ip->frag_off) & IP_OFFSET;
 
+#ifdef CONFIG_PREEMPT_REALTIME
+	write_lock_bh(&table->lock);
+#else
 	read_lock_bh(&table->lock);
+#endif
 	IP_NF_ASSERT(table->valid_hooks & (1 << hook));
 	table_base = (void *)table->private->entries
-		+ TABLE_OFFSET(table->private, smp_processor_id());
+		+ TABLE_OFFSET(table->private, _smp_processor_id());
 	e = get_entry(table_base, table->private->hook_entry[hook]);
 
 #ifdef CONFIG_NETFILTER_DEBUG
@@ -397,7 +401,11 @@ ipt_do_table(struct sk_buff **pskb,
 #ifdef CONFIG_NETFILTER_DEBUG
 	((struct ipt_entry *)table_base)->comefrom = 0xdead57ac;
 #endif
+#ifdef CONFIG_PREEMPT_REALTIME
+	write_unlock_bh(&table->lock);
+#else
 	read_unlock_bh(&table->lock);
+#endif
 
 #ifdef DEBUG_ALLOW_ALL
 	return NF_ACCEPT;

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
                               ` (5 preceding siblings ...)
  2004-10-14 18:52             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Daniel Walker
@ 2004-10-14 20:02             ` Daniel Walker
  2004-10-14 20:23               ` Ingo Molnar
  2004-10-14 22:13             ` Radoslaw Szkodzinski
  2004-10-14 22:40             ` Karim Yaghmour
  8 siblings, 1 reply; 951+ messages in thread
From: Daniel Walker @ 2004-10-14 20:02 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Andrew Morton

I'm not sure about this one ..


------------[ cut here ]------------
kernel BUG at fs/buffer.c:1360!
invalid operand: 0000 [#1]
PREEMPT SMP
Modules linked in:
CPU:    0
EIP:    0060:[<c01619c1>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-VP-U1)
EIP is at __find_get_block+0xe1/0x100
eax: 00000001   ebx: cfd30c14   ecx: cffdc600   edx: 00000000
esi: 0005709b   edi: 00000000   ebp: cfd30b70   esp: cfd30b54
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process kjournald (pid: 786, threadinfo=cfd30000 task=cfd26040)
Stack: 00000002 00000000 0005709b 00000000 cfd30c14 0005709b 00000000
cfd30b94
       c01619fe cffeab80 0005709b 00000000 00001000 cfd30c14 00000002
cfd30c44
       cfd30bac c0161a99 cffeab80 0005709b 00000000 00001000 cfd30bd4
c019aff0
Call Trace:
 [<c01619fe>] __getblk+0x1e/0x60
 [<c0161a99>] __bread+0x19/0x40
 [<c019aff0>] ext3_get_branch+0x70/0x100
 [<c019b61a>] ext3_get_block_handle+0x7a/0x2e0
 [<c026b1ee>] as_choose_req+0xe/0x1e0
 [<c026bc5f>] as_update_arq+0x1f/0x60
 [<c019b8c3>] ext3_get_block+0x43/0x80
 [<c0163735>] generic_block_bmap+0x35/0x40
 [<c0134c73>] __mcount+0x13/0x20
 [<c019c26d>] ext3_bmap+0xd/0xa0
 [<c01797c5>] bmap+0x45/0x60
 [<c019c2dc>] ext3_bmap+0x7c/0xa0
 [<c019b880>] ext3_get_block+0x0/0x80
 [<c01797c5>] bmap+0x45/0x60
 [<c01af8c2>] journal_bmap+0x42/0xa0
 [<c0134c73>] __mcount+0x13/0x20
 [<c0134249>] _mutex_unlock+0x9/0x60
 [<c01af827>] journal_next_log_block+0x47/0xa0
 [<c0113d30>] mcount+0x14/0x18
 [<c01af832>] journal_next_log_block+0x52/0xa0
 [<c01af939>] journal_get_descriptor_buffer+0x19/0xc0
 [<c01ac4ec>] journal_commit_transaction+0xf6c/0x13e0
 [<c01aedee>] kjournald+0xce/0x260
 [<c013555c>] sub_preempt_count+0x7c/0xa0
 [<c0133d00>] autoremove_wake_function+0x0/0x60
 [<c03b2a33>] _spin_unlock_irq+0x13/0x40
 [<c0133d00>] autoremove_wake_function+0x0/0x60
 [<c0119459>] schedule_tail+0x19/0x60
 [<c01aece0>] commit_timeout+0x0/0x20
 [<c01aed20>] kjournald+0x0/0x260
 [<c0103339>] kernel_thread_helper+0x5/0xc
Code: 45 14 39 43 10 75 a0 85 ff 74 17 8b 45 e4 89 f9 8d 14 b8 8b 42 fc
89 02 83 ea 04
                                                                                      


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
       [not found]               ` <200410142216.23572.l_allegrucci@yahoo.it>
@ 2004-10-14 20:21                 ` Lee Revell
  0 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-14 20:21 UTC (permalink / raw)
  To: Lorenzo Allegrucci
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Dipankar Sarma

On Thu, 2004-10-14 at 16:16, Lorenzo Allegrucci wrote:
> BTW, I'm getting a lot of "scheduling while atomic" messages
> running LTP's runalltests.sh -x 200.
> Attached is the kern.log and the latency trace.

Looks like that latency trace is mostly printk overhead from the
scheduling while atomic errors.  In general, if you are still getting
lots of printks in your logs due to bugs, the latency traces are not
very useful.

Lee


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 20:02             ` Daniel Walker
@ 2004-10-14 20:23               ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14 20:23 UTC (permalink / raw)
  To: Daniel Walker
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Andrew Morton


* Daniel Walker <dwalker@mvista.com> wrote:

> I'm not sure about this one ..
> 
> ------------[ cut here ]------------
> kernel BUG at fs/buffer.c:1360!

> EIP is at __find_get_block+0xe1/0x100

> Call Trace:
>  [<c01619fe>] __getblk+0x1e/0x60
>  [<c0161a99>] __bread+0x19/0x40
>  [<c019aff0>] ext3_get_branch+0x70/0x100
>  [<c019b61a>] ext3_get_block_handle+0x7a/0x2e0
>  [<c026b1ee>] as_choose_req+0xe/0x1e0
>  [<c026bc5f>] as_update_arq+0x1f/0x60
>  [<c019b8c3>] ext3_get_block+0x43/0x80
>  [<c0163735>] generic_block_bmap+0x35/0x40
>  [<c0134c73>] __mcount+0x13/0x20
>  [<c019c26d>] ext3_bmap+0xd/0xa0
>  [<c01797c5>] bmap+0x45/0x60
>  [<c019c2dc>] ext3_bmap+0x7c/0xa0
>  [<c019b880>] ext3_get_block+0x0/0x80
>  [<c01797c5>] bmap+0x45/0x60
>  [<c01af8c2>] journal_bmap+0x42/0xa0
>  [<c0134c73>] __mcount+0x13/0x20
>  [<c0134249>] _mutex_unlock+0x9/0x60
>  [<c01af827>] journal_next_log_block+0x47/0xa0
>  [<c0113d30>] mcount+0x14/0x18
>  [<c01af832>] journal_next_log_block+0x52/0xa0
>  [<c01af939>] journal_get_descriptor_buffer+0x19/0xc0
>  [<c01ac4ec>] journal_commit_transaction+0xf6c/0x13e0
>  [<c01aedee>] kjournald+0xce/0x260
>  [<c013555c>] sub_preempt_count+0x7c/0xa0
>  [<c0133d00>] autoremove_wake_function+0x0/0x60
>  [<c03b2a33>] _spin_unlock_irq+0x13/0x40
>  [<c0133d00>] autoremove_wake_function+0x0/0x60
>  [<c0119459>] schedule_tail+0x19/0x60
>  [<c01aece0>] commit_timeout+0x0/0x20
>  [<c01aed20>] kjournald+0x0/0x260
>  [<c0103339>] kernel_thread_helper+0x5/0xc

this is a weird one. This is the first message, right? I've reviewed
bh_lru_lock/unlock and cannot spot anything that could be wrong there.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-14 14:31             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Ingo Molnar
                                 ` (2 preceding siblings ...)
       [not found]               ` <200410142216.23572.l_allegrucci@yahoo.it>
@ 2004-10-14 20:28               ` Lorenzo Allegrucci
  2004-10-14 20:39               ` K.R. Foley
                                 ` (3 subsequent siblings)
  7 siblings, 0 replies; 951+ messages in thread
From: Lorenzo Allegrucci @ 2004-10-14 20:28 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Dipankar Sarma

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


gzipped latecy_trace this time, sorry.

On Thursday 14 October 2004 16:31, Ingo Molnar wrote:
> 
> i have released the -U1 PREEMPT_REALTIME patch:
>  
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U1
> 
> this is a strict bugfixes-only release. With -U1 i cannot reproduce any
> of the bugs on my testsystems anymore, but take care nevertheless, this
> is still experimental code.
> 
> Changes since -U0:
> 
>  - bugfix: fixed the highmem related crash reported by Adam Heath and i 
>    think this could also fix the crash reported by Mark H Johnson.
> 
>  - bugfix: fixed a number of networking related soft-lockups, caused by
>    a deadlock scenarios in the ipv4, netfilter and net-xmit locking
>    code. This could fix the lockup reported by Lorenzo Allegrucci.

Yes, -U1 seems to have fixed it for me.

BTW, I'm getting a lot of "scheduling while atomic" messages
running LTP's runalltests.sh -x 200.
Attached is the kern.log and the latency trace.

-- 
I route therefore you are

[-- Attachment #2: kern.log.gz --]
[-- Type: application/x-gzip, Size: 5147 bytes --]

[-- Attachment #3: latency_trace.gz --]
[-- Type: application/x-gzip, Size: 13754 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 18:52             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Daniel Walker
  2004-10-14 19:28               ` Ingo Molnar
@ 2004-10-14 20:30               ` Bill Huey
  1 sibling, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-14 20:30 UTC (permalink / raw)
  To: Daniel Walker
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Andrew Morton

On Thu, Oct 14, 2004 at 11:52:52AM -0700, Daniel Walker wrote:
> When I was reviewing this it seemed like it would be possible to keep
> RCU anonymous by moving the callback processing out of the tasklet . The
> reason it was moved into a tasklet was to reduce latency. But if you
> serialize it like you have, aren't you removing all the benefits of the
> RCU type lock in those section that are converted to the new API ?
 
What Ingo is doing now is mostly like a temporary fix for dealing with
this issue. Simple backing with a normal mutex should be sufficient for
protecting that access. RCU is still an open problem.

> Why not have a per cpu mutex instead of a per variable per cpu mutex?
> I'm not sure what the trade off are, except size.

It's a read-mostly read/write lock. N number of real processors can
do N number of read locks. That structure needs to be emulated somehow
and a per CPU mutex is probably the correct method of getting it.
It's just a matter of how. I did suggest something in my project
announcement.

I don't know if it's crack smoking or not. :)

bill


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-14 19:57                 ` Ingo Molnar
@ 2004-10-14 20:34                   ` Daniel Walker
  0 siblings, 0 replies; 951+ messages in thread
From: Daniel Walker @ 2004-10-14 20:34 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel



This fixed it..


Daniel


On Thu, 2004-10-14 at 12:57, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
> 
> > This was during NFS startup in init.
> > 
> > using smp_processor_id() in preemptible [00000001] code:
> > rpc.rquotad/2158
> > caller is ipt_do_table+0x7b/0x3a0
> >  [<c011aa15>] smp_processor_id+0x95/0xa0
> >  [<c038cbfb>] ipt_do_table+0x7b/0x3a0
> 
> ugh, this is a nasty one - if you look at the TABLE_OFFSET trickery in
> ipt_do_table it's basically an open-coded per-CPU variable in essence. 
> (probably predating percpu.h so it's fair.) Could you try the quick hack
> below? (it compiles but is otherwise untested)
> 
> The proper solution would be to change the code to use per-cpu variables
> (and get that patch accepted upstream) and then trivially convert it to
> get_cpu_var_locked().
> 
> 	Ingo
> 
> --- linux/net/ipv4/netfilter/ip_tables.c.orig
> +++ linux/net/ipv4/netfilter/ip_tables.c
> @@ -287,10 +287,14 @@ ipt_do_table(struct sk_buff **pskb,
>  	 * match it. */
>  	offset = ntohs(ip->frag_off) & IP_OFFSET;
>  
> +#ifdef CONFIG_PREEMPT_REALTIME
> +	write_lock_bh(&table->lock);
> +#else
>  	read_lock_bh(&table->lock);
> +#endif
>  	IP_NF_ASSERT(table->valid_hooks & (1 << hook));
>  	table_base = (void *)table->private->entries
> -		+ TABLE_OFFSET(table->private, smp_processor_id());
> +		+ TABLE_OFFSET(table->private, _smp_processor_id());
>  	e = get_entry(table_base, table->private->hook_entry[hook]);
>  
>  #ifdef CONFIG_NETFILTER_DEBUG
> @@ -397,7 +401,11 @@ ipt_do_table(struct sk_buff **pskb,
>  #ifdef CONFIG_NETFILTER_DEBUG
>  	((struct ipt_entry *)table_base)->comefrom = 0xdead57ac;
>  #endif
> +#ifdef CONFIG_PREEMPT_REALTIME
> +	write_unlock_bh(&table->lock);
> +#else
>  	read_unlock_bh(&table->lock);
> +#endif
>  
>  #ifdef DEBUG_ALLOW_ALL
>  	return NF_ACCEPT;


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-14 14:31             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Ingo Molnar
                                 ` (3 preceding siblings ...)
  2004-10-14 20:28               ` Lorenzo Allegrucci
@ 2004-10-14 20:39               ` K.R. Foley
  2004-10-14 22:52               ` Radoslaw Szkodzinski
                                 ` (2 subsequent siblings)
  7 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-14 20:39 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Dipankar Sarma

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

Ingo Molnar wrote:
> i have released the -U1 PREEMPT_REALTIME patch:
>  
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U1
> 
> this is a strict bugfixes-only release. With -U1 i cannot reproduce any
> of the bugs on my testsystems anymore, but take care nevertheless, this
> is still experimental code.
> 

Got this one running on my SMP workstation FINALLY. The problems that I 
have been having with the keyboard not working goes away if I compile in 
CONFIG_SERIO_PCIPS2 instead of making it a module. :-/ Anyway I am 
getting some "using smp_processor_id messages" all of which seem to be 
getting generated from ip_tables as in:



[-- Attachment #2: smpdump.txt --]
[-- Type: text/plain, Size: 3617 bytes --]

Oct 14 15:35:52 swdev14 kernel: using smp_processor_id() in preemptible [00000001] code: thunderbird-bin/3933
Oct 14 15:35:52 swdev14 kernel: caller is ipt_do_table+0x79/0x335 [ip_tables]
Oct 14 15:35:52 swdev14 kernel:  [<c011878e>] smp_processor_id+0xa8/0xb9
Oct 14 15:35:52 swdev14 kernel:  [<e08550a8>] ipt_do_table+0x79/0x335 [ip_tables]
Oct 14 15:35:52 swdev14 kernel:  [<e08550a8>] ipt_do_table+0x79/0x335 [ip_tables]
Oct 14 15:35:52 swdev14 kernel:  [<e09ba0b5>] ipt_local_out_hook+0x76/0x79 [iptable_filter]
Oct 14 15:35:52 swdev14 kernel:  [<c02394ea>] nf_iterate+0x70/0xa1
Oct 14 15:35:52 swdev14 kernel:  [<c024ef4f>] dst_output+0x0/0x2f
Oct 14 15:35:52 swdev14 kernel:  [<c023982d>] nf_hook_slow+0x79/0x126
Oct 14 15:35:52 swdev14 kernel:  [<c024ef4f>] dst_output+0x0/0x2f
Oct 14 15:35:52 swdev14 kernel:  [<c024cfe2>] ip_queue_xmit+0x495/0x59e
Oct 14 15:35:52 swdev14 kernel:  [<c024ef4f>] dst_output+0x0/0x2f
Oct 14 15:35:52 swdev14 kernel:  [<c01325d5>] __mcount+0x1d/0x21
Oct 14 15:35:52 swdev14 kernel:  [<c0298716>] _spin_unlock_irq+0xb/0x35
Oct 14 15:35:52 swdev14 kernel:  [<c01171e7>] finish_task_switch+0x3c/0x85
Oct 14 15:35:52 swdev14 kernel:  [<c0111d1c>] mcount+0x14/0x18
Oct 14 15:35:52 swdev14 kernel:  [<c01325d5>] __mcount+0x1d/0x21
Oct 14 15:35:52 swdev14 kernel:  [<c0263c48>] tcp_v4_send_check+0xe/0xe2
Oct 14 15:35:52 swdev14 kernel:  [<c025d95b>] tcp_transmit_skb+0x435/0x85b
Oct 14 15:35:52 swdev14 kernel:  [<c0111d1c>] mcount+0x14/0x18
Oct 14 15:35:52 swdev14 kernel:  [<c0263c48>] tcp_v4_send_check+0xe/0xe2
Oct 14 15:35:52 swdev14 kernel:  [<c025da07>] tcp_transmit_skb+0x4e1/0x85b
Oct 14 15:35:52 swdev14 kernel:  [<c01af5ee>] memcpy+0x12/0x3c
Oct 14 15:35:52 swdev14 kernel:  [<c025e830>] tcp_write_xmit+0x14c/0x2c6
Oct 14 15:35:52 swdev14 kernel:  [<c0252608>] tcp_sendmsg+0x50d/0x10a7
Oct 14 15:35:52 swdev14 kernel:  [<c0111d1c>] mcount+0x14/0x18
Oct 14 15:35:52 swdev14 kernel:  [<c02525dc>] tcp_sendmsg+0x4e1/0x10a7
Oct 14 15:35:52 swdev14 kernel:  [<c0224f0e>] sock_sendmsg+0xfa/0xfc
Oct 14 15:35:52 swdev14 kernel:  [<c0274665>] inet_sendmsg+0x50/0x5b
Oct 14 15:35:52 swdev14 kernel:  [<c0224f0e>] sock_sendmsg+0xfa/0xfc
Oct 14 15:35:52 swdev14 kernel:  [<c01325d5>] __mcount+0x1d/0x21
Oct 14 15:35:52 swdev14 kernel:  [<c01af10e>] find_next_bit+0x16/0x92
Oct 14 15:35:52 swdev14 kernel:  [<c0117b37>] find_busiest_group+0xd4/0x2e0
Oct 14 15:35:52 swdev14 kernel:  [<c0131d20>] _mutex_unlock+0xe/0x5e
Oct 14 15:35:52 swdev14 kernel:  [<c0111d1c>] mcount+0x14/0x18
Oct 14 15:35:52 swdev14 kernel:  [<c0131d20>] _mutex_unlock+0xe/0x5e
Oct 14 15:35:52 swdev14 kernel:  [<c0131cba>] _mutex_lock+0x29/0x3f
Oct 14 15:35:52 swdev14 kernel:  [<c013186b>] autoremove_wake_function+0x0/0x57
Oct 14 15:35:52 swdev14 kernel:  [<c0224c69>] sockfd_lookup+0x1f/0x74
Oct 14 15:35:52 swdev14 kernel:  [<c0111d1c>] mcount+0x14/0x18
Oct 14 15:35:52 swdev14 kernel:  [<c0226493>] sys_sendto+0xed/0x10c
Oct 14 15:35:52 swdev14 kernel:  [<c0173221>] inode_times_differ+0x9/0x4a
Oct 14 15:35:52 swdev14 kernel:  [<c017332a>] update_atime+0xc8/0xcd
Oct 14 15:35:52 swdev14 kernel:  [<c01325d5>] __mcount+0x1d/0x21
Oct 14 15:35:52 swdev14 kernel:  [<c02264bd>] sys_send+0xb/0x3f
Oct 14 15:35:52 swdev14 kernel:  [<c0226d5e>] sys_socketcall+0x12e/0x239
Oct 14 15:35:52 swdev14 kernel:  [<c0111d1c>] mcount+0x14/0x18
Oct 14 15:35:52 swdev14 kernel:  [<c02264ed>] sys_send+0x3b/0x3f
Oct 14 15:35:52 swdev14 kernel:  [<c0226d5e>] sys_socketcall+0x12e/0x239
Oct 14 15:35:52 swdev14 kernel:  [<c0158cdd>] sys_read+0x78/0x7a
Oct 14 15:35:52 swdev14 kernel:  [<c0106161>] sysenter_past_esp+0x52/0x71

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
                               ` (6 preceding siblings ...)
  2004-10-14 20:02             ` Daniel Walker
@ 2004-10-14 22:13             ` Radoslaw Szkodzinski
  2004-10-14 22:40             ` Karim Yaghmour
  8 siblings, 0 replies; 951+ messages in thread
From: Radoslaw Szkodzinski @ 2004-10-14 22:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, mark_h_johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton

On Thu, 14 Oct 2004 02:24:33 +0200, Ingo Molnar <mingo@elte.hu> wrote:
> 
> i'm pleased to announce a significantly improved version of the
> Real-Time Preemption (PREEMPT_REALTIME) feature that i have been working
> towards in the past couple of weeks.
> 
> the patch (against 2.6.9-rc4-mm1) can be downloaded from:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U0
> 

I'm getting some scheduling_while_atomic messages concerning Reiser4.
They're non-fatal, please look into them.

scheduling while atomic: rc/0x04000001/908
caller is cond_resched+0x4c/0x69
 [<c0105666>] dump_stack+0x1e/0x20
 [<c035e40c>] schedule+0x94/0x3f9
 [<c035ec0d>] cond_resched+0x4c/0x69
 [<c012bda7>] _rw_mutex_read_lock+0x1f/0x33
 [<c019e7dd>] cbk_cache_scan_slots+0x5c/0x276
 [<c019ea22>] cbk_cache_search+0x2b/0x5e
 [<c019d84d>] coord_by_handle+0x12/0x29
 [<c019d831>] object_lookup+0xce/0xd8
 [<c01c8dad>] find_entry+0x123/0x2b7
 [<c01c788d>] lookup_name_hashed+0xc3/0x143
 [<c01c7997>] lookup_hashed+0x3e/0xc0
 [<c01a6bdd>] reiser4_lookup+0x83/0x10e
 [<c015e02c>] real_lookup+0x74/0xf4
 [<c015e2cb>] do_lookup+0x5e/0x9d
 [<c015ec7c>] link_path_walk+0x972/0xde6
 [<c015f49e>] path_lookup+0x19a/0x1a6
 [<c015f63a>] __user_walk+0x31/0x53
 [<c015a16d>] vfs_stat+0x1e/0x53
 [<c015a890>] sys_stat64+0x19/0x32
 [<c010509d>] sysenter_past_esp+0x52/0x71
scheduling while atomic: sh/0x04000001/4346
caller is cond_resched+0x4c/0x69
 [<c0105666>] dump_stack+0x1e/0x20
 [<c035e40c>] schedule+0x94/0x3f9
 [<c035ec0d>] cond_resched+0x4c/0x69
 [<c012bda7>] _rw_mutex_read_lock+0x1f/0x33
 [<c019e7dd>] cbk_cache_scan_slots+0x5c/0x276
 [<c019ea22>] cbk_cache_search+0x2b/0x5e
 [<c019d84d>] coord_by_handle+0x12/0x29
 [<c019d831>] object_lookup+0xce/0xd8
 [<c01cfc83>] find_file_item+0x127/0x1bc
 [<c01d1b2e>] read_unix_file+0x2e4/0x48d
 [<c01a74e8>] reiser4_read+0x90/0xaf
 [<c0150abb>] vfs_read+0xe0/0x126
 [<c015b39d>] kernel_read+0x4a/0x57
 [<c017aaeb>] load_elf_binary+0x303/0xba1
 [<c015bfe2>] search_binary_handler+0xd6/0x1f1
 [<c015c2fb>] do_execve+0x1fe/0x2af
 [<c0103c1c>] sys_execve+0x3f/0x91
 [<c010509d>] sysenter_past_esp+0x52/0x71

scheduling while atomic: gcc/0x04000001/5587
caller is cond_resched+0x4c/0x69
 [<c0105666>] dump_stack+0x1e/0x20
 [<c035e40c>] schedule+0x94/0x3f9
 [<c035ec0d>] cond_resched+0x4c/0x69
 [<c012bda7>] _rw_mutex_read_lock+0x1f/0x33
 [<c019e7dd>] cbk_cache_scan_slots+0x5c/0x276
 [<c019ea22>] cbk_cache_search+0x2b/0x5e
 [<c019d84d>] coord_by_handle+0x12/0x29
 [<c019d831>] object_lookup+0xce/0xd8
 [<c01c8dad>] find_entry+0x123/0x2b7
 [<c01c8acb>] rem_entry_hashed+0x75/0x1d5
 [<c01c97cb>] unlink_common+0xd4/0x1ca
 [<c01a6fe0>] unlink_file+0x48/0x75
 [<c01a703a>] reiser4_unlink+0x2d/0x37
 [<c0160d12>] vfs_unlink+0x1d1/0x225
 [<c0160e24>] sys_unlink+0xbe/0x145
 [<c010509d>] sysenter_past_esp+0x52/0x71
scheduling while atomic: xinit/0x04000001/5628
caller is cond_resched+0x4c/0x69
 [<c0105666>] dump_stack+0x1e/0x20
 [<c035e40c>] schedule+0x94/0x3f9
 [<c035ec0d>] cond_resched+0x4c/0x69
 [<c012bda7>] _rw_mutex_read_lock+0x1f/0x33
 [<c019e7dd>] cbk_cache_scan_slots+0x5c/0x276
 [<c019ea22>] cbk_cache_search+0x2b/0x5e
 [<c019d84d>] coord_by_handle+0x12/0x29
 [<c019d831>] object_lookup+0xce/0xd8
 [<c01cfc83>] find_file_item+0x127/0x1bc
 [<c01d1550>] readpage_unix_file+0xb1/0x35b
 [<c01a7961>] reiser4_readpage+0x4d/0x7d
 [<c0134e1e>] page_cache_read+0x72/0xea
 [<c013505d>] filemap_nopage+0x1c7/0x391
 [<c01d21bf>] unix_file_filemap_nopage+0x59/0x84
 [<c01429c9>] do_no_page+0xb5/0x32f
 [<c0142db6>] handle_mm_fault+0x91/0x164
 [<c01133db>] do_page_fault+0x20c/0x654
 [<c0105299>] error_code+0x2d/0x38

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-14 17:34               ` Adam Heath
@ 2004-10-14 22:16                 ` Adam Heath
  2004-10-14 22:24                   ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-14 22:16 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Thu, 14 Oct 2004, Adam Heath wrote:

> On Thu, 14 Oct 2004, Ingo Molnar wrote:
>
> >
> > i have released the -U1 PREEMPT_REALTIME patch:
> >
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U1
> >
> > Changes since -U0:
> >
> >  - bugfix: fixed the highmem related crash reported by Adam Heath and i
> >    think this could also fix the crash reported by Mark H Johnson.
>
> I've reenabled highmem(4g).
>
> Seems to be working fine.  Has been running 11 minutes, without problems.
>
> ps: Something that irks me.  During bootup, I get the high-latency traces for
>     swapper/0.  These fill up the dmesg ring buffer, so the early messages get
>     dropped.  Is there anything that can be done to fix that?

Got my first message.

scheduling while atomic: kswapd0/0x04000001/10
caller is cond_resched+0x53/0x70
 [<c027ad31>] schedule+0x531/0x570
 [<c027b2a3>] cond_resched+0x53/0x70
 [<c012c604>] _mutex_lock+0x14/0x40
 [<c0149521>] page_lock_anon_vma+0x31/0x60
 [<c0149725>] page_referenced_anon+0x15/0x80
 [<c01498ba>] page_referenced+0x7a/0x80
 [<c0141635>] refill_inactive_zone+0x435/0x4b0
 [<c01408a3>] shrink_slab+0x143/0x160
 [<c0141728>] shrink_zone+0x78/0xc0
 [<c0141b7a>] balance_pgdat+0x23a/0x2f0
 [<c0141ced>] kswapd+0xbd/0xf0
 [<c012c140>] autoremove_wake_function+0x0/0x50
 [<c01056d2>] ret_from_fork+0x6/0x14
 [<c012c140>] autoremove_wake_function+0x0/0x50
 [<c0141c30>] kswapd+0x0/0xf0
 [<c0103a2d>] kernel_thread_helper+0x5/0x18

Config is as before, with highmem enabled being the only difference.

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-14 22:16                 ` Adam Heath
@ 2004-10-14 22:24                   ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14 22:24 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


* Adam Heath <doogie@debian.org> wrote:

> > Seems to be working fine.  Has been running 11 minutes, without problems.
> >
> > ps: Something that irks me.  During bootup, I get the high-latency traces for
> >     swapper/0.  These fill up the dmesg ring buffer, so the early messages get
> >     dropped.  Is there anything that can be done to fix that?
> 
> Got my first message.
> 
> scheduling while atomic: kswapd0/0x04000001/10
> caller is cond_resched+0x53/0x70
>  [<c027ad31>] schedule+0x531/0x570
>  [<c027b2a3>] cond_resched+0x53/0x70
>  [<c012c604>] _mutex_lock+0x14/0x40
>  [<c0149521>] page_lock_anon_vma+0x31/0x60

i'm working on this one currently, it's a bit tricky.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
                               ` (7 preceding siblings ...)
  2004-10-14 22:13             ` Radoslaw Szkodzinski
@ 2004-10-14 22:40             ` Karim Yaghmour
  2004-10-14 23:46               ` Ingo Molnar
  8 siblings, 1 reply; 951+ messages in thread
From: Karim Yaghmour @ 2004-10-14 22:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Zanussi, Robert Wisniewski, Richard J Moore,
	Michel Dagenais


Ingo Molnar wrote:
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U0

I notice:
+	local_irq_save(flags);
+	____trace(&__get_cpu_var(trace), eip, parent_eip);
+	local_irq_restore(flags);

Why not use the lockless logging available in relayfs, you'll avoid the
interrupt disabling altogether since, umm ... it's lockless.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-14 14:31             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Ingo Molnar
                                 ` (4 preceding siblings ...)
  2004-10-14 20:39               ` K.R. Foley
@ 2004-10-14 22:52               ` Radoslaw Szkodzinski
  2004-10-14 23:42               ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2 Ingo Molnar
  2004-10-15 11:22               ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Florian Schmidt
  7 siblings, 0 replies; 951+ messages in thread
From: Radoslaw Szkodzinski @ 2004-10-14 22:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, mark_h_johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Dipankar Sarma

On Thu, 14 Oct 2004 16:31:31 +0200, Ingo Molnar <mingo@elte.hu> wrote:
> 
> i have released the -U1 PREEMPT_REALTIME patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U1
> 

"scheduling while atomic" messages in Reiser4 mentioned at -U0 thread
also appear in this version, but less often.

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

* [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-14 14:31             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Ingo Molnar
                                 ` (5 preceding siblings ...)
  2004-10-14 22:52               ` Radoslaw Szkodzinski
@ 2004-10-14 23:42               ` Ingo Molnar
  2004-10-15  0:31                 ` Adam Heath
                                   ` (3 more replies)
  2004-10-15 11:22               ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Florian Schmidt
  7 siblings, 4 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14 23:42 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci


i have released the -U2 PREEMPT_REALTIME patch:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2

this too is a bugfixes-only release, and it is still experimental code.

Changes since -U1:

 - bugfix: fix page_lock_anon_vma() crash reported by Adam Heath and 
   Lorenzo Allegrucci.

 - bugfix: fix selinux atomic-schedule warning messages, reported by
   Mark H Johnson.

 - bugfix: ip_tables atomic-schedule fix, fixes the messages reported by 
   Daniel Walker and K.R. Foley.

 - bugfix: fix warnings/deadlocks in inet_create(), reported by Mark H 
   Johnson.

 - bugfix: fixed a crash-in-shmfs-during-heavy-swapout bug

 - bugfix: enable preemption while doing mmdrop() in the scheduler - it 
   may schedule.

 - debugging feature: when PREEMPT_TIMING is enabled then the code also 
   keeps a trace/stack of preemption enabler EIPs. (if LATENCY_TRACE is 
   enabled as well then the parent EIP is recorded as well.) Whenever a 
   stack trace due to atomicity violations is printed, the preemption
   stack is printed as well. This makes it much easier to identify the 
   place that did the illegal preemption-disabling.

to create a -U2 tree from scratch the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 22:40             ` Karim Yaghmour
@ 2004-10-14 23:46               ` Ingo Molnar
  2004-10-15  0:07                 ` Karim Yaghmour
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-14 23:46 UTC (permalink / raw)
  To: Karim Yaghmour
  Cc: linux-kernel, Thomas Zanussi, Robert Wisniewski, Richard J Moore,
	Michel Dagenais


* Karim Yaghmour <karim@opersys.com> wrote:

> 
> Ingo Molnar wrote:
> >  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U0
> 
> I notice:
> +	local_irq_save(flags);
> +	____trace(&__get_cpu_var(trace), eip, parent_eip);
> +	local_irq_restore(flags);
> 
> Why not use the lockless logging available in relayfs, you'll avoid
> the interrupt disabling altogether since, umm ... it's lockless.

i just added something ad-hoc. I wanted it to be accurate across
interrupt entries. I have not looked at the relayfs locking but how does
it solve that? Also, cli/sti makes it obviously SMP-safe and is pretty
cheap on all x86 CPUs. (Also, i didnt want to use preempt_disable/enable
because the tracer interacts with that code quite heavily.)

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-14 23:46               ` Ingo Molnar
@ 2004-10-15  0:07                 ` Karim Yaghmour
  2004-10-15  0:31                   ` Roland Dreier
  2004-10-15  6:59                   ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Karim Yaghmour @ 2004-10-15  0:07 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Zanussi, Robert Wisniewski, Richard J Moore,
	Michel Dagenais


Ingo Molnar wrote:
> i just added something ad-hoc.

Yes, I understood as much. I'm suggesting it because a lot of
people who need such ad-hoc functionality could easily be
using relayfs.

> I wanted it to be accurate across
> interrupt entries. I have not looked at the relayfs locking but how does
> it solve that?

cmpxchg (basically: try reserve; if fail retry; else write),
with per-cpu buffers.

> Also, cli/sti makes it obviously SMP-safe and is pretty
> cheap on all x86 CPUs. (Also, i didnt want to use preempt_disable/enable
> because the tracer interacts with that code quite heavily.)

No preempt_disable/enable found in the lockless logging in relayfs.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-14 23:42               ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2 Ingo Molnar
@ 2004-10-15  0:31                 ` Adam Heath
  2004-10-15  0:41                   ` Adam Heath
  2004-10-15  2:23                 ` Bill Huey
                                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-15  0:31 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Fri, 15 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U2 PREEMPT_REALTIME patch:
>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2

kernel/latency.c: In function `add_preempt_count':
kernel/latency.c:390: error: structure has no member named `preempt_trace_eip'
kernel/latency.c:394: error: structure has no member named `preempt_trace_parent_eip'

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-15  0:07                 ` Karim Yaghmour
@ 2004-10-15  0:31                   ` Roland Dreier
  2004-10-15  1:22                     ` Karim Yaghmour
  2004-10-15  2:00                     ` Robert Wisniewski
  2004-10-15  6:59                   ` Ingo Molnar
  1 sibling, 2 replies; 951+ messages in thread
From: Roland Dreier @ 2004-10-15  0:31 UTC (permalink / raw)
  To: karim
  Cc: Ingo Molnar, linux-kernel, Thomas Zanussi, Robert Wisniewski,
	Richard J Moore, Michel Dagenais

    Karim> cmpxchg (basically: try reserve; if fail retry; else
    Karim> write), with per-cpu buffers.

Not sure if I really understand the context where Ingo would use this,
but this lockless scheme doesn't seem to be safe for realtime; the
retry can potentially happen an arbitrary number of times.

 - Roland

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15  0:31                 ` Adam Heath
@ 2004-10-15  0:41                   ` Adam Heath
  2004-10-15  0:53                     ` Adam Heath
  2004-10-15  7:14                     ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-15  0:41 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Thu, 14 Oct 2004, Adam Heath wrote:

> On Fri, 15 Oct 2004, Ingo Molnar wrote:
>
> >
> > i have released the -U2 PREEMPT_REALTIME patch:
> >
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2
>
> kernel/latency.c: In function `add_preempt_count':
> kernel/latency.c:390: error: structure has no member named `preempt_trace_eip'
> kernel/latency.c:394: error: structure has no member named `preempt_trace_parent_eip'

Here's a patch:

--- kernel/latency.c.orig	2004-10-14 19:36:26.000000000 -0500
+++ kernel/latency.c	2004-10-14 19:33:30.000000000 -0500
@@ -387,11 +387,9 @@
 	if (val <= 10) {
 		unsigned int idx = preempt_count() & PREEMPT_MASK;
 		if (idx < MAX_PREEMPT_TRACE) {
-			current->preempt_trace_eip[idx] = eip;
 #ifdef CONFIG_LATENCY_TRACE
+			current->preempt_trace_eip[idx] = eip;
 			current->preempt_trace_parent_eip[idx] = parent_eip;
-#else
-			current->preempt_trace_parent_eip[idx] = 0;
 #endif
 		}
 	}
--


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15  0:41                   ` Adam Heath
@ 2004-10-15  0:53                     ` Adam Heath
  2004-10-15  7:14                     ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-15  0:53 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Thu, 14 Oct 2004, Adam Heath wrote:

> On Thu, 14 Oct 2004, Adam Heath wrote:
>
> > On Fri, 15 Oct 2004, Ingo Molnar wrote:
> >
> > >
> > > i have released the -U2 PREEMPT_REALTIME patch:
> > >
> > >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2
> >
> > kernel/latency.c: In function `add_preempt_count':
> > kernel/latency.c:390: error: structure has no member named `preempt_trace_eip'
> > kernel/latency.c:394: error: structure has no member named `preempt_trace_parent_eip'
>
> Here's a patch:
>
> --- kernel/latency.c.orig	2004-10-14 19:36:26.000000000 -0500
> +++ kernel/latency.c	2004-10-14 19:33:30.000000000 -0500
> @@ -387,11 +387,9 @@
>  	if (val <= 10) {
>  		unsigned int idx = preempt_count() & PREEMPT_MASK;
>  		if (idx < MAX_PREEMPT_TRACE) {
> -			current->preempt_trace_eip[idx] = eip;
>  #ifdef CONFIG_LATENCY_TRACE
> +			current->preempt_trace_eip[idx] = eip;
>  			current->preempt_trace_parent_eip[idx] = parent_eip;
> -#else
> -			current->preempt_trace_parent_eip[idx] = 0;
>  #endif
>  		}
>  	}
> --

How do you set that config option?  I only see it in .c and .h files.

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-15  0:31                   ` Roland Dreier
@ 2004-10-15  1:22                     ` Karim Yaghmour
  2004-10-15  2:00                     ` Robert Wisniewski
  1 sibling, 0 replies; 951+ messages in thread
From: Karim Yaghmour @ 2004-10-15  1:22 UTC (permalink / raw)
  To: Roland Dreier
  Cc: Ingo Molnar, linux-kernel, Thomas Zanussi, Robert Wisniewski,
	Richard J Moore, Michel Dagenais


Roland Dreier wrote:
> Not sure if I really understand the context where Ingo would use this,
> but this lockless scheme doesn't seem to be safe for realtime; the
> retry can potentially happen an arbitrary number of times.

In theory. In practice it doesn't often happen twice and very rarely
more than that.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-15  0:31                   ` Roland Dreier
  2004-10-15  1:22                     ` Karim Yaghmour
@ 2004-10-15  2:00                     ` Robert Wisniewski
  2004-10-15  2:21                       ` Lee Revell
  1 sibling, 1 reply; 951+ messages in thread
From: Robert Wisniewski @ 2004-10-15  2:00 UTC (permalink / raw)
  To: Roland Dreier
  Cc: karim, Ingo Molnar, linux-kernel, Thomas Zanussi,
	Robert Wisniewski, Richard J Moore, Michel Dagenais

Theoretically a problem, in practice not, i.e., good enough for soft/normal
real-time, not hard real-time; probably wouldn't want my heart monitor on
it, but then I wouldn't be using Linux for that either :-)

Robert Wisniewski
The K42 MP OS Project
Advanced Operating Systems
Scalable Parallel Systems
IBM T.J. Watson Research Center
914-945-3181
http://www.research.ibm.com/K42/
bob@watson.ibm.com


Roland Dreier writes:
 >     Karim> cmpxchg (basically: try reserve; if fail retry; else
 >     Karim> write), with per-cpu buffers.
 > 
 > Not sure if I really understand the context where Ingo would use this,
 > but this lockless scheme doesn't seem to be safe for realtime; the
 > retry can potentially happen an arbitrary number of times.
 > 
 >  - Roland

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-15  2:00                     ` Robert Wisniewski
@ 2004-10-15  2:21                       ` Lee Revell
  2004-10-15 12:27                         ` Robert Wisniewski
  0 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-15  2:21 UTC (permalink / raw)
  To: Robert Wisniewski
  Cc: Roland Dreier, karim, Ingo Molnar, linux-kernel, Thomas Zanussi,
	Richard J Moore, Michel Dagenais

On Thu, 2004-10-14 at 22:00, Robert Wisniewski wrote:
> Theoretically a problem, in practice not, i.e., good enough for soft/normal
> real-time, not hard real-time; probably wouldn't want my heart monitor on
> it, but then I wouldn't be using Linux for that either :-)

Also, the issue here is how we do debug logging.  You would presumably
not use this at all in production.

Lee 


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-14 23:42               ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2 Ingo Molnar
  2004-10-15  0:31                 ` Adam Heath
@ 2004-10-15  2:23                 ` Bill Huey
  2004-10-15  2:40                   ` K.R. Foley
  2004-10-15  7:08                   ` Ingo Molnar
  2004-10-15  2:33                 ` Adam Heath
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
  3 siblings, 2 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-15  2:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci

On Fri, Oct 15, 2004 at 01:42:02AM +0200, Ingo Molnar wrote:
> 
> i have released the -U2 PREEMPT_REALTIME patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2

mm/shmem.c: In function `shmem_dir_map':
mm/shmem.c:103: warning: implicit declaration of function `kmap_atomic_rt'
mm/shmem.c:103: error: `KM_USER0' undeclared (first use in this function)
mm/shmem.c:103: error: (Each undeclared identifier is reported only once
mm/shmem.c:103: error: for each function it appears in.)
mm/shmem.c: In function `shmem_dir_unmap':
mm/shmem.c:108: warning: implicit declaration of function `kunmap_atomic_rt'
mm/shmem.c:108: error: `KM_USER0' undeclared (first use in this function)
mm/shmem.c: In function `shmem_swp_map':
mm/shmem.c:113: error: `KM_USER1' undeclared (first use in this function)
mm/shmem.c: In function `shmem_swp_balance_unmap':
mm/shmem.c:125: error: `KM_USER1' undeclared (first use in this function)
mm/shmem.c: In function `shmem_swp_unmap':
mm/shmem.c:130: error: `KM_USER1' undeclared (first use in this function)
mm/shmem.c: In function `shmem_swp_set':
mm/shmem.c:333: warning: implicit declaration of function `kmap_atomic_to_page_rt'
mm/shmem.c:333: error: invalid type argument of `->'
mm/shmem.c: In function `shmem_file_write':
mm/shmem.c:1362: error: `KM_USER0' undeclared (first use in this function)
mm/shmem.c:1362: warning: assignment makes pointer from integer without a cast
mm/shmem.c: In function `shmem_symlink':
mm/shmem.c:1719: error: `KM_USER0' undeclared (first use in this function)
mm/shmem.c:1719: warning: assignment makes pointer from integer without a cast
make[1]: *** [mm/shmem.o] Error 1
make: *** [mm] Error 2
root@nietzsche> /home/bhuey/linux-2.6.8% 17# make tags

....

I've got kgdb targetted next and I'm trying to figure out how to write a
rw/semaphore with priority inheritance.

bill


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-14 23:42               ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2 Ingo Molnar
  2004-10-15  0:31                 ` Adam Heath
  2004-10-15  2:23                 ` Bill Huey
@ 2004-10-15  2:33                 ` Adam Heath
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
  3 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-15  2:33 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Fri, 15 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U2 PREEMPT_REALTIME patch:
>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2

scheduling while atomic: XFree86/0x04000002/1129
caller is cond_resched+0x53/0x70
 [<c027acd7>] schedule+0x517/0x550
 [<c012ce6a>] check_preempt_timing+0x1a/0x130
 [<c0107b98>] do_IRQ+0x58/0x80
 [<c027b243>] cond_resched+0x53/0x70
 [<c012c684>] _mutex_lock+0x14/0x40
 [<c012c6d5>] _mutex_lock_irqsave+0x5/0x10
 [<c01b28bf>] avc_has_perm_noaudit+0x10f/0x180
 [<c012ce6a>] check_preempt_timing+0x1a/0x130
 [<c01b296a>] avc_has_perm+0x3a/0x78
 [<c014de87>] shmem_truncate+0x1d7/0x400
 [<c01b8060>] ipc_has_perm+0x70/0x90
 [<c027b209>] cond_resched+0x19/0x70
 [<c01a9c72>] ipcperms+0x72/0xa0
 [<c01adaf7>] do_shmat+0xc7/0x300
 [<c010b8b6>] sys_ipc+0x1c6/0x280
 [<c01c8040>] copy_to_user+0x40/0x60
 [<c011d69c>] sys_gettimeofday+0x2c/0x70
 [<c01057fb>] syscall_call+0x7/0xb
scheduling while atomic: liquidwar/0x04000002/1553
caller is cond_resched+0x53/0x70
 [<c027acd7>] schedule+0x517/0x550
 [<c012ce6a>] check_preempt_timing+0x1a/0x130
 [<c027b243>] cond_resched+0x53/0x70
 [<c012c684>] _mutex_lock+0x14/0x40
 [<c012c6d5>] _mutex_lock_irqsave+0x5/0x10
 [<c01b27da>] avc_has_perm_noaudit+0x2a/0x180
 [<c01b2992>] avc_has_perm+0x62/0x78
 [<c01b296a>] avc_has_perm+0x3a/0x78
 [<c012c690>] _mutex_lock+0x20/0x40
 [<c01b8060>] ipc_has_perm+0x70/0x90
 [<c01b8060>] ipc_has_perm+0x70/0x90
 [<c0107b98>] do_IRQ+0x58/0x80
 [<c01adb13>] do_shmat+0xe3/0x300
 [<c010b8b6>] sys_ipc+0x1c6/0x280
 [<c0147a4f>] sys_munmap+0x3f/0x60
 [<c01057fb>] syscall_call+0x7/0xb


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15  2:23                 ` Bill Huey
@ 2004-10-15  2:40                   ` K.R. Foley
  2004-10-15  2:47                     ` Bill Huey
  2004-10-15  7:08                   ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-15  2:40 UTC (permalink / raw)
  To: Bill Huey (hui)
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Daniel Walker, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci

Bill Huey (hui) wrote:
> On Fri, Oct 15, 2004 at 01:42:02AM +0200, Ingo Molnar wrote:
> 
>>i have released the -U2 PREEMPT_REALTIME patch:
>>
>>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2
> 
> 
> mm/shmem.c: In function `shmem_dir_map':
> mm/shmem.c:103: warning: implicit declaration of function `kmap_atomic_rt'
> mm/shmem.c:103: error: `KM_USER0' undeclared (first use in this function)
> mm/shmem.c:103: error: (Each undeclared identifier is reported only once
> mm/shmem.c:103: error: for each function it appears in.)
> mm/shmem.c: In function `shmem_dir_unmap':
> mm/shmem.c:108: warning: implicit declaration of function `kunmap_atomic_rt'
> mm/shmem.c:108: error: `KM_USER0' undeclared (first use in this function)
> mm/shmem.c: In function `shmem_swp_map':
> mm/shmem.c:113: error: `KM_USER1' undeclared (first use in this function)
> mm/shmem.c: In function `shmem_swp_balance_unmap':
> mm/shmem.c:125: error: `KM_USER1' undeclared (first use in this function)
> mm/shmem.c: In function `shmem_swp_unmap':
> mm/shmem.c:130: error: `KM_USER1' undeclared (first use in this function)
> mm/shmem.c: In function `shmem_swp_set':
> mm/shmem.c:333: warning: implicit declaration of function `kmap_atomic_to_page_rt'
> mm/shmem.c:333: error: invalid type argument of `->'
> mm/shmem.c: In function `shmem_file_write':
> mm/shmem.c:1362: error: `KM_USER0' undeclared (first use in this function)
> mm/shmem.c:1362: warning: assignment makes pointer from integer without a cast
> mm/shmem.c: In function `shmem_symlink':
> mm/shmem.c:1719: error: `KM_USER0' undeclared (first use in this function)
> mm/shmem.c:1719: warning: assignment makes pointer from integer without a cast
> make[1]: *** [mm/shmem.o] Error 1
> make: *** [mm] Error 2
> root@nietzsche> /home/bhuey/linux-2.6.8% 17# make tags
> 
> ....
> 
> I've got kgdb targetted next and I'm trying to figure out how to write a
> rw/semaphore with priority inheritance.
> 
> bill
> 
> 

What platform are you getting this on?

kr

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15  2:40                   ` K.R. Foley
@ 2004-10-15  2:47                     ` Bill Huey
  2004-10-15  3:19                       ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-15  2:47 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Bill Huey (hui),
	Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Daniel Walker, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci

On Thu, Oct 14, 2004 at 09:40:10PM -0500, K.R. Foley wrote:
> >mm/shmem.c:1362: warning: assignment makes pointer from integer without a 
> >cast
> >mm/shmem.c: In function `shmem_symlink':
> >mm/shmem.c:1719: error: `KM_USER0' undeclared (first use in this function)
> >mm/shmem.c:1719: warning: assignment makes pointer from integer without a 
> >cast
> >make[1]: *** [mm/shmem.o] Error 1
> >make: *** [mm] Error 2
> >root@nietzsche> /home/bhuey/linux-2.6.8% 17# make tags
> 
> What platform are you getting this on?

x86

I ran into other build problems BTW too.

bill


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15  2:47                     ` Bill Huey
@ 2004-10-15  3:19                       ` K.R. Foley
  2004-10-15  3:47                         ` Bill Huey
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-15  3:19 UTC (permalink / raw)
  To: Bill Huey (hui)
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Daniel Walker, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci

Bill Huey (hui) wrote:
> On Thu, Oct 14, 2004 at 09:40:10PM -0500, K.R. Foley wrote:
> 
>>>mm/shmem.c:1362: warning: assignment makes pointer from integer without a 
>>>cast
>>>mm/shmem.c: In function `shmem_symlink':
>>>mm/shmem.c:1719: error: `KM_USER0' undeclared (first use in this function)
>>>mm/shmem.c:1719: warning: assignment makes pointer from integer without a 
>>>cast
>>>make[1]: *** [mm/shmem.o] Error 1
>>>make: *** [mm] Error 2
>>>root@nietzsche> /home/bhuey/linux-2.6.8% 17# make tags
>>
>>What platform are you getting this on?
> 
> 
> x86

Not sure how you could be missing these with any configuration. Ah. Did 
you miss Linus' rc4 patch by any chance?

Just finished booting my slower UP box. My SMP box has been up for about 
1 hr 45 mins.

kr
> 
> I ran into other build problems BTW too.
> 
> bill
> 
> 


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15  3:19                       ` K.R. Foley
@ 2004-10-15  3:47                         ` Bill Huey
  2004-10-15  3:48                           ` Bill Huey
  0 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-15  3:47 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Bill Huey (hui),
	Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Daniel Walker, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci

On Thu, Oct 14, 2004 at 10:19:59PM -0500, K.R. Foley wrote:
> Not sure how you could be missing these with any configuration. Ah. Did 
> you miss Linus' rc4 patch by any chance?
 
> Just finished booting my slower UP box. My SMP box has been up for about 
> 1 hr 45 mins.

    31  20:34   bzip2 -dc ../linux-2.6.8.tar.bz2 | tar xf -
    37  20:36   cd linux-2.6.8/
    38  20:36   bzip2 -dc ../../patch-2.6.9-rc4.bz2 | patch -p1
    39  20:37   bzip2 -dc ../../2.6.9-rc4-mm1.bz2 | patch -p1
    41  20:37   cat ../../voluntary-preempt-2.6.9-rc4-mm1-U2 | patch -p1

That's what I did.

bill


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15  3:47                         ` Bill Huey
@ 2004-10-15  3:48                           ` Bill Huey
  0 siblings, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-15  3:48 UTC (permalink / raw)
  To: Bill Huey
  Cc: K.R. Foley, Ingo Molnar, linux-kernel, Lee Revell,
	Rui Nuno Capela, Mark_H_Johnson, Daniel Walker, Andrew Morton,
	Adam Heath, Lorenzo Allegrucci

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

On Thu, Oct 14, 2004 at 08:47:29PM -0700, Bill Huey wrote:
>     31  20:34   bzip2 -dc ../linux-2.6.8.tar.bz2 | tar xf -
>     37  20:36   cd linux-2.6.8/
>     38  20:36   bzip2 -dc ../../patch-2.6.9-rc4.bz2 | patch -p1
>     39  20:37   bzip2 -dc ../../2.6.9-rc4-mm1.bz2 | patch -p1
>     41  20:37   cat ../../voluntary-preempt-2.6.9-rc4-mm1-U2 | patch -p1
> 
> That's what I did.

.config attached.

bill


[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 24366 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-rc4-mm1-VP-U2
# Thu Oct 14 20:42:12 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=15
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CPUSETS is not set
CONFIG_PREEMPT_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# 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=y
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=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_SMP=y
CONFIG_NR_CPUS=2
# CONFIG_SCHED_SMT is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y

#
# Firmware Drivers
#
CONFIG_EDD=y
# CONFIG_EDD_SKIP_MBR is not set
# CONFIG_EFI_VARS is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_EFI=y
# CONFIG_IRQBALANCE is not set
CONFIG_HAVE_DEC_LOCK=y
CONFIG_BOOT_IOREMAP=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
# 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_BOOT=y
CONFIG_ACPI_INTERPRETER=y
# CONFIG_ACPI_SLEEP is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
# CONFIG_ACPI_FAN is not set
# CONFIG_ACPI_PROCESSOR is not set
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_THINKPAD=m
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER 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_PCI_MSI is not set
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
# CONFIG_PCMCIA_DEBUG is not set
# CONFIG_YENTA is not set
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

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

#
# Device Drivers
#

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

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

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

#
# Protocols
#
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_PNPBIOS_PROC_FS=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD 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_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_LBD=y
# CONFIG_CDROM_PKTCDVD 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 is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=y
CONFIG_BLK_DEV_IDEFLOPPY=y
# CONFIG_BLK_DEV_IDESCSI is not set
CONFIG_IDE_TASK_IOCTL=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_IDEPCI_SHARE_IRQ is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_PCI_AUTO 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_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=y

#
# Note: most of these also require special kernel boot parameters
#
# CONFIG_BLK_DEV_4DRIVES is not set
# CONFIG_BLK_DEV_ALI14XX is not set
# CONFIG_BLK_DEV_DTC2278 is not set
# CONFIG_BLK_DEV_HT6560B is not set
# CONFIG_BLK_DEV_QD65XX is not set
# CONFIG_BLK_DEV_UMC8672 is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_IDEDMA_AUTO is not set
# CONFIG_BLK_DEV_HD is not set

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

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

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

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO 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_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA6322 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

#
# PCMCIA SCSI adapter support
#
# CONFIG_PCMCIA_AHA152X is not set
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_NINJA_SCSI is not set
# CONFIG_PCMCIA_QLOGIC is not set
# CONFIG_PCMCIA_SYM53C500 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

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
CONFIG_XFRM=y
CONFIG_XFRM_USER=y

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

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_NETDEVICES 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 I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set

#
# 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=y
CONFIG_INPUT_PCSPKR=y
CONFIG_INPUT_UINPUT=y

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

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

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

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

#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_MWAVE is not set
CONFIG_RAW_DRIVER=y
# CONFIG_HPET is not set
CONFIG_MAX_RAW_DEVS=256
CONFIG_HANGCHECK_TIMER=y

#
# I2C support
#
# CONFIG_I2C is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

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

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB=y
CONFIG_USB_DEBUG=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
# 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 is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_UHCI_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_STORAGE is not set

#
# USB Human Interface Devices (HID)
#
# CONFIG_USB_HID is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

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

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

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

#
# USB Network adaptors
#
# 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

#
# USB port drivers
#

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=y
# CONFIG_USB_SERIAL_CONSOLE is not set
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_TEST is not set

#
# USB ATM/DSL drivers
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FS_MBCACHE=y
CONFIG_REISER4_FS=y
CONFIG_REISER4_LARGE_KEY=y
# CONFIG_REISER4_CHECK is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
CONFIG_AUTOFS_FS=y
# CONFIG_AUTOFS4_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# 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_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS 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_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=y
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

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

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=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=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_INFO=y
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
# CONFIG_SCHEDSTATS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
# CONFIG_KGDB is not set
# CONFIG_KGDB_9600BAUD is not set
# CONFIG_KGDB_19200BAUD is not set
# CONFIG_KGDB_38400BAUD is not set
# CONFIG_KGDB_57600BAUD is not set
# CONFIG_KGDB_115200BAUD is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set

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

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-15  0:07                 ` Karim Yaghmour
  2004-10-15  0:31                   ` Roland Dreier
@ 2004-10-15  6:59                   ` Ingo Molnar
  2004-10-15 12:32                     ` Robert Wisniewski
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-15  6:59 UTC (permalink / raw)
  To: Karim Yaghmour
  Cc: linux-kernel, Thomas Zanussi, Robert Wisniewski, Richard J Moore,
	Michel Dagenais


* Karim Yaghmour <karim@opersys.com> wrote:

> >i just added something ad-hoc.
>
> Yes, I understood as much. I'm suggesting it because a lot of people
> who need such ad-hoc functionality could easily be using relayfs.

the latency tracer is pretty specialized for a number of reasons, i'm
not sure there's a good match between the two. If relayfs were in the
mainline kernel i'd consider reusing parts of it.

> >I wanted it to be accurate across
> >interrupt entries. I have not looked at the relayfs locking but how does
> >it solve that?
> 
> cmpxchg (basically: try reserve; if fail retry; else write), with
> per-cpu buffers.

this still does not solve all problems related to irq entries: if the
IRQ interrups the tracing code after a 'successful reserve' but before
the 'else write' point, and the trace is printed/saved from an
interrupt, then there will be an incomplete entry in the trace.

also, there is the problem of timestamp atomicity: if an IRQ interrupts
the tracing code and the trace timestamp is taken in the 'else' branch
then a time-reversal situation can occur: the entry will have a
timestamp _larger_ than the IRQ trace-entries. With cli/sti all tracing
entries occur atomically: either fully or not at all.

> >Also, cli/sti makes it obviously SMP-safe and is pretty
> >cheap on all x86 CPUs. (Also, i didnt want to use preempt_disable/enable
> >because the tracer interacts with that code quite heavily.)
> 
> No preempt_disable/enable found in the lockless logging in relayfs.

it would have to do that on PREEMPT_REALTIME. The irq flag solves both
the races, the predictability problem and the preemption problem nicely.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15  2:23                 ` Bill Huey
  2004-10-15  2:40                   ` K.R. Foley
@ 2004-10-15  7:08                   ` Ingo Molnar
  2004-10-15  8:21                     ` Bill Huey
  2004-10-15 11:47                     ` K.R. Foley
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-15  7:08 UTC (permalink / raw)
  To: Bill Huey
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci


* Bill Huey <bhuey@lnxw.com> wrote:

> On Fri, Oct 15, 2004 at 01:42:02AM +0200, Ingo Molnar wrote:
> > 
> > i have released the -U2 PREEMPT_REALTIME patch:
> > 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2
> 
> mm/shmem.c: In function `shmem_dir_map':
> mm/shmem.c:103: warning: implicit declaration of function `kmap_atomic_rt'
> mm/shmem.c:103: error: `KM_USER0' undeclared (first use in this function)

as a workaround enable HIGHMEM and PREEMPT_TIMING+LATENCY_TRACE.

(i fixed this in my tree, will be in -U3.)

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15  0:41                   ` Adam Heath
  2004-10-15  0:53                     ` Adam Heath
@ 2004-10-15  7:14                     ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-15  7:14 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


* Adam Heath <doogie@debian.org> wrote:

> > >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2
> >
> > kernel/latency.c: In function `add_preempt_count':
> > kernel/latency.c:390: error: structure has no member named `preempt_trace_eip'
> > kernel/latency.c:394: error: structure has no member named `preempt_trace_parent_eip'
> 
> Here's a patch:

please try the patch below instead - it will keep the tracer working
even with !LATENCY_TRACE.

	Ingo

--- linux.old/include/linux/sched.h	
+++ linux.new/include/linux/sched.h	
@@ -706,7 +706,7 @@ struct task_struct {
 
 #define MAX_PREEMPT_TRACE 16
 
-#ifdef CONFIG_LATENCY_TRACE
+#ifdef CONFIG_PREEMPT_TIMING
 	unsigned long preempt_trace_eip[MAX_PREEMPT_TRACE];
 	unsigned long preempt_trace_parent_eip[MAX_PREEMPT_TRACE];
 #endif
--- linux.old/include/linux/highmem.h	
+++ linux.new/include/linux/highmem.h	
@@ -33,6 +33,11 @@ static inline void *kmap(struct page *pa
 #define kmap_atomic_pfn(pfn, idx)	page_address(pfn_to_page(pfn))
 #define kmap_atomic_to_page(ptr)	virt_to_page(ptr)
 
+#define kmap_atomic_rt kmap_atomic
+#define kmap_atomic_pfn_rt kmap_atomic_pfn
+#define kunmap_atomic_rt kunmap_atomic
+#define kmap_atomic_to_page_rt(kvaddr) kmap_atomic_to_page(kvaddr)
+
 #endif /* CONFIG_HIGHMEM */
 
 /* when CONFIG_HIGHMEM is not set these will be plain clear/copy_page */


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15  7:08                   ` Ingo Molnar
@ 2004-10-15  8:21                     ` Bill Huey
  2004-10-15 11:47                     ` K.R. Foley
  1 sibling, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-15  8:21 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Daniel Walker, Andrew Morton,
	Adam Heath, Lorenzo Allegrucci

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

On Fri, Oct 15, 2004 at 09:08:39AM +0200, Ingo Molnar wrote:
> as a workaround enable HIGHMEM and PREEMPT_TIMING+LATENCY_TRACE.

Build problem:

bill


[-- Attachment #2: t --]
[-- Type: text/plain, Size: 1622 bytes --]

  CC      fs/reiser4/debug.o
In file included from include/linux/spinlock.h:16,
                 from include/linux/wait.h:25,
                 from include/linux/fs.h:12,
                 from fs/reiser4/kattr.h:12,
                 from fs/reiser4/debug.c:31:
include/asm/mutex.h:75:5: warning: "RWSEM_DEBUG" is not defined
  CC      fs/reiser4/stats.o
In file included from include/linux/spinlock.h:16,
                 from include/linux/wait.h:25,
                 from include/linux/fs.h:12,
                 from fs/reiser4/kattr.h:12,
                 from fs/reiser4/stats.c:46:
include/asm/mutex.h:75:5: warning: "RWSEM_DEBUG" is not defined
  CC      fs/reiser4/jnode.o
In file included from include/linux/spinlock.h:16,
                 from include/linux/wait.h:25,
                 from include/linux/fs.h:12,
                 from fs/reiser4/reiser4.h:13,
                 from fs/reiser4/jnode.c:103:
include/asm/mutex.h:75:5: warning: "RWSEM_DEBUG" is not defined
  CC      fs/reiser4/znode.o
In file included from include/linux/spinlock.h:16,
                 from include/linux/wait.h:25,
                 from include/linux/fs.h:12,
                 from fs/reiser4/reiser4.h:13,
                 from fs/reiser4/debug.h:9,
                 from fs/reiser4/znode.c:142:
include/asm/mutex.h:75:5: warning: "RWSEM_DEBUG" is not defined
  CC      fs/reiser4/key.o
In file included from include/linux/spinlock.h:16,
                 from include/linux/wait.h:25,
                 from include/linux/fs.h:12,
                 from fs/reiser4/reiser4.h:13,
                 from fs/reiser4/debug.h:9,
     


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

* [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-14 23:42               ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2 Ingo Molnar
                                   ` (2 preceding siblings ...)
  2004-10-15  2:33                 ` Adam Heath
@ 2004-10-15 10:26                 ` Ingo Molnar
  2004-10-15 11:59                   ` Dominik Karall
                                     ` (9 more replies)
  3 siblings, 10 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-15 10:26 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


i have released the -U3 PREEMPT_REALTIME patch:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3

this is a buildfixes-only release, and it is still experimental code.

Changes since -U2:

 - build fix: fixes the latency.c compilation error reported by Adam 
   Heath.

 - build fix: fixes !HIGHMEM compilation, patch from Andrew Rodland

to create a -U3 tree from scratch the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-14 14:31             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Ingo Molnar
                                 ` (6 preceding siblings ...)
  2004-10-14 23:42               ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2 Ingo Molnar
@ 2004-10-15 11:22               ` Florian Schmidt
  2004-10-15 11:44                 ` Ingo Molnar
  7 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-15 11:22 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Dipankar Sarma

On Thu, 14 Oct 2004 16:31:31 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> i have released the -U1 PREEMPT_REALTIME patch:
>  
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U1

Ok, 

with the help of Paul Davis i think i have found what's causing  the jackd
FP exception. It seems to be a bug in the kernel when PREEMPT_REALTIME is
enabled:

~$ cat /proc/cpuinfo|grep cpu
cpu family      : 6
cpu MHz         : 0.001
cpuid level     : 1

Mhz == 0.001? Hrmm. No wonder jackd was freaking out in its timing code..
The real cpu speed is 1.2ghz.

flo

P.S.: Will retry with U3, to see if this persists.

dmesg output:

Linux version 2.6.9-rc4-mm1-VP-U1-RT (root@mango.fruits.de) (gcc version 3.3.5 (Debian 1:3.3.5-1)) #3 Thu Oct 14 22:40:26 CEST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000030000000 (usable)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffee0000 - 00000000fff00000 (reserved)
 BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
768MB LOWMEM available.
On node 0 totalpages: 196608
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 192512 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
Built 1 zonelists
Initializing CPU#0
Kernel command line: BOOT_IMAGE=2.6.9-U0 ro root=1601
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 1195.144 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 776332k/786432k available (1673k kernel code, 9644k reserved, 482k data, 340k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 2367.48 BogoMIPS (lpj=1183744)
Security Scaffold v1.0.0 initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: After vendor identify, caps:  0183f9ff c1c7f9ff 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps:        0183f9ff c1c7f9ff 00000000 00000020
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
ksoftirqd started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfdb01, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Uncovering SIS18 that hid as a SIS503 (compatible=1)
Enabling SiS 96x SMBus.
PCI: Using IRQ router SIS [1039/0018] at 0000:00:02.0
PCI: IRQ 0 for device 0000:00:02.1 doesn't match PIRQ mask - try pci=usepirqmask
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
Initializing Cryptographic API
Real Time Clock Driver v1.12
Non-volatile memory driver v1.2
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller at PCI slot 0000:00:02.5
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SIS5513: SiS735 ATA 100 (2nd gen) controller
    ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: IC35L060AVER07-0, ATA DISK drive
elevator: using anticipatory as default io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: ST340823A, ATA DISK drive
hdd: TDK CDRW121032, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
Probing IDE interface ide4...
ide4: Wait for ready failed before probe !
Probing IDE interface ide5...
ide5: Wait for ready failed before probe !
hda: max request size: 128KiB
hda: 120103200 sectors (61492 MB) w/1916KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes not supported
 hda: hda1 hda2 hda3
hdc: max request size: 128KiB
hdc: Host Protected Area detected.
	current capacity is 78165360 sectors (40020 MB)
	native  capacity is 78165361 sectors (40020 MB)
hdc: Host Protected Area disabled.
hdc: 78165361 sectors (40020 MB) w/1024KiB Cache, CHS=65535/16/63, UDMA(33)
hdc: cache flushes not supported
 hdc: hdc1 hdc2
hdd: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
input: PC Speaker
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 64Kbytes
TCP: Hash tables configured (established 65536 bind 37449)
NET: Registered protocol family 1
NET: Registered protocol family 17
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 340k freed
kjournald starting.  Commit interval 5 seconds
Adding 289160k swap on /dev/hda3.  Priority:-1 extents:1
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on hdc1, internal journal
PCI: Found IRQ 5 for device 0000:00:0f.0
sis900.c: v1.08.07 11/02/2003
PCI: Found IRQ 10 for device 0000:00:03.0
eth0: Realtek RTL8201 PHY transceiver found at address 1.
eth0: Using transceiver found at address 1 as default
eth0: SiS 900 PCI Fast Ethernet at 0xdc00, IRQ 10, 00:d0:09:e9:c1:0f.
CSLIP: code copyright 1989 Regents of the University of California
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdc2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.


complete /proc/cpuinfo

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 6
model		: 4
model name	: AMD Athlon(tm) Processor
stepping	: 2
cpu MHz		: 0.001
cache size	: 256 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips	: 2367.48


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-15 11:22               ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Florian Schmidt
@ 2004-10-15 11:44                 ` Ingo Molnar
  2004-10-15 12:25                   ` Florian Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-15 11:44 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Dipankar Sarma


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> > i have released the -U1 PREEMPT_REALTIME patch:
> >  
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U1
> 
> Ok, 
> 
> with the help of Paul Davis i think i have found what's causing  the jackd
> FP exception. It seems to be a bug in the kernel when PREEMPT_REALTIME is
> enabled:
> 
> ~$ cat /proc/cpuinfo|grep cpu
> cpu family      : 6
> cpu MHz         : 0.001
> cpuid level     : 1
> 
> Mhz == 0.001? Hrmm. No wonder jackd was freaking out in its timing code..
> The real cpu speed is 1.2ghz.
> 
> flo
> 
> P.S.: Will retry with U3, to see if this persists.

ah ... good eyes. Seems to be working fine here:

 saturn:~> cat /proc/cpuinfo | grep -i mhz
 cpu MHz         : 2051.126
 saturn:~> uname -a
 Linux saturn 2.6.9-rc4-mm1-VP-U4 #288 SMP Fri Oct 15 12:31:38 CEST 2004 

but it could easily be happening on some CPUs only. Let me know if that
problem persists. Fortunately i think it will be at most a detection
problem, not some FPU breakage that i initially suspected.

it could be the following thing: if you got an smp_processor_id()
warning _in the CPU detection code_ in earlier PREEMPT_REALTIME kernels
then the kernel could easily see that the CPU is extremely slow, because
it didnt manage to do much work (due to the long printout...). So i'd
say if this happens again it's most likely a debug printout in the
'calibrating delay loop' phase.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15  7:08                   ` Ingo Molnar
  2004-10-15  8:21                     ` Bill Huey
@ 2004-10-15 11:47                     ` K.R. Foley
  2004-10-15 11:58                       ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-15 11:47 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Daniel Walker, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci

Ingo Molnar wrote:
> * Bill Huey <bhuey@lnxw.com> wrote:
> 
> 
>>On Fri, Oct 15, 2004 at 01:42:02AM +0200, Ingo Molnar wrote:
>>
>>>i have released the -U2 PREEMPT_REALTIME patch:
>>>
>>>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2
>>
>>mm/shmem.c: In function `shmem_dir_map':
>>mm/shmem.c:103: warning: implicit declaration of function `kmap_atomic_rt'
>>mm/shmem.c:103: error: `KM_USER0' undeclared (first use in this function)
> 
> 
> as a workaround enable HIGHMEM and PREEMPT_TIMING+LATENCY_TRACE.
> 
> (i fixed this in my tree, will be in -U3.)
> 
> 	Ingo
> 
Sorry Bill. Is there a brown paper bag you can get that is not for 
writing the bug but misdiagnosing it? :)

kr

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2
  2004-10-15 11:47                     ` K.R. Foley
@ 2004-10-15 11:58                       ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-15 11:58 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Bill Huey, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Daniel Walker, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci


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

> >>>i have released the -U2 PREEMPT_REALTIME patch:
> >>>
> >>> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U2
> >>
> >>mm/shmem.c: In function `shmem_dir_map':
> >>mm/shmem.c:103: warning: implicit declaration of function `kmap_atomic_rt'
> >>mm/shmem.c:103: error: `KM_USER0' undeclared (first use in this function)
> >
> >
> >as a workaround enable HIGHMEM and PREEMPT_TIMING+LATENCY_TRACE.
> >
> >(i fixed this in my tree, will be in -U3.)
> >
> >	Ingo
> >
> Sorry Bill. Is there a brown paper bag you can get that is not for 
> writing the bug but misdiagnosing it? :)

no you thief! Are you trying to steal my preciousss? :-)

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
@ 2004-10-15 11:59                   ` Dominik Karall
  2004-10-15 12:03                     ` Ingo Molnar
  2004-10-15 16:48                     ` Lee Revell
  2004-10-15 17:54                   ` K.R. Foley
                                     ` (8 subsequent siblings)
  9 siblings, 2 replies; 951+ messages in thread
From: Dominik Karall @ 2004-10-15 11:59 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

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

On Friday 15 October 2004 12:26, Ingo Molnar wrote:
> i have released the -U3 PREEMPT_REALTIME patch:
>
>  
> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-
>U3

hi ingo!
can you change your version string to lower case letters to avoid "problems" 
with make-kpkg?
if not, no problem...

thanks,
dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 11:59                   ` Dominik Karall
@ 2004-10-15 12:03                     ` Ingo Molnar
  2004-10-15 16:48                     ` Lee Revell
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-15 12:03 UTC (permalink / raw)
  To: Dominik Karall; +Cc: linux-kernel


* Dominik Karall <dominik.karall@gmx.net> wrote:

> On Friday 15 October 2004 12:26, Ingo Molnar wrote:
> > i have released the -U3 PREEMPT_REALTIME patch:
> >
> >  
> > http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-
> >U3
> 
> hi ingo!
> can you change your version string to lower case letters to avoid "problems" 
> with make-kpkg?
> if not, no problem...

sure, no problem. Next one will be -rt-u4.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
  2004-10-15 11:44                 ` Ingo Molnar
@ 2004-10-15 12:25                   ` Florian Schmidt
  0 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-15 12:25 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Dipankar Sarma

On Fri, 15 Oct 2004 13:44:05 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> > cpu MHz         : 0.001

> ah ... good eyes. Seems to be working fine here:
> 
>  saturn:~> cat /proc/cpuinfo | grep -i mhz
>  cpu MHz         : 2051.126
>  saturn:~> uname -a
>  Linux saturn 2.6.9-rc4-mm1-VP-U4 #288 SMP Fri Oct 15 12:31:38 CEST 2004 
> 
> but it could easily be happening on some CPUs only. Let me know if that
> problem persists. 

Same problem with U3.

~$ uname -a
Linux mango.fruits.de 2.6.9-rc4-mm1-VP-U3-RT #1 Fri Oct 15 13:45:00 CEST 2004 i686 GNU/Linux
~$ cat /proc/cpuinfo |grep MHz
cpu MHz         : 0.001


> Fortunately i think it will be at most a detection
> problem, not some FPU breakage that i initially suspected.
> 
> it could be the following thing: if you got an smp_processor_id()
> warning _in the CPU detection code_ in earlier PREEMPT_REALTIME kernels
> then the kernel could easily see that the CPU is extremely slow, because
> it didnt manage to do much work (due to the long printout...). So i'd
> say if this happens again it's most likely a debug printout in the
> 'calibrating delay loop' phase.

I see. btw: i built this one with CONFIG_PREEMPT_TIMING and
CONFIG_LATENCY_TRACE and, naturally, this also throws the timing code of the
critical section timing off:

Linux version 2.6.9-rc4-mm1-VP-U3-RT (root@mango.fruits.de) (gcc version 3.3.5 (Debian 1:3.3.5-1)) #1 Fri Oct 15 13:45:00 CEST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000030000000 (usable)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffee0000 - 00000000fff00000 (reserved)
 BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
768MB LOWMEM available.
On node 0 totalpages: 196608
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 192512 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
Built 1 zonelists
Initializing CPU#0
Kernel command line: BOOT_IMAGE=2.6.9-U3-RT ro root=1601
PID hash table entries: 4096 (order: 12, 65536 bytes)
(swapper/0): new 436746 us maximum-latency critical section.
 => started at: <start_kernel+0x39/0x1c0>
 => ended at:   <cond_resched+0x23/0x80>
 [<c012ea8c>] touch_preempt_timing+0x3c/0x40
 [<c012e9b0>] check_preempt_timing+0x160/0x200
 [<c02a3e23>] cond_resched+0x23/0x80
 [<c012ea8c>] touch_preempt_timing+0x3c/0x40
 [<c02a3e23>] cond_resched+0x23/0x80
 [<c02a3e23>] cond_resched+0x23/0x80
 [<c012d899>] _mutex_lock+0x19/0x40
 [<c011dad0>] tasklet_hi_action+0x0/0x70
 [<c010b51a>] get_cmos_time+0x1a/0x1e0
 [<c03228e3>] start_kernel+0xc3/0x1c0
 [<c0112240>] mcount+0x14/0x18
 [<c0326ba0>] time_init+0x10/0x70
 [<c011dad0>] tasklet_hi_action+0x0/0x70
 [<c03228e3>] start_kernel+0xc3/0x1c0
 [<c03225a0>] unknown_bootoption+0x0/0x160
preempt count: 1
entry 1: start_kernel+0x39/0x1c0 / (0xc010019f)
Detected 1195.144 MHz processor.
Using tsc for high-res timesource
(swapper/0): new 597854 us maximum-latency critical section.
 => started at: <cond_resched+0x23/0x80>
 => ended at:   <cond_resched+0x23/0x80>
 [<c012ea8c>] touch_preempt_timing+0x3c/0x40
 [<c012e9b0>] check_preempt_timing+0x160/0x200
 [<c02a3e23>] cond_resched+0x23/0x80
 [<c012ea8c>] touch_preempt_timing+0x3c/0x40
 [<c02a3e23>] cond_resched+0x23/0x80
 [<c02a3e23>] cond_resched+0x23/0x80
 [<c012d899>] _mutex_lock+0x19/0x40
 [<c012d916>] _mutex_lock_irqsave+0x16/0x20
 [<c01f0347>] tty_register_ldisc+0x37/0xb0
 [<c0333367>] console_init+0x27/0x50
 [<c03228e8>] start_kernel+0xc8/0x1c0
 [<c03225a0>] unknown_bootoption+0x0/0x160
preempt count: 1
entry 1: start_kernel+0x39/0x1c0 / (0xc010019f)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 776156k/786432k available (1685k kernel code, 9820k reserved, 485k data, 344k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 2351.10 BogoMIPS (lpj=1175552)
Security Scaffold v1.0.0 initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: After vendor identify, caps:  0183f9ff c1c7f9ff 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps:        0183f9ff c1c7f9ff 00000000 00000020
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
ksoftirqd started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfdb01, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Uncovering SIS18 that hid as a SIS503 (compatible=1)
Enabling SiS 96x SMBus.
PCI: Using IRQ router SIS [1039/0018] at 0000:00:02.0
PCI: IRQ 0 for device 0000:00:02.1 doesn't match PIRQ mask - try pci=usepirqmask
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
Initializing Cryptographic API
Real Time Clock Driver v1.12
Non-volatile memory driver v1.2
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller at PCI slot 0000:00:02.5
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SIS5513: SiS735 ATA 100 (2nd gen) controller
    ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: IC35L060AVER07-0, ATA DISK drive
elevator: using anticipatory as default io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: ST340823A, ATA DISK drive
hdd: TDK CDRW121032, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
Probing IDE interface ide4...
ide4: Wait for ready failed before probe !
Probing IDE interface ide5...
ide5: Wait for ready failed before probe !
hda: max request size: 128KiB
hda: 120103200 sectors (61492 MB) w/1916KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes not supported
 hda: hda1 hda2 hda3
hdc: max request size: 128KiB
hdc: Host Protected Area detected.
	current capacity is 78165360 sectors (40020 MB)
	native  capacity is 78165361 sectors (40020 MB)
hdc: Host Protected Area disabled.
hdc: 78165361 sectors (40020 MB) w/1024KiB Cache, CHS=65535/16/63, UDMA(33)
hdc: cache flushes not supported
 hdc: hdc1 hdc2
hdd: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
input: PC Speaker
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 64Kbytes
TCP: Hash tables configured (established 65536 bind 37449)
NET: Registered protocol family 1
NET: Registered protocol family 17
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 344k freed
kjournald starting.  Commit interval 5 seconds
Adding 289160k swap on /dev/hda3.  Priority:-1 extents:1
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on hdc1, internal journal
PCI: Found IRQ 5 for device 0000:00:0f.0
sis900.c: v1.08.07 11/02/2003
PCI: Found IRQ 10 for device 0000:00:03.0
eth0: Realtek RTL8201 PHY transceiver found at address 1.
eth0: Using transceiver found at address 1 as default
eth0: SiS 900 PCI Fast Ethernet at 0xdc00, IRQ 10, 00:d0:09:e9:c1:0f.
CSLIP: code copyright 1989 Regents of the University of California
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdc2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
(S40networking/210): new 698390 us maximum-latency critical section.
 => started at: <kernel_fpu_begin+0x21/0x60>
 => ended at:   <_mmx_memcpy+0x131/0x180>
 [<c012ec41>] sub_preempt_count+0x71/0x90
 [<c012e9b0>] check_preempt_timing+0x160/0x200
 [<c01e48d1>] _mmx_memcpy+0x131/0x180
 [<c010c44e>] kernel_fpu_begin+0xe/0x60
 [<c012ec41>] sub_preempt_count+0x71/0x90
 [<c01e48d1>] _mmx_memcpy+0x131/0x180
 [<c01e48d1>] _mmx_memcpy+0x131/0x180
 [<c01edbe5>] vgacon_scroll+0x245/0x260
 [<c01fe33a>] scrup+0xda/0xf0
 [<c0112240>] mcount+0x14/0x18
 [<c01ffe82>] lf+0x72/0x80
 [<c0201b20>] do_con_trol+0xa90/0xc30
 [<c01fef3b>] hide_softcursor+0xb/0x70
 [<c0201f25>] do_con_write+0x265/0x720
 [<c0202a0b>] con_write+0x3b/0x50
 [<c0202a65>] con_put_char+0x45/0x50
 [<c01f4b15>] opost+0xa5/0x1d0
 [<c0112240>] mcount+0x14/0x18
 [<c01f7083>] write_chan+0x1b3/0x220
 [<c0114ff0>] default_wake_function+0x0/0x20
 [<c0112240>] mcount+0x14/0x18
 [<c0114ff0>] default_wake_function+0x0/0x20
 [<c0114f8f>] lock_kernel+0x2f/0x50
 [<c01f169f>] tty_write+0x12f/0x1e0
 [<c01f6ed0>] write_chan+0x0/0x220
 [<c01f1750>] redirected_tty_write+0x0/0xb0
 [<c015584a>] vfs_write+0xca/0x140
 [<c0112240>] mcount+0x14/0x18
 [<c0155990>] sys_write+0x50/0x80
 [<c010603b>] syscall_call+0x7/0xb
preempt count: 1
entry 1: kernel_fpu_begin+0x21/0x60 / (_mmx_memcpy+0x36/0x180)



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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-15  2:21                       ` Lee Revell
@ 2004-10-15 12:27                         ` Robert Wisniewski
  0 siblings, 0 replies; 951+ messages in thread
From: Robert Wisniewski @ 2004-10-15 12:27 UTC (permalink / raw)
  To: Lee Revell
  Cc: Robert Wisniewski, Roland Dreier, karim, Ingo Molnar,
	linux-kernel, Thomas Zanussi, Richard J Moore, Michel Dagenais

Lee Revell writes:
 > On Thu, 2004-10-14 at 22:00, Robert Wisniewski wrote:
 > > Theoretically a problem, in practice not, i.e., good enough for soft/normal
 > > real-time, not hard real-time; probably wouldn't want my heart monitor on
 > > it, but then I wouldn't be using Linux for that either :-)
 > 
 > Also, the issue here is how we do debug logging.  You would presumably
 > not use this at all in production.
 > 
 > Lee 

Yes actually you would.  If the tracing subsystem is designed correctly you
leave it in for production systems and enable it when you need to find a
problem.  The reason is because many times you can not reproduce a problem
someone in production is seeing in your environment.  In addition to the
LTT/Relayfs and K42 tracing work, lots of of tracing work/papers suggest
leaving it in all the time.  Most commercial operating systems have made
the investment to correctly design tracing facilities so they are
available.  LTT in combination with relayfs could fulfill that role for
Linux.

Robert Wisniewski
The K42 MP OS Project
Advanced Operating Systems
Scalable Parallel Systems
IBM T.J. Watson Research Center
914-945-3181
http://www.research.ibm.com/K42/
bob@watson.ibm.com

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-15  6:59                   ` Ingo Molnar
@ 2004-10-15 12:32                     ` Robert Wisniewski
  2004-10-15 13:11                       ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Robert Wisniewski @ 2004-10-15 12:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Karim Yaghmour, linux-kernel, Thomas Zanussi, Robert Wisniewski,
	Richard J Moore, Michel Dagenais

Ingo Molnar writes:
 > 
 > * Karim Yaghmour <karim@opersys.com> wrote:
 > 
 > > >i just added something ad-hoc.
 > >
 > > Yes, I understood as much. I'm suggesting it because a lot of people
 > > who need such ad-hoc functionality could easily be using relayfs.
 > 
 > the latency tracer is pretty specialized for a number of reasons, i'm
 > not sure there's a good match between the two. If relayfs were in the
 > mainline kernel i'd consider reusing parts of it.

:-)  it's nice we all have a sense of humor.


 > 
 > > >I wanted it to be accurate across
 > > >interrupt entries. I have not looked at the relayfs locking but how does
 > > >it solve that?
 > > 
 > > cmpxchg (basically: try reserve; if fail retry; else write), with
 > > per-cpu buffers.
 > 
 > this still does not solve all problems related to irq entries: if the
 > IRQ interrups the tracing code after a 'successful reserve' but before
 > the 'else write' point, and the trace is printed/saved from an
 > interrupt, then there will be an incomplete entry in the trace.

That is incorrect.  The system behavior needed to generate an incomplete
entry is far more complicated and unlikely than what you describe.


 > 
 > also, there is the problem of timestamp atomicity: if an IRQ interrupts
 > the tracing code and the trace timestamp is taken in the 'else' branch
 > then a time-reversal situation can occur: the entry will have a
 > timestamp _larger_ than the IRQ trace-entries. With cli/sti all tracing
 > entries occur atomically: either fully or not at all.
 > 
 > > >Also, cli/sti makes it obviously SMP-safe and is pretty
 > > >cheap on all x86 CPUs. (Also, i didnt want to use preempt_disable/enable
 > > >because the tracer interacts with that code quite heavily.)
 > > 
 > > No preempt_disable/enable found in the lockless logging in relayfs.
 > 
 > it would have to do that on PREEMPT_REALTIME. The irq flag solves both
 > the races, the predictability problem and the preemption problem nicely.
 > 
 > 	Ingo

If you do not care about performance then you're probably right, this is
fine.  If you are concerned about the time it takes to go through the
sequence of code, then probably not.


Robert Wisniewski
The K42 MP OS Project
Advanced Operating Systems
Scalable Parallel Systems
IBM T.J. Watson Research Center
914-945-3181
http://www.research.ibm.com/K42/
bob@watson.ibm.com

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-15 12:32                     ` Robert Wisniewski
@ 2004-10-15 13:11                       ` Ingo Molnar
  2004-10-15 14:50                         ` Robert Wisniewski
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-15 13:11 UTC (permalink / raw)
  To: Robert Wisniewski
  Cc: Karim Yaghmour, linux-kernel, Thomas Zanussi, Richard J Moore,
	Michel Dagenais


* Robert Wisniewski <bob@watson.ibm.com> wrote:

>  > > cmpxchg (basically: try reserve; if fail retry; else write), with
>  > > per-cpu buffers.
>  > 
>  > this still does not solve all problems related to irq entries: if the
>  > IRQ interrups the tracing code after a 'successful reserve' but before
>  > the 'else write' point, and the trace is printed/saved from an
>  > interrupt, then there will be an incomplete entry in the trace.
> 
> That is incorrect.  The system behavior needed to generate an
> incomplete entry is far more complicated and unlikely than what you
> describe.

ah, but i'm talking about actual first-hand experience, not supposition. 
It happens quite easily with latency traces (which are saved/printed
from IRQ entries) and it can be very annoying to analyze. My first
tracers tried to do things without the IRQ flag, so i've seen both
methods.

and lets not forget this other issue:

>  > also, there is the problem of timestamp atomicity: if an IRQ interrupts
>  > the tracing code and the trace timestamp is taken in the 'else' branch
>  > then a time-reversal situation can occur: the entry will have a
>  > timestamp _larger_ than the IRQ trace-entries. With cli/sti all tracing
>  > entries occur atomically: either fully or not at all.


>  > > >Also, cli/sti makes it obviously SMP-safe and is pretty
                                                      ^^^^^^^^^^
>  > > >cheap on all x86 CPUs. (Also, i didnt want to use preempt_disable/enable
        ^^^^^^^^^^^^^^^^^^^^^^
>  > > >because the tracer interacts with that code quite heavily.)
>  > > 
>  > > No preempt_disable/enable found in the lockless logging in relayfs.
>  > 
>  > it would have to do that on PREEMPT_REALTIME. The irq flag solves both
>  > the races, the predictability problem and the preemption problem nicely.
>  > 
>  > 	Ingo
> 
> If you do not care about performance then you're probably right, this
> is fine.  If you are concerned about the time it takes to go through
> the sequence of code, then probably not.

see the portion i highlighted above. CPU makers are busy making cli/sti
as fast as possible. To make sure i tested it on a typical x86 box:

    # ./cli-latency
    CLI+STI latency: 8 cycles

Since the trace entry can be filled in a constant amount of time there's
no reason not to make use of that extra silicon that makes fast cli/sti
possible! How many trace entries can you generate per second via
relayfs, on a typical PC? Have you ever measured this?

in fact on a modern CPU cli/sti is very likely faster than a cmpxchgl
for the following reason: the cmpxchgl generates a read dependency on
the cacheline which must be fetched in. A single cachemiss can cost
_alot_ in comparison, 200 cycles easily. While in the cli/sti case we
stream out to a new cacheline in a linear fashion which is nicely
optimized by write-allocate cache policies in modern CPUs. No
cachemisses on the trace buffer! Just simple streaming out of data.

i challenge you to change your code to use cli/sti and compare it with
the cmpxchgl variant doing some heavy tracing on a modern PC. Please
just _do_ it and come back with numbers. I have done my own
measurements.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-15 13:11                       ` Ingo Molnar
@ 2004-10-15 14:50                         ` Robert Wisniewski
  2004-10-15 14:58                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Robert Wisniewski @ 2004-10-15 14:50 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Robert Wisniewski, Karim Yaghmour, linux-kernel, Thomas Zanussi,
	Richard J Moore, Michel Dagenais

Ingo Molnar writes:
 > 
 > * Robert Wisniewski <bob@watson.ibm.com> wrote:
 > 
 > >  > > cmpxchg (basically: try reserve; if fail retry; else write), with
 > >  > > per-cpu buffers.
 > >  > 
 > >  > this still does not solve all problems related to irq entries: if the
 > >  > IRQ interrups the tracing code after a 'successful reserve' but before
 > >  > the 'else write' point, and the trace is printed/saved from an
 > >  > interrupt, then there will be an incomplete entry in the trace.
 > > 
 > > That is incorrect.  The system behavior needed to generate an
 > > incomplete entry is far more complicated and unlikely than what you
 > > describe.
 > 
 > ah, but i'm talking about actual first-hand experience, not supposition. 
 > It happens quite easily with latency traces (which are saved/printed
 > from IRQ entries) and it can be very annoying to analyze. My first
 > tracers tried to do things without the IRQ flag, so i've seen both
 > methods.

This means that other code you've written has this happen, it doesn't mean
the fundamental model is broken.  Also, if what you claim is true and there
really is this contention, then it both means that 1) there are many many
other higher priority tasks in the system than the one you are trying to
trace, and 2) it's questionable whether you want to use locks.

 > and lets not forget this other issue:
 > 
 > >  > also, there is the problem of timestamp atomicity: if an IRQ interrupts
 > >  > the tracing code and the trace timestamp is taken in the 'else' branch
 > >  > then a time-reversal situation can occur: the entry will have a
 > >  > timestamp _larger_ than the IRQ trace-entries. With cli/sti all tracing
 > >  > entries occur atomically: either fully or not at all.
 > 
 > 
 > >  > > >Also, cli/sti makes it obviously SMP-safe and is pretty
 >                                                       ^^^^^^^^^^
 > >  > > >cheap on all x86 CPUs. (Also, i didnt want to use preempt_disable/enable
 >         ^^^^^^^^^^^^^^^^^^^^^^
 > >  > > >because the tracer interacts with that code quite heavily.)
 > >  > > 
 > >  > > No preempt_disable/enable found in the lockless logging in relayfs.
 > >  > 
 > >  > it would have to do that on PREEMPT_REALTIME. The irq flag solves both
 > >  > the races, the predictability problem and the preemption problem nicely.
 > >  > 
 > >  > 	Ingo
 > > 
 > > If you do not care about performance then you're probably right, this
 > > is fine.  If you are concerned about the time it takes to go through
 > > the sequence of code, then probably not.
 > 
 > see the portion i highlighted above. CPU makers are busy making cli/sti
 > as fast as possible. To make sure i tested it on a typical x86 box:
 > 
 >     # ./cli-latency
 >     CLI+STI latency: 8 cycles
 > 
 > Since the trace entry can be filled in a constant amount of time there's
 > no reason not to make use of that extra silicon that makes fast cli/sti
 > possible! How many trace entries can you generate per second via
 > relayfs, on a typical PC? Have you ever measured this?
 > 
 > in fact on a modern CPU cli/sti is very likely faster than a cmpxchgl
 > for the following reason: the cmpxchgl generates a read dependency on
 > the cacheline which must be fetched in. A single cachemiss can cost
 > _alot_ in comparison, 200 cycles easily. While in the cli/sti case we
 > stream out to a new cacheline in a linear fashion which is nicely
 > optimized by write-allocate cache policies in modern CPUs. No
 > cachemisses on the trace buffer! Just simple streaming out of data.
 > 
 > i challenge you to change your code to use cli/sti and compare it with
 > the cmpxchgl variant doing some heavy tracing on a modern PC. Please
 > just _do_ it and come back with numbers. I have done my own
 > measurements.
 > 
 > 	Ingo

This is an interesting analysis, do you have a paper you can point to, or
can you post the numbers from, and what the setup of the experiment was,
that you ran.  Sounds interesting.

Robert Wisniewski
The K42 MP OS Project
Advanced Operating Systems
Scalable Parallel Systems
IBM T.J. Watson Research Center
914-945-3181
http://www.research.ibm.com/K42/
bob@watson.ibm.com

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
  2004-10-15 14:50                         ` Robert Wisniewski
@ 2004-10-15 14:58                           ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-15 14:58 UTC (permalink / raw)
  To: Robert Wisniewski
  Cc: Karim Yaghmour, linux-kernel, Thomas Zanussi, Richard J Moore,
	Michel Dagenais


* Robert Wisniewski <bob@watson.ibm.com> wrote:

> Ingo Molnar writes:
>  > 
>  > * Robert Wisniewski <bob@watson.ibm.com> wrote:
>  > 
>  > >  > > cmpxchg (basically: try reserve; if fail retry; else write), with
>  > >  > > per-cpu buffers.
>  > >  > 
>  > >  > this still does not solve all problems related to irq entries: if the
>  > >  > IRQ interrups the tracing code after a 'successful reserve' but before
>  > >  > the 'else write' point, and the trace is printed/saved from an
>  > >  > interrupt, then there will be an incomplete entry in the trace.
>  > > 
>  > > That is incorrect.  The system behavior needed to generate an
>  > > incomplete entry is far more complicated and unlikely than what you
>  > > describe.
>  > 
>  > ah, but i'm talking about actual first-hand experience, not supposition. 
>  > It happens quite easily with latency traces (which are saved/printed
>  > from IRQ entries) and it can be very annoying to analyze. My first
>  > tracers tried to do things without the IRQ flag, so i've seen both
>  > methods.
> 
> This means that other code you've written has this happen, it doesn't mean
> the fundamental model is broken.  Also, if what you claim is true and there
> really is this contention, then it both means that 1) there are many many
> other higher priority tasks in the system than the one you are trying to
> trace, and 2) it's questionable whether you want to use locks.

_interrupts_. The latency tracer does traces like:

 00000002 0.022ms (+0.000ms): mark_page_accessed (zap_pte_range)
 00000002 0.022ms (+0.000ms): page_remove_rmap (zap_pte_range)
 00000002 0.022ms (+0.000ms): free_page_and_swap_cache (zap_pte_range)
 00000002 0.022ms (+0.001ms): put_page (zap_pte_range)
 00010002 0.023ms (+0.000ms): do_IRQ (zap_pte_range)
 00010002 0.023ms (+0.000ms): do_IRQ (<00000000>)
 00010003 0.024ms (+0.004ms): mask_and_ack_8259A (do_IRQ)
 00010003 0.029ms (+0.000ms): redirect_hardirq (do_IRQ)
 00010000 0.029ms (+0.000ms): handle_IRQ_event (do_IRQ)

and i just pointed out why i didnt use relayfs.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 11:59                   ` Dominik Karall
  2004-10-15 12:03                     ` Ingo Molnar
@ 2004-10-15 16:48                     ` Lee Revell
  2004-10-15 17:40                       ` Adam Heath
  1 sibling, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-15 16:48 UTC (permalink / raw)
  To: Dominik Karall; +Cc: Ingo Molnar, linux-kernel

On Fri, 2004-10-15 at 07:59, Dominik Karall wrote:
> On Friday 15 October 2004 12:26, Ingo Molnar wrote:
> > i have released the -U3 PREEMPT_REALTIME patch:
> >
> >  
> > http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-
> >U3
> 
> hi ingo!
> can you change your version string to lower case letters to avoid "problems" 
> with make-kpkg?
> if not, no problem...

Please file a Debian bug report.  make-kpkg should be able to handle
this.

Lee


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 16:48                     ` Lee Revell
@ 2004-10-15 17:40                       ` Adam Heath
  0 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-15 17:40 UTC (permalink / raw)
  To: Lee Revell; +Cc: Dominik Karall, Ingo Molnar, linux-kernel

On Fri, 15 Oct 2004, Lee Revell wrote:

> On Fri, 2004-10-15 at 07:59, Dominik Karall wrote:
> > On Friday 15 October 2004 12:26, Ingo Molnar wrote:
> > > i have released the -U3 PREEMPT_REALTIME patch:
> > >
> > >
> > > http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-
> > >U3
> >
> > hi ingo!
> > can you change your version string to lower case letters to avoid "problems"
> > with make-kpkg?
> > if not, no problem...
>
> Please file a Debian bug report.  make-kpkg should be able to handle
> this.

Yes and no.  Package names in debian must be lowercase.  Of course, make-kpkg
could always do a lowercase on the string.  shrug.

ps: Speaking with my dpkg hat on.

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
  2004-10-15 11:59                   ` Dominik Karall
@ 2004-10-15 17:54                   ` K.R. Foley
  2004-10-15 18:16                   ` K.R. Foley
                                     ` (7 subsequent siblings)
  9 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-15 17:54 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

Ingo Molnar wrote:
> i have released the -U3 PREEMPT_REALTIME patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
> 

Overall, for me, this just seems to be getting better and better with 
each iteration. I have posted a few traces that I have captured during 
some of my testing on my SMP system at home. Only the last four are from 
U3 (9-12). The others are from previous versions and in some cases 
probably aren't relevant any more. No. 9 which is the worst I've seen 
with U3 very well may have happened before the system was up completely.

Traces:
http://www.cybsft.com/testresults/2.6.9-rc4-mm1-VP/

kr

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
  2004-10-15 11:59                   ` Dominik Karall
  2004-10-15 17:54                   ` K.R. Foley
@ 2004-10-15 18:16                   ` K.R. Foley
  2004-10-15 20:29                   ` Gunther Persoons
                                     ` (6 subsequent siblings)
  9 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-15 18:16 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

Ingo Molnar wrote:
> i have released the -U3 PREEMPT_REALTIME patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
> 

I have gotten a couple of interesting traces on my dual 2.6G Xeon 
workstation here at the office. These were both generated running tests 
on (oddly enough) my own trace buffer that I am working on for a client 
here. The test basically consists of 100 threads putting data into the 
trace buffer concurrently and then one reader thread draining it and 
populating a multi-dimensional array to make sure all of the data is 
accounted for and not corrupted. All threads are running at a normal 
priority since the test is for correctness not performance. The traces 
are here:

http://www.cybsft.com/testresults/26workstation/2.6.9-rc4-mm1-VP/

kr

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
                                     ` (2 preceding siblings ...)
  2004-10-15 18:16                   ` K.R. Foley
@ 2004-10-15 20:29                   ` Gunther Persoons
  2004-10-15 23:16                   ` Bill Huey
                                     ` (5 subsequent siblings)
  9 siblings, 0 replies; 951+ messages in thread
From: Gunther Persoons @ 2004-10-15 20:29 UTC (permalink / raw)
  To: linux-kernel; +Cc: Ingo Molnar

Ingo Molnar wrote:

>i have released the -U3 PREEMPT_REALTIME patch:
>
>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
>
>this is a buildfixes-only release, and it is still experimental code.
>
>Changes since -U2:
>
> - build fix: fixes the latency.c compilation error reported by Adam 
>   Heath.
>
> - build fix: fixes !HIGHMEM compilation, patch from Andrew Rodland
>
>to create a -U3 tree from scratch the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
> + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
> + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
> + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
>
>	Ingo
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
Hey,

I get lockups a few second after i issue the dhcpcd command for my 
wireless pcmcia network card (cisco).
These lockups go away when i disable PREEMPT_REALTIME. Are there any 
logs or information you want?

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
                                     ` (3 preceding siblings ...)
  2004-10-15 20:29                   ` Gunther Persoons
@ 2004-10-15 23:16                   ` Bill Huey
  2004-10-16  0:21                     ` Bill Huey
  2004-10-16  6:48                     ` Ingo Molnar
  2004-10-16  1:00                   ` Lee Revell
                                     ` (4 subsequent siblings)
  9 siblings, 2 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-15 23:16 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

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

On Fri, Oct 15, 2004 at 12:26:33PM +0200, Ingo Molnar wrote:
> 
> i have released the -U3 PREEMPT_REALTIME patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3

Atomic violations:

bill


[-- Attachment #2: t --]
[-- Type: application/x-troff, Size: 3236 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 23:16                   ` Bill Huey
@ 2004-10-16  0:21                     ` Bill Huey
  2004-10-16  6:48                     ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-16  0:21 UTC (permalink / raw)
  To: Bill Huey
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Daniel Walker, Andrew Morton,
	Adam Heath, Lorenzo Allegrucci, Andrew Rodland

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

On Fri, Oct 15, 2004 at 04:16:09PM -0700, Bill Huey wrote:
> Atomic violations:

More atomic violations:

bill


[-- Attachment #2: t --]
[-- Type: application/x-troff, Size: 1741 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
                                     ` (4 preceding siblings ...)
  2004-10-15 23:16                   ` Bill Huey
@ 2004-10-16  1:00                   ` Lee Revell
  2004-10-16  2:35                     ` Lee Revell
  2004-10-16  2:58                   ` Adam Heath
                                     ` (3 subsequent siblings)
  9 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-16  1:00 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

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

On Fri, 2004-10-15 at 06:26, Ingo Molnar wrote:
> i have released the -U3 PREEMPT_REALTIME patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3

Does not compile.  .config attached:

  HOSTCC  scripts/bin2c
  CC      arch/i386/kernel/asm-offsets.s
In file included from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/spinlock.h:104: error: conflicting types for `spinlock_t'
include/asm/mutex.h:92: error: previous declaration of `spinlock_t'
In file included from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/spinlock.h:105:1: warning: "SPIN_LOCK_UNLOCKED" redefined
In file included from include/linux/spinlock.h:16,
                 from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/i386/kernel/asm-offsets.c:7:
include/asm/mutex.h:86:1: warning: this is the location of the previous definition
In file included from include/linux/capability.h:45,
                 from include/linux/sched.h:7,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/spinlock.h:538:1: warning: "spin_lock_init" redefined
include/linux/spinlock.h:107:1: warning: this is the location of the previous definition
include/linux/spinlock.h:548:1: warning: "spin_is_locked" redefined
include/linux/spinlock.h:143:1: warning: this is the location of the previous definition
include/linux/spinlock.h:558:1: warning: "spin_unlock_wait" redefined
include/linux/spinlock.h:173:1: warning: this is the location of the previous definition
In file included from include/linux/time.h:7,
                 from include/linux/timex.h:58,
                 from include/linux/sched.h:11,
                 from arch/i386/kernel/asm-offsets.c:7:
include/linux/seqlock.h: In function `__write_seqlock':
include/linux/seqlock.h:74: error: structure has no member named `magic'
include/linux/seqlock.h:74: error: structure has no member named `lock'
include/linux/seqlock.h:74: error: structure has no member named `babble'
include/linux/seqlock.h:74: error: structure has no member named `babble'
include/linux/seqlock.h:74: error: structure has no member named `module'
include/linux/seqlock.h:74: error: structure has no member named `owner'
include/linux/seqlock.h:74: error: structure has no member named `oline'
include/linux/seqlock.h:74: error: structure has no member named `lock'
include/linux/seqlock.h:74: error: structure has no member named `owner'
include/linux/seqlock.h:74: error: structure has no member named `oline'
include/linux/seqlock.h: In function `__write_sequnlock':
include/linux/seqlock.h:83: error: structure has no member named `magic'
include/linux/seqlock.h:83: error: structure has no member named `lock'
include/linux/seqlock.h:83: error: structure has no member named `babble'
include/linux/seqlock.h:83: error: structure has no member named `babble'
include/linux/seqlock.h:83: error: structure has no member named `module'
include/linux/seqlock.h:83: error: structure has no member named `lock'
include/linux/seqlock.h: In function `__write_tryseqlock':
include/linux/seqlock.h:88: error: structure has no member named `magic'
include/linux/seqlock.h:88: error: structure has no member named `lock'
include/linux/seqlock.h:88: error: structure has no member named `babble'
include/linux/seqlock.h:88: error: structure has no member named `babble'
include/linux/seqlock.h:88: error: structure has no member named `module'
include/linux/seqlock.h:88: error: structure has no member named `owner'
include/linux/seqlock.h:88: error: structure has no member named `oline'
include/linux/seqlock.h:88: error: structure has no member named `lock'
include/linux/seqlock.h:88: error: structure has no member named `owner'
include/linux/seqlock.h:88: error: structure has no member named `oline'
include/linux/seqlock.h: In function `__write_seqlock_raw':

etc

Lee

[-- Attachment #2: Type: text/plain, Size: 19537 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-rc4-mm1-VP-U3
# Fri Oct 15 20:23:43 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_PREEMPT_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

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

#
# 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 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_MCYRIXIII=y
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
# CONFIG_KEXEC is not set

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

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

#
# 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_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m

#
# Device Drivers
#

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

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD 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_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

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

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 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 is not set
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 is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER 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_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 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=m
CONFIG_VIA_RHINE_MMIO=y

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

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set

#
# 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=m
# CONFIG_MOUSE_SERIAL 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

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=m
CONFIG_RTC=y
# CONFIG_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=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=m
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
CONFIG_DRM_VIA=m
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
# CONFIG_I2C is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

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

#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
# CONFIG_SND is not set

#
# Open Sound System
#
CONFIG_SOUND_PRIME=m
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_CMPCI is not set
CONFIG_SOUND_EMU10K1=m
CONFIG_MIDI_EMU10K1=y
# CONFIG_SOUND_FUSION is not set
# CONFIG_SOUND_CS4281 is not set
# CONFIG_SOUND_ES1370 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ESSSOLO1 is not set
# CONFIG_SOUND_MAESTRO is not set
# CONFIG_SOUND_MAESTRO3 is not set
# CONFIG_SOUND_ICH is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
# CONFIG_SOUND_VIA82CXXX is not set
# CONFIG_SOUND_OSS is not set
# CONFIG_SOUND_ALI5455 is not set
# CONFIG_SOUND_FORTE is not set
# CONFIG_SOUND_RME96XX is not set
# CONFIG_SOUND_AD1980 is not set

#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

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

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_STORAGE is not set

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

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

#
# USB Network adaptors
#
# 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

#
# USB port drivers
#

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

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_TEST is not set

#
# USB ATM/DSL drivers
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
# CONFIG_EXT2_FS 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=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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

#
# 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=m
# 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=m
# 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=m
CONFIG_NLS_KOI8_R=m
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_INFO=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_4KSTACKS=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_ROOTPLUG is not set
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

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

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16  1:00                   ` Lee Revell
@ 2004-10-16  2:35                     ` Lee Revell
  2004-10-16  6:42                       ` Ingo Molnar
  2004-10-16 10:29                       ` Rui Nuno Capela
  0 siblings, 2 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-16  2:35 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

On Fri, 2004-10-15 at 21:00, Lee Revell wrote:
> On Fri, 2004-10-15 at 06:26, Ingo Molnar wrote:
> > i have released the -U3 PREEMPT_REALTIME patch:
> > 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
> 
> Does not compile.  .config attached:

It builds fine if CONFIG_SMP is set.  Am I really the only person
running this on UP?

Lee


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
                                     ` (5 preceding siblings ...)
  2004-10-16  1:00                   ` Lee Revell
@ 2004-10-16  2:58                   ` Adam Heath
  2004-10-16  7:56                     ` Ingo Molnar
  2004-10-16  6:13                   ` Lee Revell
                                     ` (2 subsequent siblings)
  9 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-16  2:58 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Fri, 15 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U3 PREEMPT_REALTIME patch:
>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3

scheduling while atomic: postmaster/0x04000002/3175
caller is cond_resched+0x53/0x70
 [<c01069f7>] dump_stack+0x17/0x20
 [<c027b457>] schedule+0x517/0x550
 [<c027b9c3>] cond_resched+0x53/0x70
 [<c012cdc7>] _mutex_lock+0x17/0x40
 [<c012ce18>] _mutex_lock_irqsave+0x8/0x10
 [<c01b21ae>] avc_has_perm_noaudit+0x2e/0x180
 [<c01b2335>] avc_has_perm+0x35/0x68
 [<c01b79ca>] ipc_has_perm+0x6a/0x80
 [<c01ab716>] semctl_main+0xa6/0x410
 [<c01abcad>] sys_semctl+0xad/0xb0
 [<c010bafd>] sys_ipc+0xad/0x250
 [<c0105bff>] syscall_call+0x7/0xb
scheduling while atomic: postmaster/0x04000002/5260
caller is cond_resched+0x53/0x70
 [<c01069f7>] dump_stack+0x17/0x20
 [<c027b457>] schedule+0x517/0x550
 [<c027b9c3>] cond_resched+0x53/0x70
 [<c012cdc7>] _mutex_lock+0x17/0x40
 [<c012ce18>] _mutex_lock_irqsave+0x8/0x10
 [<c01b21ae>] avc_has_perm_noaudit+0x2e/0x180
 [<c01b2335>] avc_has_perm+0x35/0x68
 [<c01b79ca>] ipc_has_perm+0x6a/0x80
 [<c01a9832>] ipcperms+0x82/0xb0
 [<c01ab6fe>] semctl_main+0x8e/0x410
 [<c01abcad>] sys_semctl+0xad/0xb0
 [<c010bafd>] sys_ipc+0xad/0x250
 [<c0105bff>] syscall_call+0x7/0xb
scheduling while atomic: liquidwar/0x04000002/5505
caller is cond_resched+0x53/0x70
 [<c01069f7>] dump_stack+0x17/0x20
 [<c027b457>] schedule+0x517/0x550
 [<c027b9c3>] cond_resched+0x53/0x70
 [<c012cdc7>] _mutex_lock+0x17/0x40
 [<c012ce18>] _mutex_lock_irqsave+0x8/0x10
 [<c01b21ae>] avc_has_perm_noaudit+0x2e/0x180
 [<c01b2335>] avc_has_perm+0x35/0x68
 [<c01b79ca>] ipc_has_perm+0x6a/0x80
 [<c01acfe6>] sys_shmctl+0x196/0x690
 [<c010bc9a>] sys_ipc+0x24a/0x250
 [<c0105bff>] syscall_call+0x7/0xb
scheduling while atomic: XFree86/0x04000002/1127
caller is cond_resched+0x53/0x70
 [<c01069f7>] dump_stack+0x17/0x20
 [<c027b457>] schedule+0x517/0x550
 [<c027b9c3>] cond_resched+0x53/0x70
 [<c012cdd3>] _mutex_lock+0x23/0x40
 [<c012ce18>] _mutex_lock_irqsave+0x8/0x10
 [<c01b228e>] avc_has_perm_noaudit+0x10e/0x180
 [<c01b2335>] avc_has_perm+0x35/0x68
 [<c01b79ca>] ipc_has_perm+0x6a/0x80
 [<c01ad30d>] sys_shmctl+0x4bd/0x690
 [<c010bc9a>] sys_ipc+0x24a/0x250
 [<c0105bff>] syscall_call+0x7/0xb
scheduling while atomic: XFree86/0x04000002/1127
caller is cond_resched+0x53/0x70
 [<c01069f7>] dump_stack+0x17/0x20
 [<c027b457>] schedule+0x517/0x550
 [<c027b9c3>] cond_resched+0x53/0x70
 [<c012cdc7>] _mutex_lock+0x17/0x40
 [<c012ce18>] _mutex_lock_irqsave+0x8/0x10
 [<c01b21ae>] avc_has_perm_noaudit+0x2e/0x180
 [<c01b2335>] avc_has_perm+0x35/0x68
 [<c01b79ca>] ipc_has_perm+0x6a/0x80
 [<c01a9832>] ipcperms+0x82/0xb0
 [<c01ad59f>] do_shmat+0xbf/0x2e0
 [<c010bbef>] sys_ipc+0x19f/0x250
 [<c0105bff>] syscall_call+0x7/0xb
scheduling while atomic: liquidwar/0x04000002/5505
caller is cond_resched+0x53/0x70
 [<c01069f7>] dump_stack+0x17/0x20
 [<c027b457>] schedule+0x517/0x550
 [<c027b9c3>] cond_resched+0x53/0x70
 [<c012cdc7>] _mutex_lock+0x17/0x40
 [<c012ce18>] _mutex_lock_irqsave+0x8/0x10
 [<c01b21ae>] avc_has_perm_noaudit+0x2e/0x180
 [<c01b2335>] avc_has_perm+0x35/0x68
 [<c01b79ca>] ipc_has_perm+0x6a/0x80
 [<c01ad5ba>] do_shmat+0xda/0x2e0
 [<c010bbef>] sys_ipc+0x19f/0x250
 [<c0105bff>] syscall_call+0x7/0xb
scheduling while atomic: liquidwar/0x04000002/5505
caller is cond_resched+0x53/0x70
 [<c01069f7>] dump_stack+0x17/0x20
 [<c027b457>] schedule+0x517/0x550
 [<c027b9c3>] cond_resched+0x53/0x70
 [<c012cdc7>] _mutex_lock+0x17/0x40
 [<c012ce18>] _mutex_lock_irqsave+0x8/0x10
 [<c01b21ae>] avc_has_perm_noaudit+0x2e/0x180
 [<c01b2335>] avc_has_perm+0x35/0x68
 [<c01b79ca>] ipc_has_perm+0x6a/0x80
 [<c01a9832>] ipcperms+0x82/0xb0
 [<c01ad59f>] do_shmat+0xbf/0x2e0
 [<c010bbef>] sys_ipc+0x19f/0x250
 [<c0105bff>] syscall_call+0x7/0xb


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
                                     ` (6 preceding siblings ...)
  2004-10-16  2:58                   ` Adam Heath
@ 2004-10-16  6:13                   ` Lee Revell
  2004-10-16 14:21                   ` Dominik Karall
  2004-10-16 15:33                   ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4 Ingo Molnar
  9 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-16  6:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

On Fri, 2004-10-15 at 06:26, Ingo Molnar wrote:
> i have released the -U3 PREEMPT_REALTIME patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
> 

OK, I got this to build by enabling CONFIG_SMP, but it died during the
boot process.  It may have been network related, as it hung on when
running ntpdate.  I hit ctrl-C and the boot process continued, but as
soon as gdm started I got a blank screen, I could not get to X or the
console.

Oct 16 02:01:22 krustophenia kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Oct 16 02:01:22 krustophenia kernel: NET: Registered protocol family 17

This was the last thing in dmesg.  I did not see any errors at all
during the boot process.

I suspect the network driver, via-rhine.

Lee 


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16  2:35                     ` Lee Revell
@ 2004-10-16  6:42                       ` Ingo Molnar
  2004-10-16  9:02                         ` Lee Revell
  2004-10-16 10:29                       ` Rui Nuno Capela
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16  6:42 UTC (permalink / raw)
  To: Lee Revell
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Lee Revell <rlrevell@joe-job.com> wrote:

> > > i have released the -U3 PREEMPT_REALTIME patch:
> > > 
> > >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
> > 
> > Does not compile.  .config attached:
> 
> It builds fine if CONFIG_SMP is set.  Am I really the only person
> running this on UP?

i regularly test it on UP. Do you have SPINLOCK_DEBUG enabled perhaps? 
That doesnt work right now. You can enable DEBUG_SPINLOCK_SLEEP and
DEBUG_PREEMPT.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 23:16                   ` Bill Huey
  2004-10-16  0:21                     ` Bill Huey
@ 2004-10-16  6:48                     ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16  6:48 UTC (permalink / raw)
  To: Bill Huey
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Bill Huey <bhuey@lnxw.com> wrote:

> On Fri, Oct 15, 2004 at 12:26:33PM +0200, Ingo Molnar wrote:
> > 
> > i have released the -U3 PREEMPT_REALTIME patch:
> > 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
> 
> Atomic violations:

ok, the rtc clock needs to go back to raw for the time being - the patch
below should fix it.

	Ingo

--- linux.old/arch/i386/kernel/time.c	
+++ linux.new/arch/i386/kernel/time.c	
@@ -81,7 +81,7 @@ unsigned long cpu_khz;	/* Detected as we
 
 extern unsigned long wall_jiffies;
 
-DECLARE_SPINLOCK(rtc_lock);
+DECLARE_RAW_SPINLOCK(rtc_lock);
 
 #include <asm/i8253.h>
 
--- linux.old/include/linux/mc146818rtc.h	
+++ linux.new/include/linux/mc146818rtc.h	
@@ -16,7 +16,7 @@
 #include <linux/spinlock.h>		/* spinlock_t */
 #include <asm/mc146818rtc.h>		/* register access macros */
 
-extern spinlock_t rtc_lock;		/* serialize CMOS RAM access */
+extern raw_spinlock_t rtc_lock;		/* serialize CMOS RAM access */
 
 /**********************************************************************
  * register summary

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16  2:58                   ` Adam Heath
@ 2004-10-16  7:56                     ` Ingo Molnar
  2004-10-16  8:18                       ` Ingo Molnar
  2004-10-16 18:38                       ` Adam Heath
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16  7:56 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


* Adam Heath <doogie@debian.org> wrote:

> On Fri, 15 Oct 2004, Ingo Molnar wrote:
> 
> >
> > i have released the -U3 PREEMPT_REALTIME patch:
> >
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
> 
> scheduling while atomic: postmaster/0x04000002/3175
> caller is cond_resched+0x53/0x70
>  [<c01069f7>] dump_stack+0x17/0x20
>  [<c027b457>] schedule+0x517/0x550
>  [<c027b9c3>] cond_resched+0x53/0x70
>  [<c012cdc7>] _mutex_lock+0x17/0x40
>  [<c012ce18>] _mutex_lock_irqsave+0x8/0x10
>  [<c01b21ae>] avc_has_perm_noaudit+0x2e/0x180
>  [<c01b2335>] avc_has_perm+0x35/0x68
>  [<c01b79ca>] ipc_has_perm+0x6a/0x80
>  [<c01ab716>] semctl_main+0xa6/0x410
>  [<c01abcad>] sys_semctl+0xad/0xb0
>  [<c010bafd>] sys_ipc+0xad/0x250
>  [<c0105bff>] syscall_call+0x7/0xb

thanks - that's the IPC code that is not converted over from RCU yet.

a suggestion for future testing: please enable PREEMPT_TIMING for the
next kernels you build, it will print such entries at the end of
stacktraces:

 preempt count: 2
 entry 1: cpu_idle+0x38/0x90 / (start_kernel+0x1ac/0x1f0)
 entry 2: _spin_lock+0x22/0x80 / (timer_interrupt+0x1b/0x130)

while in this particular IPC case it's immediately visible that it's the
IPC RCU use that is the root of the problem, the preemption trace
printout can be very helpful in other cases to quickly identify where
the preemptible section was started. E.g. the networking code sometimes
has very deep nesting and non-obvious locking. Thanks,

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16  7:56                     ` Ingo Molnar
@ 2004-10-16  8:18                       ` Ingo Molnar
  2004-10-16 18:38                       ` Adam Heath
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16  8:18 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


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

> a suggestion for future testing: please enable PREEMPT_TIMING for the
> next kernels you build, it will print such entries at the end of
> stacktraces:
> 
>  preempt count: 2
>  entry 1: cpu_idle+0x38/0x90 / (start_kernel+0x1ac/0x1f0)
>  entry 2: _spin_lock+0x22/0x80 / (timer_interrupt+0x1b/0x130)

correction: in -U3 you'll also need to enable LATENCY_TRACE for this to
work. I've fixed this in my tree and from -U4 onwards the preemption
trace will be maintained and printed if DEBUG_PREEMPT is enabled.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16  6:42                       ` Ingo Molnar
@ 2004-10-16  9:02                         ` Lee Revell
  2004-10-16 10:36                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-16  9:02 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

On Sat, 2004-10-16 at 02:42, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > > > i have released the -U3 PREEMPT_REALTIME patch:
> > > > 
> > > >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
> > > 
> > > Does not compile.  .config attached:
> > 
> > It builds fine if CONFIG_SMP is set.  Am I really the only person
> > running this on UP?
> 
> i regularly test it on UP. Do you have SPINLOCK_DEBUG enabled perhaps? 
> That doesnt work right now. You can enable DEBUG_SPINLOCK_SLEEP and
> DEBUG_PREEMPT.

Sorry, I did have that enabled.  This caused a build failure with a UP
build and a boot failure with CONFIG_SMP.

Lee


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16  2:35                     ` Lee Revell
  2004-10-16  6:42                       ` Ingo Molnar
@ 2004-10-16 10:29                       ` Rui Nuno Capela
  2004-10-16 12:54                         ` K.R. Foley
  1 sibling, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-16 10:29 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

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

Lee Revell writes:
>> On Fri, 2004-10-15 at 06:26, Ingo Molnar wrote:
>> > i have released the -U3 PREEMPT_REALTIME patch:
>> >
>> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
>>
>> Does not compile.  .config attached:
>
> It builds fine if CONFIG_SMP is set.  Am I really the only person
> running this on UP?
>

I run both, on different machines.

I'm actually running 2.6.9-rc4-mm1-U3 at this very moment, on my laptop
(P4 2.53Ghz/UP, Mdk 10.1c) and also on my desktop machine (P4
2.80Ghz/SMP/HT, SuSE 9.1).

However, on the desktop (SMP/HT) I could only made it boot/init
successfully with CONFIG_PREEMPT_REALTIME off. On my laptop (UP) is
running pretty well on full RT.

Both kernel configs are attached.

config-2.6.9-rc4-mm1-U3.0smp.gz: is from my SMP/HT destop (non-RT-preempted)

config-2.6.9-rc4-mm1-RT-U3.0.gz: is from my laptopn (RT-preempted).

These seem stable, even though are taken from the menu-du-jour :)

Take care.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: config-2.6.9-rc4-mm1-U3.0smp.gz --]
[-- Type: application/x-gzip, Size: 7942 bytes --]

[-- Attachment #3: config-2.6.9-rc4-mm1-RT-U3.0.gz --]
[-- Type: application/x-gzip, Size: 8248 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16  9:02                         ` Lee Revell
@ 2004-10-16 10:36                           ` Ingo Molnar
  2004-10-16 11:03                             ` Rui Nuno Capela
                                               ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16 10:36 UTC (permalink / raw)
  To: Lee Revell
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Lee Revell <rlrevell@joe-job.com> wrote:

> > i regularly test it on UP. Do you have SPINLOCK_DEBUG enabled perhaps? 
> > That doesnt work right now. You can enable DEBUG_SPINLOCK_SLEEP and
> > DEBUG_PREEMPT.
> 
> Sorry, I did have that enabled.  This caused a build failure with a UP
> build and a boot failure with CONFIG_SMP.

not your fault at all - i cleaned this up in my tree so that only valid
combinations can be selected, these fixes will show up in -U4.

it seems that SMP + PREEMPT_TIMING is not stable though, somehow the
latency printk's cause a crash sooner or later. I'm still debugging this
problem. Without PREEMPT_TIMING the SMP kernel is stable.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 10:36                           ` Ingo Molnar
@ 2004-10-16 11:03                             ` Rui Nuno Capela
  2004-10-16 11:12                               ` Ingo Molnar
  2004-10-16 12:32                             ` K.R. Foley
  2004-10-17 13:14                             ` Rui Nuno Capela
  2 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-16 11:03 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

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

Ingo Molnar wrote:
>
> it seems that SMP + PREEMPT_TIMING is not stable though, somehow the
> latency printk's cause a crash sooner or later. I'm still debugging this
> problem. Without PREEMPT_TIMING the SMP kernel is stable.
>

How true!

My first successful SMP/HT PREEMPT_REALTIME has been achieved, by just
turning off PREEMPT_TIMING. So you won't get any latency trace dumps from
here ;)

Actual .config.gz attached.

But now I have my two prime machines on full-RT-throttle, yeepee! :)

Thankful for the hint!
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: config-2.6.9-rc4-mm1-RT-U3.1smp.gz --]
[-- Type: application/x-gzip, Size: 7949 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 11:03                             ` Rui Nuno Capela
@ 2004-10-16 11:12                               ` Ingo Molnar
  2004-10-16 11:55                                 ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16 11:12 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> Ingo Molnar wrote:
> >
> > it seems that SMP + PREEMPT_TIMING is not stable though, somehow the
> > latency printk's cause a crash sooner or later. I'm still debugging this
> > problem. Without PREEMPT_TIMING the SMP kernel is stable.
> >
> 
> How true!
> 
> My first successful SMP/HT PREEMPT_REALTIME has been achieved, by just
> turning off PREEMPT_TIMING. So you won't get any latency trace dumps
> from here ;)

meanwhile i've mostly debugged the problem: it's an illegal recursion
into the timer code caused by PREEMPT_TIMING printks from within the
timer code calling do_poke_blanked_console() which in turn calls
del_timer() ...

this bug has been in the PREEMPT_TIMING code for almost forever, it's
just that under PREEMPT_REALTIME all the other latency sources are gone,
only the few places that still use raw spinlocks are remaining, amongst
them the timer code ...

> Actual .config.gz attached.
> 
> But now I have my two prime machines on full-RT-throttle, yeepee! :)

great! :) I strongly suspect this bug is the one Lee and Mark are seeing
too.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 11:12                               ` Ingo Molnar
@ 2004-10-16 11:55                                 ` Rui Nuno Capela
  2004-10-16 12:01                                   ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-16 11:55 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

Ingo,

>
> Rui Nuno Capela wrote:
>
>> Ingo Molnar wrote:
>> >
>> > it seems that SMP + PREEMPT_TIMING is not stable though, somehow the
>> > latency printk's cause a crash sooner or later. I'm still debugging
>> > this problem. Without PREEMPT_TIMING the SMP kernel is stable.
>> >
>>
>> How true!
>>
>> My first successful SMP/HT PREEMPT_REALTIME has been achieved, by just
>> turning off PREEMPT_TIMING. So you won't get any latency trace dumps
>> from here ;)

OOPS. I think I've made a terrible mistake. It seems that
SMP+PREEMPT_REALTIME is NOT solved after all in my P4/HT box, even with
PREEMPT_TIMING not set.

As one may check from the .config.gz I've sent just about minutes ago,
PREEMPT_REALTIME wasn't being set, and the RT label was bogus.

So sorry to mislead you all. I should have known, it was too good to be
true :(

Take care.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 11:55                                 ` Rui Nuno Capela
@ 2004-10-16 12:01                                   ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16 12:01 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> OOPS. I think I've made a terrible mistake. It seems that
> SMP+PREEMPT_REALTIME is NOT solved after all in my P4/HT box, even
> with PREEMPT_TIMING not set.

no problem, there are other types of bugs too reported by others that do
not seem to be related to the PREEMPT_TIMING problem.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 10:36                           ` Ingo Molnar
  2004-10-16 11:03                             ` Rui Nuno Capela
@ 2004-10-16 12:32                             ` K.R. Foley
  2004-10-17 13:14                             ` Rui Nuno Capela
  2 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-16 12:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> 
>>>i regularly test it on UP. Do you have SPINLOCK_DEBUG enabled perhaps? 
>>>That doesnt work right now. You can enable DEBUG_SPINLOCK_SLEEP and
>>>DEBUG_PREEMPT.
>>
>>Sorry, I did have that enabled.  This caused a build failure with a UP
>>build and a boot failure with CONFIG_SMP.
> 
> 
> not your fault at all - i cleaned this up in my tree so that only valid
> combinations can be selected, these fixes will show up in -U4.
> 
> it seems that SMP + PREEMPT_TIMING is not stable though, somehow the
> latency printk's cause a crash sooner or later. I'm still debugging this
> problem. Without PREEMPT_TIMING the SMP kernel is stable.
> 
> 	Ingo
> 

On my SMP system here at home I have not seen this instability. It's 
been rock solid since yesterday morning and I already posted the worst 
latencies that have been generated. My SMP system at work was up and 
doing fine until I shut it down when I left last night. And posted the 
high latencies from that yesterday as well. All in all it doesn't look 
too bad to me.

kr

Home SMP system:
[root@porky latencies]# uptime
  07:23:55 up 19:42,  3 users,  load average: 67.22, 83.69, 57.23

Current time: Sat Oct 16 06:37:08 CDT 2004
Exiting test run..
Displaying report...
Total test time: 18h46m6s
Tests passed:
TTCP ran 1024 times in 8h32m50s, failed on 0 attempts.
FS ran 64 times in 18h46m3s, failed on 0 attempts.
CRASHME ran 256 times in 2h31m42s, failed on 0 attempts.
FIFOS_MMAP ran 256 times in 11h23m41s, failed on 0 attempts.
P3-FPU ran 256 times in 6h41m44s, failed on 0 attempts.
SAVE-STATE ran 1 times in 1m2s, failed on 0 attempts.
**** Test run completed successfully ****



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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 10:29                       ` Rui Nuno Capela
@ 2004-10-16 12:54                         ` K.R. Foley
  2004-10-16 13:04                           ` Ingo Molnar
  2004-10-16 13:41                           ` Rui Nuno Capela
  0 siblings, 2 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-16 12:54 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Lee Revell, Ingo Molnar, linux-kernel, mark_h_johnson,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

Rui Nuno Capela wrote:
> Lee Revell writes:
> 
>>>On Fri, 2004-10-15 at 06:26, Ingo Molnar wrote:
>>>
>>>>i have released the -U3 PREEMPT_REALTIME patch:
>>>>
>>>>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
>>>
>>>Does not compile.  .config attached:
>>
>>It builds fine if CONFIG_SMP is set.  Am I really the only person
>>running this on UP?
>>
> 
> 
> I run both, on different machines.
> 
> I'm actually running 2.6.9-rc4-mm1-U3 at this very moment, on my laptop
> (P4 2.53Ghz/UP, Mdk 10.1c) and also on my desktop machine (P4
> 2.80Ghz/SMP/HT, SuSE 9.1).
> 
> However, on the desktop (SMP/HT) I could only made it boot/init
> successfully with CONFIG_PREEMPT_REALTIME off. On my laptop (UP) is
> running pretty well on full RT.

I'm curious what you get when you try to boot the SMP system with 
REALTIME on? My SMP/HT system at the office works fine with this. 
Although there is one difference that jumps out at me. I have disabled 
ACPI. I don't have the config handy so I can't do a complete comparison, 
just going from memory.

kr

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 12:54                         ` K.R. Foley
@ 2004-10-16 13:04                           ` Ingo Molnar
  2004-10-16 13:07                             ` K.R. Foley
  2004-10-16 13:41                           ` Rui Nuno Capela
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16 13:04 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Rui Nuno Capela, Lee Revell, linux-kernel, mark_h_johnson,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


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

> >>It builds fine if CONFIG_SMP is set.  Am I really the only person
> >>running this on UP?
> >
> >I run both, on different machines.
> >
> >I'm actually running 2.6.9-rc4-mm1-U3 at this very moment, on my laptop
> >(P4 2.53Ghz/UP, Mdk 10.1c) and also on my desktop machine (P4
> >2.80Ghz/SMP/HT, SuSE 9.1).
> >
> >However, on the desktop (SMP/HT) I could only made it boot/init
> >successfully with CONFIG_PREEMPT_REALTIME off. On my laptop (UP) is
> >running pretty well on full RT.
> 
> I'm curious what you get when you try to boot the SMP system with
> REALTIME on? My SMP/HT system at the office works fine with this. 
> Although there is one difference that jumps out at me. I have disabled
> ACPI. I don't have the config handy so I can't do a complete
> comparison, just going from memory.

one group of complaints seems to be related to SELINUX=y: it has hooks
all across the kernel deep within the locking hierarchy - and then
itself it does pretty complex stuff too. IPC is certainly broken due to
this, but some networking problems seem to be related too.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 13:04                           ` Ingo Molnar
@ 2004-10-16 13:07                             ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-16 13:07 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, Lee Revell, linux-kernel, mark_h_johnson,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>>>It builds fine if CONFIG_SMP is set.  Am I really the only person
>>>>running this on UP?
>>>
>>>I run both, on different machines.
>>>
>>>I'm actually running 2.6.9-rc4-mm1-U3 at this very moment, on my laptop
>>>(P4 2.53Ghz/UP, Mdk 10.1c) and also on my desktop machine (P4
>>>2.80Ghz/SMP/HT, SuSE 9.1).
>>>
>>>However, on the desktop (SMP/HT) I could only made it boot/init
>>>successfully with CONFIG_PREEMPT_REALTIME off. On my laptop (UP) is
>>>running pretty well on full RT.
>>
>>I'm curious what you get when you try to boot the SMP system with
>>REALTIME on? My SMP/HT system at the office works fine with this. 
>>Although there is one difference that jumps out at me. I have disabled
>>ACPI. I don't have the config handy so I can't do a complete
>>comparison, just going from memory.
> 
> 
> one group of complaints seems to be related to SELINUX=y: it has hooks
> all across the kernel deep within the locking hierarchy - and then
> itself it does pretty complex stuff too. IPC is certainly broken due to
> this, but some networking problems seem to be related too.
> 
> 	Ingo
> 
Well therein lies a big difference. I have disabled this on all the 
systems that I am testing on.

kr

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 12:54                         ` K.R. Foley
  2004-10-16 13:04                           ` Ingo Molnar
@ 2004-10-16 13:41                           ` Rui Nuno Capela
  2004-10-16 13:55                             ` K.R. Foley
  1 sibling, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-16 13:41 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Lee Revell, Ingo Molnar, linux-kernel, mark_h_johnson,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

K.R. Foley wrote:
>Rui Nuno Capela:
>>
>> I run both, on different machines.
>>
>> I'm actually running 2.6.9-rc4-mm1-U3 at this very moment, on my laptop
>> (P4 2.53Ghz/UP, Mdk 10.1c) and also on my desktop machine (P4
>> 2.80Ghz/SMP/HT, SuSE 9.1).
>>
>> However, on the desktop (SMP/HT) I could only made it boot/init
>> successfully with CONFIG_PREEMPT_REALTIME off. On my laptop (UP) is
>> running pretty well on full RT.
>
> I'm curious what you get when you try to boot the SMP system with
> REALTIME on? My SMP/HT system at the office works fine with this.
> Although there is one difference that jumps out at me. I have disabled
> ACPI. I don't have the config handy so I can't do a complete comparison,
> just going from memory.
>

Hmm. The way I see it, if I say acpi=off on kernel boot, I loose HT, and
end in a SMP enabled kernel running on only one CPU. To keep ACPI disabled
but rely on it to show up those hyperthreaded virtual cpus on boot, one
should say acpi=ht, I guess.

Is that what you're asking?
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 13:41                           ` Rui Nuno Capela
@ 2004-10-16 13:55                             ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-16 13:55 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Lee Revell, Ingo Molnar, linux-kernel, mark_h_johnson,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

Rui Nuno Capela wrote:
> K.R. Foley wrote:
> 
>>Rui Nuno Capela:
>>
>>>I run both, on different machines.
>>>
>>>I'm actually running 2.6.9-rc4-mm1-U3 at this very moment, on my laptop
>>>(P4 2.53Ghz/UP, Mdk 10.1c) and also on my desktop machine (P4
>>>2.80Ghz/SMP/HT, SuSE 9.1).
>>>
>>>However, on the desktop (SMP/HT) I could only made it boot/init
>>>successfully with CONFIG_PREEMPT_REALTIME off. On my laptop (UP) is
>>>running pretty well on full RT.
>>
>>I'm curious what you get when you try to boot the SMP system with
>>REALTIME on? My SMP/HT system at the office works fine with this.
>>Although there is one difference that jumps out at me. I have disabled
>>ACPI. I don't have the config handy so I can't do a complete comparison,
>>just going from memory.
>>
> 
> 
> Hmm. The way I see it, if I say acpi=off on kernel boot, I loose HT, and
> end in a SMP enabled kernel running on only one CPU. To keep ACPI disabled
> but rely on it to show up those hyperthreaded virtual cpus on boot, one
> should say acpi=ht, I guess.
> 
> Is that what you're asking?

Actually what I was asking was what messages, etc. you get before the 
system fails to boot. I think Ingo already pointed out why several 
people, maybe yourself included, are having problems with this patch.

As for acpi, I just disabled the power management stuff prior to 
building the kernel. Of course my ht still works.

kr

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
                                     ` (7 preceding siblings ...)
  2004-10-16  6:13                   ` Lee Revell
@ 2004-10-16 14:21                   ` Dominik Karall
  2004-10-16 15:24                     ` Ingo Molnar
  2004-10-16 15:33                   ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4 Ingo Molnar
  9 siblings, 1 reply; 951+ messages in thread
From: Dominik Karall @ 2004-10-16 14:21 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

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

On Friday 15 October 2004 12:26, Ingo Molnar wrote:
> i have released the -U3 PREEMPT_REALTIME patch:
>
>  
> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-
>U3

i'm not sure if this bug depends on preemption patch, or if it is a general 
one in -mm1 tree.

kernel BUG at fs/fat/cache.c:150!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: ipx p8022 psnap llc nvidia snd_mixer_oss sd_mod tda9887 
tuner saa7134 video_buf v4l2_common v4l1_compat ir_common videodev 8139too 
sis900 crc32 ehci_hcd usb_storage scsi_mod ohci_hcd usbcore snd_intel8x0 
snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc ohci1394 
ieee1394 i2c_sis96x i2c_core
CPU:    0
EIP:    0060:[<c01a0b53>]    Tainted: P      VLI
EFLAGS: 00210202   (2.6.9-rc4-mm1-vp-u3)
EIP is at fat_cache_add+0x135/0x151
eax: 00000001   ebx: cf5712b8   ecx: c656f780   edx: cf571201
esi: ce414c50   edi: c656f768   ebp: c656f7b8   esp: ce414c1c
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process mplayer (pid: 9843, threadinfo=ce414000 task=c8128a20)
Stack: c656f7b8 ce414c88 cf785800 00000001 c656f768 c01a11bb ce414c88 ce414c8c
       c6d06300 00000000 c8128a20 0003ffff c656f7b8 00000000 00000000 00000001
       000db50e c656f7b8 c656f768 cf785800 cee1d800 c01a12c1 ce414c8c 00200246
Call Trace:
 [<c01a11bb>] fat_get_cluster+0x11f/0x1de
 [<c01a12c1>] fat_bmap_cluster+0x47/0x98
 [<c01a13f1>] fat_bmap+0xdf/0x101
 [<c01a36e8>] fat_get_block+0x30/0x198
 [<c0152866>] alloc_buffer_head+0x33/0x52
 [<c01501ea>] create_buffers+0x51/0x86
 [<c015141c>] block_read_full_page+0x1bd/0x2cc
 [<c01a36b8>] fat_get_block+0x0/0x198
 [<c0132f0c>] add_to_page_cache+0x58/0x6e
 [<c013a0e4>] read_pages+0xbe/0x15e
 [<c013a49c>] do_page_cache_readahead+0x120/0x19b
 [<c013a606>] page_cache_readahead+0xef/0x1f8
 [<c01336ab>] do_generic_mapping_read+0x133/0x54b
 [<c013c911>] lru_cache_add+0xd/0x4f
 [<c0133d53>] __generic_file_aio_read+0x1a3/0x218
 [<c0133ac3>] file_read_actor+0x0/0xed
 [<c0133ec5>] generic_file_read+0x9c/0xba
 [<c012b84c>] _mutex_lock+0x20/0x36
 [<c01244c8>] do_sigaction+0x1dc/0x1f7
 [<c012b468>] autoremove_wake_function+0x0/0x43
 [<c012b84c>] _mutex_lock+0x20/0x36
 [<c0167974>] dnotify_parent+0x35/0x95
 [<c014e0a9>] vfs_read+0xcd/0x126
 [<c014e36f>] sys_read+0x41/0x6a
 [<c0103f7b>] syscall_call+0x7/0xb
Code: f2 89 e8 e8 9f fe ff ff 85 c0 89 c3 74 2a 83 6f 20 01 8b 04 24 39 00 75 
24 8b 14 24 a1 74 0b 3c c0 e8 9c b1 f9 ff e9 40 ff ff ff <0f> 0b 96 00 e5 b7 
2d c0 e9 2f ff ff ff 8b 1c 24 eb 88 0f 0b 48
 <5>Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0,  type 0

best regards,
dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 14:21                   ` Dominik Karall
@ 2004-10-16 15:24                     ` Ingo Molnar
  2004-10-16 20:30                       ` Dominik Karall
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16 15:24 UTC (permalink / raw)
  To: Dominik Karall
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Dominik Karall <dominik.karall@gmx.net> wrote:

> i'm not sure if this bug depends on preemption patch, or if it is a
> general one in -mm1 tree.
> 
> kernel BUG at fs/fat/cache.c:150!

> EIP is at fat_cache_add+0x135/0x151

> Process mplayer (pid: 9843, threadinfo=ce414000 task=c8128a20)

> Call Trace:
>  [<c01a11bb>] fat_get_cluster+0x11f/0x1de
>  [<c01a12c1>] fat_bmap_cluster+0x47/0x98
>  [<c01a13f1>] fat_bmap+0xdf/0x101
>  [<c01a36e8>] fat_get_block+0x30/0x198
>  [<c0152866>] alloc_buffer_head+0x33/0x52
>  [<c01501ea>] create_buffers+0x51/0x86
>  [<c015141c>] block_read_full_page+0x1bd/0x2cc
>  [<c01a36b8>] fat_get_block+0x0/0x198
>  [<c0132f0c>] add_to_page_cache+0x58/0x6e
>  [<c013a0e4>] read_pages+0xbe/0x15e
>  [<c013a49c>] do_page_cache_readahead+0x120/0x19b
>  [<c013a606>] page_cache_readahead+0xef/0x1f8
>  [<c01336ab>] do_generic_mapping_read+0x133/0x54b
>  [<c013c911>] lru_cache_add+0xd/0x4f
>  [<c0133d53>] __generic_file_aio_read+0x1a3/0x218
>  [<c0133ac3>] file_read_actor+0x0/0xed
>  [<c0133ec5>] generic_file_read+0x9c/0xba
>  [<c012b84c>] _mutex_lock+0x20/0x36
>  [<c01244c8>] do_sigaction+0x1dc/0x1f7
>  [<c012b468>] autoremove_wake_function+0x0/0x43
>  [<c012b84c>] _mutex_lock+0x20/0x36
>  [<c0167974>] dnotify_parent+0x35/0x95
>  [<c014e0a9>] vfs_read+0xcd/0x126
>  [<c014e36f>] sys_read+0x41/0x6a
>  [<c0103f7b>] syscall_call+0x7/0xb

indeed this does not seem to be related to the preemption patch. How
hard is it to reproduce this problem? If it's easy then please try with
vanilla 2.6.9-rc4-mm1 (and if it breaks too, with 2.6.9-rc4 as well), to
narrow down where the breakage got introduced.

	Ingo

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

* [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
                                     ` (8 preceding siblings ...)
  2004-10-16 14:21                   ` Dominik Karall
@ 2004-10-16 15:33                   ` Ingo Molnar
  2004-10-16 17:11                     ` K.R. Foley
                                       ` (4 more replies)
  9 siblings, 5 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16 15:33 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath


i have released the -U4 PREEMPT_REALTIME patch:

   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U4

this is a fixes-only release, and it is still experimental code.

Changes since -U3:

 - crash fix: fix the rtc_lock related crash reported by Bill Huey, the 
   rtc_lock is now a raw spinlock again.

 - crash fix: avoid recursion into timer code when PREEMPT_TIMING is 
   enabled.

 - crash/printout fix: revert some of selinux's locks back to raw 
   spinlocks. This could fix the problems reported by Mark H. Johnson, 
   Adam Heath.

 - build fix: fix the compilation problems reported by Lee Revell

 - debug feature: implemented 'print backtrace on all CPUs' on SMP 
   systems, SysRq+L will trigger it.

 - build cleanup: restructure the debug config options. This should 
   resolve the build problems and incompatible debug-options
   problems reported.

 - cleanup: move definitions around, turn on generic rwlocks instead of
   the x86-specific version.

i think all bugs that were reported with logs are fixed in -U4. Please
re-report any issue that might remain.

to create a -U4 tree from scratch the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U4

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 15:33                   ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4 Ingo Molnar
@ 2004-10-16 17:11                     ` K.R. Foley
  2004-10-16 19:25                       ` Ingo Molnar
  2004-10-16 18:54                     ` Adam Heath
                                       ` (3 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-16 17:11 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath

Ingo Molnar wrote:
> i have released the -U4 PREEMPT_REALTIME patch:
> 
>    http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U4
> 
> this is a fixes-only release, and it is still experimental code.
> 

This fixes a compile problem on UP with CONFIG_LATENCY_TRACE enabled.

--- linux-2.6.9-rc4-mm1/kernel/latency.c.orig   2004-10-16 
12:02:39.539487008 -0500
+++ linux-2.6.9-rc4-mm1/kernel/latency.c        2004-10-16 
12:03:44.536344303 -0500
@@ -602,7 +602,8 @@
  /*
   * On UP, NMI tracing is quite simple:
   */
-void notrace nmi_trace(unsigned long eip, unsigned long parent_eip)
+void notrace nmi_trace(unsigned long eip, unsigned long parent_eip,
+                       unsigned long flags)
  {
         __trace(eip, parent_eip);
  }

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16  7:56                     ` Ingo Molnar
  2004-10-16  8:18                       ` Ingo Molnar
@ 2004-10-16 18:38                       ` Adam Heath
  1 sibling, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-16 18:38 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Sat, 16 Oct 2004, Ingo Molnar wrote:

>
> * Adam Heath <doogie@debian.org> wrote:
>
> > On Fri, 15 Oct 2004, Ingo Molnar wrote:
> >
> > >
> > > i have released the -U3 PREEMPT_REALTIME patch:
> > >
> > >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
> >
> > scheduling while atomic: postmaster/0x04000002/3175
> > caller is cond_resched+0x53/0x70
> >  [<c01069f7>] dump_stack+0x17/0x20
> >  [<c027b457>] schedule+0x517/0x550
> >  [<c027b9c3>] cond_resched+0x53/0x70
> >  [<c012cdc7>] _mutex_lock+0x17/0x40
> >  [<c012ce18>] _mutex_lock_irqsave+0x8/0x10
> >  [<c01b21ae>] avc_has_perm_noaudit+0x2e/0x180
> >  [<c01b2335>] avc_has_perm+0x35/0x68
> >  [<c01b79ca>] ipc_has_perm+0x6a/0x80
> >  [<c01ab716>] semctl_main+0xa6/0x410
> >  [<c01abcad>] sys_semctl+0xad/0xb0
> >  [<c010bafd>] sys_ipc+0xad/0x250
> >  [<c0105bff>] syscall_call+0x7/0xb
>
> thanks - that's the IPC code that is not converted over from RCU yet.
>
> a suggestion for future testing: please enable PREEMPT_TIMING for the
> next kernels you build, it will print such entries at the end of
> stacktraces:

adam@gradall:~/kernel/gradall/linux-2.6.9-rc4-mm1-U3$ grep PREEMPT /boot/config-2.6.9-rc4-mm1-vp-u3
CONFIG_PREEMPT_TIMING=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
CONFIG_DEBUG_PREEMPT=y
adam@gradall:~/kernel/gradall/linux-2.6.9-rc4-mm1-U3$ grep LATENCY /boot/config-2.6.9-rc4-mm1-vp-u3
# CONFIG_LATENCY_TRACE is not set

So, it must not be working.

I'm recompiling now to enable LATENCY_TRACE, however.

>  preempt count: 2
>  entry 1: cpu_idle+0x38/0x90 / (start_kernel+0x1ac/0x1f0)
>  entry 2: _spin_lock+0x22/0x80 / (timer_interrupt+0x1b/0x130)

There were no preempt count lines anywhere.


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 15:33                   ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4 Ingo Molnar
  2004-10-16 17:11                     ` K.R. Foley
@ 2004-10-16 18:54                     ` Adam Heath
  2004-10-16 19:24                       ` Ingo Molnar
  2004-10-16 19:29                     ` Adam Heath
                                       ` (2 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-16 18:54 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Sat, 16 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U4 PREEMPT_REALTIME patch:
>
>    http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U4
>
> this is a fixes-only release, and it is still experimental code.

You forgot to lowercase RT and U in the EXTRAVERSION.

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 18:54                     ` Adam Heath
@ 2004-10-16 19:24                       ` Ingo Molnar
  2004-10-16 19:27                         ` Robert Love
  2004-10-16 19:35                         ` Adam Heath
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16 19:24 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


* Adam Heath <doogie@debian.org> wrote:

> >    http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U4
> >
> > this is a fixes-only release, and it is still experimental code.
> 
> You forgot to lowercase RT and U in the EXTRAVERSION.

i changed my mind because lowercase it looks pretty ugly in uname,
appended to the already lowercase -mm string. Why does Debian need to
have it in lowercase anyway? It doesnt seem to make much sense.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 17:11                     ` K.R. Foley
@ 2004-10-16 19:25                       ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16 19:25 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath


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

> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U4
> >
> >this is a fixes-only release, and it is still experimental code.
> >
> 
> This fixes a compile problem on UP with CONFIG_LATENCY_TRACE enabled.

thanks - i've fixed the U4 patch too so new downloads will have the fix.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 19:24                       ` Ingo Molnar
@ 2004-10-16 19:27                         ` Robert Love
  2004-10-16 19:35                         ` Adam Heath
  1 sibling, 0 replies; 951+ messages in thread
From: Robert Love @ 2004-10-16 19:27 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Adam Heath, linux-kernel

On Sat, 2004-10-16 at 21:24 +0200, Ingo Molnar wrote:

> i changed my mind because lowercase it looks pretty ugly in uname,
> appended to the already lowercase -mm string. Why does Debian need to
> have it in lowercase anyway? It doesnt seem to make much sense.

It becomes part of the package version, and the package versions are
lowercase.  But I agree, it doesn't make much sense.

-RT does look better.

	Robert Love



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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 15:33                   ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4 Ingo Molnar
  2004-10-16 17:11                     ` K.R. Foley
  2004-10-16 18:54                     ` Adam Heath
@ 2004-10-16 19:29                     ` Adam Heath
  2004-10-16 19:36                       ` Ingo Molnar
  2004-10-17 17:03                     ` Florian Schmidt
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
  4 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-16 19:29 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

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

On Sat, 16 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U4 PREEMPT_REALTIME patch:
>
>    http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U4
>
> this is a fixes-only release, and it is still experimental code.

Few stack dumps now.

[cut early messages]
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 364k freed
(swapper/1/CPU#0): new 1 us maximum-latency critical section.
 => started at timestamp 27541945: <call_console_drivers+0x76/0x140>
 =>   ended at timestamp 27541946: <__find_get_block+0x56/0xf0>
 [<c0132650>] sub_preempt_count+0x60/0x90
 [<c01323c7>] check_preempt_timing+0x1b7/0x260
 [<c015e7a6>] __find_get_block+0x56/0xf0
 [<c0132650>] sub_preempt_count+0x60/0x90
 [<c015e7a6>] __find_get_block+0x56/0xf0
 [<c015e7a6>] __find_get_block+0x56/0xf0
 [<c0113304>] mcount+0x14/0x18
 [<c015e86d>] __getblk+0x2d/0x70
 [<c01992a2>] ext3_getblk+0x92/0x280
 [<c019d5ee>] ext3_find_entry+0xe/0x3d0
 [<c019dbff>] ext3_lookup+0x3f/0xc0
 [<c0113304>] mcount+0x14/0x18
 [<c019d6f6>] ext3_find_entry+0x116/0x3d0
 [<c0131b7d>] __mcount+0x1d/0x20
 [<c013131e>] _mutex_unlock+0xe/0x60
 [<c0131b7d>] __mcount+0x1d/0x20
 [<c019dbd4>] ext3_lookup+0x14/0xc0
 [<c0169ec0>] real_lookup+0xf0/0x120
 [<c0113304>] mcount+0x14/0x18
 [<c019dbff>] ext3_lookup+0x3f/0xc0
 [<c0169ec0>] real_lookup+0xf0/0x120
 [<c016a159>] do_lookup+0x89/0xa0
 [<c016a27d>] link_path_walk+0x10d/0xde0
 [<c016b238>] path_lookup+0xa8/0x1c0
 [<c015ab61>] filp_open+0x41/0x70
 [<c016bae9>] open_namei+0x89/0x700
 [<c0131b7d>] __mcount+0x1d/0x20
 [<c015afdb>] sys_open+0x4b/0xb0
 [<c0113304>] mcount+0x14/0x18
 [<c015ab61>] filp_open+0x41/0x70
 [<c013131e>] _mutex_unlock+0xe/0x60
 [<c01dccb4>] find_next_zero_bit+0x14/0xa8
 [<c015ae70>] get_unused_fd+0x90/0xf0
 [<c015afdb>] sys_open+0x4b/0xb0
 [<c01002e0>] init+0x0/0x120
 [<c010037c>] init+0x9c/0x120
 [<c0104099>] kernel_thread_helper+0x5/0xc
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __find_get_block+0x32/0xf0 / (__getblk+0x2d/0x70)
.. entry 2: print_traces+0x17/0x43 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 27543467

(kjournald/19/CPU#0): new 2 us maximum-latency critical section.
 => started at timestamp 27543602: <call_console_drivers+0x76/0x140>
 =>   ended at timestamp 27543604: <preempt_schedule+0x61/0x80>
 [<c0132650>] sub_preempt_count+0x60/0x90
 [<c01323c7>] check_preempt_timing+0x1b7/0x260
 [<c02a3bf1>] preempt_schedule+0x61/0x80
 [<c0132650>] sub_preempt_count+0x60/0x90
 [<c02a3bf1>] preempt_schedule+0x61/0x80
 [<c02a3bf1>] preempt_schedule+0x61/0x80
 [<c01aefa3>] kjournald+0x73/0x240
 [<c0117f31>] finish_task_switch+0x51/0xa0
 [<c0117f31>] finish_task_switch+0x51/0xa0
 [<c0117faf>] schedule_tail+0x2f/0x80
 [<c0105faa>] ret_from_fork+0x6/0x14
 [<c01aef30>] kjournald+0x0/0x240
 [<c01aef00>] commit_timeout+0x0/0x20
 [<c01aef30>] kjournald+0x0/0x240
 [<c0104099>] kernel_thread_helper+0x5/0xc
preempt count: 04000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x43 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 27544227

kjournald starting.  Commit interval 5 seconds
(kjournald/19/CPU#0): new 4 us maximum-latency critical section.
 => started at timestamp 27544266: <vprintk+0x2b/0x190>
 =>   ended at timestamp 27544270: <vprintk+0x102/0x190>
 [<c0132650>] sub_preempt_count+0x60/0x90
 [<c01323c7>] check_preempt_timing+0x1b7/0x260
 [<c011c672>] vprintk+0x102/0x190
 [<c0132650>] sub_preempt_count+0x60/0x90
 [<c011c672>] vprintk+0x102/0x190
 [<c011c672>] vprintk+0x102/0x190
 [<c011c56d>] printk+0x1d/0x20
 [<c01aefc1>] kjournald+0x91/0x240
 [<c0117f31>] finish_task_switch+0x51/0xa0
 [<c0117f31>] finish_task_switch+0x51/0xa0
 [<c0117faf>] schedule_tail+0x2f/0x80
 [<c0105faa>] ret_from_fork+0x6/0x14
 [<c01aef30>] kjournald+0x0/0x240
 [<c01aef00>] commit_timeout+0x0/0x20
 [<c01aef30>] kjournald+0x0/0x240
 [<c0104099>] kernel_thread_helper+0x5/0xc
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: vprintk+0x2b/0x190 / (printk+0x1d/0x20)
.. entry 2: print_traces+0x17/0x43 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 27544470

(kjournald/19/CPU#0): new 493 us maximum-latency critical section.
 => started at timestamp 27544482: <kernel_fpu_begin+0x21/0x60>
 =>   ended at timestamp 27544975: <_mmx_memcpy+0x131/0x180>
 [<c0132650>] sub_preempt_count+0x60/0x90
 [<c01323c7>] check_preempt_timing+0x1b7/0x260
 [<c01dd311>] _mmx_memcpy+0x131/0x180
 [<c0132650>] sub_preempt_count+0x60/0x90
 [<c01dd311>] _mmx_memcpy+0x131/0x180
 [<c01dd311>] _mmx_memcpy+0x131/0x180
 [<c01e3a25>] vgacon_scroll+0x245/0x260
 [<c01f43ba>] scrup+0xda/0xf0
 [<c0113304>] mcount+0x14/0x18
 [<c01f5f02>] lf+0x72/0x80
 [<c01f86cf>] vt_console_print+0x13f/0x320
 [<c011c2b1>] __call_console_drivers+0x61/0x70
 [<c011c3da>] call_console_drivers+0x9a/0x140
 [<c011c7f1>] release_console_sem+0x71/0x110
 [<c011c68f>] vprintk+0x11f/0x190
 [<c011c56d>] printk+0x1d/0x20
 [<c01aefc1>] kjournald+0x91/0x240
 [<c0117f31>] finish_task_switch+0x51/0xa0
 [<c0117f31>] finish_task_switch+0x51/0xa0
 [<c0117faf>] schedule_tail+0x2f/0x80
 [<c0105faa>] ret_from_fork+0x6/0x14
 [<c01aef30>] kjournald+0x0/0x240
 [<c01aef00>] commit_timeout+0x0/0x20
 [<c01aef30>] kjournald+0x0/0x240
 [<c0104099>] kernel_thread_helper+0x5/0xc
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: kernel_fpu_begin+0x21/0x60 / (_mmx_memcpy+0x36/0x180)
.. entry 2: print_traces+0x17/0x43 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 27545263

Adding 516056k swap on /dev/hda1.  Priority:-1 extents:1
EXT3 FS on hda5, internal journal
SiI680: IDE controller at PCI slot 0000:00:0d.0
SiI680: chipset revision 2
SiI680: BASE CLOCK == 133
SiI680: 100% native mode on irq 10
    ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio
    ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: Maxtor 6Y080P0, ATA DISK drive
ide2 at 0xf8840f80-0xf8840f87,0xf8840f8a on irq 10
hde: max request size: 64KiB
hde: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(133)
hde: cache flushes supported
 hde: hde1
Probing IDE interface ide3...
sis900.c: v1.08.07 11/02/2003
eth0: Realtek RTL8201 PHY transceiver found at address 1.
eth0: Using transceiver found at address 1 as default
eth0: SiS 900 PCI Fast Ethernet at 0xc000, IRQ 5, 00:0a:e6:ab:93:c9.
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
0000:00:0f.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xbc00. Vers LK1.1.19
intel8x0_measure_ac97_clock: measured 49102 usecs
intel8x0: clocking to 48000
SCSI subsystem initialized
device-mapper: 4.1.0-ioctl (2003-12-10) initialised: dm@uk.sistina.com
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: raidstart(pid 154) used deprecated START_ARRAY ioctl. This will not be supported beyond 2.6
md: autorun ...
md: considering hdb1 ...
md:  adding hdb1 ...
md:  adding hdc1 ...
md:  adding hdd1 ...
md: created md0
md: bind<hdd1>
md: bind<hdc1>
md: bind<hdb1>
md: running: <hdb1><hdc1><hdd1>
md: kicking non-fresh hdd1 from array!
md: unbind<hdd1>
md: export_rdev(hdd1)
raid5: automatically using best checksumming function: pIII_sse
   pIII_sse  :  1224.000 MB/sec
raid5: using function: pIII_sse (1224.000 MB/sec)
md: raid5 personality registered as nr 4
raid5: device hdb1 operational as raid disk 2
raid5: device hdc1 operational as raid disk 0
raid5: allocated 3160kB for md0
raid5: raid level 5 set md0 active with 2 out of 3 devices, algorithm 2
RAID5 conf printout:
 --- rd:3 wd:2 fd:1
 disk 0, o:1, dev:hdc1
 disk 2, o:1, dev:hdb1
md: ... autorun DONE.
device-mapper: : dm-linear: Device lookup failed

device-mapper: error adding target to table
device-mapper: : dm-linear: Device lookup failed

device-mapper: error adding target to table
device-mapper: : dm-linear: Device lookup failed

device-mapper: error adding target to table
device-mapper: : dm-linear: Device lookup failed

device-mapper: error adding target to table
device-mapper: : dm-linear: Device lookup failed

device-mapper: error adding target to table
device-mapper: : dm-linear: Device lookup failed

device-mapper: error adding target to table
device-mapper: : dm-linear: Device lookup failed

device-mapper: error adding target to table
device-mapper: : dm-linear: Device lookup failed

device-mapper: error adding target to table
device-mapper: : dm-linear: Device lookup failed

device-mapper: error adding target to table
device-mapper: : dm-linear: Device lookup failed

(evms_activate/312/CPU#0): new 526 us maximum-latency critical section.
 => started at timestamp 38955962: <kernel_fpu_begin+0x21/0x60>
 =>   ended at timestamp 38956488: <_mmx_memcpy+0x131/0x180>
 [<c0132650>] sub_preempt_count+0x60/0x90
 [<c01323c7>] check_preempt_timing+0x1b7/0x260
 [<c01dd311>] _mmx_memcpy+0x131/0x180
 [<c0132650>] sub_preempt_count+0x60/0x90
 [<c01dd311>] _mmx_memcpy+0x131/0x180
 [<c01dd311>] _mmx_memcpy+0x131/0x180
 [<c01e3a25>] vgacon_scroll+0x245/0x260
 [<c01f43ba>] scrup+0xda/0xf0
 [<c0113304>] mcount+0x14/0x18
 [<c01f5f02>] lf+0x72/0x80
 [<c01f86cf>] vt_console_print+0x13f/0x320
 [<c011c2b1>] __call_console_drivers+0x61/0x70
 [<c011c3da>] call_console_drivers+0x9a/0x140
 [<c011c7f1>] release_console_sem+0x71/0x110
 [<c011c68f>] vprintk+0x11f/0x190
 [<c011c56d>] printk+0x1d/0x20
 [<f8909683>] dm_table_add_target+0xb3/0x1b0 [dm_mod]
 [<f890c022>] populate_table+0x82/0xe0 [dm_mod]
 [<f890c0dd>] table_load+0x5d/0x120 [dm_mod]
 [<f890c8dc>] ctl_ioctl+0xdc/0x140 [dm_mod]
 [<c0118541>] lock_kernel+0x41/0x60
 [<f890c080>] table_load+0x0/0x120 [dm_mod]
 [<c016f6d5>] sys_ioctl+0xd5/0x240
 [<c01060d3>] syscall_call+0x7/0xb
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: kernel_fpu_begin+0x21/0x60 / (_mmx_memcpy+0x36/0x180)
.. entry 2: print_traces+0x17/0x43 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 38957038

[cut trailing messages]

[-- Attachment #2: Type: TEXT/PLAIN, Size: 32283 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-rc4-mm1-rt-u4
# Sat Oct 16 13:57:48 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=""
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_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_GENERIC_SPINLOCK=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_X86_USE_3DNOW=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
# 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 is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

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

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

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

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set

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

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 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 is not set
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 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=m
CONFIG_BLK_DEV_SIS5513=y
# 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_SCSI=m
CONFIG_SCSI_PROC_FS=y

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

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

#
# SCSI low-level drivers
#
CONFIG_BLK_DEV_3W_XXXX_RAID=m
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST 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=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_SCSI_SATA=y
# CONFIG_SCSI_SATA_SVW is not set
# CONFIG_SCSI_ATA_PIIX is not set
# CONFIG_SCSI_SATA_NV is not set
# CONFIG_SCSI_SATA_PROMISE is not set
# CONFIG_SCSI_SATA_SX4 is not set
CONFIG_SCSI_SATA_SIL=m
# CONFIG_SCSI_SATA_SIS is not set
# CONFIG_SCSI_SATA_ULI is not set
# CONFIG_SCSI_SATA_VIA is not set
# CONFIG_SCSI_SATA_VITESSE is not set
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
CONFIG_SCSI_GDTH=m
# 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_NCR53C406A is not set
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

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

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

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
# CONFIG_IP_PIMSM_V1 is not set
# CONFIG_IP_PIMSM_V2 is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m

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

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

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

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_CT_ACCT=y
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_PHYSDEV=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
CONFIG_IP_NF_MATCH_COMMENT=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_IP_NF_NAT_LOCAL=y
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set

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

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
CONFIG_BRIDGE=m
# 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_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
CONFIG_VORTEX=m
# CONFIG_TYPHOON 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 is not set
CONFIG_SIS900=m
# 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

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

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD64=m
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_INTEL_MCH is not set
CONFIG_AGP_NVIDIA=m
# 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=m
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

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

#
# Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set

#
# Other I2C Chip support
#
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set

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

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

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

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

#
# ISA devices
#
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_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_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
CONFIG_SND_CMIPCI=m
# 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=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_DEVPTS_FS_SECURITY=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS 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=m
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_NCP_FS is not set
CONFIG_CODA_FS=m
# CONFIG_CODA_FS_OLD_API is not set
# CONFIG_AFS_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=m
# 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=m
CONFIG_NLS_ISO8859_1=m
# 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=m

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_PREEMPT_TIMING=y
CONFIG_PREEMPT_TRACE=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_EARLY_PRINTK=y
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

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

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

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 19:24                       ` Ingo Molnar
  2004-10-16 19:27                         ` Robert Love
@ 2004-10-16 19:35                         ` Adam Heath
  1 sibling, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-16 19:35 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Sat, 16 Oct 2004, Ingo Molnar wrote:

>
> * Adam Heath <doogie@debian.org> wrote:
>
> > >    http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U4
> > >
> > > this is a fixes-only release, and it is still experimental code.
> >
> > You forgot to lowercase RT and U in the EXTRAVERSION.
>
> i changed my mind because lowercase it looks pretty ugly in uname,
> appended to the already lowercase -mm string. Why does Debian need to
> have it in lowercase anyway? It doesnt seem to make much sense.

It's only a minor annoyance right now.  I have to edit Makefile before
starting make-kpkg, and before backing out the previous patch.  I'll file a
bug on kernel-package at some point, but it probably won't be fixed anytime
soon(debian is preparing to release soon(HAHA!)).

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 19:29                     ` Adam Heath
@ 2004-10-16 19:36                       ` Ingo Molnar
  2004-10-16 19:59                         ` Adam Heath
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16 19:36 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


* Adam Heath <doogie@debian.org> wrote:

> > i have released the -U4 PREEMPT_REALTIME patch:
> >
> >    http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U4
> >
> > this is a fixes-only release, and it is still experimental code.
> 
> Few stack dumps now.

these are normal, they are the PREEMPT_TIMING traces which get printed
every time the kernel measures a new latency maximum. The stack dumps
are done to make it easier to identify which place too that long of a
delay and why. (if LATENCY_TRACE is enabled too then the last latency
and its trace can also be found in /proc/latency_trace.)

after bootup it makes sense to reset the maximum:

	echo 10 > /proc/sys/kernel/preempt_max_latency

because during bootup there are a number of latencies that are one-time
only.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 19:36                       ` Ingo Molnar
@ 2004-10-16 19:59                         ` Adam Heath
  2004-10-16 20:14                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-16 19:59 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Sat, 16 Oct 2004, Ingo Molnar wrote:

>
> * Adam Heath <doogie@debian.org> wrote:
>
> > > i have released the -U4 PREEMPT_REALTIME patch:
> > >
> > >    http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U4
> > >
> > > this is a fixes-only release, and it is still experimental code.
> >
> > Few stack dumps now.
>
> these are normal, they are the PREEMPT_TIMING traces which get printed
> every time the kernel measures a new latency maximum. The stack dumps
> are done to make it easier to identify which place too that long of a
> delay and why. (if LATENCY_TRACE is enabled too then the last latency
> and its trace can also be found in /proc/latency_trace.)
>
> after bootup it makes sense to reset the maximum:
>
> 	echo 10 > /proc/sys/kernel/preempt_max_latency
>
> because during bootup there are a number of latencies that are one-time
> only.

So, I did that, and immediately started getting more stack dumps.  Are these
things that are interesting, or only informational?

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 19:59                         ` Adam Heath
@ 2004-10-16 20:14                           ` Ingo Molnar
  2004-10-16 20:39                             ` john cooper
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16 20:14 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


* Adam Heath <doogie@debian.org> wrote:

> > after bootup it makes sense to reset the maximum:
> >
> > 	echo 10 > /proc/sys/kernel/preempt_max_latency
> >
> > because during bootup there are a number of latencies that are one-time
> > only.
> 
> So, I did that, and immediately started getting more stack dumps.  Are
> these things that are interesting, or only informational?

they are informational, if you are evaluating latencies. Feel free to
post larger latencies. Right now the threshold for "large" depends - on
a fast box i'd say latencies above 200 usecs are worth reporting - but
any trace can be interesting. Latencies above 1000 usecs are definitely
worth seeing.

stability has the highest priority at the moment, and the other type of
non-latency stackdumps (scheduling while atomic, smp_processor_id()
warnings or outright kernel oopses) should always be reported if
possible.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 15:24                     ` Ingo Molnar
@ 2004-10-16 20:30                       ` Dominik Karall
  2004-10-16 20:31                         ` Lee Revell
  0 siblings, 1 reply; 951+ messages in thread
From: Dominik Karall @ 2004-10-16 20:30 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

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

On Saturday 16 October 2004 17:24, Ingo Molnar wrote:
> * Dominik Karall <dominik.karall@gmx.net> wrote:
> > i'm not sure if this bug depends on preemption patch, or if it is a
> > general one in -mm1 tree.
> >
> > kernel BUG at fs/fat/cache.c:150!
> >
> > EIP is at fat_cache_add+0x135/0x151
> >
> > Process mplayer (pid: 9843, threadinfo=ce414000 task=c8128a20)
> >
> > Call Trace:
> >  [<c01a11bb>] fat_get_cluster+0x11f/0x1de
> >  [<c01a12c1>] fat_bmap_cluster+0x47/0x98
> >  [<c01a13f1>] fat_bmap+0xdf/0x101
> >  [<c01a36e8>] fat_get_block+0x30/0x198
> >  [<c0152866>] alloc_buffer_head+0x33/0x52
> >  [<c01501ea>] create_buffers+0x51/0x86
> >  [<c015141c>] block_read_full_page+0x1bd/0x2cc
> >  [<c01a36b8>] fat_get_block+0x0/0x198
> >  [<c0132f0c>] add_to_page_cache+0x58/0x6e
> >  [<c013a0e4>] read_pages+0xbe/0x15e
> >  [<c013a49c>] do_page_cache_readahead+0x120/0x19b
> >  [<c013a606>] page_cache_readahead+0xef/0x1f8
> >  [<c01336ab>] do_generic_mapping_read+0x133/0x54b
> >  [<c013c911>] lru_cache_add+0xd/0x4f
> >  [<c0133d53>] __generic_file_aio_read+0x1a3/0x218
> >  [<c0133ac3>] file_read_actor+0x0/0xed
> >  [<c0133ec5>] generic_file_read+0x9c/0xba
> >  [<c012b84c>] _mutex_lock+0x20/0x36
> >  [<c01244c8>] do_sigaction+0x1dc/0x1f7
> >  [<c012b468>] autoremove_wake_function+0x0/0x43
> >  [<c012b84c>] _mutex_lock+0x20/0x36
> >  [<c0167974>] dnotify_parent+0x35/0x95
> >  [<c014e0a9>] vfs_read+0xcd/0x126
> >  [<c014e36f>] sys_read+0x41/0x6a
> >  [<c0103f7b>] syscall_call+0x7/0xb
>
> indeed this does not seem to be related to the preemption patch. How
> hard is it to reproduce this problem? If it's easy then please try with
> vanilla 2.6.9-rc4-mm1 (and if it breaks too, with 2.6.9-rc4 as well), to
> narrow down where the breakage got introduced.
>
>  Ingo

sorry, i tried to reproduce this bug, but can't. i even don't know _when_ this 
bug occurred, as i just wanted to take a look in the dmesg output after 
loading sg module. but it does not depend on sg, as i unloaded it and tried 
again to load.

best regards,
dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 20:30                       ` Dominik Karall
@ 2004-10-16 20:31                         ` Lee Revell
  2004-10-16 21:44                           ` Dominik Karall
  0 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-16 20:31 UTC (permalink / raw)
  To: Dominik Karall
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

On Sat, 2004-10-16 at 16:30, Dominik Karall wrote:
> sorry, i tried to reproduce this bug, but can't. i even don't know _when_ this 
> bug occurred, as i just wanted to take a look in the dmesg output after 
> loading sg module. but it does not depend on sg, as i unloaded it and tried 
> again to load.
> 

The trace looks like mplayer reading from a FAT filesystem.  Can you
reproduce the problem if you do whatever you were doing with mplayer 
again?

Lee


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 20:14                           ` Ingo Molnar
@ 2004-10-16 20:39                             ` john cooper
  2004-10-16 21:02                               ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: john cooper @ 2004-10-16 20:39 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, john cooper

Ingo,
    In reading your -U3 patch the test below (#156)
wasn't clear to me.   It would seem in the case of
softirq_preemption, __do_softirq() should be called
to kick ksoftirqd, otherwise ___do_softirq() would
be called to exec softirqs in the immediate context.

kernel/softirq.c:

  153   asmlinkage void _do_softirq(void)
  154   {
  155           local_irq_disable();
  156           if (!softirq_preemption)
  157                   __do_softirq();
  158           else
  159                   ___do_softirq();
  160           local_irq_enable();
  161   }

-john

-- 
john.cooper@timesys.com


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 20:39                             ` john cooper
@ 2004-10-16 21:02                               ` Ingo Molnar
  2004-10-16 21:15                                 ` Esben Nielsen
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-16 21:02 UTC (permalink / raw)
  To: john cooper; +Cc: linux-kernel


* john cooper <john.cooper@timesys.com> wrote:

> Ingo,
>    In reading your -U3 patch the test below (#156)
> wasn't clear to me.   It would seem in the case of
> softirq_preemption, __do_softirq() should be called
> to kick ksoftirqd, otherwise ___do_softirq() would
> be called to exec softirqs in the immediate context.

the dependencies here are a bit complex due to the
various compile-time and runtime flags, and various
architecture call-ins to softirq.c.

> kernel/softirq.c:
> 
>  153   asmlinkage void _do_softirq(void)
>  154   {
>  155           local_irq_disable();
>  156           if (!softirq_preemption)
>  157                   __do_softirq();
>  158           else
>  159                   ___do_softirq();
>  160           local_irq_enable();
>  161   }

___do_softirq() is the 'lowest level' softirq function, it
directly executes the handlers.

__do_softirq() disables bhs and calls ___do_softirq() - this
is the 'direct' softirq execution model, this function is
called by hardirq contexts and by softirqd. [btw., irqd calls
this function too which is a bit pointless.] In the indirect
execution model (SOFTIRQ_PREEMPT) this function does no softirq
execution, it only wakes up softirqd.

_do_softirq() is what is called by softirqd - dependent on the
execution model this function will either execute ___do_softirq()
[no additional locking or bh disabling] in the threaded case,
while in the direct case it will execute __do_softirq().

so the logic seems to be correct to me. (except for the minor
detail of irqd calling __do_softirq() which doesnt make much 
sense but which is harmless otherwise.)

with DEBUG_PREEMPT it is relatively safe to call ___do_softirq()
from softirqd (without doing the extra bh disabling), because
the two main rules of softirqs are still preserved:

 1) softirq execution doesnt reenter itself

 2) per-CPU assumptions safely detected

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 21:02                               ` Ingo Molnar
@ 2004-10-16 21:15                                 ` Esben Nielsen
  2004-10-16 23:41                                   ` Sam Ravnborg
  0 siblings, 1 reply; 951+ messages in thread
From: Esben Nielsen @ 2004-10-16 21:15 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Hi,
 I have compile error when I use the make O= option: usr/initramfs_list
doesn't exist. This doesn't occur in pure 2.6.8.1 or 2.6.9-rc4 but does  
occur in 2.6.9-rc4-mm1.

Esben

Here is a fix (the build seems not to be broken with or without O=)

--- linux-2.6.9-rc4-mm1-RT-U4/usr/Makefile.orig 2004-10-16
19:39:46.000000000 +0200
+++ linux-2.6.9-rc4-mm1-RT-U4/usr/Makefile      2004-10-16
23:04:13.661382082 +0200
@@ -35,7 +35,10 @@
          echo 'scripts/gen_initramfs_list.sh $(CONFIG_INITRAMFS_SOURCE) > $@'; \
        else \
          echo 'echo Using shipped $@'; \
-       fi)
+          if [ $(KBUILD_SRC)!="" ]; then \
+            cp -f $(KBUILD_SRC)/usr/initramfs_list ./usr/initramfs_list; \
+          fi; \
+        fi)
 
 
 $(INITRAMFS_LIST): FORCE


On Sat, 16 Oct 2004, Ingo Molnar wrote:

> 
> * john cooper <john.cooper@timesys.com> wrote:
> 
> > Ingo,
> >    In reading your -U3 patch the test below (#156)
> > wasn't clear to me.   It would seem in the case of
> > softirq_preemption, __do_softirq() should be called
> > to kick ksoftirqd, otherwise ___do_softirq() would
> > be called to exec softirqs in the immediate context.
> 
> the dependencies here are a bit complex due to the
> various compile-time and runtime flags, and various
> architecture call-ins to softirq.c.
> 
> > kernel/softirq.c:
> > 
> >  153   asmlinkage void _do_softirq(void)
> >  154   {
> >  155           local_irq_disable();
> >  156           if (!softirq_preemption)
> >  157                   __do_softirq();
> >  158           else
> >  159                   ___do_softirq();
> >  160           local_irq_enable();
> >  161   }
> 
> ___do_softirq() is the 'lowest level' softirq function, it
> directly executes the handlers.
> 
> __do_softirq() disables bhs and calls ___do_softirq() - this
> is the 'direct' softirq execution model, this function is
> called by hardirq contexts and by softirqd. [btw., irqd calls
> this function too which is a bit pointless.] In the indirect
> execution model (SOFTIRQ_PREEMPT) this function does no softirq
> execution, it only wakes up softirqd.
> 
> _do_softirq() is what is called by softirqd - dependent on the
> execution model this function will either execute ___do_softirq()
> [no additional locking or bh disabling] in the threaded case,
> while in the direct case it will execute __do_softirq().
> 
> so the logic seems to be correct to me. (except for the minor
> detail of irqd calling __do_softirq() which doesnt make much 
> sense but which is harmless otherwise.)
> 
> with DEBUG_PREEMPT it is relatively safe to call ___do_softirq()
> from softirqd (without doing the extra bh disabling), because
> the two main rules of softirqs are still preserved:
> 
>  1) softirq execution doesnt reenter itself
> 
>  2) per-CPU assumptions safely detected
> 
> 	Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 20:31                         ` Lee Revell
@ 2004-10-16 21:44                           ` Dominik Karall
  2004-10-17  5:21                             ` Ingo Molnar
  2004-10-17 15:32                             ` OGAWA Hirofumi
  0 siblings, 2 replies; 951+ messages in thread
From: Dominik Karall @ 2004-10-16 21:44 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

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

On Saturday 16 October 2004 22:31, Lee Revell wrote:
> On Sat, 2004-10-16 at 16:30, Dominik Karall wrote:
> > sorry, i tried to reproduce this bug, but can't. i even don't know _when_
> > this bug occurred, as i just wanted to take a look in the dmesg output
> > after loading sg module. but it does not depend on sg, as i unloaded it
> > and tried again to load.
>
> The trace looks like mplayer reading from a FAT filesystem.  Can you
> reproduce the problem if you do whatever you were doing with mplayer
> again?
>
> Lee

i could reproduce it now, but only once. it appeared when i started an avi 
movie from my fat32 partition. mplayer stopped at buffering 2% and does not 
play the movie. i tried to start mplayer again and reproduce it, but the bug 
does not appear again. mplayer only stopped at 2% buffering and does nothing 
more. it seems like the file couldn't be read clearly now from the fat32 
partition, as it does not work with xine and others too.
here is the bug i get now:

------------[ cut here ]------------
kernel BUG at fs/fat/cache.c:150!
invalid operand: 0000 [#2]
PREEMPT
Modules linked in: sg sr_mod ipx p8022 psnap llc nvidia snd_mixer_oss sd_mod 
tda9887 tuner saa7134 video_buf v4l2_common v4l1_compat ir_common videodev 
8139too sis900 crc32 ehci_hcd usb_storage scsi_mod ohci_hcd usbcore 
snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc 
ohci1394 ieee1394 i2c_sis96x i2c_core
CPU:    0
EIP:    0060:[<c01a0b53>]    Tainted: P      VLI
EFLAGS: 00210202   (2.6.9-rc4-mm1-vp-u3)
EIP is at fat_cache_add+0x135/0x151
eax: 00000001   ebx: cf57136c   ecx: cf57127c   edx: cf571301
esi: c1e53c50   edi: cd0d63c8   ebp: cd0d6418   esp: c1e53c1c
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process mplayer (pid: 29320, threadinfo=c1e53000 task=c6abca20)
Stack: cd0d6418 c1e53c88 cf785800 00000001 cd0d63c8 c01a11bb c1e53c88 c1e53c8c
       00000000 00000000 00000000 0003ffff cd0d6418 00000000 00000000 00000001
       00093710 cd0d6418 cd0d63c8 cf785800 cee1d800 c01a12c1 c1e53c8c 00000000
Call Trace:
 [<c01a11bb>] fat_get_cluster+0x11f/0x1de
 [<c01a12c1>] fat_bmap_cluster+0x47/0x98
 [<c01a13f1>] fat_bmap+0xdf/0x101
 [<c01a36e8>] fat_get_block+0x30/0x198
 [<c0152866>] alloc_buffer_head+0x33/0x52
 [<c01501ea>] create_buffers+0x51/0x86
 [<c015141c>] block_read_full_page+0x1bd/0x2cc
 [<c01a36b8>] fat_get_block+0x0/0x198
 [<c0132f0c>] add_to_page_cache+0x58/0x6e
 [<c013a0e4>] read_pages+0xbe/0x15e
 [<c013a49c>] do_page_cache_readahead+0x120/0x19b
 [<c013a606>] page_cache_readahead+0xef/0x1f8
 [<c01336ab>] do_generic_mapping_read+0x133/0x54b
 [<c013c911>] lru_cache_add+0xd/0x4f
 [<c0133d53>] __generic_file_aio_read+0x1a3/0x218
 [<c0133ac3>] file_read_actor+0x0/0xed
 [<c0133ec5>] generic_file_read+0x9c/0xba
 [<c012b84c>] _mutex_lock+0x20/0x36
 [<c01244c8>] do_sigaction+0x1dc/0x1f7
 [<c012b468>] autoremove_wake_function+0x0/0x43
 [<c012b84c>] _mutex_lock+0x20/0x36
 [<c0167974>] dnotify_parent+0x35/0x95
 [<c014e0a9>] vfs_read+0xcd/0x126
 [<c014e36f>] sys_read+0x41/0x6a
 [<c0103f7b>] syscall_call+0x7/0xb
Code: f2 89 e8 e8 9f fe ff ff 85 c0 89 c3 74 2a 83 6f 20 01 8b 04 24 39 00 75 
24 8b 14 24 a1 74 0b 3c c0 e8 9c b1 f9 ff e9 40 ff ff ff <0f> 0b 96 00 e5 b7 
2d c0 e9 2f ff ff ff 8b 1c 24 eb 88 0f 0b 48


best regards,
dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 21:15                                 ` Esben Nielsen
@ 2004-10-16 23:41                                   ` Sam Ravnborg
  0 siblings, 0 replies; 951+ messages in thread
From: Sam Ravnborg @ 2004-10-16 23:41 UTC (permalink / raw)
  To: Esben Nielsen; +Cc: Ingo Molnar, linux-kernel

On Sat, Oct 16, 2004 at 11:15:33PM +0200, Esben Nielsen wrote:
> Hi,
>  I have compile error when I use the make O= option: usr/initramfs_list
> doesn't exist. This doesn't occur in pure 2.6.8.1 or 2.6.9-rc4 but does  
> occur in 2.6.9-rc4-mm1.
> 
> Esben
> 
> Here is a fix (the build seems not to be broken with or without O=)
> 
> --- linux-2.6.9-rc4-mm1-RT-U4/usr/Makefile.orig 2004-10-16
> 19:39:46.000000000 +0200
> +++ linux-2.6.9-rc4-mm1-RT-U4/usr/Makefile      2004-10-16
> 23:04:13.661382082 +0200
> @@ -35,7 +35,10 @@
>           echo 'scripts/gen_initramfs_list.sh $(CONFIG_INITRAMFS_SOURCE) > $@'; \
>         else \
>           echo 'echo Using shipped $@'; \
> -       fi)
> +          if [ $(KBUILD_SRC)!="" ]; then \
> +            cp -f $(KBUILD_SRC)/usr/initramfs_list ./usr/initramfs_list; \
> +          fi; \
> +        fi)

The above error is from -mm and not part of Ingo's patch.
The better fix is to prefix $(CONFIG_INITRAMFS_SOURCE) with $(srctree)/

	Sam

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 21:44                           ` Dominik Karall
@ 2004-10-17  5:21                             ` Ingo Molnar
  2004-10-17 15:32                             ` OGAWA Hirofumi
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-17  5:21 UTC (permalink / raw)
  To: Dominik Karall
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Dominik Karall <dominik.karall@gmx.net> wrote:

> > The trace looks like mplayer reading from a FAT filesystem.  Can you
> > reproduce the problem if you do whatever you were doing with mplayer
> > again?
> 
> i could reproduce it now, but only once. it appeared when i started an
> avi movie from my fat32 partition. mplayer stopped at buffering 2% and
> does not play the movie. i tried to start mplayer again and reproduce
> it, but the bug does not appear again. mplayer only stopped at 2%
> buffering and does nothing more. it seems like the file couldn't be
> read clearly now from the fat32 partition, as it does not work with
> xine and others too. here is the bug i get now:

did you retry after rebooting the box? Such bugs can easily depend on IO
patterns (and code sequences) that only happen the first time the file
is accessed in such way (inode init, delays due to IO, etc.). So what
would be nice to try (if you havent tried it already) is to:

 - reboot the box into this same kernel and retry - do you get the oops?

 - if you can reproduce the oops this way in a more or less reliable way
   then please try the same with 2.6.9-rc4-mm1 too.

it _looks_ like a bug not related to the RT patch but a connection
cannot be ruled out: the mutex based kernel changes locking for fatfs
too, and could trigger hidden or hard-to-trigger bugs in an easier way.

In the locking sense the RT kernel can be considered equivalent to an
SMP box with an infinite number of CPUs, even on a uniprocessor. It
tests SMP locking in way nothing else does.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 10:36                           ` Ingo Molnar
  2004-10-16 11:03                             ` Rui Nuno Capela
  2004-10-16 12:32                             ` K.R. Foley
@ 2004-10-17 13:14                             ` Rui Nuno Capela
  2004-10-17 13:21                               ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-17 13:14 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

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

Hi,

Ingo Molnar wrote:
>
> it seems that SMP + PREEMPT_TIMING is not stable though, somehow the
> latency printk's cause a crash sooner or later. I'm still debugging this
> problem. Without PREEMPT_TIMING the SMP kernel is stable.
>

Here I go again, while my SMP/HT box still dying on the beach of U4 :)

Finally this time, I've got the serial console logging setup up and
running, and now I'm ready to capture and dump all that I can, regarding
this SMP+PREEMPT_REALTIME issue I'm experiencing.

The main symptom, if you can remember, is that the boot/init sequence
stalls soon or later, in non deterministic point. And its an actual issue
of PREEMPT_REALTIME being set. Without that single config option set, the
kernel boots and runs just fine (which is actually the one running, while
I'm writing this very post).

Attached you may find some of those boot/init sessions, which are just
being taken from capturing the serial console output (ttyS0,115200) via
minicom in the other end of a null modem cable.

The point where the boot/init sequence stalls is marked with a
"<<<---STALL--->>>" line mark. Then it follows the output of SysRq-S
(Sync), SysRq-T (Trace), another SysRq-S (Sync), and finally a SysRq-B
(reBoot).

To me, it looks there's plenty dirt to dig :) Hope it helps.

Take care.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: minicom.cap-2.6.9-rc4-mm1-RT-U4.0smp.tar.gz --]
[-- Type: application/x-tgz, Size: 55074 bytes --]

[-- Attachment #3: config-2.6.9-rc4-mm1-RT-U4.0smp.gz --]
[-- Type: application/x-gzip, Size: 7762 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-17 13:14                             ` Rui Nuno Capela
@ 2004-10-17 13:21                               ` Ingo Molnar
       [not found]                                 ` <32793.192.168.1.5.1098023139.squirrel@192.168.1.5>
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-17 13:21 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> The point where the boot/init sequence stalls is marked with a
> "<<<---STALL--->>>" line mark. Then it follows the output of SysRq-S
> (Sync), SysRq-T (Trace), another SysRq-S (Sync), and finally a SysRq-B
> (reBoot).

thanks. Could you send me the full successful bootlog of -U4 with
PREEMPT_REALTIME disabled (but otherwise the same .config)?

this looks suspicious:

eth0: -- ERROR --
        Class:  internal Software error
        Nr:  0x1ae
        Msg:  General: Driver release date not initialized
eth0: -- ERROR --
        Class:  internal Software error
        Nr:  0x1ae
        Msg:  General: Driver release date not initialized
eth0: 3Com Gigabit LOM (3C940)
eth0: network connection down
      PrefPort:A  RlmtMode:Check Link State

is this normal? Could the stall simply be a bootup stall due to no
network available?

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-16 21:44                           ` Dominik Karall
  2004-10-17  5:21                             ` Ingo Molnar
@ 2004-10-17 15:32                             ` OGAWA Hirofumi
  2004-10-17 17:46                               ` Dominik Karall
  1 sibling, 1 reply; 951+ messages in thread
From: OGAWA Hirofumi @ 2004-10-17 15:32 UTC (permalink / raw)
  To: Dominik Karall
  Cc: Lee Revell, Ingo Molnar, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Daniel Walker, Bill Huey,
	Andrew Morton, Adam Heath, Lorenzo Allegrucci, Andrew Rodland

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

Dominik Karall <dominik.karall@gmx.net> writes:

> i could reproduce it now, but only once. it appeared when i started an avi 
> movie from my fat32 partition. mplayer stopped at buffering 2% and does not 
> play the movie. i tried to start mplayer again and reproduce it, but the bug 
> does not appear again. mplayer only stopped at 2% buffering and does nothing 
> more. it seems like the file couldn't be read clearly now from the fat32 
> partition, as it does not work with xine and others too.
> here is the bug i get now:
>
> ------------[ cut here ]------------
> kernel BUG at fs/fat/cache.c:150!

Probably this BUG_ON() was wrong. Does this bug occur only by the
specific file?

If so, please do "filefrag -v filename" against that file.

Then, can you try the attached patch? This patch removes the BUG_ON(),
and instead adds printk() for debugging. When the bug occured, it prints
the current cache.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: fat-debug.patch --]
[-- Type: text/x-patch, Size: 1694 bytes --]



Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

 fs/fat/cache.c |   26 +++++++++++++++++++++++++-
 1 files changed, 25 insertions(+), 1 deletion(-)

diff -puN fs/fat/cache.c~fat-debug fs/fat/cache.c
--- linux-2.6.9-final-a/fs/fat/cache.c~fat-debug	2004-10-17 23:45:27.000000000 +0900
+++ linux-2.6.9-final-a-hirofumi/fs/fat/cache.c	2004-10-18 00:26:44.000000000 +0900
@@ -134,6 +134,30 @@ static struct fat_cache *fat_cache_merge
 	return NULL;
 }
 
+static void fat_cache_check(struct inode *inode, struct fat_cache_id *new)
+{
+	struct fat_cache *p;
+
+	if (new->id == FAT_CACHE_VALID) {
+		list_for_each_entry(p, &MSDOS_I(inode)->cache_lru, cache_list) {
+			/* Find the same part as "new" in cluster-chain. */
+			if (p->fcluster == new->fcluster) {
+				BUG_ON(p->dcluster != new->dcluster);
+				goto dump_cache;
+			}
+		}
+	}
+	return;
+
+dump_cache:
+	printk("%s: id %u, contig %d, fclus %d, dclus %d\n", __FUNCTION__,
+	       new->id, new->nr_contig, new->fcluster, new->dcluster);
+	list_for_each_entry(p, &MSDOS_I(inode)->cache_lru, cache_list) {
+		printk("contig %d, fclus %d, dclus %d\n",
+		       p->nr_contig, p->fcluster, p->dcluster);
+	}
+}
+
 static void fat_cache_add(struct inode *inode, struct fat_cache_id *new)
 {
 	struct fat_cache *cache, *tmp;
@@ -146,8 +170,8 @@ static void fat_cache_add(struct inode *
 	    new->id != MSDOS_I(inode)->cache_valid_id)
 		goto out;	/* this cache was invalidated */
 
+	fat_cache_check(inode, new);
 	cache = fat_cache_merge(inode, new);
-	BUG_ON(new->id == FAT_CACHE_VALID && cache != NULL);
 	if (cache == NULL) {
 		if (MSDOS_I(inode)->nr_caches < fat_max_cache(inode)) {
 			MSDOS_I(inode)->nr_caches++;
_

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
       [not found]                                 ` <32793.192.168.1.5.1098023139.squirrel@192.168.1.5>
@ 2004-10-17 16:12                                   ` Ingo Molnar
  2004-10-17 17:20                                     ` Rui Nuno Capela
  2004-10-17 16:47                                   ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-17 16:12 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> > eth0: 3Com Gigabit LOM (3C940)
> > eth0: network connection down
> >       PrefPort:A  RlmtMode:Check Link State
> >
> > is this normal? Could the stall simply be a bootup stall due to no
> > network available?
> >
> 
> Yes, I think it's normal. The fact is that on the non-RT kernel, the eth0
> device comes up immediately after, as you can see on minicom.cap.{6,7,8}
> capture files.

ok, then please try to do a sysrq-T. The bootup is soft-hung for some 
reason, lets see what tasks are around.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
       [not found]                                 ` <32793.192.168.1.5.1098023139.squirrel@192.168.1.5>
  2004-10-17 16:12                                   ` Ingo Molnar
@ 2004-10-17 16:47                                   ` Ingo Molnar
  2004-10-17 19:05                                     ` Rui Nuno Capela
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-17 16:47 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> OK. Here goes some more food-for-thought :)
> 
> - minitor.cap-2.6.9-rc4-mm1-RT-U4.1smp.tar.gz has another three
> capture sessions, minicom.cap.{3,4,5}, which stalls on boot/init
> (CONFIG_PREEMPT_REALTIME=y). Take a special look on minicom.cap.5,
> where the session has been force-truncated, due to an never ending
> trace dump, and where no SysRq could do the rescue. This is one of
> another symptoms, but with less occurrences I've noticed.

i think you are getting stack overflows. Could you disable
CONFIG_4KSTACKS and see whether that helps?

	Ingo



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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-17 17:03                     ` Florian Schmidt
@ 2004-10-17 16:55                       ` Ingo Molnar
  2004-10-17 17:53                         ` Florian Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-17 16:55 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> the cpu mhz issue seems to be fixed:
> 
> ~$ uname -a
> Linux mango.fruits.de 2.6.9-rc4-mm1-RT-U4-RT #1 Sun Oct 17 17:48:48 CEST 2004 i686 GNU/Linux
> ~$ cat /proc/cpuinfo |grep MHz
> cpu MHz         : 1195.145
> mango:/usr/src/linux-2.6.9-rc4-mm1-VP-U4# grep REALTIME .config
> CONFIG_PREEMPT_REALTIME=y
> 
> Might of course be coincidence. Will report as soon as i see the 0.001 Mhz
> pop up again.

ok.

> I saw one of these in /var/log/syslog:
> 
> Oct 17 18:53:52 mango kernel: PCI: Found IRQ 3 for device 0000:00:0f.0
> Oct 17 18:53:52 mango kernel: Debug: sleeping function called from invalid context modprobe(109) at kernel/mutex.c:25
> Oct 17 18:53:52 mango kernel: in_atomic():0 [00000000], irqs_disabled():1
> Oct 17 18:53:52 mango kernel:  [print_context_stack+78/112] dump_stack+0x1e/0x20
> Oct 17 18:53:52 mango kernel:  [sinbin_release_fn+536/864] __might_sleep+0xb8/0xd0
> Oct 17 18:53:52 mango kernel:  [__create_workqueue+35/320] _mutex_lock+0x23/0x60
> Oct 17 18:53:52 mango kernel:  [__create_workqueue+145/320] _mutex_lock_irqsave+0x11/0x20
> Oct 17 18:53:52 mango kernel:  [pg0+809943061/1069765632] get_time_pit+0x15/0x50 [gameport]

ok, does the patch below fix those messages? (gameport.c used its own,
private, incompatible prototype for i8253_lock which breaks raw spinlock
handling.)

	Ingo

--- linux/drivers/input/gameport/gameport.c.orig
+++ linux/drivers/input/gameport/gameport.c
@@ -37,12 +37,13 @@ static LIST_HEAD(gameport_dev_list);
 
 #ifdef __i386__
 
+#include <asm/i8253.h>
+
 #define DELTA(x,y)      ((y)-(x)+((y)<(x)?1193182/HZ:0))
 #define GET_TIME(x)     do { x = get_time_pit(); } while (0)
 
 static unsigned int get_time_pit(void)
 {
-	extern spinlock_t i8253_lock;
 	unsigned long flags;
 	unsigned int count;
 

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-16 15:33                   ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4 Ingo Molnar
                                       ` (2 preceding siblings ...)
  2004-10-16 19:29                     ` Adam Heath
@ 2004-10-17 17:03                     ` Florian Schmidt
  2004-10-17 16:55                       ` Ingo Molnar
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
  4 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-17 17:03 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath

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

On Sat, 16 Oct 2004 17:33:44 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> i have released the -U4 PREEMPT_REALTIME patch:
> 
>    http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U4
> 
> this is a fixes-only release, and it is still experimental code.

Hi,

the cpu mhz issue seems to be fixed:

~$ uname -a
Linux mango.fruits.de 2.6.9-rc4-mm1-RT-U4-RT #1 Sun Oct 17 17:48:48 CEST 2004 i686 GNU/Linux
~$ cat /proc/cpuinfo |grep MHz
cpu MHz         : 1195.145
mango:/usr/src/linux-2.6.9-rc4-mm1-VP-U4# grep REALTIME .config
CONFIG_PREEMPT_REALTIME=y


Might of course be coincidence. Will report as soon as i see the 0.001 Mhz
pop up again.

I saw one of these in /var/log/syslog:

Oct 17 18:53:52 mango kernel: PCI: Found IRQ 3 for device 0000:00:0f.0
Oct 17 18:53:52 mango kernel: Debug: sleeping function called from invalid context modprobe(109) at kernel/mutex.c:25
Oct 17 18:53:52 mango kernel: in_atomic():0 [00000000], irqs_disabled():1
Oct 17 18:53:52 mango kernel:  [print_context_stack+78/112] dump_stack+0x1e/0x20
Oct 17 18:53:52 mango kernel:  [sinbin_release_fn+536/864] __might_sleep+0xb8/0xd0
Oct 17 18:53:52 mango kernel:  [__create_workqueue+35/320] _mutex_lock+0x23/0x60
Oct 17 18:53:52 mango kernel:  [__create_workqueue+145/320] _mutex_lock_irqsave+0x11/0x20
Oct 17 18:53:52 mango kernel:  [pg0+809943061/1069765632] get_time_pit+0x15/0x50 [gameport]
Oct 17 18:53:52 mango kernel:  [pg0+809943199/1069765632] gameport_measure_speed+0x4f/0x100 [gameport]
Oct 17 18:53:52 mango kernel:  [pg0+809943550/1069765632] gameport_register_port+0x2e/0x40 [gameport]
Oct 17 18:53:52 mango kernel:  [pg0+809931156/1069765632] snd_card_cs46xx_probe+0x194/0x250 [snd_cs46xx]
Oct 17 18:53:52 mango kernel:  [crypto_unregister_alg+43/192] pci_device_probe_static+0x4b/0x60
Oct 17 18:53:52 mango kernel:  [crypto_unregister_alg+104/192] __pci_device_probe+0x28/0x30
Oct 17 18:53:52 mango kernel:  [crypto_unregister_alg+156/192] pci_device_probe+0x2c/0x50
Oct 17 18:53:52 mango kernel:  [take_over_console+605/1248] bus_match+0x3d/0x70
Oct 17 18:53:52 mango kernel:  [take_over_console+906/1248] driver_attach+0x5a/0x90
Oct 17 18:53:52 mango kernel:  [do_blank_screen+608/688] bus_add_driver+0xa0/0xd0
Oct 17 18:53:52 mango kernel:  [con_set_cmap+1/64] driver_register+0x31/0x40
Oct 17 18:53:52 mango kernel:  [scatterwalk_pagedone+18/96] pci_register_driver+0x42/0x50
Oct 17 18:53:52 mango kernel:  [pg0+809931362/1069765632] alsa_card_cs46xx_init+0x12/0x30 [snd_cs46xx]
Oct 17 18:53:52 mango kernel:  [__kfifo_put+65/208] sys_init_module+0x1f1/0x2d0
Oct 17 18:53:52 mango kernel:  [need_resched+36/37] syscall_call+0x7/0xb
Oct 17 18:53:52 mango kernel: preempt count: 00000001
Oct 17 18:53:52 mango kernel: . 1-level deep critical section nesting:
Oct 17 18:53:52 mango kernel: .. entry 1: print_traces+0x12/0x40 / (dump_stack+0x1e/0x20)
Oct 17 18:53:52 mango kernel: 

This seems to be related to modprobe'ing snd-cs46xx

flo

p.s.: attached is the .config of this kernel.

[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 25897 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-rc4-mm1-RT-U4
# Sun Oct 17 17:25:42 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION="-RT"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

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

#
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_GENERIC_SPINLOCK=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_X86_USE_3DNOW=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
# 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 is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

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

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

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

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD 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=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_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 is not set
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 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=y
# 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

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

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

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

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_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_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_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

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT 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_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM 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_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

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

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set

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

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

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

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

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

#
# Generic devices
#
CONFIG_SND_DUMMY=m
# 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

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

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY 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_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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=m
CONFIG_RXRPC=m

#
# 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=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_PREEMPT=y
# CONFIG_PREEMPT_TIMING is not set
CONFIG_PREEMPT_TRACE=y
# CONFIG_DEBUG_INFO is not set
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set

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

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-17 16:12                                   ` Ingo Molnar
@ 2004-10-17 17:20                                     ` Rui Nuno Capela
  2004-10-17 17:27                                       ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-17 17:20 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

Ingo Molnar wrote:
>
> Rui Nuno Capela wrote:
>
>> > eth0: 3Com Gigabit LOM (3C940)
>> > eth0: network connection down
>> >       PrefPort:A  RlmtMode:Check Link State
>> >
>> > is this normal? Could the stall simply be a bootup stall due to no
>> > network available?
>> >
>>
>> Yes, I think it's normal. The fact is that on the non-RT kernel, the
>> eth0 device comes up immediately after, as you can see on
>> minicom.cap.{6,7,8} capture files.
>
> ok, then please try to do a sysrq-T. The bootup is soft-hung for some
> reason, lets see what tasks are around.
>

Hey, all the captured files I've sent, minicom.cap{0,1,2,3,4,5}, includes
the SysRq-T output, taken right after the hang. Am I missing something?
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-17 17:20                                     ` Rui Nuno Capela
@ 2004-10-17 17:27                                       ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-17 17:27 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> > ok, then please try to do a sysrq-T. The bootup is soft-hung for some
> > reason, lets see what tasks are around.
> >
> 
> Hey, all the captured files I've sent, minicom.cap{0,1,2,3,4,5}, includes
> the SysRq-T output, taken right after the hang. Am I missing something?

ah, ok, my fault. I started with minicom.cap.0 and stopped here:

SysRq : Emergency Sync

because this itself caused some regression too. It seems init is blocked
on the dcache_lock mutex, but lets first see whether 8K stacks fix your
box - stack overflows can cause nasty, mostly random bugs that look like
real bugs.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-17 17:53                         ` Florian Schmidt
@ 2004-10-17 17:40                           ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-17 17:40 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> > ok, does the patch below fix those messages? (gameport.c used its own,
> > private, incompatible prototype for i8253_lock which breaks raw spinlock
> > handling.)
> > 
> 
> it seems to fix it. i don't see any more messages like the reported
> anymore.

good!

> snd-cs46xx might have some other issues though: Upon rmmod snd-cs46xx
> i see:
> 
> Oct 17 19:43:04 mango kernel: Sound Fusion CS46xx 0000:00:0f.0: Device
> was removed without properly calling pci_disable_device(). This may
> need fixing.
> 
> but i should probably report that to alsa-devel instead right?

yeah, i think so.

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-17 15:32                             ` OGAWA Hirofumi
@ 2004-10-17 17:46                               ` Dominik Karall
  2004-10-18  3:50                                 ` OGAWA Hirofumi
  0 siblings, 1 reply; 951+ messages in thread
From: Dominik Karall @ 2004-10-17 17:46 UTC (permalink / raw)
  To: OGAWA Hirofumi
  Cc: Lee Revell, Ingo Molnar, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Daniel Walker, Bill Huey,
	Andrew Morton, Adam Heath, Lorenzo Allegrucci, Andrew Rodland

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

On Sunday 17 October 2004 17:32, OGAWA Hirofumi wrote:
> Dominik Karall <dominik.karall@gmx.net> writes:
> > i could reproduce it now, but only once. it appeared when i started an
> > avi movie from my fat32 partition. mplayer stopped at buffering 2% and
> > does not play the movie. i tried to start mplayer again and reproduce it,
> > but the bug does not appear again. mplayer only stopped at 2% buffering
> > and does nothing more. it seems like the file couldn't be read clearly
> > now from the fat32 partition, as it does not work with xine and others
> > too.
> > here is the bug i get now:
> >
> > ------------[ cut here ]------------
> > kernel BUG at fs/fat/cache.c:150!
>
> Probably this BUG_ON() was wrong. Does this bug occur only by the
> specific file?
>
> If so, please do "filefrag -v filename" against that file.
>
> Then, can you try the attached patch? This patch removes the BUG_ON(),
> and instead adds printk() for debugging. When the bug occured, it prints
> the current cache.
>
> Thanks.

yes, the bug only occurs on a specific file.
as the bug is present in -mm1 (without vp) too, i applied your patch to that 
one. here is the output:

fat_cache_check: id 0, contig 6415, fclus 38231, dclus 1010103
contig 6416, fclus 38231, dclus 1010103
contig 0, fclus 32, dclus 603964
contig 1, fclus 30, dclus 603960
contig 7, fclus 22, dclus 603950
contig 4, fclus 17, dclus 603943
contig 1, fclus 15, dclus 603940
contig 6, fclus 8, dclus 603931
contig 0, fclus 7, dclus 603929

and the movie starts to play in mplayer without problems. tell me if you need 
more debugging!

best regards,
dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4
  2004-10-17 16:55                       ` Ingo Molnar
@ 2004-10-17 17:53                         ` Florian Schmidt
  2004-10-17 17:40                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-17 17:53 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath

On Sun, 17 Oct 2004 18:55:09 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> ok, does the patch below fix those messages? (gameport.c used its own,
> private, incompatible prototype for i8253_lock which breaks raw spinlock
> handling.)
> 

it seems to fix it. i don't see any more messages like the reported anymore.
snd-cs46xx might have some other issues though: Upon rmmod snd-cs46xx i see:

Oct 17 19:43:04 mango kernel: Sound Fusion CS46xx 0000:00:0f.0: Device was removed without properly calling pci_disable_device(). This may need fixing.

but i should probably report that to alsa-devel instead right?

flo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-17 16:47                                   ` Ingo Molnar
@ 2004-10-17 19:05                                     ` Rui Nuno Capela
  2004-10-17 19:24                                       ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-17 19:05 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

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

Ingo Molnar wrote:
>
> Rui Nuno Capela wrote:
>
>> OK. Here goes some more food-for-thought :)
>> - minicom.cap-2.6.9-rc4-mm1-RT-U4.1smp.tar.gz has another three capture
>> sessions, minicom.cap.{3,4,5}, which stalls on boot/init
>> (CONFIG_PREEMPT_REALTIME=y). Take a special look on minicom.cap.5,
>> where the session has been force-truncated, due to an never ending
>> trace dump, and where no SysRq could do the rescue. This is one of
>> another symptoms, but with less occurrences I've noticed.
>
> i think you are getting stack overflows. Could you disable
> CONFIG_4KSTACKS and see whether that helps?
>

OK. There is goes another bunch, now with CONFIG_4KSTACKS not set. It
doesn't seem to solve anything, unless perhaps more entropy.

BTW, stack overflows wasn't supposed to be pin-pointed when one has
CONFIG_DEBUG_STACKOVERFLOW=y ???

Take care.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: minicom.cap-2.6.9-rc4-mm1-RT-U4.2smp.tar.gz --]
[-- Type: application/x-tgz, Size: 61906 bytes --]

[-- Attachment #3: config-2.6.9-rc4-mm1-RT-U4.2smp.gz --]
[-- Type: application/x-gzip, Size: 7769 bytes --]

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-17 19:05                                     ` Rui Nuno Capela
@ 2004-10-17 19:24                                       ` Ingo Molnar
  2004-10-17 20:23                                         ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-17 19:24 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> BTW, stack overflows wasn't supposed to be pin-pointed when one has
> CONFIG_DEBUG_STACKOVERFLOW=y ???

there were some signs of it:

  minicom.cap.5:do_IRQ: stack overflow: 504

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-17 19:24                                       ` Ingo Molnar
@ 2004-10-17 20:23                                         ` Rui Nuno Capela
  0 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-17 20:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, mark_h_johnson, K.R. Foley,
	Daniel Walker, Bill Huey, Andrew Morton, Adam Heath,
	Lorenzo Allegrucci, Andrew Rodland

Ingo Molnar wrote:
>
> * Rui Nuno Capela <rncbc@rncbc.org> wrote:
>
>> BTW, stack overflows wasn't supposed to be pin-pointed when one has
>> CONFIG_DEBUG_STACKOVERFLOW=y ???
>
> there were some signs of it:
>
>   minicom.cap.5:do_IRQ: stack overflow: 504
>

Yeah. And that was the one who went away in a never ending trace...
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-17 17:46                               ` Dominik Karall
@ 2004-10-18  3:50                                 ` OGAWA Hirofumi
  2004-10-21 10:24                                   ` Dominik Karall
  0 siblings, 1 reply; 951+ messages in thread
From: OGAWA Hirofumi @ 2004-10-18  3:50 UTC (permalink / raw)
  To: Dominik Karall
  Cc: Lee Revell, Ingo Molnar, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Daniel Walker, Bill Huey,
	Andrew Morton, Adam Heath, Lorenzo Allegrucci, Andrew Rodland

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

Dominik Karall <dominik.karall@gmx.net> writes:

> yes, the bug only occurs on a specific file.
> as the bug is present in -mm1 (without vp) too, i applied your patch to that 
> one. here is the output:
>
> fat_cache_check: id 0, contig 6415, fclus 38231, dclus 1010103
> contig 6416, fclus 38231, dclus 1010103
> contig 0, fclus 32, dclus 603964
> contig 1, fclus 30, dclus 603960
> contig 7, fclus 22, dclus 603950
> contig 4, fclus 17, dclus 603943
> contig 1, fclus 15, dclus 603940
> contig 6, fclus 8, dclus 603931
> contig 0, fclus 7, dclus 603929

Thanks. Seems good. There is no inconsistency in cache.

> and the movie starts to play in mplayer without problems. tell me if
> you need more debugging!

Can you please try the patch again? This patch should tell who added
the cache.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: fat-debug.patch --]
[-- Type: text/x-patch, Size: 2719 bytes --]



Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

 fs/fat/cache.c |   41 ++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 40 insertions(+), 1 deletion(-)

diff -puN fs/fat/cache.c~fat-debug fs/fat/cache.c
--- linux-2.6.9-final-a/fs/fat/cache.c~fat-debug	2004-10-17 23:45:27.000000000 +0900
+++ linux-2.6.9-final-a-hirofumi/fs/fat/cache.c	2004-10-18 09:38:31.000000000 +0900
@@ -11,6 +11,7 @@
 #include <linux/fs.h>
 #include <linux/msdos_fs.h>
 #include <linux/buffer_head.h>
+#include <linux/sched.h>
 
 /* this must be > 0. */
 #define FAT_MAX_CACHE	8
@@ -20,6 +21,10 @@ struct fat_cache {
 	int nr_contig;	/* number of contiguous clusters */
 	int fcluster;	/* cluster number in the file. */
 	int dcluster;	/* cluster number on disk. */
+	char comm[16];
+	pid_t pid;
+	unsigned int id;
+	unsigned long long tsc;
 };
 
 struct fat_cache_id {
@@ -134,6 +139,36 @@ static struct fat_cache *fat_cache_merge
 	return NULL;
 }
 
+static void fat_cache_check(struct inode *inode, struct fat_cache_id *new)
+{
+	struct fat_cache *p;
+	unsigned long long tsc;
+
+	if (new->id == FAT_CACHE_VALID) {
+		list_for_each_entry(p, &MSDOS_I(inode)->cache_lru, cache_list) {
+			/* Find the same part as "new" in cluster-chain. */
+			if (p->fcluster == new->fcluster) {
+				BUG_ON(p->dcluster != new->dcluster);
+				goto dump_cache;
+			}
+		}
+	}
+	return;
+
+dump_cache:
+	rdtscll(tsc);
+	printk("%s: tsc %llu, comm %s, pid %d, id %u, "
+	       "contig %d, fclus %d, dclus %d\n",
+	       __FUNCTION__, tsc, current->comm, current->pid, new->id,
+	       new->nr_contig, new->fcluster, new->dcluster);
+	list_for_each_entry(p, &MSDOS_I(inode)->cache_lru, cache_list) {
+		printk("tsc %llu, comm %s, pid %d, id %u, "
+		       "contig %d, fclus %d, dclus %d\n",
+		       p->tsc, p->comm, p->pid, p->id,
+		       p->nr_contig, p->fcluster, p->dcluster);
+	}
+}
+
 static void fat_cache_add(struct inode *inode, struct fat_cache_id *new)
 {
 	struct fat_cache *cache, *tmp;
@@ -146,8 +181,8 @@ static void fat_cache_add(struct inode *
 	    new->id != MSDOS_I(inode)->cache_valid_id)
 		goto out;	/* this cache was invalidated */
 
+	fat_cache_check(inode, new);
 	cache = fat_cache_merge(inode, new);
-	BUG_ON(new->id == FAT_CACHE_VALID && cache != NULL);
 	if (cache == NULL) {
 		if (MSDOS_I(inode)->nr_caches < fat_max_cache(inode)) {
 			MSDOS_I(inode)->nr_caches++;
@@ -171,6 +206,10 @@ static void fat_cache_add(struct inode *
 		cache->nr_contig = new->nr_contig;
 	}
 out_update_lru:
+	strcpy(cache->comm, current->comm);
+	cache->pid = current->pid;
+	cache->id = new->id;
+	rdtscll(cache->tsc);
 	fat_cache_update_lru(inode, cache);
 out:
 	spin_unlock(&MSDOS_I(inode)->cache_lru_lock);
_

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

* [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-16 15:33                   ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4 Ingo Molnar
                                       ` (3 preceding siblings ...)
  2004-10-17 17:03                     ` Florian Schmidt
@ 2004-10-18 14:50                     ` Ingo Molnar
  2004-10-18 15:58                       ` Jason Munro
                                         ` (10 more replies)
  4 siblings, 11 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-18 14:50 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt


i have released the -U5 Real-Time Preemption patch:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5

this is a release intended to increase stability, but since it also
includes new debug features and related cleanups it might introduce new
regressions. Be careful.

there are two big changes:

 - debug feature: automatic semaphore/rwsem deadlock detection, based on
   the code from Igor Manyilov and Bill Huey.

this is a very nice feature that should help in debugging the remaining
deadlocks. The deadlock detection feature has already helped me fix a
bug that was causing hangs in the VFS, so it's really useful.

 - generic semaphore implementation

the generic semaphore implementation (which uses rwsems) makes it
possible to use the deadlock detection mechanism for all the mutex types
we currently have: semaphores, rw-semaphores, spinlock-mutexes and
rwlock-mutexes. Another benefit is that PREEMPT_REALTIME becomes much
more portable this way. (although it's still x86-only at the moment.)

other changes since -U4:

 - crash fix: fixed a possible "unbound recursion upon IRQ entry" bug.
   introduced preempt_schedule_irq() which now schedules without
   enabling interrupts again, preventing new IRQs from hitting this
   task again and triggering preemption. This might fix the
   'infinite stackdumps' problem Rui Nuno Capela was seeing.

 - deadlock fix: is_subdir()'s PREEMPT_REALTIME locking was buggy. This 
   could perhaps fix the other problem reported by Rui Nuno Capela.

 - i8253_lock fixes: apm, hd.c, gameport.c and analog.c were all 
   improperly importing the variable while overriding the prototype. 
   This fixes the bug reported by Florian Schmidt.

 - possible crash fix: one particular lock in selinux has to be 
   mutex-based, because while held it calls other mutex-using code.

 - two more selinux locks converted to raw spinlocks, because they were
   called from within raw-critical sections.

 - debug feature: enforce interrupts-enabled upon schedule().
   (Note that this does not break sleep_on() because sleep_on() does not
   disable interrupts in the PREEMPT_REALTIME mode. It might break with 
   !PREEMPT_REALTIME though.)

 - locking cleanup: converted the IPC code from raw spinlocks & RCU to
   spinlock-mutexes.

 - code cleanup: cleaned up the generic rwsem code.

 - debug feature: implemented /proc/sys/kernel/trace_verbose runtime
   flag (default:0), which enables a much more verbose printout in
   /proc/latency_trace.  This trace format can be useful in e.g. 
   debugging timestamp weirdnesses.

 - irqs-off fix: there was one codepath where irqd would call schedule() 
   with interrupts disabled.

 - debug feature: the NMI entries in the latency trace now also include 
   the last-observed-EFLAGS value. Can be useful in figuring out what a
   certain CPU is doing and why.

 - cleanup: fixed preemption-off ordering: often the spinlock (and 
   scheduler) code would re-enable preemption and interrupts in the
   wrong order, opening up a small window for an interrupt handler to
   fit in and increase the latency of that almost-finished critical
   section.

 - cleanup: consolidated various bug-printouts. It should now be easy to
   find whether anything bad happens even amongst lots of preempt-timing
   printouts: 'dmesg | grep BUG'.

to create a -U5 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
@ 2004-10-18 15:58                       ` Jason Munro
  2004-10-18 17:08                       ` Adam Heath
                                         ` (9 subsequent siblings)
  10 siblings, 0 replies; 951+ messages in thread
From: Jason Munro @ 2004-10-18 15:58 UTC (permalink / raw)
  To: linux-kernel

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

On 9:50:08 am 10/18/04 Ingo Molnar <mingo@elte.hu> wrote:
>
> i have released the -U5 Real-Time Preemption patch:
>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-r
> c4-mm1-U5

Im getting this on a make bzImage:

  CC      fs/xfs/xfs_inode_item.o
fs/xfs/xfs_inode_item.c: In function `xfs_inode_item_pushbuf':
fs/xfs/xfs_inode_item.c:803: error: structure has no member named `count'
fs/xfs/xfs_inode_item.c:825: error: structure has no member named `count'
make[2]: *** [fs/xfs/xfs_inode_item.o] Error 1

I'm currently running 2.6.9-rc4-mm1-U1 without error. I backed out the U1
patch, applied the new one, did a make oldconfig, make clean, make bzImage,
make modules. My config is attached. 

\__ Jason Munro
 \__ jason@stdbev.com
  \__ http://hastymail.sourceforge.net/

[-- Attachment #2: config --]
[-- Type: text/plain, Size: 35188 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-rc4-mm1-RT-U5
# Mon Oct 18 10:23:45 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_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_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_GENERIC=y
CONFIG_GENERIC_SEMAPHORES=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_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
CONFIG_TOSHIBA=y
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP 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_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_THINKPAD=m
CONFIG_ACPI_TOSHIBA=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set

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

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_PROC_INTF is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=m
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_24_API is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
CONFIG_CPU_FREQ_TABLE=y

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

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=y

#
# 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_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_YENTA=y
CONFIG_CARDBUS=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

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

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

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

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD 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_IDECS=m
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
CONFIG_BLK_DEV_IDEFLOPPY=m
# 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 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 is not set
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_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_SCSI=y
# CONFIG_SCSI_PROC_FS is not set

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

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

#
# 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 is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA6322 is not set
# CONFIG_SCSI_SEAGATE 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

#
# PCMCIA SCSI adapter support
#
# CONFIG_PCMCIA_AHA152X is not set
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_NINJA_SCSI is not set
# CONFIG_PCMCIA_QLOGIC is not set
# CONFIG_PCMCIA_SYM53C500 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

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP 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=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
CONFIG_XFRM=y
CONFIG_XFRM_USER=m

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

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET 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_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=y
# 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 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

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

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

#
# Wireless 802.11 Frequency Hopping cards support
#
# CONFIG_PCMCIA_RAYCS is not set

#
# Wireless 802.11b ISA/PCI cards support
#
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set

#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
# CONFIG_AIRO_CS is not set
# CONFIG_PCMCIA_WL3501 is not set

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
# CONFIG_PRISM54 is not set
CONFIG_NET_WIRELESS=y

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

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPPOE is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
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

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

#
# 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_CS=m
# 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_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=m
# 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=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_INTEL_MCH is not set
# 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 is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS 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

#
# I2C support
#
CONFIG_I2C=m
# CONFIG_I2C_CHARDEV is not set

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

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

#
# Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set

#
# Other I2C Chip support
#
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_ZR36120 is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set

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

#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
CONFIG_FB_RIVA=m
CONFIG_FB_RIVA_I2C=y
# CONFIG_FB_RIVA_DEBUG is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
# CONFIG_FONT_8x16 is not set
CONFIG_FONT_6x11=y
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set

#
# Logo configuration
#
# CONFIG_LOGO is not set

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=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_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_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_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=y
# 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_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set

#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_VXP440 is not set
# CONFIG_SND_PDAUDIOCF is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
# 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_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_RW_DETECT 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_HP8200e 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 Human Interface Devices (HID)
#
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_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

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

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

#
# USB Network adaptors
#
# 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

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
CONFIG_USB_SERIAL_VISOR=m
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
CONFIG_USB_SERIAL_PL2303=m
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_TEST is not set

#
# USB ATM/DSL drivers
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=m
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_SECURITY is not set
# CONFIG_XFS_POSIX_ACL is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

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

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

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
# CONFIG_DEVFS_DEBUG is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS 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=m
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=m
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_LOCKD=m
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_POSIX is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_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=y

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_PREEMPT_TIMING is not set
# CONFIG_RWSEM_DEADLOCK_DETECT is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_4KSTACKS=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

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

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
  2004-10-18 15:58                       ` Jason Munro
@ 2004-10-18 17:08                       ` Adam Heath
  2004-10-18 17:12                         ` Ingo Molnar
  2004-10-18 17:57                       ` Adam Heath
                                         ` (8 subsequent siblings)
  10 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-18 17:08 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Mon, 18 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U5 Real-Time Preemption patch:
>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5
>
> this is a release intended to increase stability, but since it also
> includes new debug features and related cleanups it might introduce new
> regressions. Be careful.
>
> [snip]
>
>  - debug feature: implemented /proc/sys/kernel/trace_verbose runtime
>    flag (default:0), which enables a much more verbose printout in
>    /proc/latency_trace.  This trace format can be useful in e.g.
>    debugging timestamp weirdnesses.
>

With all these proc values, what do you recommend they should be set to?

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 17:08                       ` Adam Heath
@ 2004-10-18 17:12                         ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-18 17:12 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


* Adam Heath <doogie@debian.org> wrote:

> >  - debug feature: implemented /proc/sys/kernel/trace_verbose runtime
> >    flag (default:0), which enables a much more verbose printout in
> >    /proc/latency_trace.  This trace format can be useful in e.g.
> >    debugging timestamp weirdnesses.
> 
> With all these proc values, what do you recommend they should be set
> to?

just the default values - same for the .config options. Once the feature
gets more stable the latency measurements can begin again - for them the
/proc values are important.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
  2004-10-18 15:58                       ` Jason Munro
  2004-10-18 17:08                       ` Adam Heath
@ 2004-10-18 17:57                       ` Adam Heath
  2004-10-18 18:18                         ` Ingo Molnar
  2004-10-18 18:44                       ` K.R. Foley
                                         ` (7 subsequent siblings)
  10 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-18 17:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Florian Schmidt

On Mon, 18 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U5 Real-Time Preemption patch:
>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5
>

EXT3 FS on hda5, internal journal
(mount/71/CPU#0): new 493 us maximum-latency critical section.
 => started at timestamp 29143938: <kernel_fpu_begin+0x21/0x60>
 =>   ended at timestamp 29144431: <_mmx_memcpy+0x131/0x180>
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01dcf51>] _mmx_memcpy+0x131/0x180
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01dcf51>] _mmx_memcpy+0x131/0x180
 [<c01dcf51>] _mmx_memcpy+0x131/0x180
 [<c01e3625>] vgacon_scroll+0x245/0x260
 [<c01f3bba>] scrup+0xda/0xf0
 [<c0113104>] mcount+0x14/0x18
 [<c01f5702>] lf+0x72/0x80
 [<c01f7e9f>] vt_console_print+0x13f/0x320
 [<c011c231>] __call_console_drivers+0x61/0x70
 [<c011c35a>] call_console_drivers+0x9a/0x140
 [<c011c721>] release_console_sem+0x71/0x100
 [<c011c5f6>] vprintk+0x116/0x180
 [<c011c4dd>] printk+0x1d/0x20
 [<c01a0957>] ext3_setup_super+0x127/0x1b0
 [<c01db07f>] up_write+0x4f/0x80
 [<c01a2552>] ext3_remount+0x132/0x190
 [<c01dae41>] down_write+0x71/0xa0
 [<c0162903>] do_remount_sb+0xb3/0xe0
 [<c0179712>] do_remount+0x72/0xc0
 [<c017a073>] do_mount+0x1a3/0x1b0
 [<c01dae41>] down_write+0x71/0xa0
 [<c017a3ec>] sys_mount+0x9c/0x100
 [<c0106013>] syscall_call+0x7/0xb
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: kernel_fpu_begin+0x21/0x60 / (_mmx_memcpy+0x36/0x180)
.. entry 2: print_traces+0x1d/0x70 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 29144924

The kernel is jsut getting ready to start init at this point(mounting root),
so I don't know if you are really interested in this high latency trace, but
I'm sending anyways.

However, after I reset the threshold to 50(and got a few small traces), I got
this whopper.

(XFree86/1129/CPU#0): new 4692 us maximum-latency critical section.
 => started at timestamp 358506933: <call_console_drivers+0x76/0x140>
 =>   ended at timestamp 358511625: <finish_task_switch+0x43/0xa0>
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c0117ca3>] finish_task_switch+0x43/0xa0
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c0117ca3>] finish_task_switch+0x43/0xa0
 [<c0117ca3>] finish_task_switch+0x43/0xa0
 [<c02a2859>] __sched_text_start+0x2d9/0x570
 [<c02a3323>] schedule_timeout+0x63/0xc0
 [<c02a316e>] cond_resched+0xe/0x90
 [<c01253a0>] process_timeout+0x0/0x20
 [<c02a3185>] cond_resched+0x25/0x90
 [<c016f592>] do_select+0x172/0x280
 [<c016f280>] __pollwait+0x0/0xb0
 [<c016f984>] sys_select+0x294/0x570
 [<c0106013>] syscall_call+0x7/0xb
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __sched_text_start+0x3b/0x570 / (schedule_timeout+0x63/0xc0)
.. entry 2: print_traces+0x1d/0x70 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 358512077

ps: I've never mentioned the hardware I am running.  Athlon XP 2000, 1G ram,
    460G(usable) software raid5(3*250g ide)(plus boot 120G), LVM, extra
    SiliconImage UDMA133 controller(mobo can only do 100).

    I'm not certain what kind of latencies to expect with this setup.  I'm
    tending to ignore <100us, at least for now.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 17:57                       ` Adam Heath
@ 2004-10-18 18:18                         ` Ingo Molnar
  2004-10-18 20:58                           ` Adam Heath
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-18 18:18 UTC (permalink / raw)
  To: Adam Heath
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Florian Schmidt


* Adam Heath <adam@doogie.org> wrote:

>  =>   dump-end timestamp 29144924
> 
> The kernel is jsut getting ready to start init at this point(mounting
> root), so I don't know if you are really interested in this high
> latency trace, but I'm sending anyways.

lets skip these for the time being, large runtime ones are the first 
ones to be squashed.

> However, after I reset the threshold to 50(and got a few small traces), I got
> this whopper.
> 
> (XFree86/1129/CPU#0): new 4692 us maximum-latency critical section.
>  => started at timestamp 358506933: <call_console_drivers+0x76/0x140>
>  =>   ended at timestamp 358511625: <finish_task_switch+0x43/0xa0>
>  [<c0132480>] sub_preempt_count+0x60/0x90

interesting - this could be a printk (trace) done in a critical section
though. What does /proc/latency_trace tell, is it full of console code
functions?

one of the best ways to avoid the console-printk-ing overhead is to do a
'dmesg -n 1' and reset the maximum back to 50. (i prefer to use the
preempt_max_latency option not the preempt_thresh option.)

> ps: I've never mentioned the hardware I am running.  Athlon XP 2000, 1G ram,
>     460G(usable) software raid5(3*250g ide)(plus boot 120G), LVM, extra
>     SiliconImage UDMA133 controller(mobo can only do 100).
> 
>     I'm not certain what kind of latencies to expect with this setup.  I'm
>     tending to ignore <100us, at least for now.

this setup shouldnt produce above-100 usec latencies with -U5 and
PREEMPT_REALTIME.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
                                         ` (2 preceding siblings ...)
  2004-10-18 17:57                       ` Adam Heath
@ 2004-10-18 18:44                       ` K.R. Foley
  2004-10-18 18:49                         ` Ingo Molnar
  2004-10-18 19:32                       ` Bill Huey
                                         ` (6 subsequent siblings)
  10 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-18 18:44 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt

Ingo Molnar wrote:
> i have released the -U5 Real-Time Preemption patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5
> 

Ingo,

*** Warning: "__you_cannot_kmalloc_that_much" 
[drivers/scsi/aacraid/aacraid.ko] undefined!

This just appeared in U5. I was trying to track this one down just 
because I saw it, even though I don't need aacraid. I am having a hell 
of a time tracking down what changed that would cause this, but I figure 
you will know exactly what changed that would cause it. :)

kr


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 18:44                       ` K.R. Foley
@ 2004-10-18 18:49                         ` Ingo Molnar
  2004-10-18 19:17                           ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-18 18:49 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt


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

> Ingo Molnar wrote:
> >i have released the -U5 Real-Time Preemption patch:
> >
> >  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5
> >
> 
> Ingo,
> 
> *** Warning: "__you_cannot_kmalloc_that_much" 
> [drivers/scsi/aacraid/aacraid.ko] undefined!
> 
> This just appeared in U5. I was trying to track this one down just
> because I saw it, even though I don't need aacraid. I am having a hell
> of a time tracking down what changed that would cause this, but I
> figure you will know exactly what changed that would cause it. :)

i suspect this is due to the size increase of semaphores if
CONFIG_RWSEM_DEADLOCK_DETECT is enabled. Try lowering
CONFIG_RWSEM_MAX_OWNERS from the default 64 to 32, does that help?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 18:49                         ` Ingo Molnar
@ 2004-10-18 19:17                           ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-18 19:17 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>Ingo Molnar wrote:
>>
>>>i have released the -U5 Real-Time Preemption patch:
>>>
>>> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5
>>>
>>
>>Ingo,
>>
>>*** Warning: "__you_cannot_kmalloc_that_much" 
>>[drivers/scsi/aacraid/aacraid.ko] undefined!
>>
>>This just appeared in U5. I was trying to track this one down just
>>because I saw it, even though I don't need aacraid. I am having a hell
>>of a time tracking down what changed that would cause this, but I
>>figure you will know exactly what changed that would cause it. :)
> 
> 
> i suspect this is due to the size increase of semaphores if
> CONFIG_RWSEM_DEADLOCK_DETECT is enabled. Try lowering
> CONFIG_RWSEM_MAX_OWNERS from the default 64 to 32, does that help?
> 
> 	Ingo
> 
Yes. That does help.

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
                                         ` (3 preceding siblings ...)
  2004-10-18 18:44                       ` K.R. Foley
@ 2004-10-18 19:32                       ` Bill Huey
  2004-10-18 19:34                         ` Bill Huey
  2004-10-18 19:36                         ` Ingo Molnar
  2004-10-19  1:27                       ` Adam Heath
                                         ` (5 subsequent siblings)
  10 siblings, 2 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-18 19:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt

On Mon, Oct 18, 2004 at 04:50:08PM +0200, Ingo Molnar wrote:
> i have released the -U5 Real-Time Preemption patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5

  CC      arch/i386/kernel/traps.o
arch/i386/kernel/traps.c: In function `do_debug':
arch/i386/kernel/traps.c:786: error: `sysenter_past_esp' undeclared (first use in this function)
arch/i386/kernel/traps.c:786: error: (Each undeclared identifier is reported only once
arch/i386/kernel/traps.c:786: error: for each function it appears in.)
make[1]: *** [arch/i386/kernel/traps.o] Error 1
make: *** [arch/i386/kernel] Error 2

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 19:32                       ` Bill Huey
@ 2004-10-18 19:34                         ` Bill Huey
  2004-10-18 19:36                         ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-18 19:34 UTC (permalink / raw)
  To: Bill Huey
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt

On Mon, Oct 18, 2004 at 12:32:51PM -0700, Bill Huey wrote:
> On Mon, Oct 18, 2004 at 04:50:08PM +0200, Ingo Molnar wrote:
> > i have released the -U5 Real-Time Preemption patch:
> > 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5
> 
>   CC      arch/i386/kernel/traps.o
> arch/i386/kernel/traps.c: In function `do_debug':
> arch/i386/kernel/traps.c:786: error: `sysenter_past_esp' undeclared (first use in this function)
> arch/i386/kernel/traps.c:786: error: (Each undeclared identifier is reported only once
> arch/i386/kernel/traps.c:786: error: for each function it appears in.)
> make[1]: *** [arch/i386/kernel/traps.o] Error 1
> make: *** [arch/i386/kernel] Error 2

bah, let me handle this, CONFIG_KGDB was turned on and I'm workin on
this now...

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 19:32                       ` Bill Huey
  2004-10-18 19:34                         ` Bill Huey
@ 2004-10-18 19:36                         ` Ingo Molnar
  2004-10-18 19:40                           ` Bill Huey
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-18 19:36 UTC (permalink / raw)
  To: Bill Huey
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Adam Heath, Florian Schmidt


* Bill Huey <bhuey@lnxw.com> wrote:

> On Mon, Oct 18, 2004 at 04:50:08PM +0200, Ingo Molnar wrote:
> > i have released the -U5 Real-Time Preemption patch:
> > 
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U5
> 
>   CC      arch/i386/kernel/traps.o
> arch/i386/kernel/traps.c: In function `do_debug':
> arch/i386/kernel/traps.c:786: error: `sysenter_past_esp' undeclared (first use in this function)
> arch/i386/kernel/traps.c:786: error: (Each undeclared identifier is reported only once
> arch/i386/kernel/traps.c:786: error: for each function it appears in.)
> make[1]: *** [arch/i386/kernel/traps.o] Error 1
> make: *** [arch/i386/kernel] Error 2

i guess this might be an -mm1 breakage if CONFIG_KGDB enabled - does it
happen with vanilla -mm1 too?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 19:36                         ` Ingo Molnar
@ 2004-10-18 19:40                           ` Bill Huey
  2004-10-18 19:46                             ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-18 19:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Andrew Morton

On Mon, Oct 18, 2004 at 09:36:03PM +0200, Ingo Molnar wrote:
> * Bill Huey <bhuey@lnxw.com> wrote:
> > 
> >   CC      arch/i386/kernel/traps.o
> > arch/i386/kernel/traps.c: In function `do_debug':
> > arch/i386/kernel/traps.c:786: error: `sysenter_past_esp' undeclared (first use in this function)
> > arch/i386/kernel/traps.c:786: error: (Each undeclared identifier is reported only once
> > arch/i386/kernel/traps.c:786: error: for each function it appears in.)
> > make[1]: *** [arch/i386/kernel/traps.o] Error 1
> > make: *** [arch/i386/kernel] Error 2
> 
> i guess this might be an -mm1 breakage if CONFIG_KGDB enabled - does it
> happen with vanilla -mm1 too?

yep, should I wait for -mm2 ?

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 19:40                           ` Bill Huey
@ 2004-10-18 19:46                             ` Ingo Molnar
  2004-10-18 19:52                               ` Bill Huey
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-18 19:46 UTC (permalink / raw)
  To: Bill Huey
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Adam Heath, Florian Schmidt, Andrew Morton


* Bill Huey <bhuey@lnxw.com> wrote:

> On Mon, Oct 18, 2004 at 09:36:03PM +0200, Ingo Molnar wrote:
> > * Bill Huey <bhuey@lnxw.com> wrote:
> > > 
> > >   CC      arch/i386/kernel/traps.o
> > > arch/i386/kernel/traps.c: In function `do_debug':
> > > arch/i386/kernel/traps.c:786: error: `sysenter_past_esp' undeclared (first use in this function)
> > > arch/i386/kernel/traps.c:786: error: (Each undeclared identifier is reported only once
> > > arch/i386/kernel/traps.c:786: error: for each function it appears in.)
> > > make[1]: *** [arch/i386/kernel/traps.o] Error 1
> > > make: *** [arch/i386/kernel] Error 2
> > 
> > i guess this might be an -mm1 breakage if CONFIG_KGDB enabled - does it
> > happen with vanilla -mm1 too?
> 
> yep, should I wait for -mm2 ?

since 2.6.9's release is imminent there will unlikely be an -rc4-mm2,
2.6.9-mm1 should be the next one.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 19:46                             ` Ingo Molnar
@ 2004-10-18 19:52                               ` Bill Huey
  0 siblings, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-18 19:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Andrew Morton

On Mon, Oct 18, 2004 at 09:46:32PM +0200, Ingo Molnar wrote:
> since 2.6.9's release is imminent there will unlikely be an -rc4-mm2,
> 2.6.9-mm1 should be the next one.

The new kgdb logic is a bit foreign to me. I'll have to look at it a
bit more, but this kgdb build problem is criticial for a certain
part of the kernel community that needs it. I've commented out that
section and rebuilding it now.

To get kgdb work (referencing my tree), I've just demoted all of the
spinlocks in arch/i386/{kernel,lib}/kgdb*.c files. It's pretty straight
forward, nothing tricky at all.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 18:18                         ` Ingo Molnar
@ 2004-10-18 20:58                           ` Adam Heath
  2004-10-18 21:06                             ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-18 20:58 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Mon, 18 Oct 2004, Ingo Molnar wrote:

> > However, after I reset the threshold to 50(and got a few small traces), I got
> > this whopper.
> >
> > (XFree86/1129/CPU#0): new 4692 us maximum-latency critical section.
> >  => started at timestamp 358506933: <call_console_drivers+0x76/0x140>
> >  =>   ended at timestamp 358511625: <finish_task_switch+0x43/0xa0>
> >  [<c0132480>] sub_preempt_count+0x60/0x90
>
> interesting - this could be a printk (trace) done in a critical section
> though. What does /proc/latency_trace tell, is it full of console code
> functions?

Too late, it's gone.  It'd be nice if there was some way to have history on
that file.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 20:58                           ` Adam Heath
@ 2004-10-18 21:06                             ` Ingo Molnar
  2004-10-18 21:21                               ` Adam Heath
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-18 21:06 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


* Adam Heath <doogie@debian.org> wrote:

> On Mon, 18 Oct 2004, Ingo Molnar wrote:
> 
> > > However, after I reset the threshold to 50(and got a few small traces), I got
> > > this whopper.
> > >
> > > (XFree86/1129/CPU#0): new 4692 us maximum-latency critical section.
> > >  => started at timestamp 358506933: <call_console_drivers+0x76/0x140>
> > >  =>   ended at timestamp 358511625: <finish_task_switch+0x43/0xa0>
> > >  [<c0132480>] sub_preempt_count+0x60/0x90
> >
> > interesting - this could be a printk (trace) done in a critical section
> > though. What does /proc/latency_trace tell, is it full of console code
> > functions?
> 
> Too late, it's gone.  It'd be nice if there was some way to have
> history on that file.

well - if it's gone it's always replaced by a larger latency (if you use
the preempt_max_latency method), which in most cases is more interesting
than the one you wanted to save.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 21:06                             ` Ingo Molnar
@ 2004-10-18 21:21                               ` Adam Heath
  0 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-18 21:21 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

yOn Mon, 18 Oct 2004, Ingo Molnar wrote:

> > Too late, it's gone.  It'd be nice if there was some way to have
> > history on that file.
>
> well - if it's gone it's always replaced by a larger latency (if you use
> the preempt_max_latency method), which in most cases is more interesting
> than the one you wanted to save.

I reset the minimum to 50, and it's only gotten up to 83.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
                                         ` (4 preceding siblings ...)
  2004-10-18 19:32                       ` Bill Huey
@ 2004-10-19  1:27                       ` Adam Heath
  2004-10-19  8:09                       ` Thomas Gleixner
                                         ` (4 subsequent siblings)
  10 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-19  1:27 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

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

On Mon, 18 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U5 Real-Time Preemption patch:

>From the first line of the attached oops file:

kernel BUG at lib/rwsem-generic.c:130!

Then, a BUG, sleeping while atomic.

[-- Attachment #2: Type: TEXT/PLAIN, Size: 5669 bytes --]

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:130!
invalid operand: 0000 [#1]
PREEMPT 
Modules linked in: nfsd exportfs snd_cmipci snd_opl3_lib snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device 8250 serial_core nfs lockd sunrpc raid5 xor md dm_mirror dm_mod aic7xxx sg sr_mod cdrom sd_mod scsi_mod snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snd_page_alloc soundcore 3c59x mii sis900 crc32 siimage
CPU:    0
EIP:    0060:[<c01da56b>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-rt-u5) 
EIP is at rwsem_owner_del+0x6b/0x90
eax: 00000001   ebx: f7b31658   ecx: 00000000   edx: 00000001
esi: 00000000   edi: f7b31658   ebp: d3113f34   esp: d3113f28
ds: 007b   es: 007b   ss: 0068   preempt: 00000002
Process liquidwar (pid: 6352, threadinfo=d3113000 task=d7ec6e60)
Stack: f7b31658 00000202 d3113fa8 d3113f48 c01db057 f7b31658 f741ac00 d74036c0 
       d3113f64 f88c1c18 d3113f64 c0113104 00000000 f88c1be0 d74036c0 d3113f90 
       c015b61b d74036c0 080d77f8 00000800 d3113fa8 f0d94164 f0d94164 d74036c0 
Call Trace:
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: up_write+0x70/0x80 / (snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss])
.. entry 2: die+0x3f/0x1a0 / (do_invalid_op+0x106/0x110)
.. entry 3: print_traces+0x1d/0x70 / (show_stack+0x83/0xa0)

Code: 16 bb 00 f0 ff ff 21 e3 8b 44 8f 10 3b 03 74 28 41 89 d6 39 d1 7c f1 8b 15 b8 fe 2e c0 85 d2 74 12 c7 05 b8 fe 2e c0 00 00 00 00 <0f> 0b 82 00 e1 05 2c c0 5b 5e 5f c9 c3 8d 56 ff 39 d1 74 08 8b 
 <6>note: liquidwar[6352] exited with preempt_count 1
BUG: sleeping function called from invalid context liquidwar(6352) at kernel/fork.c:421
in_atomic():1 [00000001], irqs_disabled():0
 [<c0119582>] __might_sleep+0xc2/0xe0
 [<c0119bce>] mm_release+0x6e/0xd0
 [<c011c4dd>] printk+0x1d/0x20
 [<c011e6d3>] do_exit+0x83/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: task_rq_lock+0x1e/0x30 / (try_to_wake_up+0x2d/0xc0)
.. entry 2: print_traces+0x1d/0x70 / (dump_stack+0x23/0x30)

BUG: scheduling while atomic: liquidwar/0x04000001/6352
caller is cond_resched+0x62/0x90
 [<c02a2ab9>] __sched_text_start+0x539/0x570
 [<c02a31c2>] cond_resched+0x62/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c02a31c2>] cond_resched+0x62/0x90
 [<c0119bd3>] mm_release+0x73/0xd0
 [<c011c4dd>] printk+0x1d/0x20
 [<c011e6d3>] do_exit+0x83/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: __do_IRQ+0x111/0x190 / (do_IRQ+0x75/0xa0)
.. entry 2: print_traces+0x1d/0x70 / (dump_stack+0x23/0x30)

BUG: scheduling while atomic: liquidwar/0x00000001/6352
caller is do_exit+0x292/0x4a0
 [<c02a2ab9>] __sched_text_start+0x539/0x570
 [<c011e8e2>] do_exit+0x292/0x4a0
 [<c0113104>] mcount+0x14/0x18
 [<c011e8e2>] do_exit+0x292/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __do_IRQ+0x111/0x190 / (do_IRQ+0x75/0xa0)
.. entry 2: print_traces+0x1d/0x70 / (dump_stack+0x23/0x30)


[-- Attachment #3: Type: TEXT/PLAIN, Size: 15641 bytes --]

ksymoops 2.4.9 on i686 2.6.9-rc4-mm1-rt-u5.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.6.9-rc4-mm1-rt-u5/ (default)
     -m /boot/System.map-2.6.9-rc4-mm1-rt-u5 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01dae41>] down_write+0x71/0xa0
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01db07f>] up_write+0x4f/0x80
 [<c01320ac>] check_preempt_timing+0x5c/0x250
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01db07f>] up_write+0x4f/0x80
 [<c013193d>] __mcount+0x1d/0x20
 [<c01da9be>] __up_write+0xe/0x1b0
 [<c01db05f>] up_write+0x2f/0x80
 [<c0113104>] mcount+0x14/0x18
 [<c016ea97>] sys_ioctl+0x47/0x230
 [<c0106013>] syscall_call+0x7/0xb
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4b74>] avc_has_perm+0x14/0xa0
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c4ba3>] avc_has_perm+0x43/0xa0
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c01db07f>] up_write+0x4f/0x80
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b3d6>] vfs_read+0xa6/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c015b3d6>] vfs_read+0xa6/0x140
 [<c015c604>] fget_light+0x14/0xa0
 [<c0113104>] mcount+0x14/0x18
 [<c015b6e0>] sys_read+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c499b>] avc_has_perm_noaudit+0x7b/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01320ac>] check_preempt_timing+0x5c/0x250
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01183ee>] __wake_up+0x5e/0x90
 [<c01c4b74>] avc_has_perm+0x14/0xa0
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c4ba3>] avc_has_perm+0x43/0xa0
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01db07f>] up_write+0x4f/0x80
 [<c01320ac>] check_preempt_timing+0x5c/0x250
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c015c604>] fget_light+0x14/0xa0
 [<c0113104>] mcount+0x14/0x18
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4b74>] avc_has_perm+0x14/0xa0
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c4ba3>] avc_has_perm+0x43/0xa0
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01db07f>] up_write+0x4f/0x80
 [<c013193d>] __mcount+0x1d/0x20
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c01320ac>] check_preempt_timing+0x5c/0x250
 [<c0113104>] mcount+0x14/0x18
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c015c67f>] fget_light+0x8f/0xa0
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4b74>] avc_has_perm+0x14/0xa0
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c4ba3>] avc_has_perm+0x43/0xa0
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c0176db9>] inode_times_differ+0x9/0x50
 [<c0176f6f>] inode_update_time+0x9f/0xe0
 [<c0113104>] mcount+0x14/0x18
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b3d6>] vfs_read+0xa6/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c01c8a33>] selinux_file_permission+0x133/0x170
 [<c01320ac>] check_preempt_timing+0x5c/0x250
 [<c0113104>] mcount+0x14/0x18
 [<c015b3d6>] vfs_read+0xa6/0x140
 [<c015c67f>] fget_light+0x8f/0xa0
 [<c015b6e0>] sys_read+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01321ff>] check_preempt_timing+0x1af/0x250
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c0132480>] sub_preempt_count+0x60/0x90
 [<c01dafff>] up_read+0x4f/0x80
 [<c01c4b74>] avc_has_perm+0x14/0xa0
 [<c01cabcf>] selinux_ip_postroute_last+0x1bf/0x2a0
 [<c0113104>] mcount+0x14/0x18
 [<c01c4ba3>] avc_has_perm+0x43/0xa0
 [<c01cabcf>] selinux_ip_postroute_last+0x1bf/0x2a0
 [<c0113104>] mcount+0x14/0x18
 [<c01cacea>] selinux_ipv4_postroute_last+0x3a/0x40
 [<c02636d0>] ip_finish_output2+0x0/0x1f0
 [<c024fe65>] nf_iterate+0x75/0xb0
 [<c02636d0>] ip_finish_output2+0x0/0x1f0
 [<c0250280>] nf_hook_slow+0x90/0x140
 [<c02636d0>] ip_finish_output2+0x0/0x1f0
 [<c02610e3>] ip_finish_output+0x223/0x230
 [<c02636d0>] ip_finish_output2+0x0/0x1f0
 [<c0261716>] ip_queue_xmit+0x3d6/0x540
 [<c01c4bd1>] avc_has_perm+0x71/0xa0
 [<c0113104>] mcount+0x14/0x18
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01c4a02>] avc_has_perm_noaudit+0xe2/0x240
 [<c01dafff>] up_read+0x4f/0x80
 [<c013193d>] __mcount+0x1d/0x20
 [<c027842e>] tcp_v4_send_check+0xe/0xf0
 [<c0272119>] tcp_transmit_skb+0x439/0x860
 [<c0113104>] mcount+0x14/0x18
 [<c027846f>] tcp_v4_send_check+0x4f/0xf0
 [<c02721c2>] tcp_transmit_skb+0x4e2/0x860
 [<c0113104>] mcount+0x14/0x18
 [<c0274d76>] tcp_send_ack+0xa6/0xf0
 [<c026fdf4>] __tcp_ack_snd_check+0x14/0xa0
 [<c0270427>] tcp_rcv_established+0x287/0x900
 [<c013193d>] __mcount+0x1d/0x20
 [<c027965d>] tcp_v4_do_rcv+0xd/0x120
 [<c0279e7b>] tcp_v4_rcv+0x70b/0x950
 [<c0113104>] mcount+0x14/0x18
 [<c0279765>] tcp_v4_do_rcv+0x115/0x120
 [<c0279e7b>] tcp_v4_rcv+0x70b/0x950
 [<c025db75>] ip_local_deliver+0xf5/0x250
 [<c025df31>] ip_rcv+0x261/0x4c0
 [<c01dae41>] down_write+0x71/0xa0
 [<c0245570>] netif_receive_skb+0x1b0/0x280
 [<c0130008>] nanosleep_wake_up+0x18/0x20
 [<c024564e>] process_backlog+0xe/0x150
 [<c024580f>] net_rx_action+0x7f/0x150
 [<c02456c8>] process_backlog+0x88/0x150
 [<c024580f>] net_rx_action+0x7f/0x150
 [<c0120f87>] ___do_softirq+0x87/0xd0
 [<c0121058>] _do_softirq+0x8/0x30
 [<c01213a4>] ksoftirqd+0x94/0xe0
 [<c0121070>] _do_softirq+0x20/0x30
 [<c01213a4>] ksoftirqd+0x94/0xe0
 [<c013072a>] kthread+0xaa/0xb0
 [<c0121310>] ksoftirqd+0x0/0xe0
 [<c0130680>] kthread+0x0/0xb0
 [<c0104099>] kernel_thread_helper+0x5/0xc
kernel BUG at lib/rwsem-generic.c:130!
invalid operand: 0000 [#1]
CPU:    0
EIP:    0060:[<c01da56b>]    Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002   (2.6.9-rc4-mm1-rt-u5) 
eax: 00000001   ebx: f7b31658   ecx: 00000000   edx: 00000001
esi: 00000000   edi: f7b31658   ebp: d3113f34   esp: d3113f28
ds: 007b   es: 007b   ss: 0068   preempt: 00000002
Stack: f7b31658 00000202 d3113fa8 d3113f48 c01db057 f7b31658 f741ac00 d74036c0 
       d3113f64 f88c1c18 d3113f64 c0113104 00000000 f88c1be0 d74036c0 d3113f90 
       c015b61b d74036c0 080d77f8 00000800 d3113fa8 f0d94164 f0d94164 d74036c0 
Call Trace:
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
Warning (Oops_read): Code line not seen, dumping what data is available


>>EIP; c01da56b <rwsem_owner_del+6b/90>   <=====

>>ebx; f7b31658 <pg0+37735658/3fc02400>
>>edi; f7b31658 <pg0+37735658/3fc02400>
>>ebp; d3113f34 <pg0+12d17f34/3fc02400>
>>esp; d3113f28 <pg0+12d17f28/3fc02400>

Trace; c01db057 <up_write+27/80>
Trace; f88c1c18 <pg0+384c5c18/3fc02400>
Trace; c0113104 <mcount+14/18>
Trace; f88c1be0 <pg0+384c5be0/3fc02400>
Trace; c015b61b <vfs_write+cb/140>
Trace; c015b760 <sys_write+50/80>
Trace; c0106013 <syscall_call+7/b>

Code: 16 bb 00 f0 ff ff 21 e3 8b 44 8f 10 3b 03 74 28 41 89 d6 39 d1 7c f1 8b 15 b8 fe 2e c0 85 d2 74 12 c7 05 b8 fe 2e c0 00 00 00 00 <0f> 0b 82 00 e1 05 2c c0 5b 5e 5f c9 c3 8d 56 ff 39 d1 74 08 8b 


This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.

Code;  c01da540 <rwsem_owner_del+40/90>
00000000 <_EIP>:
Code;  c01da540 <rwsem_owner_del+40/90>
   0:   16                        push   %ss
Code;  c01da541 <rwsem_owner_del+41/90>
   1:   bb 00 f0 ff ff            mov    $0xfffff000,%ebx
Code;  c01da546 <rwsem_owner_del+46/90>
   6:   21 e3                     and    %esp,%ebx
Code;  c01da548 <rwsem_owner_del+48/90>
   8:   8b 44 8f 10               mov    0x10(%edi,%ecx,4),%eax
Code;  c01da54c <rwsem_owner_del+4c/90>
   c:   3b 03                     cmp    (%ebx),%eax
Code;  c01da54e <rwsem_owner_del+4e/90>
   e:   74 28                     je     38 <_EIP+0x38>
Code;  c01da550 <rwsem_owner_del+50/90>
  10:   41                        inc    %ecx
Code;  c01da551 <rwsem_owner_del+51/90>
  11:   89 d6                     mov    %edx,%esi
Code;  c01da553 <rwsem_owner_del+53/90>
  13:   39 d1                     cmp    %edx,%ecx
Code;  c01da555 <rwsem_owner_del+55/90>
  15:   7c f1                     jl     8 <_EIP+0x8>
Code;  c01da557 <rwsem_owner_del+57/90>
  17:   8b 15 b8 fe 2e c0         mov    0xc02efeb8,%edx
Code;  c01da55d <rwsem_owner_del+5d/90>
  1d:   85 d2                     test   %edx,%edx
Code;  c01da55f <rwsem_owner_del+5f/90>
  1f:   74 12                     je     33 <_EIP+0x33>
Code;  c01da561 <rwsem_owner_del+61/90>
  21:   c7 05 b8 fe 2e c0 00      movl   $0x0,0xc02efeb8
Code;  c01da568 <rwsem_owner_del+68/90>
  28:   00 00 00 

This decode from eip onwards should be reliable

Code;  c01da56b <rwsem_owner_del+6b/90>
00000000 <_EIP>:
Code;  c01da56b <rwsem_owner_del+6b/90>
   0:   0f 0b                     ud2a   
Code;  c01da56d <rwsem_owner_del+6d/90>
   2:   82                        (bad)  
Code;  c01da56e <rwsem_owner_del+6e/90>
   3:   00 e1                     add    %ah,%cl
Code;  c01da570 <rwsem_owner_del+70/90>
   5:   05 2c c0 5b 5e            add    $0x5e5bc02c,%eax
Code;  c01da575 <rwsem_owner_del+75/90>
   a:   5f                        pop    %edi
Code;  c01da576 <rwsem_owner_del+76/90>
   b:   c9                        leave  
Code;  c01da577 <rwsem_owner_del+77/90>
   c:   c3                        ret    
Code;  c01da578 <rwsem_owner_del+78/90>
   d:   8d 56 ff                  lea    0xffffffff(%esi),%edx
Code;  c01da57b <rwsem_owner_del+7b/90>
  10:   39 d1                     cmp    %edx,%ecx
Code;  c01da57d <rwsem_owner_del+7d/90>
  12:   74 08                     je     1c <_EIP+0x1c>
Code;  c01da57f <rwsem_owner_del+7f/90>
  14:   8b                        .byte 0x8b

 [<c0119582>] __might_sleep+0xc2/0xe0
 [<c0119bce>] mm_release+0x6e/0xd0
 [<c011c4dd>] printk+0x1d/0x20
 [<c011e6d3>] do_exit+0x83/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c02a2ab9>] __sched_text_start+0x539/0x570
 [<c02a31c2>] cond_resched+0x62/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c02a31c2>] cond_resched+0x62/0x90
 [<c0119bd3>] mm_release+0x73/0xd0
 [<c011c4dd>] printk+0x1d/0x20
 [<c011e6d3>] do_exit+0x83/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb
 [<c02a2ab9>] __sched_text_start+0x539/0x570
 [<c011e8e2>] do_exit+0x292/0x4a0
 [<c0113104>] mcount+0x14/0x18
 [<c011e8e2>] do_exit+0x292/0x4a0
 [<c01075f0>] do_invalid_op+0x0/0x110
 [<c0107242>] die+0x192/0x1a0
 [<c0116c5c>] fixup_exception+0x1c/0x40
 [<c01076f6>] do_invalid_op+0x106/0x110
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c0113104>] mcount+0x14/0x18
 [<c01c6064>] inode_has_perm+0x64/0x90
 [<c013193d>] __mcount+0x1d/0x20
 [<c01c890e>] selinux_file_permission+0xe/0x170
 [<c015b5f3>] vfs_write+0xa3/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0106a25>] error_code+0x2d/0x38
 [<c01da56b>] rwsem_owner_del+0x6b/0x90
 [<c01db057>] up_write+0x27/0x80
 [<f88c1c18>] snd_pcm_oss_write+0x38/0x70 [snd_pcm_oss]
 [<c0113104>] mcount+0x14/0x18
 [<f88c1be0>] snd_pcm_oss_write+0x0/0x70 [snd_pcm_oss]
 [<c015b61b>] vfs_write+0xcb/0x140
 [<c015b760>] sys_write+0x50/0x80
 [<c0106013>] syscall_call+0x7/0xb

2 warnings and 1 error issued.  Results may not be reliable.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
                                         ` (5 preceding siblings ...)
  2004-10-19  1:27                       ` Adam Heath
@ 2004-10-19  8:09                       ` Thomas Gleixner
  2004-10-19  8:12                       ` Thomas Gleixner
                                         ` (3 subsequent siblings)
  10 siblings, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19  8:09 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

On Mon, 2004-10-18 at 16:50, Ingo Molnar wrote:
> i have released the -U5 Real-Time Preemption patch:
> 

starting nfsd triggers the deadlock detection, but it's not really a
deadlock.

The first nfsd thread acquires nlmsvc_sema. The other 7 nfsd threads
wait on it. The first thread creates lockd and tries to get lockd_start,
which is initialized locked and will be released when the lockd thread
starts. The deadlock complains about a deadlock on nlmsvc_sema inside of
down(&lockd_start). ?

Converting lockd_start to a waitqueue solves the problem and is more
sane, than the locked mutex.

tglx

--- 2.6.9-rc4-mm1-RT-U5/fs/lockd/svc.c.orig     2004-10-19
10:02:17.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U5/fs/lockd/svc.c  2004-10-19 09:54:22.000000000
+0200
@@ -46,7 +46,7 @@
 int                            nlmsvc_grace_period;
 unsigned long                  nlmsvc_timeout;

-static DECLARE_MUTEX(lockd_start);
+static DECLARE_WAIT_QUEUE_HEAD(lockd_start);
 static DECLARE_WAIT_QUEUE_HEAD(lockd_exit);

 /*
@@ -109,7 +109,7 @@
         * Let our maker know we're running.
         */
        nlmsvc_pid = current->pid;
-       up(&lockd_start);
+       wake_up(&lockd_start);

        daemonize("lockd");

@@ -230,6 +230,7 @@
                printk(KERN_WARNING
                        "lockd_up: no pid, %d users??\n", nlmsvc_users);

+
        error = -ENOMEM;
        serv = svc_create(&nlmsvc_program, LOCKD_BUFSIZE);
        if (!serv) {
@@ -258,7 +259,19 @@
                        "lockd_up: create thread failed, error=%d\n",
error);
                goto destroy_and_out;
        }
-       down(&lockd_start);
+       /*
+        * Wait for the lockd process to start, but since we're holding
+        * the lockd semaphore, we can't wait around forever ...
+        */
+       clear_thread_flag(TIF_SIGPENDING);
+       interruptible_sleep_on_timeout(&lockd_start, HZ);
+       if (!nlmsvc_pid) {
+               printk(KERN_WARNING
+                       "lockd_down: lockd failed to start\n");
+       }
+       spin_lock_irq(&current->sighand->siglock);
+       recalc_sigpending();
+       spin_unlock_irq(&current->sighand->siglock);

        /*
         * Note: svc_serv structures have an initial use count of 1,
@@ -423,7 +436,6 @@

 static int __init init_nlm(void)
 {
-       init_MUTEX_LOCKED(&lockd_start);
        nlm_sysctl_table = register_sysctl_table(nlm_sysctl_root, 0);
        return nlm_sysctl_table ? 0 : -ENOMEM;
 }


Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
 mountdBUG: semaphore deadlock detected!
.. task nfsd/1246 is holding c89f4560.
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
       00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
       00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
Call Trace:
 [<c0117fc7>] copy_process+0x5f7/0xc30
 [<c01c4e62>] __delay+0x12/0x20
 [<c01fe460>] serial8250_console_write+0x170/0x280
 [<c011930e>] __call_console_drivers+0x5e/0x60
 [<c011982a>] release_console_sem+0xda/0xe0
 [<c01196a7>] vprintk+0x107/0x160
 [<c01196a7>] vprintk+0x107/0x160
 [<c012a3ae>] __kernel_text_address+0x2e/0x40
 [<c0106bf5>] show_trace+0x35/0x90
 [<c0106bf5>] show_trace+0x35/0x90
 [<c0106cd0>] show_stack+0x80/0xa0
 [<c01c2976>] __rwsem_deadlock+0x136/0x180
 [<c01c28aa>] __rwsem_deadlock+0x6a/0x180
 [<c02c3c33>] __down_write+0x93/0x170
 [<c01c3033>] down_write+0x43/0x80
 [<c89e661d>] lockd_up+0x9d/0x120 [lockd]
 [<c89e62e0>] lockd+0x0/0x2a0 [lockd]
 [<c883d2e1>] nfsd+0x91/0x380 [nfsd]
 [<c0105e12>] ret_from_fork+0x6/0x14
 [<c883d250>] nfsd+0x0/0x380 [nfsd]
 [<c0103ffd>] kernel_thread_helper+0x5/0x18
...#0 task nfsd/1246 is holding c89f4560.
BUG: semaphore deadlock: nfsd/1252 is blocked on c89f4560, deadlocking
nfsd/1246
c733df60 00000046 c7adad10 c03d6060 00000000 00000000 00000000 00000000
       00000000 00000000 c7a306f0 00005b6e 39133ac7 0000001a c7adae6c
c7adad10
       c7adad10 c7584400 00000000 c02c3cad c89f4560 c6853f6c c6819f6c
c7adad10
Call Trace:
 [<c02c3cad>] __down_write+0x10d/0x170
 [<c01c3033>] down_write+0x43/0x80
 [<c89e6591>] lockd_up+0x11/0x120 [lockd]
 [<c883d250>] nfsd+0x0/0x380 [nfsd]
 [<c883d2e1>] nfsd+0x91/0x380 [nfsd]
 [<c0105e12>] ret_from_fork+0x6/0x14
 [<c883d250>] nfsd+0x0/0x380 [nfsd]
 [<c0103ffd>] kernel_thread_helper+0x5/0x18
------------[ cut here ]------------



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
                                         ` (6 preceding siblings ...)
  2004-10-19  8:09                       ` Thomas Gleixner
@ 2004-10-19  8:12                       ` Thomas Gleixner
  2004-10-19  9:04                         ` Ingo Molnar
  2004-10-19 10:34                       ` Michal Schmidt
                                         ` (2 subsequent siblings)
  10 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19  8:12 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

On Mon, 2004-10-18 at 16:50, Ingo Molnar wrote:
> i have released the -U5 Real-Time Preemption patch:

All sleep_on variants trigger the irqs_disabled() check in schedule(). 
tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-19  9:04                         ` Ingo Molnar
@ 2004-10-19  9:03                           ` Thomas Gleixner
  2004-10-19  9:34                             ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19  9:03 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

On Tue, 2004-10-19 at 11:04, Ingo Molnar wrote:
> > All sleep_on variants trigger the irqs_disabled() check in schedule(). 
> > tglx
> 
> ah, forgot that the waitqueue lock is a raw lock. Is there _any_
> scenario where sleep_on() is actually correct kernel code?

Hmm, the sleep_on() variants are used quite a lot over the kernel. Whats
wrong with them and to what should they be converted ?

tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-19  8:12                       ` Thomas Gleixner
@ 2004-10-19  9:04                         ` Ingo Molnar
  2004-10-19  9:03                           ` Thomas Gleixner
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19  9:04 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML


* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Mon, 2004-10-18 at 16:50, Ingo Molnar wrote:
> > i have released the -U5 Real-Time Preemption patch:
> 
> All sleep_on variants trigger the irqs_disabled() check in schedule(). 
> tglx

ah, forgot that the waitqueue lock is a raw lock. Is there _any_
scenario where sleep_on() is actually correct kernel code?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-19  9:03                           ` Thomas Gleixner
@ 2004-10-19  9:34                             ` Ingo Molnar
  2004-10-19  9:50                               ` Ingo Molnar
  2004-10-19 10:12                               ` Thomas Gleixner
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19  9:34 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML


* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Tue, 2004-10-19 at 11:04, Ingo Molnar wrote:
> > > All sleep_on variants trigger the irqs_disabled() check in schedule(). 
> > > tglx
> > 
> > ah, forgot that the waitqueue lock is a raw lock. Is there _any_
> > scenario where sleep_on() is actually correct kernel code?
> 
> Hmm, the sleep_on() variants are used quite a lot over the kernel.
> Whats wrong with them and to what should they be converted ?

they are racy on SMP. It does:

	current->state = TASK_INTERRUPTIBLE;

	schedule();

which is almost always a bug to go to sleep via sleep_on() _after_
checking for the condition, because the following could happen:

	CPU1				CPU2

	if (condition)
		goto done;

					wake_up(&waitqueue);

	current->state = TASK_INTERRUPTIBLE;

	schedule();

The proper interface is wait_event() (and variants).

your patch probably only works due to timing - the wakeup always happens
after sleep_on() has been called.

this particular NFS case is probably only correct due to userspace
behavior. The code is apparently relying on the wake_up() never
happening _before_ we do the sleep_on().

so, could you try the init_MUTEX_LOCKED() fix plus the patch below -
does that turn off the deadlock assert? (Plus also uncomment the
RWSEM_BUG() around line 130.)

	Ingo

--- linux/lib/rwsem-generic.c.orig
+++ linux/lib/rwsem-generic.c
@@ -750,6 +750,15 @@ void fastcall sema_init(struct semaphore
 	case 0:
 		init_rwsem(&sem->lock);
 		down(sem);
+#ifdef CONFIG_RWSEM_DEADLOCK_DETECT
+		{
+			unsigned long flags;
+
+			rwsem_lock_irqsave(&rwsem_lock, flags);
+			rwsem_owner_del(&sem->lock);
+			rwsem_unlock_irqrestore(&rwsem_lock, flags);
+		}
+#endif
 		break;
 	default:
 		RWSEM_BUG();

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-19  9:34                             ` Ingo Molnar
@ 2004-10-19  9:50                               ` Ingo Molnar
  2004-10-19 10:12                               ` Thomas Gleixner
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19  9:50 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML


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

> so, could you try the init_MUTEX_LOCKED() fix plus the patch below -
> does that turn off the deadlock assert? (Plus also uncomment the
> RWSEM_BUG() around line 130.)

but i agree with you that this semaphore (ab-)use in the NFS code should
be fixed. Best would be to use a completion, but unfortunately there's
no wait_for_completion_timeout() API right now.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-19  9:34                             ` Ingo Molnar
  2004-10-19  9:50                               ` Ingo Molnar
@ 2004-10-19 10:12                               ` Thomas Gleixner
  2004-10-19 11:07                                 ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 10:12 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

On Tue, 2004-10-19 at 11:34, Ingo Molnar wrote:
> > Hmm, the sleep_on() variants are used quite a lot over the kernel.
> > Whats wrong with them and to what should they be converted ?
> 
> they are racy on SMP. It does:
> The proper interface is wait_event() (and variants).

Sorry for beeing stupid. I remebered the wait_event stuff immidiately
after hitting send (:

> your patch probably only works due to timing - the wakeup always happens
> after sleep_on() has been called.
> 
> this particular NFS case is probably only correct due to userspace
> behavior. The code is apparently relying on the wake_up() never
> happening _before_ we do the sleep_on().

Correct fix appended. I think it's more sane than the locked mutex, as
we actually come back if lockd is not started for any reason.

> so, could you try the init_MUTEX_LOCKED() fix plus the patch below -
> does that turn off the deadlock assert? (Plus also uncomment the
> RWSEM_BUG() around line 130.)

Yep, that fixes the problem

tglx

--- 2.6.9-rc4-mm1-RT-U5/fs/lockd/svc.c.orig 2004-10-19
10:02:17.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U5/fs/lockd/svc.c     2004-10-19 11:34:12.000000000
+0200
@@ -46,7 +46,7 @@
 int                            nlmsvc_grace_period;
 unsigned long                  nlmsvc_timeout;

-static DECLARE_MUTEX(lockd_start);
+static DECLARE_WAIT_QUEUE_HEAD(lockd_start);
 static DECLARE_WAIT_QUEUE_HEAD(lockd_exit);

 /*
@@ -109,7 +109,7 @@
         * Let our maker know we're running.
         */
        nlmsvc_pid = current->pid;
-       up(&lockd_start);
+       wake_up(&lockd_start);

        daemonize("lockd");

@@ -230,6 +230,7 @@
                printk(KERN_WARNING
                        "lockd_up: no pid, %d users??\n", nlmsvc_users);

+
        error = -ENOMEM;
        serv = svc_create(&nlmsvc_program, LOCKD_BUFSIZE);
        if (!serv) {
@@ -258,8 +259,15 @@
                        "lockd_up: create thread failed, error=%d\n",
error);
                goto destroy_and_out;
        }
-       down(&lockd_start);
-
+       /*
+        * Wait for the lockd process to start, but since we're holding
+        * the lockd semaphore, we can't wait around forever ...
+        */
+       if (wait_event_interruptible_timeout(lockd_start,
+                                            nlmsvc_pid != 0, HZ)) {
+               printk(KERN_WARNING
+                       "lockd_down: lockd failed to start\n");
+       }
        /*
         * Note: svc_serv structures have an initial use count of 1,
         * so we exit through here on both success and failure.
@@ -298,16 +306,12 @@
         * Wait for the lockd process to exit, but since we're holding
         * the lockd semaphore, we can't wait around forever ...
         */
-       clear_thread_flag(TIF_SIGPENDING);
-       interruptible_sleep_on_timeout(&lockd_exit, HZ);
-       if (nlmsvc_pid) {
+       if (wait_event_interruptible_timeout(lockd_exit,
+                                            nlmsvc_pid == 0, HZ)) {
                printk(KERN_WARNING
                        "lockd_down: lockd failed to exit, clearing
pid\n");
                nlmsvc_pid = 0;
        }
-       spin_lock_irq(&current->sighand->siglock);
-       recalc_sigpending();
-       spin_unlock_irq(&current->sighand->siglock);
 out:
        up(&nlmsvc_sema);
 }
@@ -423,7 +427,6 @@

 static int __init init_nlm(void)
 {
-       init_MUTEX_LOCKED(&lockd_start);
        nlm_sysctl_table = register_sysctl_table(nlm_sysctl_root, 0);
        return nlm_sysctl_table ? 0 : -ENOMEM;
 }




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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
                                         ` (7 preceding siblings ...)
  2004-10-19  8:12                       ` Thomas Gleixner
@ 2004-10-19 10:34                       ` Michal Schmidt
  2004-10-19 12:46                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Ingo Molnar
  2004-10-19 12:57                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Kevin Hilman
  10 siblings, 0 replies; 951+ messages in thread
From: Michal Schmidt @ 2004-10-19 10:34 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

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

Ingo Molnar wrote:
> there are two big changes:
> 
>  - debug feature: automatic semaphore/rwsem deadlock detection, based on
>    the code from Igor Manyilov and Bill Huey.
> 
> this is a very nice feature that should help in debugging the remaining
> deadlocks. The deadlock detection feature has already helped me fix a
> bug that was causing hangs in the VFS, so it's really useful.

I can trigger the deadlock detection when I try to ping my default 
gateway. I'm attaching the log from dmesg.

Michal

[-- Attachment #2: ping-deadlock.txt --]
[-- Type: text/plain, Size: 11700 bytes --]

BUG: semaphore deadlock detected!
.. task ksoftirqd/0/2 is holding c04019c4.
0000012c 00000001 c14f4000 00000000 c14f5f9c c011e713 c03a36b8 c011e7d9 
       c011eb18 0000000a c03a36b8 c14f4000 c14f4000 00000000 c14f5fa4 c011e7f1 
       c14f5fbc c011eb18 00000001 fffffff6 c14f4000 c14e3f70 c14f5fec c012d333 
Call Trace:
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127)
.. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97)
.. entry 3: print_traces+0x1d/0x56 / (show_stack+0x85/0x9b)

...#0 task ksoftirqd/0/2 is holding c04019c4.
------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:416!
invalid operand: 0000 [#1]
PREEMPT 
Modules linked in: ipt_REJECT ipt_pkttype ipt_LOG ipt_state ipt_multiport ipt_conntrack iptable_mangle ip_nat_irc ip_nat_tftp ip_nat_ftp iptable_nat ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp ip_conntrack iptable_filter ip_tables af_packet 8139too 8139cp mii crc32 e1000 snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc ehci_hcd usbhid uhci_hcd usbcore intel_mch_agp intel_agp evdev nls_iso8859_1 nls_cp437 vfat fat dm_mod floppy ide_cd cdrom psmouse unix
CPU:    0
EIP:    0060:[<c0289aca>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-RT-U5) 
EIP is at __down_write+0xad/0x190
eax: 00000001   ebx: c14e0d20   ecx: 00000000   edx: c14f4000
esi: c04019c4   edi: dff1b080   ebp: c14f5d64   esp: c14f5d48
ds: 007b   es: 007b   ss: 0068   preempt: 00000003
Process ksoftirqd/0 (pid: 2, threadinfo=c14f4000 task=c14e0d20)
Stack: c04019c4 c04019c8 c04019c8 c14e0d20 00000002 c14f4000 c04019c4 c14f5d7c 
       c01b33c8 c04019c4 c14e0d20 dec0f000 df59a000 c14f5da0 c02364c5 c04019c0 
       00000202 c14f5da0 df59a000 dec0f000 df59a000 df59a358 c14f5dc4 c02420cd 
Call Trace:
 [<c01b33c8>] down_write+0x52/0x97
 [<c02364c5>] dev_queue_xmit_nit+0x41/0x127
 [<c02420cd>] qdisc_restart+0x182/0x1ac
 [<c0236964>] dev_queue_xmit+0x194/0x230
 [<c023c3e3>] neigh_resolve_output+0xf1/0x1e5
 [<c023bf8d>] neigh_update+0x2c3/0x368
 [<c0272642>] arp_process+0x1f8/0x5ac
 [<c01132d0>] mcount+0x14/0x18
 [<c0272a0a>] arp_rcv+0x14/0x155
 [<c0236e14>] netif_receive_skb+0x10f/0x1ab
 [<c0241c7e>] eth_type_trans+0xe/0xc8
 [<e097582f>] rtl8139_rx+0x185/0x326 [8139too]
 [<e0975bbb>] rtl8139_poll+0x5d/0xfe [8139too]
 [<c023707b>] net_rx_action+0x7c/0x143
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb
preempt count: 00000004
. 4-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127)
.. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97)
.. entry 3: die+0x3f/0x196 / (do_invalid_op+0x106/0x108)
.. entry 4: print_traces+0x1d/0x56 / (show_stack+0x85/0x9b)

Code: 10 89 45 ec 89 34 24 e8 47 90 f2 ff 89 34 24 e8 04 91 f2 ff 85 c0 74 1b a1 58 36 2d c0 85 c0 74 12 c7 05 58 36 2d c0 00 00 00 00 <0f> 0b a0 01 2f 32 2a c0 89 b3 70 06 00 00 9c 58 c1 e8 09 83 f0 
 <3>BUG: sleeping function called from invalid context ksoftirqd/0(2) at lib/rwsem-generic.c:593
in_atomic():1 [00000002], irqs_disabled():0
 [<c0116e6c>] __might_sleep+0xc4/0xd6
 [<c01b3275>] down_read+0x27/0x96
 [<c011a353>] profile_task_exit+0x1b/0x43
 [<c01132d0>] mcount+0x14/0x18
 [<c011bfbf>] do_exit+0x1f/0x4a3
 [<c0105e9a>] do_invalid_op+0x0/0x108
 [<c0105af8>] do_divide_error+0x0/0x132
 [<c0114a1c>] fixup_exception+0x1c/0x38
 [<c0105fa0>] do_invalid_op+0x106/0x108
 [<c01132d0>] mcount+0x14/0x18
 [<c0289aca>] __down_write+0xad/0x190
 [<c0119e3b>] release_console_sem+0xa7/0xfe
 [<c0119ce2>] vprintk+0x116/0x179
 [<c0105309>] error_code+0x2d/0x38
 [<c0289aca>] __down_write+0xad/0x190
 [<c01b33c8>] down_write+0x52/0x97
 [<c02364c5>] dev_queue_xmit_nit+0x41/0x127
 [<c02420cd>] qdisc_restart+0x182/0x1ac
 [<c0236964>] dev_queue_xmit+0x194/0x230
 [<c023c3e3>] neigh_resolve_output+0xf1/0x1e5
 [<c023bf8d>] neigh_update+0x2c3/0x368
 [<c0272642>] arp_process+0x1f8/0x5ac
 [<c01132d0>] mcount+0x14/0x18
 [<c0272a0a>] arp_rcv+0x14/0x155
 [<c0236e14>] netif_receive_skb+0x10f/0x1ab
 [<c0241c7e>] eth_type_trans+0xe/0xc8
 [<e097582f>] rtl8139_rx+0x185/0x326 [8139too]
 [<e0975bbb>] rtl8139_poll+0x5d/0xfe [8139too]
 [<c023707b>] net_rx_action+0x7c/0x143
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127)
.. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97)
.. entry 3: print_traces+0x1d/0x56 / (dump_stack+0x23/0x27)

BUG: scheduling while atomic: ksoftirqd/0/0x04000002/2
caller is cond_resched+0x62/0x82
 [<c0288df2>] __sched_text_start+0x53e/0x571
 [<c02894c4>] cond_resched+0x62/0x82
 [<c01132d0>] mcount+0x14/0x18
 [<c02894c4>] cond_resched+0x62/0x82
 [<c01b327a>] down_read+0x2c/0x96
 [<c011a353>] profile_task_exit+0x1b/0x43
 [<c01132d0>] mcount+0x14/0x18
 [<c011bfbf>] do_exit+0x1f/0x4a3
 [<c0105e9a>] do_invalid_op+0x0/0x108
 [<c0105af8>] do_divide_error+0x0/0x132
 [<c0114a1c>] fixup_exception+0x1c/0x38
 [<c0105fa0>] do_invalid_op+0x106/0x108
 [<c01132d0>] mcount+0x14/0x18
 [<c0289aca>] __down_write+0xad/0x190
(ksoftirqd/0/2/CPU#0): new 856 us maximum-latency critical section.
 => started at timestamp 144481672: <__call_console_drivers+0x19/0x65>
 =>   ended at timestamp 144482528: <call_console_drivers+0x9e/0x13f>
 [<c012ec10>] touch_preempt_timing+0x3d/0x41
 [<c012eb37>] check_preempt_timing+0x1b2/0x24e
 [<c0119a54>] call_console_drivers+0x9e/0x13f
 [<c012ec10>] touch_preempt_timing+0x3d/0x41
 [<c0119a54>] call_console_drivers+0x9e/0x13f
 [<c0119a54>] call_console_drivers+0x9e/0x13f
 [<c0288edb>] preempt_schedule+0x11/0x7a
 [<c0119e04>] release_console_sem+0x70/0xfe
 [<c0119ce2>] vprintk+0x116/0x179
 [<c0289aca>] __down_write+0xad/0x190
 [<c0119bc8>] printk+0x1d/0x21
 [<c01055f8>] show_trace+0x78/0xb2
 [<c0289aca>] __down_write+0xad/0x190
 [<c01056f0>] dump_stack+0x23/0x27
 [<c0288df2>] __sched_text_start+0x53e/0x571
 [<c02894c4>] cond_resched+0x62/0x82
 [<c01132d0>] mcount+0x14/0x18
 [<c02894c4>] cond_resched+0x62/0x82
 [<c01b327a>] down_read+0x2c/0x96
 [<c011a353>] profile_task_exit+0x1b/0x43
 [<c01132d0>] mcount+0x14/0x18
 [<c011bfbf>] do_exit+0x1f/0x4a3
 [<c0105e9a>] do_invalid_op+0x0/0x108
 [<c0105af8>] do_divide_error+0x0/0x132
 [<c0114a1c>] fixup_exception+0x1c/0x38
 [<c0105fa0>] do_invalid_op+0x106/0x108
 [<c01132d0>] mcount+0x14/0x18
 [<c0289aca>] __down_write+0xad/0x190
 [<c0119e3b>] release_console_sem+0xa7/0xfe
 [<c0119ce2>] vprintk+0x116/0x179
 [<c0105309>] error_code+0x2d/0x38
 [<c0289aca>] __down_write+0xad/0x190
 [<c01b33c8>] down_write+0x52/0x97
 [<c02364c5>] dev_queue_xmit_nit+0x41/0x127
 [<c02420cd>] qdisc_restart+0x182/0x1ac
 [<c0236964>] dev_queue_xmit+0x194/0x230
 [<c023c3e3>] neigh_resolve_output+0xf1/0x1e5
 [<c023bf8d>] neigh_update+0x2c3/0x368
 [<c0272642>] arp_process+0x1f8/0x5ac
 [<c01132d0>] mcount+0x14/0x18
 [<c0272a0a>] arp_rcv+0x14/0x155
 [<c0236e14>] netif_receive_skb+0x10f/0x1ab
 [<c0241c7e>] eth_type_trans+0xe/0xc8
 [<e097582f>] rtl8139_rx+0x185/0x326 [8139too]
 [<e0975bbb>] rtl8139_poll+0x5d/0xfe [8139too]
 [<c023707b>] net_rx_action+0x7c/0x143
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb
preempt count: 04000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127)
.. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97)
.. entry 3: print_traces+0x1d/0x56 / (dump_stack+0x23/0x27)

 =>   dump-end timestamp 144483248

 [<c0119e3b>] release_console_sem+0xa7/0xfe
 [<c0119ce2>] vprintk+0x116/0x179
 [<c0105309>] error_code+0x2d/0x38
 [<c0289aca>] __down_write+0xad/0x190
 [<c01b33c8>] down_write+0x52/0x97
 [<c02364c5>] dev_queue_xmit_nit+0x41/0x127
 [<c02420cd>] qdisc_restart+0x182/0x1ac
 [<c0236964>] dev_queue_xmit+0x194/0x230
 [<c023c3e3>] neigh_resolve_output+0xf1/0x1e5
 [<c023bf8d>] neigh_update+0x2c3/0x368
 [<c0272642>] arp_process+0x1f8/0x5ac
 [<c01132d0>] mcount+0x14/0x18
 [<c0272a0a>] arp_rcv+0x14/0x155
 [<c0236e14>] netif_receive_skb+0x10f/0x1ab
 [<c0241c7e>] eth_type_trans+0xe/0xc8
 [<e097582f>] rtl8139_rx+0x185/0x326 [8139too]
 [<e0975bbb>] rtl8139_poll+0x5d/0xfe [8139too]
 [<c023707b>] net_rx_action+0x7c/0x143
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb
preempt count: 04000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127)
.. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97)
.. entry 3: print_traces+0x1d/0x56 / (dump_stack+0x23/0x27)

note: ksoftirqd/0[2] exited with preempt_count 2
BUG: scheduling while atomic: ksoftirqd/0/0x00000002/2
caller is do_exit+0x2a7/0x4a3
 [<c0288df2>] __sched_text_start+0x53e/0x571
 [<c011c247>] do_exit+0x2a7/0x4a3
 [<c01132d0>] mcount+0x14/0x18
 [<c011c247>] do_exit+0x2a7/0x4a3
 [<c0105e9a>] do_invalid_op+0x0/0x108
 [<c0105af8>] do_divide_error+0x0/0x132
 [<c0114a1c>] fixup_exception+0x1c/0x38
 [<c0105fa0>] do_invalid_op+0x106/0x108
 [<c01132d0>] mcount+0x14/0x18
 [<c0289aca>] __down_write+0xad/0x190
 [<c0119e3b>] release_console_sem+0xa7/0xfe
 [<c0119ce2>] vprintk+0x116/0x179
 [<c0105309>] error_code+0x2d/0x38
 [<c0289aca>] __down_write+0xad/0x190
 [<c01b33c8>] down_write+0x52/0x97
 [<c02364c5>] dev_queue_xmit_nit+0x41/0x127
 [<c02420cd>] qdisc_restart+0x182/0x1ac
 [<c0236964>] dev_queue_xmit+0x194/0x230
 [<c023c3e3>] neigh_resolve_output+0xf1/0x1e5
 [<c023bf8d>] neigh_update+0x2c3/0x368
 [<c0272642>] arp_process+0x1f8/0x5ac
 [<c01132d0>] mcount+0x14/0x18
 [<c0272a0a>] arp_rcv+0x14/0x155
 [<c0236e14>] netif_receive_skb+0x10f/0x1ab
 [<c0241c7e>] eth_type_trans+0xe/0xc8
 [<e097582f>] rtl8139_rx+0x185/0x326 [8139too]
 [<e0975bbb>] rtl8139_poll+0x5d/0xfe [8139too]
 [<c023707b>] net_rx_action+0x7c/0x143
 [<c011e713>] ___do_softirq+0x83/0xc8
 [<c011e7d9>] _do_softirq+0x8/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c011e7f1>] _do_softirq+0x20/0x22
 [<c011eb18>] ksoftirqd+0x93/0xd1
 [<c012d333>] kthread+0xaa/0xaf
 [<c011ea85>] ksoftirqd+0x0/0xd1
 [<c012d289>] kthread+0x0/0xaf
 [<c01032f1>] kernel_thread_helper+0x5/0xb
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x95/0x97 / (dev_queue_xmit_nit+0x41/0x127)
.. entry 2: __down_write+0x43/0x190 / (down_write+0x52/0x97)
.. entry 3: print_traces+0x1d/0x56 / (dump_stack+0x23/0x27)


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-19 10:12                               ` Thomas Gleixner
@ 2004-10-19 11:07                                 ` Ingo Molnar
  2004-10-19 11:14                                   ` Thomas Gleixner
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 11:07 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML


* Thomas Gleixner <tglx@linutronix.de> wrote:

> +        * Wait for the lockd process to start, but since we're holding
> +        * the lockd semaphore, we can't wait around forever ...
> +        */
> +       if (wait_event_interruptible_timeout(lockd_start,
> +                                            nlmsvc_pid != 0, HZ)) {
> +               printk(KERN_WARNING
> +                       "lockd_down: lockd failed to start\n");

yeah, this is much cleaner. I'd suggest to remove the init_sem() hack
from lib/rwsem-generic.c, it seems it is a nice facility to find
semaphore abuses.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-19 11:07                                 ` Ingo Molnar
@ 2004-10-19 11:14                                   ` Thomas Gleixner
  0 siblings, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 11:14 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

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

On Tue, 2004-10-19 at 13:07, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > +        * Wait for the lockd process to start, but since we're holding
> > +        * the lockd semaphore, we can't wait around forever ...
> > +        */
> > +       if (wait_event_interruptible_timeout(lockd_start,
> > +                                            nlmsvc_pid != 0, HZ)) {
> > +               printk(KERN_WARNING
> > +                       "lockd_down: lockd failed to start\n");
> 
> yeah, this is much cleaner. 

Cleaner, but not perfect. The return value is > 0, if the timeout is not
reached. Grmbl.

> I'd suggest to remove the init_sem() hack
> from lib/rwsem-generic.c, it seems it is a nice facility to find
> semaphore abuses.

True. Will do so.

tglx



[-- Attachment #2: svc.c.diff --]
[-- Type: text/x-patch, Size: 2084 bytes --]

--- 2.6.9-rc4-mm1-RT-U5/fs/lockd/svc.c.orig	2004-10-19 10:02:17.000000000 +0200
+++ 2.6.9-rc4-mm1-VP-U5/fs/lockd/svc.c	2004-10-19 12:59:41.000000000 +0200
@@ -46,7 +46,7 @@
 int				nlmsvc_grace_period;
 unsigned long			nlmsvc_timeout;
 
-static DECLARE_MUTEX(lockd_start);
+static DECLARE_WAIT_QUEUE_HEAD(lockd_start);
 static DECLARE_WAIT_QUEUE_HEAD(lockd_exit);
 
 /*
@@ -109,7 +109,7 @@
 	 * Let our maker know we're running.
 	 */
 	nlmsvc_pid = current->pid;
-	up(&lockd_start);
+	wake_up(&lockd_start);
 
 	daemonize("lockd");
 
@@ -230,6 +230,7 @@
 		printk(KERN_WARNING
 			"lockd_up: no pid, %d users??\n", nlmsvc_users);
 
+
 	error = -ENOMEM;
 	serv = svc_create(&nlmsvc_program, LOCKD_BUFSIZE);
 	if (!serv) {
@@ -258,8 +259,15 @@
 			"lockd_up: create thread failed, error=%d\n", error);
 		goto destroy_and_out;
 	}
-	down(&lockd_start);
-
+	/*
+	 * Wait for the lockd process to start, but since we're holding
+	 * the lockd semaphore, we can't wait around forever ...
+	 */
+	if (wait_event_interruptible_timeout(lockd_start, 
+					     nlmsvc_pid != 0, HZ) <= 0) {
+		printk(KERN_WARNING 
+			"lockd_down: lockd failed to start\n");
+	}
 	/*
 	 * Note: svc_serv structures have an initial use count of 1,
 	 * so we exit through here on both success and failure.
@@ -298,16 +306,12 @@
 	 * Wait for the lockd process to exit, but since we're holding
 	 * the lockd semaphore, we can't wait around forever ...
 	 */
-	clear_thread_flag(TIF_SIGPENDING);
-	interruptible_sleep_on_timeout(&lockd_exit, HZ);
-	if (nlmsvc_pid) {
+	if (!wait_event_interruptible_timeout(lockd_exit, 
+					     nlmsvc_pid == 0, HZ) <= 0) {
 		printk(KERN_WARNING 
 			"lockd_down: lockd failed to exit, clearing pid\n");
 		nlmsvc_pid = 0;
 	}
-	spin_lock_irq(&current->sighand->siglock);
-	recalc_sigpending();
-	spin_unlock_irq(&current->sighand->siglock);
 out:
 	up(&nlmsvc_sema);
 }
@@ -423,7 +427,6 @@
 
 static int __init init_nlm(void)
 {
-	init_MUTEX_LOCKED(&lockd_start);
 	nlm_sysctl_table = register_sysctl_table(nlm_sysctl_root, 0);
 	return nlm_sysctl_table ? 0 : -ENOMEM;
 }

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

* [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
                                         ` (8 preceding siblings ...)
  2004-10-19 10:34                       ` Michal Schmidt
@ 2004-10-19 12:46                       ` Ingo Molnar
  2004-10-19 14:46                         ` Ingo Molnar
                                           ` (5 more replies)
  2004-10-19 12:57                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Kevin Hilman
  10 siblings, 6 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 12:46 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


i have released the -U6 Real-Time Preemption patch:
 
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6

this is a fixes-only release.

found and fixed the 'big bug' that was probably the one causing
stability problems for a number of people. There was a small window for
a task double-free race to occur, causing all sorts of crashes later on.
This bug could trigger on UP and SMP systems alike, on SMP being a bit
more frequent.

Also, a common networking deadlock was found and fixed as well, using
the deadlock detector.

Changes since -U5:

- crash bug: fix task double free caused by irq-preemption of 
  do_exit(). This got introduced in -U5 as part of a simplification of
  the zombie-reaping rewrite that the -U series did. That rewrite had an 
  unrobustness which got triggered by -U5 in a subtle way, opening up a
  small window at the end of do_exit() for an interrupt-triggered
  preemption to cause a double-free. This could fix some of the crashes
  reported by Rui Nuno Capela, Mark H Johnson.

- deadlock bug: fix networking deadlock reported by Matthew L Foster.
  Restructured the way the RT-RCU locking of ptype_lock is done - it's
  cleaner and more obvious now (besides being correct). This could also
  fix the deadlock reported by Michal Schmidt.

- deadlock bug: fix NFS startup breakage related to semaphore abuse,
  patch from Thomas Gleixner.

- build bug: fix aha152x.c, based on patch from K.R. Foley.

- build bug: fix compilation error in qla2xxx. (reported by Fernando
  Pablo Lopez-Lezcano and Mark H Johnson)

- build bug: fix !PREEMPT_REALTIME compilation error. (reported by
  Matthew L Foster)

- build bug: fix ipmi-watchdog compilation error. (reported by Mark H 
  Johnson)

- tracer fix: if an assert happens within the tracer then we'd get into
  infinite recursion. The fix was to correctly nest tracing on/off
  points.

- debug enhancement: added a few more asserts to catch underflowing 
  atomic counters. (this made the task double-free trigger earlier.)

- debug enhancement: extended CONFIG_DEBUG_STACKOVERFLOW to be 
  mcount()-driven as well. This helps in catching stack overflows much
  more reliably than the do_IRQ() based method.

to create a -U6 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
                                         ` (9 preceding siblings ...)
  2004-10-19 12:46                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Ingo Molnar
@ 2004-10-19 12:57                       ` Kevin Hilman
  2004-10-19 13:04                         ` Ingo Molnar
  10 siblings, 1 reply; 951+ messages in thread
From: Kevin Hilman @ 2004-10-19 12:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt

Ingo Molnar <mingo@elte.hu> writes:

> i have released the -U5 Real-Time Preemption patch:

[...] 

> the generic semaphore implementation (which uses rwsems) makes it
> possible to use the deadlock detection mechanism for all the mutex types
> we currently have: semaphores, rw-semaphores, spinlock-mutexes and
> rwlock-mutexes. Another benefit is that PREEMPT_REALTIME becomes much
> more portable this way. (although it's still x86-only at the moment.)

Speaking of portability, is anyone yet working on ports to other
platforms?  I'm particularily interested in ARM.

If anyone has started on ARM, I'd be glad to help out.

Kevin
http://hilman.org/kevin/ 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5
  2004-10-19 12:57                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Kevin Hilman
@ 2004-10-19 13:04                         ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 13:04 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt


* Kevin Hilman <kevin@hilman.org> wrote:

> > the generic semaphore implementation (which uses rwsems) makes it
> > possible to use the deadlock detection mechanism for all the mutex types
> > we currently have: semaphores, rw-semaphores, spinlock-mutexes and
> > rwlock-mutexes. Another benefit is that PREEMPT_REALTIME becomes much
> > more portable this way. (although it's still x86-only at the moment.)
> 
> Speaking of portability, is anyone yet working on ports to other
> platforms?  I'm particularily interested in ARM.

i'll do x64 a couple of days after stability has been reached. I dont
know of any ARM efforts though.

a good starting point would be to enhance the generic-hardirqs framework
for ARM. Generic-hardirqs is a portion of the PREEMPT_REALTIME patch
that i've split out and submitted upstream, and which is expected to be
merged into 2.6.10. The generic irq subsystem makes the irq-threading
feature really simple and maintainable. So for PREEMPT_REALTIME to work
on ARM the first step is to enable generic-hardirqs on ARM. (which is
far from simple though.)

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 12:46                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Ingo Molnar
@ 2004-10-19 14:46                         ` Ingo Molnar
  2004-10-19 15:23                           ` Rui Nuno Capela
  2004-10-19 15:48                           ` Thomas Gleixner
  2004-10-19 17:22                         ` Adam Heath
                                           ` (4 subsequent siblings)
  5 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 14:46 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


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

> i have released the -U6 Real-Time Preemption patch:
>  
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6

i've re-released the patch because shortly after releasing it i found a
false-positive in the deadlock-detector that was triggering in oowriter. 

The latest patch is thus:

 $ md5sum realtime-preempt-2.6.9-rc4-mm1-U6
 9fd546bdd2d45ff1a8d5a88160135170  realtime-preempt-2.6.9-rc4-mm1-U6

if you've got the earlier one and have CONFIG_RWSEM_DEADLOCK_DETECT
enabled then please download the new patch.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 14:46                         ` Ingo Molnar
@ 2004-10-19 15:23                           ` Rui Nuno Capela
  2004-10-19 15:44                             ` Thomas Gleixner
                                               ` (2 more replies)
  2004-10-19 15:48                           ` Thomas Gleixner
  1 sibling, 3 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-19 15:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Ingo Molnar wrote:
>
>> i have released the -U6 Real-Time Preemption patch:
>>
>>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6
>

I'm experiencing terrible kernel panics at a very early bootstrap stage
while testing the U5 and U6 latest patch(es) on my laptop (P4/UP) --
(Ingo: this is about the very same trouble I've reported while pre-testing
U6).

Sorry that I can't show any trace dumps; only a hard-screenshot (with
digital camera?) would be possible but rather incomplete. The serial
console hack is not an option--these "modern" laptops doesn't come with
serial ports anymore, and netconsole is a no-op at a so early point of the
boot process. Or so I believe.

OK. After some incremental configurations, I've isolated that those
oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset (Y). My
first suspect was that newest RWSEM_DEADLOCK_DETECT, but it wasn't the
case.

So something has broken on that non-preemptible critical section timing
stuff since U4.

Hasn't anybody else stumbled on this?
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 15:23                           ` Rui Nuno Capela
@ 2004-10-19 15:44                             ` Thomas Gleixner
  2004-10-19 15:57                               ` Ingo Molnar
  2004-10-19 15:50                             ` Ingo Molnar
  2004-10-19 16:50                             ` Florian Schmidt
  2 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 15:44 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Tue, 2004-10-19 at 17:23, Rui Nuno Capela wrote:
> Ingo Molnar wrote:
> >
> >> i have released the -U6 Real-Time Preemption patch:
> >>
> >>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6
> >
> 
> I'm experiencing terrible kernel panics at a very early bootstrap stage
> while testing the U5 and U6 latest patch(es) on my laptop (P4/UP) --
> (Ingo: this is about the very same trouble I've reported while pre-testing
> U6).
> 
> Sorry that I can't show any trace dumps; only a hard-screenshot (with
> digital camera?) would be possible but rather incomplete. The serial
> console hack is not an option--these "modern" laptops doesn't come with
> serial ports anymore, and netconsole is a no-op at a so early point of the
> boot process. Or so I believe.
> 
> OK. After some incremental configurations, I've isolated that those
> oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset (Y). My
> first suspect was that newest RWSEM_DEADLOCK_DETECT, but it wasn't the
> case.

Same here on al DELL P4/UP. 

tglx




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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 14:46                         ` Ingo Molnar
  2004-10-19 15:23                           ` Rui Nuno Capela
@ 2004-10-19 15:48                           ` Thomas Gleixner
  2004-10-19 16:26                             ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 15:48 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

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

On Tue, 2004-10-19 at 16:46, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> i've re-released the patch because shortly after releasing it i found a
> false-positive in the deadlock-detector that was triggering in oowriter. 

Hit and converted another one. There are more, but they need more
modifications as they don't have a condition to wait for and therefor
must be converted to use the completion API, which must be extended to
provide completion_timemout() first.

tglx




[-- Attachment #2: clnt.c.diff --]
[-- Type: text/x-patch, Size: 534 bytes --]

diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U6/net/sunrpc/clnt.c 2.6.9-rc4-mm1-VP-U4-LRT1/net/sunrpc/clnt.c
--- 2.6.9-rc4-mm1-RT-U6/net/sunrpc/clnt.c	2004-10-12 09:32:23.000000000 +0200
+++ 2.6.9-rc4-mm1-VP-U4-LRT1/net/sunrpc/clnt.c	2004-10-19 16:16:29.000000000 +0200
@@ -231,7 +231,8 @@
 		clnt->cl_oneshot = 0;
 		clnt->cl_dead = 0;
 		rpc_killall_tasks(clnt);
-		sleep_on_timeout(&destroy_wait, 1*HZ);
+		wait_event_timeout(destroy_wait, 
+			atomic_read(&clnt->cl_users) > 0, 1*HZ);
 	}
 
 	if (atomic_read(&clnt->cl_users) < 0) {

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 15:23                           ` Rui Nuno Capela
  2004-10-19 15:44                             ` Thomas Gleixner
@ 2004-10-19 15:50                             ` Ingo Molnar
  2004-10-19 16:01                               ` K.R. Foley
  2004-10-19 16:20                               ` Ingo Molnar
  2004-10-19 16:50                             ` Florian Schmidt
  2 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 15:50 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> OK. After some incremental configurations, I've isolated that those
> oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset
> (Y). My first suspect was that newest RWSEM_DEADLOCK_DETECT, but it
> wasn't the case.
> 
> So something has broken on that non-preemptible critical section
> timing stuff since U4.
> 
> Hasn't anybody else stumbled on this?

i'm using it myself and havent seen the problem yet. Could you send me
the latest .configs, the working and the broken one too? I'll try to
reprodue it (or maybe someone else with a serial console sees it too).

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 15:44                             ` Thomas Gleixner
@ 2004-10-19 15:57                               ` Ingo Molnar
  2004-10-19 16:44                                 ` Thomas Gleixner
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 15:57 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


* Thomas Gleixner <tglx@linutronix.de> wrote:

> > Sorry that I can't show any trace dumps; only a hard-screenshot (with
> > digital camera?) would be possible but rather incomplete. The serial
> > console hack is not an option--these "modern" laptops doesn't come with
> > serial ports anymore, and netconsole is a no-op at a so early point of the
> > boot process. Or so I believe.
> > 
> > OK. After some incremental configurations, I've isolated that those
> > oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset (Y). My
> > first suspect was that newest RWSEM_DEADLOCK_DETECT, but it wasn't the
> > case.
> 
> Same here on al DELL P4/UP. 

any chance for serial logging on that box?

and does this bootup crash go away if you unset PREEMPT_TIMING or
LATENCY_TRACE, as suggested by Rui?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 15:50                             ` Ingo Molnar
@ 2004-10-19 16:01                               ` K.R. Foley
  2004-10-19 16:20                               ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-19 16:01 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

Ingo Molnar wrote:
> * Rui Nuno Capela <rncbc@rncbc.org> wrote:
> 
> 
>>OK. After some incremental configurations, I've isolated that those
>>oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset
>>(Y). My first suspect was that newest RWSEM_DEADLOCK_DETECT, but it
>>wasn't the case.
>>
>>So something has broken on that non-preemptible critical section
>>timing stuff since U4.
>>
>>Hasn't anybody else stumbled on this?
> 
> 
> i'm using it myself and havent seen the problem yet. Could you send me
> the latest .configs, the working and the broken one too? I'll try to
> reprodue it (or maybe someone else with a serial console sees it too).
> 
> 	Ingo
> 

I am seeing something similar here with both U5 and U6 on both of my SMP 
systems (actually I haven't gotten to try U6 on my SMP system at home 
yet.) On my SMP system here (dual Xeon) I get a handful of traces during 
the boot and then the last thing I see is a trace that has something to 
do with parport, but the key MIGHT be that it always seems to crap out 
when I get traces for 3-level deep critical section nesting. I will try 
to capture the trace the old-fashioned way when I get a chance shortly.

I do have U5 booted on my UP system at home though.

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 15:50                             ` Ingo Molnar
  2004-10-19 16:01                               ` K.R. Foley
@ 2004-10-19 16:20                               ` Ingo Molnar
  2004-10-19 16:28                                 ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 16:20 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


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

> > Hasn't anybody else stumbled on this?
> 
> i'm using it myself and havent seen the problem yet. Could you send me
> the latest .configs, the working and the broken one too? I'll try to
> reprodue it (or maybe someone else with a serial console sees it too).

i found older .config's from you and i tried your desktop one and it
didnt crash. But when i tried your laptop's U3 .config then i got the
bootup crash immediately. Debugging it ...

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 15:48                           ` Thomas Gleixner
@ 2004-10-19 16:26                             ` Ingo Molnar
  2004-10-19 16:39                               ` Thomas Gleixner
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 16:26 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML


* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Tue, 2004-10-19 at 16:46, Ingo Molnar wrote:
> > * Ingo Molnar <mingo@elte.hu> wrote:
> > i've re-released the patch because shortly after releasing it i found a
> > false-positive in the deadlock-detector that was triggering in oowriter. 
> 
> Hit and converted another one. There are more, but they need more
> modifications as they don't have a condition to wait for and therefor
> must be converted to use the completion API, which must be extended to
> provide completion_timemout() first.

thanks, i've applied your patch to my tree. Find below an untested
implementation of wait_for_completion_timeout().

	Ingo

--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -3070,6 +3148,31 @@ void fastcall __sched wait_for_completio
 }
 EXPORT_SYMBOL(wait_for_completion);
 
+unsigned long fastcall __sched
+wait_for_completion_timeout(struct completion *x, unsigned long timeout)
+{
+	might_sleep();
+	spin_lock_irq(&x->wait.lock);
+	if (!x->done) {
+		DECLARE_WAITQUEUE(wait, current);
+
+		wait.flags |= WQ_FLAG_EXCLUSIVE;
+		__add_wait_queue_tail(&x->wait, &wait);
+		do {
+			__set_current_state(TASK_UNINTERRUPTIBLE);
+			spin_unlock_irq(&x->wait.lock);
+			timeout = schedule_timeout(timeout);
+			spin_lock_irq(&x->wait.lock);
+		} while (!x->done);
+		__remove_wait_queue(&x->wait, &wait);
+	}
+	x->done--;
+	spin_unlock_irq(&x->wait.lock);
+
+	return timeout;
+}
+EXPORT_SYMBOL(wait_for_completion_timeout);
+
 #define	SLEEP_ON_VAR					\
 	unsigned long flags;				\
 	wait_queue_t wait;				\
--- linux/include/linux/completion.h.orig
+++ linux/include/linux/completion.h
@@ -28,6 +28,8 @@ static inline void init_completion(struc
 }
 
 extern void FASTCALL(wait_for_completion(struct completion *));
+extern unsigned long FASTCALL(wait_for_completion_timeout(struct completion *,
+							  unsigned long));
 extern void FASTCALL(complete(struct completion *));
 extern void FASTCALL(complete_all(struct completion *));
 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 16:20                               ` Ingo Molnar
@ 2004-10-19 16:28                                 ` Ingo Molnar
  2004-10-19 16:31                                   ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 16:28 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


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

> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > > Hasn't anybody else stumbled on this?
> > 
> > i'm using it myself and havent seen the problem yet. Could you send me
> > the latest .configs, the working and the broken one too? I'll try to
> > reprodue it (or maybe someone else with a serial console sees it too).
> 
> i found older .config's from you and i tried your desktop one and it
> didnt crash. But when i tried your laptop's U3 .config then i got the
> bootup crash immediately. Debugging it ...

one difference in your config is that you have 4K stacks enabled. Could
you disable them? Especially with rwsem-detection and tracing enabled
the stack footprint can get pretty large ...

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 16:28                                 ` Ingo Molnar
@ 2004-10-19 16:31                                   ` Ingo Molnar
  2004-10-19 17:17                                     ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 16:31 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


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

> > i found older .config's from you and i tried your desktop one and it
> > didnt crash. But when i tried your laptop's U3 .config then i got the
> > bootup crash immediately. Debugging it ...
> 
> one difference in your config is that you have 4K stacks enabled.
> Could you disable them? Especially with rwsem-detection and tracing
> enabled the stack footprint can get pretty large ...

indeed, this is what triggers with your .config:

 testing NMI watchdog ... OK.
 ENABLING IO-APIC IRQs
 ..TIMER: vector=0x31 pin1=2 pin2=-1
 mcount: stack overflow: 1008
  [<c012cd9f>] ___trace+0x105/0x117
  [<c012cdd7>] __mcount+0x1d/0x1f
  [<c013e015>] cache_grow+0xe/0x1ab
  [<c013e3cd>] cache_alloc_refill+0x21b/0x253

enabling 8K stacks ought to help this one. I've made the limit a bit too
conservative - there's still 1000 bytes left and the assert hits. Here's
the full trace, the large footprint seems to be in zlib initialization:

mcount: stack overflow: 1008
 [<c012cd9f>] ___trace+0x105/0x117
 [<c012cdd7>] __mcount+0x1d/0x1f
 [<c013e015>] cache_grow+0xe/0x1ab
 [<c013e3cd>] cache_alloc_refill+0x21b/0x253
 [<c010efec>] mcount+0x14/0x18
 [<c013e015>] cache_grow+0xe/0x1ab
 [<c013e3cd>] cache_alloc_refill+0x21b/0x253
 [<c013e730>] __kmalloc+0x82/0x9f
 [<c03607c8>] malloc+0x1e/0x20
 [<c01008c9>] huft_build+0x309/0x5e8
 [<c0101bec>] inflate+0x4c/0xb0
 [<c010efec>] mcount+0x14/0x18
 [<c0101279>] inflate_fixed+0xcb/0x1a4
 [<c0101bec>] inflate+0x4c/0xb0
 [<c010efec>] mcount+0x14/0x18
 [<c0101eae>] gunzip+0x1d4/0x396
 [<c036130e>] unpack_to_rootfs+0x162/0x225
 [<c010efec>] mcount+0x14/0x18
 [<c0100434>] init+0x0/0x124
 [<c03613fe>] populate_rootfs+0x2d/0x3f
 [<c010046b>] init+0x37/0x124
 [<c0102365>] kernel_thread_helper+0x5/0xb

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 16:26                             ` Ingo Molnar
@ 2004-10-19 16:39                               ` Thomas Gleixner
  0 siblings, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 16:39 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

On Tue, 2004-10-19 at 18:26, Ingo Molnar wrote:
> thanks, i've applied your patch to my tree. Find below an untested
> implementation of wait_for_completion_timeout().

Will give it a try.

Found another exterm ugly one. In scsi_error_handler a mutex is
initialized locked and then it is acquired again with
down_interruptible()

I have no fix yet. Somebody else ?

tglx


PCI: Found IRQ 10 for device 0000:00:02.0
sym0: <875> rev 0x4 at pci 0000:00:02.0 irq 10
BUG: semaphore recursion deadlock detected!
.. current task scsi_eh_0/730 is already holding cfed3ed8.
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
       00000000 c025a590 00000000 c0104115 cfed7800 00000000 00000000
Call Trace:
 [<c025a590>] scsi_error_handler+0x0/0x100
 [<c0104115>] kernel_thread_helper+0x5/0x10
------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:472!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in:
CPU:    0
EIP:    0060:[<c0307bb5>]    Not tainted VLI
EFLAGS: 00010046   (2.6.9-rc4-mm1-RT-U6)
EIP is at __down_write_interruptible+0xd5/0x296
eax: 00000001   ebx: 00000000   ecx: c036222c   edx: 00000001
esi: cfed3ed8   edi: cfd04070   ebp: 00000001   esp: cfed3e8c
ds: 007b   es: 007b   ss: 0068   preempt: 00000003
Process scsi_eh_0 (pid: 730, threadinfo=cfed2000 task=cfd04070)
Stack: cfed3ed8 00000000 00000000 cfed3edc cfed3edc cfd04070 00000002
cfed2000
       cfed3ed8 cfed3ed8 00000000 c01c6ae4 cfed3ed8 cfd04070 cfed7800
00000000
       c025a617 c032a106 00000000 ffffffff cfed3e98 cfed3e98 00000001
cfd04070
Call Trace:
 [<c01c6ae4>] down_write_interruptible+0x44/0x70
 [<c025a617>] scsi_error_handler+0x87/0x100
 [<c025a590>] scsi_error_handler+0x0/0x100
 [<c0104115>] kernel_thread_helper+0x5/0x10
Code: 08 89 44 24 10 89 34 24 e8 29 e7 eb ff 89 34 24 e8 d1 e7 eb ff 85
c0 74 1a 8b 2d 20 b6 36 c0 85 ed 74 10 31 db 89 1d 2
 <6>note: scsi_eh_0[730] exited with preempt_count 2



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 15:57                               ` Ingo Molnar
@ 2004-10-19 16:44                                 ` Thomas Gleixner
  2004-10-19 17:58                                   ` Thomas Gleixner
  0 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 16:44 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Tue, 2004-10-19 at 17:57, Ingo Molnar wrote:
> any chance for serial logging on that box?

No

> and does this bootup crash go away if you unset PREEMPT_TIMING or
> LATENCY_TRACE, as suggested by Rui?

It comes into init now, but dies when loading the AGP driver. Have to
look into this.

tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 15:23                           ` Rui Nuno Capela
  2004-10-19 15:44                             ` Thomas Gleixner
  2004-10-19 15:50                             ` Ingo Molnar
@ 2004-10-19 16:50                             ` Florian Schmidt
  2004-10-19 16:56                               ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-19 16:50 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Tue, 19 Oct 2004 16:23:49 +0100 (WEST)
"Rui Nuno Capela" <rncbc@rncbc.org> wrote:

> I'm experiencing terrible kernel panics at a very early bootstrap stage
> while testing the U5 and U6 latest patch(es) on my laptop (P4/UP) --
> (Ingo: this is about the very same trouble I've reported while pre-testing
> U6).

[..]

> OK. After some incremental configurations, I've isolated that those
> oops(es) only occurs if PREEMPT_TIMING and/or LATENCY_TRACE areset (Y). My
> first suspect was that newest RWSEM_DEADLOCK_DETECT, but it wasn't the
> case.
> 
> So something has broken on that non-preemptible critical section timing
> stuff since U4.
> 
> Hasn't anybody else stumbled on this?

I don't get any oopses or panics, but i can observer a rather interesting
behaviour. When i enable the latency traces via

echo 1 > /proc/sys/kernel/trace_enabled

my machine starts to make little pauses of ca 3-4 secs. X "hangs" for this
duration and so does aplay when playing a .wav file. "hangs" means that the
X display seems to be locked. Interestingly enough all keystrokes i entered
during the "hang" seem to arrive fine after the hang has ended. aplay
experiences an xrun.

jackd OTOH is not affected (probably since it runs SCHED_FIFO). I can
happily continue noodling with my guitar through jackd and jack-rack..

But besides that it runs fine here. I get some fairly long non preemptible
critical sections reports though.

here's one (i snipped off quite a few in the middle to make the email
smaller):

preemption latency trace v1.0.7 on 2.6.9-rc4-mm1-RT-U6
-------------------------------------------------------
 latency: 1841 us, entries: 4000 (12990)   |   [VP:1 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: aplay/2160, uid:1000 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: __schedule+0x3b/0x5d0 <c02a767b>
 => ended at:   finish_task_switch+0x43/0xb0 <c0114ae3>
=======>
00000001 0.000ms (+0.000ms): __schedule (ksoftirqd)
00000001 0.000ms (+0.000ms): sched_clock (__schedule)
00000002 0.000ms (+0.000ms): deactivate_task (__schedule)
00000002 0.000ms (+0.000ms): dequeue_task (deactivate_task)
04000002 0.000ms (+0.000ms): __switch_to (__schedule)
04000002 0.001ms (+0.000ms): finish_task_switch (__schedule)
04000000 0.001ms (+0.000ms): schedule (down_write)
04000000 0.001ms (+0.000ms): __schedule (down_write)
04000001 0.001ms (+0.000ms): sched_clock (__schedule)
04000000 0.001ms (+0.000ms): schedule (down_write)
04000000 0.001ms (+0.000ms): __schedule (down_write)
04000001 0.002ms (+0.000ms): sched_clock (__schedule)
04000000 0.002ms (+0.000ms): schedule (down_write)
04000000 0.002ms (+0.000ms): __schedule (down_write)
04000001 0.002ms (+0.000ms): sched_clock (__schedule)
04000000 0.002ms (+0.000ms): schedule (down_write)
04000000 0.002ms (+0.000ms): __schedule (down_write)
04000001 0.003ms (+0.000ms): sched_clock (__schedule)
04000000 0.003ms (+0.000ms): schedule (down_write)
04000000 0.003ms (+0.000ms): __schedule (down_write)
04000001 0.003ms (+0.000ms): sched_clock (__schedule)
04000000 0.003ms (+0.000ms): schedule (down_write)
04000000 0.003ms (+0.000ms): __schedule (down_write)
04000001 0.003ms (+0.000ms): sched_clock (__schedule)
04000000 0.004ms (+0.000ms): schedule (down_write)
04000000 0.004ms (+0.000ms): __schedule (down_write)
04000001 0.004ms (+0.000ms): sched_clock (__schedule)
04000000 0.004ms (+0.000ms): schedule (down_write)
04000000 0.004ms (+0.000ms): __schedule (down_write)
04000001 0.004ms (+0.000ms): sched_clock (__schedule)
04000000 0.005ms (+0.000ms): schedule (down_write)
04000000 0.005ms (+0.000ms): __schedule (down_write)
04000001 0.005ms (+0.000ms): sched_clock (__schedule)
04000000 0.005ms (+0.000ms): schedule (down_write)
04000000 0.005ms (+0.000ms): __schedule (down_write)
04000001 0.005ms (+0.000ms): sched_clock (__schedule)
04000000 0.006ms (+0.000ms): schedule (down_write)
04000000 0.006ms (+0.000ms): __schedule (down_write)
04000001 0.006ms (+0.000ms): sched_clock (__schedule)
04000000 0.006ms (+0.000ms): schedule (down_write)
04000000 0.006ms (+0.000ms): __schedule (down_write)
04000001 0.006ms (+0.000ms): sched_clock (__schedule)
04000000 0.006ms (+0.000ms): schedule (down_write)
04000000 0.007ms (+0.000ms): __schedule (down_write)
04000001 0.007ms (+0.000ms): sched_clock (__schedule)
04000000 0.007ms (+0.000ms): schedule (down_write)
04000000 0.007ms (+0.000ms): __schedule (down_write)
04000001 0.007ms (+0.000ms): sched_clock (__schedule)
04000000 0.007ms (+0.000ms): schedule (down_write)
04000000 0.007ms (+0.000ms): __schedule (down_write)
04000001 0.008ms (+0.000ms): sched_clock (__schedule)
04000000 0.008ms (+0.000ms): schedule (down_write)
04000000 0.008ms (+0.000ms): __schedule (down_write)
04000001 0.008ms (+0.000ms): sched_clock (__schedule)
04000000 0.008ms (+0.000ms): schedule (down_write)
04000000 0.008ms (+0.000ms): __schedule (down_write)
04000001 0.009ms (+0.000ms): sched_clock (__schedule)
04000000 0.009ms (+0.000ms): schedule (down_write)
04000000 0.009ms (+0.000ms): __schedule (down_write)
04000001 0.009ms (+0.000ms): sched_clock (__schedule)
04000000 0.009ms (+0.000ms): schedule (down_write)
04000000 0.009ms (+0.000ms): __schedule (down_write)
04000001 0.009ms (+0.000ms): sched_clock (__schedule)
04000000 0.010ms (+0.000ms): schedule (down_write)
04000000 0.010ms (+0.000ms): __schedule (down_write)
04000001 0.010ms (+0.000ms): sched_clock (__schedule)
04000000 0.010ms (+0.000ms): schedule (down_write)
04000000 0.010ms (+0.000ms): __schedule (down_write)
04000001 0.010ms (+0.000ms): sched_clock (__schedule)
04000000 0.011ms (+0.000ms): schedule (down_write)
04000000 0.011ms (+0.000ms): __schedule (down_write)
04000001 0.011ms (+0.000ms): sched_clock (__schedule)
04000000 0.011ms (+0.000ms): schedule (down_write)
04000000 0.011ms (+0.000ms): __schedule (down_write)
04000001 0.011ms (+0.000ms): sched_clock (__schedule)
04000000 0.012ms (+0.000ms): schedule (down_write)
04000000 0.012ms (+0.000ms): __schedule (down_write)
04000001 0.012ms (+0.000ms): sched_clock (__schedule)
04000000 0.012ms (+0.000ms): schedule (down_write)
04000000 0.012ms (+0.000ms): __schedule (down_write)
04000001 0.012ms (+0.000ms): sched_clock (__schedule)
04000000 0.012ms (+0.000ms): schedule (down_write)
04000000 0.013ms (+0.000ms): __schedule (down_write)
04000001 0.013ms (+0.000ms): sched_clock (__schedule)
04000000 0.013ms (+0.000ms): schedule (down_write)
04000000 0.013ms (+0.000ms): __schedule (down_write)
04000001 0.013ms (+0.000ms): sched_clock (__schedule)
04000000 0.013ms (+0.000ms): schedule (down_write)
04000000 0.013ms (+0.000ms): __schedule (down_write)
04000001 0.014ms (+0.000ms): sched_clock (__schedule)
04000000 0.014ms (+0.000ms): schedule (down_write)
04000000 0.014ms (+0.000ms): __schedule (down_write)
04000001 0.014ms (+0.000ms): sched_clock (__schedule)
04000000 0.014ms (+0.000ms): schedule (down_write)
04000000 0.014ms (+0.000ms): __schedule (down_write)
04000001 0.014ms (+0.000ms): sched_clock (__schedule)
04000000 0.015ms (+0.000ms): schedule (down_write)
04000000 0.015ms (+0.000ms): __schedule (down_write)
04000001 0.015ms (+0.000ms): sched_clock (__schedule)
04000000 0.015ms (+0.000ms): schedule (down_write)
04000000 0.015ms (+0.000ms): __schedule (down_write)
04000001 0.015ms (+0.000ms): sched_clock (__schedule)
04000000 0.016ms (+0.000ms): schedule (down_write)
04000000 0.016ms (+0.000ms): __schedule (down_write)
04000001 0.016ms (+0.000ms): sched_clock (__schedule)
04000000 0.016ms (+0.000ms): schedule (down_write)
04000000 0.016ms (+0.000ms): __schedule (down_write)
04000001 0.016ms (+0.000ms): sched_clock (__schedule)
04000000 0.017ms (+0.000ms): schedule (down_write)
04000000 0.017ms (+0.000ms): __schedule (down_write)
04000001 0.017ms (+0.000ms): sched_clock (__schedule)
04000000 0.017ms (+0.000ms): schedule (down_write)
04000000 0.017ms (+0.000ms): __schedule (down_write)
04000001 0.017ms (+0.000ms): sched_clock (__schedule)
04000000 0.018ms (+0.000ms): schedule (down_write)
04000000 0.018ms (+0.000ms): __schedule (down_write)
04000001 0.018ms (+0.000ms): sched_clock (__schedule)
04000000 0.018ms (+0.000ms): schedule (down_write)
04000000 0.018ms (+0.000ms): __schedule (down_write)
04000001 0.018ms (+0.000ms): sched_clock (__schedule)
04000000 0.018ms (+0.000ms): schedule (down_write)
04000000 0.019ms (+0.000ms): __schedule (down_write)
04000001 0.019ms (+0.000ms): sched_clock (__schedule)
04000000 0.019ms (+0.000ms): schedule (down_write)
04000000 0.019ms (+0.000ms): __schedule (down_write)
04000001 0.019ms (+0.000ms): sched_clock (__schedule)
04000000 0.019ms (+0.000ms): schedule (down_write)
04000000 0.019ms (+0.000ms): __schedule (down_write)
04000001 0.020ms (+0.000ms): sched_clock (__schedule)
04000000 0.020ms (+0.000ms): schedule (down_write)
04000000 0.020ms (+0.000ms): __schedule (down_write)
04000001 0.020ms (+0.000ms): sched_clock (__schedule)
04000000 0.020ms (+0.000ms): schedule (down_write)
04000000 0.020ms (+0.000ms): __schedule (down_write)
04000001 0.020ms (+0.000ms): sched_clock (__schedule)
04000000 0.021ms (+0.000ms): schedule (down_write)
04000000 0.021ms (+0.000ms): __schedule (down_write)
04000001 0.021ms (+0.000ms): sched_clock (__schedule)
04000000 0.021ms (+0.000ms): schedule (down_write)
04000000 0.021ms (+0.000ms): __schedule (down_write)
04000001 0.021ms (+0.000ms): sched_clock (__schedule)
04000000 0.022ms (+0.000ms): schedule (down_write)
04000000 0.022ms (+0.000ms): __schedule (down_write)
04000001 0.022ms (+0.000ms): sched_clock (__schedule)
04000000 0.022ms (+0.000ms): schedule (down_write)
04000000 0.022ms (+0.000ms): __schedule (down_write)
04000001 0.022ms (+0.000ms): sched_clock (__schedule)
04000000 0.023ms (+0.000ms): schedule (down_write)
04000000 0.023ms (+0.000ms): __schedule (down_write)
04000001 0.023ms (+0.000ms): sched_clock (__schedule)
04000000 0.023ms (+0.000ms): schedule (down_write)
04000000 0.023ms (+0.000ms): __schedule (down_write)
04000001 0.023ms (+0.000ms): sched_clock (__schedule)
04000000 0.023ms (+0.000ms): schedule (down_write)
04000000 0.024ms (+0.000ms): __schedule (down_write)
04000001 0.024ms (+0.000ms): sched_clock (__schedule)
04000000 0.024ms (+0.000ms): schedule (down_write)
04000000 0.024ms (+0.000ms): __schedule (down_write)
04000001 0.024ms (+0.000ms): sched_clock (__schedule)
04000000 0.024ms (+0.000ms): schedule (down_write)
04000000 0.025ms (+0.000ms): __schedule (down_write)
04000001 0.025ms (+0.000ms): sched_clock (__schedule)
04000000 0.025ms (+0.000ms): schedule (down_write)
04000000 0.025ms (+0.000ms): __schedule (down_write)
04000001 0.025ms (+0.000ms): sched_clock (__schedule)
04000000 0.025ms (+0.000ms): schedule (down_write)
04000000 0.025ms (+0.000ms): __schedule (down_write)
04000001 0.026ms (+0.000ms): sched_clock (__schedule)
04000000 0.026ms (+0.000ms): schedule (down_write)
04000000 0.026ms (+0.000ms): __schedule (down_write)
04000001 0.026ms (+0.000ms): sched_clock (__schedule)
04000000 0.026ms (+0.000ms): schedule (down_write)
04000000 0.026ms (+0.000ms): __schedule (down_write)
04000001 0.026ms (+0.000ms): sched_clock (__schedule)
04000000 0.027ms (+0.000ms): schedule (down_write)
04000000 0.027ms (+0.000ms): __schedule (down_write)
04000001 0.027ms (+0.000ms): sched_clock (__schedule)
04000000 0.027ms (+0.000ms): schedule (down_write)
04000000 0.027ms (+0.000ms): __schedule (down_write)
04000001 0.027ms (+0.000ms): sched_clock (__schedule)
04000000 0.028ms (+0.000ms): schedule (down_write)
04000000 0.028ms (+0.000ms): __schedule (down_write)
04000001 0.028ms (+0.000ms): sched_clock (__schedule)
04000000 0.028ms (+0.000ms): schedule (down_write)
04000000 0.028ms (+0.000ms): __schedule (down_write)
04000001 0.028ms (+0.000ms): sched_clock (__schedule)
04000000 0.029ms (+0.000ms): schedule (down_write)
04000000 0.029ms (+0.000ms): __schedule (down_write)
04000001 0.029ms (+0.000ms): sched_clock (__schedule)
04000000 0.029ms (+0.000ms): schedule (down_write)
04000000 0.029ms (+0.000ms): __schedule (down_write)
04000001 0.029ms (+0.000ms): sched_clock (__schedule)
04000000 0.029ms (+0.000ms): schedule (down_write)
04000000 0.030ms (+0.000ms): __schedule (down_write)
04000001 0.030ms (+0.000ms): sched_clock (__schedule)
04000000 0.030ms (+0.000ms): schedule (down_write)
04000000 0.030ms (+0.000ms): __schedule (down_write)
04000001 0.030ms (+0.000ms): sched_clock (__schedule)
04000000 0.030ms (+0.000ms): schedule (down_write)
04000000 0.030ms (+0.000ms): __schedule (down_write)
04000001 0.031ms (+0.000ms): sched_clock (__schedule)
04000000 0.031ms (+0.000ms): schedule (down_write)
04000000 0.031ms (+0.000ms): __schedule (down_write)
04000001 0.031ms (+0.000ms): sched_clock (__schedule)
04000000 0.031ms (+0.000ms): schedule (down_write)
04000000 0.031ms (+0.000ms): __schedule (down_write)
04000001 0.031ms (+0.000ms): sched_clock (__schedule)
04000000 0.032ms (+0.000ms): schedule (down_write)
04000000 0.032ms (+0.000ms): __schedule (down_write)
04000001 0.032ms (+0.000ms): sched_clock (__schedule)
04000000 0.032ms (+0.000ms): schedule (down_write)
04000000 0.032ms (+0.000ms): __schedule (down_write)
04000001 0.032ms (+0.000ms): sched_clock (__schedule)
04000000 0.033ms (+0.000ms): schedule (down_write)
04000000 0.033ms (+0.000ms): __schedule (down_write)
04000001 0.033ms (+0.000ms): sched_clock (__schedule)
04000000 0.033ms (+0.000ms): schedule (down_write)
04000000 0.033ms (+0.000ms): __schedule (down_write)
04000001 0.033ms (+0.000ms): sched_clock (__schedule)
04000000 0.034ms (+0.000ms): schedule (down_write)
04000000 0.034ms (+0.000ms): __schedule (down_write)
04000001 0.034ms (+0.000ms): sched_clock (__schedule)
04000000 0.034ms (+0.000ms): schedule (down_write)
04000000 0.034ms (+0.000ms): __schedule (down_write)
04000001 0.034ms (+0.000ms): sched_clock (__schedule)
04000000 0.035ms (+0.000ms): schedule (down_write)
04000000 0.035ms (+0.000ms): __schedule (down_write)
04000001 0.035ms (+0.000ms): sched_clock (__schedule)
04000000 0.035ms (+0.000ms): schedule (down_write)
04000000 0.035ms (+0.000ms): __schedule (down_write)
04000001 0.035ms (+0.000ms): sched_clock (__schedule)
04000000 0.035ms (+0.000ms): schedule (down_write)
04000000 0.036ms (+0.000ms): __schedule (down_write)

[...many many more of similar ones...]

04000000 0.554ms (+0.000ms): __schedule (down_write)
04000001 0.554ms (+0.000ms): sched_clock (__schedule)
04000000 0.554ms (+0.000ms): schedule (down_write)
04000000 0.554ms (+0.000ms): __schedule (down_write)
04000001 0.554ms (+0.000ms): sched_clock (__schedule)
04000000 0.555ms (+0.000ms): schedule (down_write)
04000000 0.555ms (+0.000ms): __schedule (down_write)
04000001 0.555ms (+0.000ms): sched_clock (__schedule)
04000000 0.555ms (+0.000ms): schedule (down_write)
04000000 0.555ms (+0.000ms): __schedule (down_write)
04000001 0.555ms (+0.000ms): sched_clock (__schedule)
04000000 0.555ms (+0.000ms): schedule (down_write)
04000000 0.556ms (+0.000ms): __schedule (down_write)
04000001 0.556ms (+0.000ms): sched_clock (__schedule)
04000000 0.556ms (+0.000ms): schedule (down_write)
04000000 0.556ms (+0.000ms): __schedule (down_write)
04000001 0.556ms (+0.000ms): sched_clock (__schedule)
04000000 0.556ms (+0.000ms): schedule (down_write)
04000000 0.556ms (+0.000ms): __schedule (down_write)
04000001 0.557ms (+0.000ms): sched_clock (__schedule)
04000000 0.557ms (+0.000ms): schedule (down_write)
04000000 0.557ms (+0.000ms): __schedule (down_write)
04000001 0.557ms (+0.000ms): sched_clock (__schedule)
04000000 0.557ms (+0.000ms): schedule (down_write)
04000000 0.557ms (+0.000ms): __schedule (down_write)
04000001 0.557ms (+0.000ms): sched_clock (__schedule)
04000000 0.558ms (+0.000ms): schedule (down_write)
04000000 0.558ms (+0.000ms): __schedule (down_write)
04000001 0.558ms (+0.000ms): sched_clock (__schedule)
04000000 0.558ms (+0.000ms): schedule (down_write)
04000000 0.558ms (+0.000ms): __schedule (down_write)
04000001 0.558ms (+0.000ms): sched_clock (__schedule)
04000000 0.559ms (+0.000ms): schedule (down_write)
04000000 0.559ms (+0.000ms): __schedule (down_write)
04000001 0.559ms (+0.000ms): sched_clock (__schedule)
04000000 0.559ms (+0.000ms): schedule (down_write)
04000000 0.559ms (+0.000ms): __schedule (down_write)
04000001 0.559ms (+0.000ms): sched_clock (__schedule)
04000000 0.560ms (+0.000ms): schedule (down_write)
04000000 0.560ms (+0.000ms): __schedule (down_write)
04000001 0.560ms (+0.000ms): sched_clock (__schedule)
04000000 0.560ms (+0.000ms): schedule (down_write)
04000000 0.560ms (+0.000ms): __schedule (down_write)
04000001 0.560ms (+0.000ms): sched_clock (__schedule)
04000000 0.561ms (+0.000ms): schedule (down_write)
04000000 0.561ms (+0.000ms): __schedule (down_write)
04000001 0.561ms (+0.000ms): sched_clock (__schedule)
04000000 0.561ms (+0.000ms): schedule (down_write)
04000000 0.561ms (+0.000ms): __schedule (down_write)
04000001 0.561ms (+0.000ms): sched_clock (__schedule)
04000000 0.561ms (+0.000ms): schedule (down_write)
04000000 0.562ms (+0.000ms): __schedule (down_write)
04000001 0.562ms (+0.000ms): sched_clock (__schedule)
04000000 0.562ms (+0.000ms): schedule (down_write)
04000000 0.562ms (+0.000ms): __schedule (down_write)
04000001 0.562ms (+0.000ms): sched_clock (__schedule)
04000000 0.562ms (+0.000ms): schedule (down_write)
04000000 0.562ms (+0.000ms): __schedule (down_write)
04000001 0.563ms (+0.000ms): sched_clock (__schedule)
04000000 0.563ms (+0.000ms): schedule (down_write)
04000000 0.563ms (+0.000ms): __schedule (down_write)
04000001 0.563ms (+0.000ms): sched_clock (__schedule)
04000000 0.563ms (+0.000ms): schedule (down_write)
04000000 0.563ms (+0.000ms): __schedule (down_write)
04000001 0.563ms (+0.000ms): sched_clock (__schedule)
04000000 0.564ms (+0.000ms): schedule (down_write)
04000000 0.564ms (+0.000ms): __schedule (down_write)
04000001 0.564ms (+0.000ms): sched_clock (__schedule)
04000000 0.564ms (+0.000ms): schedule (down_write)
04000000 0.564ms (+0.000ms): __schedule (down_write)
04000001 0.564ms (+0.000ms): sched_clock (__schedule)
04000000 0.565ms (+0.000ms): schedule (down_write)
04000000 0.565ms (+0.000ms): __schedule (down_write)
04000001 0.565ms (+0.000ms): sched_clock (__schedule)
04000000 0.565ms (+0.000ms): schedule (down_write)
04000000 0.565ms (+0.000ms): __schedule (down_write)
04000001 0.565ms (+0.000ms): sched_clock (__schedule)
04000000 0.566ms (+0.000ms): schedule (down_write)
04000000 0.566ms (+0.000ms): __schedule (down_write)
04000001 0.566ms (+0.000ms): sched_clock (__schedule)
04000000 0.566ms (+0.000ms): schedule (down_write)
04000000 0.566ms (+0.000ms): __schedule (down_write)
04000001 0.566ms (+0.000ms): sched_clock (__schedule)
04000000 0.567ms (+0.000ms): schedule (down_write)
04000000 0.567ms (+0.000ms): __schedule (down_write)
04000001 0.567ms (+0.000ms): sched_clock (__schedule)
04000000 0.567ms (+0.000ms): schedule (down_write)
04000000 0.567ms (+0.000ms): __schedule (down_write)
04000001 0.567ms (+0.000ms): sched_clock (__schedule)
04000000 0.567ms (+0.000ms): schedule (down_write)
04000000 0.568ms (+0.000ms): __schedule (down_write)
04000001 0.568ms (+0.000ms): sched_clock (__schedule)
04000000 0.568ms (+0.000ms): schedule (down_write)
04000000 0.568ms (+0.000ms): __schedule (down_write)
04000001 0.568ms (+0.000ms): sched_clock (__schedule)
04000000 0.568ms (+0.000ms): schedule (down_write)
04000000 0.568ms (+0.000ms): __schedule (down_write)
04000001 0.569ms (+0.000ms): sched_clock (__schedule)
04000000 0.569ms (+0.000ms): schedule (down_write)
04000000 0.569ms (+0.000ms): __schedule (down_write)
04000001 0.569ms (+0.000ms): sched_clock (__schedule)
04000000 0.569ms (+0.000ms): schedule (down_write)
04000000 0.569ms (+0.000ms): __schedule (down_write)
04000001 0.569ms (+0.000ms): sched_clock (__schedule)
04000000 0.570ms (+0.000ms): schedule (down_write)
04000000 0.570ms (+0.000ms): __schedule (down_write)
04000001 0.570ms (+0.000ms): sched_clock (__schedule)
04000000 0.570ms (+0.000ms): schedule (down_write)
04000000 0.570ms (+0.000ms): __schedule (down_write)
04000001 0.570ms (+0.000ms): sched_clock (__schedule)
04000000 0.571ms (+0.000ms): schedule (down_write)
04000000 0.571ms (+0.000ms): __schedule (down_write)
04000001 0.571ms (+0.000ms): sched_clock (__schedule)
04000000 0.571ms (+0.000ms): schedule (down_write)
04000000 0.571ms (+0.000ms): __schedule (down_write)
04000001 0.571ms (+0.000ms): sched_clock (__schedule)
04000000 0.572ms (+0.000ms): schedule (down_write)
04000000 0.572ms (+0.000ms): __schedule (down_write)
04000001 0.572ms (+0.000ms): sched_clock (__schedule)
04000000 0.572ms (+0.000ms): schedule (down_write)
04000000 0.572ms (+0.000ms): __schedule (down_write)
04000001 0.572ms (+0.000ms): sched_clock (__schedule)
04000000 0.572ms (+0.000ms): schedule (down_write)
04000000 0.573ms (+0.000ms): __schedule (down_write)
04000001 0.573ms (+0.000ms): sched_clock (__schedule)
04000000 0.573ms (+0.000ms): schedule (down_write)
04000000 0.573ms (+0.000ms): __schedule (down_write)
04000001 0.573ms (+0.000ms): sched_clock (__schedule)
04000000 0.573ms (+0.000ms): schedule (down_write)
04000000 0.574ms (+0.000ms): __schedule (down_write)
04000001 0.574ms (+0.000ms): sched_clock (__schedule)
04000000 0.574ms (+0.000ms): schedule (down_write)
04000000 0.574ms (+0.000ms): __schedule (down_write)
04000001 0.574ms (+0.000ms): sched_clock (__schedule)
04000000 0.574ms (+0.000ms): schedule (down_write)
04000000 0.574ms (+0.000ms): __schedule (down_write)
04000001 0.575ms (+0.000ms): sched_clock (__schedule)
04000000 0.575ms (+0.000ms): schedule (down_write)
04000000 0.575ms (+0.000ms): __schedule (down_write)
04000001 0.575ms (+0.000ms): sched_clock (__schedule)
04000000 0.575ms (+0.000ms): schedule (down_write)
04000000 0.575ms (+0.000ms): __schedule (down_write)
04000001 0.575ms (+0.000ms): sched_clock (__schedule)
04000000 0.576ms (+0.000ms): schedule (down_write)
04000000 0.576ms (+0.000ms): __schedule (down_write)
04000001 0.576ms (+0.000ms): sched_clock (__schedule)
04000000 0.576ms (+0.000ms): schedule (down_write)
04000000 0.576ms (+0.000ms): __schedule (down_write)
04000001 0.576ms (+0.000ms): sched_clock (__schedule)
04000000 0.577ms (+0.000ms): schedule (down_write)
04000000 0.577ms (+0.000ms): __schedule (down_write)
04000001 0.577ms (+0.000ms): sched_clock (__schedule)
04000000 0.577ms (+0.000ms): schedule (down_write)
04000000 0.577ms (+0.000ms): __schedule (down_write)
04000001 0.577ms (+0.000ms): sched_clock (__schedule)
04000000 0.578ms (+0.000ms): schedule (down_write)
04000000 0.578ms (+0.000ms): __schedule (down_write)
04000001 0.578ms (+0.000ms): sched_clock (__schedule)
04000000 0.578ms (+0.000ms): schedule (down_write)
04000000 0.578ms (+0.000ms): __schedule (down_write)
04000001 0.578ms (+0.000ms): sched_clock (__schedule)
04000000 0.578ms (+0.000ms): schedule (down_write)
04000000 0.579ms (+0.000ms): __schedule (down_write)
04000001 0.579ms (+0.000ms): sched_clock (__schedule)
04000000 0.579ms (+0.000ms): schedule (down_write)
04000000 0.579ms (+0.000ms): __schedule (down_write)
04000001 0.579ms (+0.000ms): sched_clock (__schedule)
04000000 0.579ms (+0.000ms): schedule (down_write)
04000000 0.579ms (+0.000ms): __schedule (down_write)
04000001 0.580ms (+0.000ms): sched_clock (__schedule)
04000000 0.580ms (+0.000ms): schedule (down_write)
04000000 0.580ms (+0.000ms): __schedule (down_write)
04000001 0.580ms (+0.000ms): sched_clock (__schedule)
04000000 0.580ms (+0.000ms): schedule (down_write)
04000000 0.580ms (+0.000ms): __schedule (down_write)
04000001 0.581ms (+0.000ms): sched_clock (__schedule)
04000000 0.581ms (+0.000ms): schedule (down_write)
04000000 0.581ms (+0.000ms): __schedule (down_write)
04000001 0.581ms (+0.000ms): sched_clock (__schedule)
04000000 0.581ms (+0.000ms): schedule (down_write)
04000000 0.581ms (+0.000ms): __schedule (down_write)
04000001 0.581ms (+0.000ms): sched_clock (__schedule)
04000000 0.582ms (+0.000ms): schedule (down_write)
04000000 0.582ms (+0.000ms): __schedule (down_write)
04000001 0.582ms (+0.000ms): sched_clock (__schedule)
04000000 0.582ms (+0.000ms): schedule (down_write)
04000000 0.582ms (+0.000ms): __schedule (down_write)
04000001 0.582ms (+0.000ms): sched_clock (__schedule)
04000000 0.583ms (+0.000ms): schedule (down_write)
04000000 0.583ms (+0.000ms): __schedule (down_write)
04000001 0.583ms (+0.000ms): sched_clock (__schedule)
04000000 0.583ms (+0.000ms): schedule (down_write)
04000000 0.583ms (+0.000ms): __schedule (down_write)
04000001 0.583ms (+0.000ms): sched_clock (__schedule)
04000000 0.584ms (+0.000ms): schedule (down_write)
04000000 0.584ms (+0.000ms): __schedule (down_write)
04000001 0.584ms (+0.000ms): sched_clock (__schedule)
04000000 0.584ms (+0.000ms): schedule (down_write)
04000000 0.584ms (+0.000ms): __schedule (down_write)
04000001 0.584ms (+0.000ms): sched_clock (__schedule)
04000000 0.584ms (+0.000ms): schedule (down_write)
04000000 0.585ms (+0.000ms): __schedule (down_write)
04000001 0.585ms (+0.000ms): sched_clock (__schedule)
04000000 0.585ms (+0.000ms): schedule (down_write)
04000000 0.585ms (+0.000ms): __schedule (down_write)
04000001 0.585ms (+0.000ms): sched_clock (__schedule)
04000000 0.585ms (+0.000ms): schedule (down_write)
04000000 0.585ms (+0.000ms): __schedule (down_write)
04000001 0.586ms (+0.000ms): sched_clock (__schedule)
04000000 0.586ms (+0.000ms): schedule (down_write)
04000000 0.586ms (+0.000ms): __schedule (down_write)
04000001 0.586ms (+0.000ms): sched_clock (__schedule)
04000000 0.586ms (+0.000ms): schedule (down_write)
04000000 0.586ms (+0.000ms): __schedule (down_write)
04000001 0.586ms (+0.000ms): sched_clock (__schedule)
04000000 0.587ms (+0.000ms): schedule (down_write)
04000000 0.587ms (+0.000ms): __schedule (down_write)
04000001 0.587ms (+0.000ms): sched_clock (__schedule)
04000000 0.587ms (+0.000ms): schedule (down_write)
04000000 0.587ms (+0.000ms): __schedule (down_write)
04000001 0.587ms (+0.000ms): sched_clock (__schedule)
04000000 0.588ms (+0.000ms): schedule (down_write)
04000000 0.588ms (+0.000ms): __schedule (down_write)
04000001 0.588ms (+0.000ms): sched_clock (__schedule)
04000000 0.588ms (+0.000ms): schedule (down_write)
04000000 0.588ms (+0.000ms): __schedule (down_write)
04000001 0.588ms (+0.000ms): sched_clock (__schedule)
04000000 0.589ms (+0.000ms): schedule (down_write)
04000000 0.589ms (+0.000ms): __schedule (down_write)
04000001 0.589ms (+0.000ms): sched_clock (__schedule)
04000000 0.589ms (+0.000ms): schedule (down_write)
04000000 0.589ms (+0.000ms): __schedule (down_write)
04000001 0.589ms (+0.000ms): sched_clock (__schedule)
04000000 0.590ms (+0.000ms): schedule (down_write)
04000000 0.590ms (+0.000ms): __schedule (down_write)
04000001 0.590ms (+0.000ms): sched_clock (__schedule)
04000000 0.590ms (+0.000ms): schedule (down_write)
04000000 0.590ms (+0.000ms): __schedule (down_write)
04000001 0.590ms (+0.000ms): sched_clock (__schedule)
04000000 0.590ms (+0.000ms): schedule (down_write)
04000000 0.591ms (+0.000ms): __schedule (down_write)
04000001 0.591ms (+0.000ms): sched_clock (__schedule)
04000000 0.591ms (+0.000ms): schedule (down_write)
04000000 0.591ms (+0.000ms): __schedule (down_write)
04000001 0.591ms (+0.000ms): sched_clock (__schedule)
04000000 0.591ms (+0.000ms): schedule (down_write)
04000000 0.591ms (+0.000ms): __schedule (down_write)
04000001 0.592ms (+0.000ms): sched_clock (__schedule)
04000000 0.592ms (+0.000ms): schedule (down_write)
04000000 0.592ms (+0.000ms): __schedule (down_write)
04000001 0.592ms (+0.000ms): sched_clock (__schedule)
04000000 0.592ms (+0.000ms): schedule (down_write)
04000000 0.592ms (+0.000ms): __schedule (down_write)
04000001 0.592ms (+0.000ms): sched_clock (__schedule)
04000000 0.593ms (+0.000ms): schedule (down_write)
04000000 0.593ms (+0.000ms): __schedule (down_write)
04000001 0.593ms (+0.000ms): sched_clock (__schedule)
04000000 0.593ms (+0.000ms): schedule (down_write)
04000000 0.593ms (+0.000ms): __schedule (down_write)
04000001 0.593ms (+0.000ms): sched_clock (__schedule)
04000000 0.594ms (+0.000ms): schedule (down_write)
04000000 0.594ms (+0.000ms): __schedule (down_write)
04000001 0.594ms (+0.000ms): sched_clock (__schedule)
04000000 0.594ms (+0.000ms): schedule (down_write)
04000000 0.594ms (+0.000ms): __schedule (down_write)
04000001 0.594ms (+0.000ms): sched_clock (__schedule)
04000000 0.595ms (+0.000ms): schedule (down_write)
04000000 0.595ms (+0.000ms): __schedule (down_write)
04000001 0.595ms (+0.000ms): sched_clock (__schedule)
04000000 0.595ms (+0.000ms): schedule (down_write)
04000000 0.595ms (+0.000ms): __schedule (down_write)
04000001 0.595ms (+0.000ms): sched_clock (__schedule)
04000000 0.596ms (+0.000ms): schedule (down_write)
04000000 0.596ms (+0.000ms): __schedule (down_write)
04000001 0.596ms (+0.000ms): sched_clock (__schedule)
04000000 0.596ms (+0.000ms): schedule (down_write)
04000000 0.596ms (+0.000ms): __schedule (down_write)
04000001 0.596ms (+0.000ms): sched_clock (__schedule)
04000000 0.596ms (+0.000ms): schedule (down_write)
04000000 0.597ms (+0.000ms): __schedule (down_write)
04000001 0.597ms (+0.000ms): sched_clock (__schedule)
04000000 0.597ms (+0.000ms): schedule (down_write)
04000000 0.597ms (+0.000ms): __schedule (down_write)
04000001 0.597ms (+0.000ms): sched_clock (__schedule)
04000000 0.597ms (+0.000ms): schedule (down_write)
04000000 0.597ms (+0.000ms): __schedule (down_write)
04000001 0.598ms (+0.000ms): sched_clock (__schedule)
04000000 0.598ms (+0.000ms): schedule (down_write)
04000000 0.598ms (+0.000ms): __schedule (down_write)
04000001 0.598ms (+0.000ms): sched_clock (__schedule)
04000000 0.598ms (+0.000ms): schedule (down_write)
04000000 0.598ms (+0.000ms): __schedule (down_write)
04000001 0.598ms (+0.000ms): sched_clock (__schedule)
04000000 0.599ms (+0.000ms): schedule (down_write)
04000000 0.599ms (+0.000ms): __schedule (down_write)
04000001 0.599ms (+0.000ms): sched_clock (__schedule)
04000000 0.599ms (+0.000ms): schedule (down_write)
04000000 0.599ms (+0.000ms): __schedule (down_write)
04000001 0.599ms (+0.000ms): sched_clock (__schedule)
04000000 0.600ms (+0.000ms): schedule (down_write)
04000000 0.600ms (+0.000ms): __schedule (down_write)
04000001 0.600ms (+0.000ms): sched_clock (__schedule)
04000000 0.600ms (+0.000ms): schedule (down_write)
04000000 0.600ms (+0.000ms): __schedule (down_write)
04000001 0.600ms (+0.000ms): sched_clock (__schedule)
04000000 0.601ms (+0.000ms): schedule (down_write)
04000000 0.601ms (+0.000ms): __schedule (down_write)
04000001 0.601ms (+0.000ms): sched_clock (__schedule)
04000000 0.601ms (+0.000ms): schedule (down_write)
04000000 0.601ms (+0.000ms): __schedule (down_write)
04000001 0.601ms (+0.000ms): sched_clock (__schedule)
04000000 0.601ms (+0.000ms): schedule (down_write)
04000000 0.602ms (+0.000ms): __schedule (down_write)
04000001 0.602ms (+0.000ms): sched_clock (__schedule)
04000000 0.602ms (+0.000ms): schedule (down_write)
04000000 0.602ms (+0.000ms): __schedule (down_write)
04000001 0.602ms (+0.000ms): sched_clock (__schedule)
04000000 0.602ms (+0.000ms): schedule (down_write)
04000000 0.602ms (+0.000ms): __schedule (down_write)
04000001 0.603ms (+0.000ms): sched_clock (__schedule)
04000000 0.603ms (+0.000ms): schedule (down_write)
04000000 0.603ms (+0.000ms): __schedule (down_write)
04000001 0.603ms (+0.000ms): sched_clock (__schedule)
04000000 0.603ms (+0.000ms): schedule (down_write)
04000000 0.603ms (+0.000ms): __schedule (down_write)
04000001 0.604ms (+0.000ms): sched_clock (__schedule)
04000000 0.604ms (+0.000ms): schedule (down_write)
04000000 0.604ms (+0.000ms): __schedule (down_write)
04000001 0.604ms (+0.000ms): sched_clock (__schedule)
04000000 0.604ms (+0.000ms): schedule (down_write)
04000000 0.604ms (+0.000ms): __schedule (down_write)
04000001 0.604ms (+0.000ms): sched_clock (__schedule)
04000000 0.605ms (+0.000ms): schedule (down_write)
04000000 0.605ms (+0.000ms): __schedule (down_write)
04000001 0.605ms (+0.000ms): sched_clock (__schedule)
04000000 0.605ms (+0.000ms): schedule (down_write)
04000000 0.605ms (+0.000ms): __schedule (down_write)
04000001 0.605ms (+0.000ms): sched_clock (__schedule)
04000000 0.606ms (+0.000ms): schedule (down_write)
04000000 0.606ms (+0.000ms): __schedule (down_write)
04000001 0.606ms (+0.000ms): sched_clock (__schedule)
04000000 0.606ms (+0.000ms): schedule (down_write)
04000000 0.606ms (+0.000ms): __schedule (down_write)
04000001 0.606ms (+0.000ms): sched_clock (__schedule)
04000000 0.607ms (+0.000ms): schedule (down_write)
04000000 0.607ms (+0.000ms): __schedule (down_write)
04000001 0.607ms (+0.000ms): sched_clock (__schedule)
04000000 0.607ms (+0.000ms): schedule (down_write)
04000000 0.607ms (+0.000ms): __schedule (down_write)
04000001 0.607ms (+0.000ms): sched_clock (__schedule)
04000000 0.607ms (+0.000ms): schedule (down_write)
04000000 0.608ms (+0.000ms): __schedule (down_write)
04000001 0.608ms (+0.000ms): sched_clock (__schedule)
04000000 0.608ms (+0.000ms): schedule (down_write)
04000000 0.608ms (+0.000ms): __schedule (down_write)
04000001 0.608ms (+0.000ms): sched_clock (__schedule)
04000000 0.608ms (+0.000ms): schedule (down_write)
04000000 0.608ms (+0.000ms): __schedule (down_write)
04000001 0.609ms (+0.000ms): sched_clock (__schedule)
04000000 0.609ms (+0.000ms): schedule (down_write)
04000000 0.609ms (+0.000ms): __schedule (down_write)
04000001 0.609ms (+0.000ms): sched_clock (__schedule)
04000000 0.609ms (+0.000ms): schedule (down_write)
04000000 0.609ms (+0.000ms): __schedule (down_write)
04000001 0.610ms (+0.000ms): sched_clock (__schedule)
04000000 0.610ms (+0.000ms): schedule (down_write)
04000000 0.610ms (+0.000ms): __schedule (down_write)
04000001 0.610ms (+0.000ms): sched_clock (__schedule)
04000000 0.610ms (+0.000ms): schedule (down_write)
04000000 0.610ms (+0.000ms): __schedule (down_write)
04000001 0.610ms (+0.000ms): sched_clock (__schedule)
04000000 0.611ms (+0.000ms): schedule (down_write)
04000000 0.611ms (+0.000ms): __schedule (down_write)
04000001 0.611ms (+0.000ms): sched_clock (__schedule)
04000000 0.611ms (+0.000ms): schedule (down_write)
04000000 0.611ms (+0.000ms): __schedule (down_write)
04000001 0.611ms (+0.000ms): sched_clock (__schedule)
04000000 0.612ms (+0.000ms): schedule (down_write)
04000000 0.612ms (+0.000ms): __schedule (down_write)
04000001 0.612ms (+0.000ms): sched_clock (__schedule)
04000000 0.612ms (+0.000ms): schedule (down_write)
04000000 0.612ms (+0.000ms): __schedule (down_write)
04000001 0.612ms (+0.000ms): sched_clock (__schedule)
04000000 0.613ms (+0.000ms): schedule (down_write)
04000000 0.613ms (+0.000ms): __schedule (down_write)
04000001 0.613ms (+0.000ms): sched_clock (__schedule)
04000000 0.613ms (+0.000ms): schedule (down_write)
04000000 0.613ms (+0.000ms): __schedule (down_write)
04000001 0.613ms (+0.000ms): sched_clock (__schedule)
04000000 0.613ms (+1168210.574ms): schedule (down_write)


mango:~# uname -a
Linux mango.fruits.de 2.6.9-rc4-mm1-RT-U6 #1 Tue Oct 19 17:59:48 CEST 2004 i686 GNU/Linux

mango:~# cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 4
model name      : AMD Athlon(tm) Processor
stepping        : 2
cpu MHz         : 1195.144
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips        : 2359.29

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-rc4-mm1-RT-U6
# Tue Oct 19 17:39:11 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

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

#
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_GENERIC=y
CONFIG_GENERIC_SEMAPHORES=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_X86_USE_3DNOW=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
# 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 is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

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

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

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

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD 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=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_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 is not set
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 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=y
# 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

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

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

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

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_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_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_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

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT 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_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM 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_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

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

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
# CONFIG_I2C is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

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

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

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

#
# Generic devices
#
CONFIG_SND_DUMMY=m
# 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

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

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY 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_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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=m
CONFIG_RXRPC=m

#
# 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=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_PREEMPT_TIMING=y
CONFIG_PREEMPT_TRACE=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_RWSEM_DEADLOCK_DETECT=y
CONFIG_RWSEM_MAX_OWNERS=64
# CONFIG_DEBUG_INFO is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_4KSTACKS=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set

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

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 16:50                             ` Florian Schmidt
@ 2004-10-19 16:56                               ` Ingo Molnar
  2004-10-19 17:49                                 ` Florian Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 16:56 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> I don't get any oopses or panics, but i can observer a rather
> interesting behaviour. When i enable the latency traces via
> 
> echo 1 > /proc/sys/kernel/trace_enabled
> 
> my machine starts to make little pauses of ca 3-4 secs. X "hangs" for
> this duration and so does aplay when playing a .wav file. "hangs"
> means that the X display seems to be locked. Interestingly enough all
> keystrokes i entered during the "hang" seem to arrive fine after the
> hang has ended. aplay experiences an xrun.

do you get the same pauses if you do 'dmesg -n 1'? Also, are you using
preempt_thresh or the maximum-searching variant? preempt_thresh can
generate _tons_ of messages with a low threshold, freezing the system in
essence for long periods of time.

but this trace is weird:

> preemption latency trace v1.0.7 on 2.6.9-rc4-mm1-RT-U6
> -------------------------------------------------------
>  latency: 1841 us, entries: 4000 (12990)   |   [VP:1 KP:1 SP:1 HP:1 #CPUS:1]
>     -----------------
>     | task: aplay/2160, uid:1000 nice:0 policy:0 rt_prio:0
>     -----------------
>  => started at: __schedule+0x3b/0x5d0 <c02a767b>
>  => ended at:   finish_task_switch+0x43/0xb0 <c0114ae3>
> =======>
> 00000001 0.000ms (+0.000ms): __schedule (ksoftirqd)
> 00000001 0.000ms (+0.000ms): sched_clock (__schedule)
> 00000002 0.000ms (+0.000ms): deactivate_task (__schedule)
> 00000002 0.000ms (+0.000ms): dequeue_task (deactivate_task)
> 04000002 0.000ms (+0.000ms): __switch_to (__schedule)
> 04000002 0.001ms (+0.000ms): finish_task_switch (__schedule)
> 04000000 0.001ms (+0.000ms): schedule (down_write)
> 04000000 0.001ms (+0.000ms): __schedule (down_write)
> 04000001 0.001ms (+0.000ms): sched_clock (__schedule)
> 04000000 0.001ms (+0.000ms): schedule (down_write)
> 04000000 0.001ms (+0.000ms): __schedule (down_write)
> 04000001 0.002ms (+0.000ms): sched_clock (__schedule)
> 04000000 0.002ms (+0.000ms): schedule (down_write)

this doesnt seem like normal behavior. It seems two tasks are
ping-pong-ing a semaphore but are unable to make any progress. The whole
thing is non-preemptible because this semaphore was taken while in a 
PREEMPT_ACTIVE section.

(i'd say this is the BKL semaphore - it is quite special in that
regard.)

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 16:31                                   ` Ingo Molnar
@ 2004-10-19 17:17                                     ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 17:17 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Andrew Morton, Arjan van de Ven


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

> enabling 8K stacks ought to help this one. I've made the limit a bit
> too conservative - there's still 1000 bytes left and the assert hits.
> Here's the full trace, the large footprint seems to be in zlib
> initialization:
> 
> mcount: stack overflow: 1008

i've added a stackframe-size field to the end of every stack trace
entry:

mcount: stack overflow: 1008
 [<c012cdaf>] ___trace+0x105/0x117 (12)
 [<c012cde7>] __mcount+0x1d/0x1f (32)
 [<c013e025>] cache_grow+0xe/0x1ab (4)
 [<c013e3dd>] cache_alloc_refill+0x21b/0x253 (4)
 [<c010effc>] mcount+0x14/0x18 (8)
 [<c013e025>] cache_grow+0xe/0x1ab (20)
 [<c013e3dd>] cache_alloc_refill+0x21b/0x253 (52)
 [<c013e740>] __kmalloc+0x82/0x9f (48)
 [<c03607c8>] malloc+0x1e/0x20 (28)
 [<c01008c9>] huft_build+0x309/0x5e8 (16)
 [<c0101bec>] inflate+0x4c/0xb0 (1444)
 [<c010effc>] mcount+0x14/0x18 (8)
 [<c0101279>] inflate_fixed+0xcb/0x1a4 (20)
 [<c0101bec>] inflate+0x4c/0xb0 (1212)
 [<c010effc>] mcount+0x14/0x18 (12)
 [<c0101eae>] gunzip+0x1d4/0x396 (20)
 [<c036130e>] unpack_to_rootfs+0x162/0x225 (28)
 [<c010effc>] mcount+0x14/0x18 (8)
 [<c0100434>] init+0x0/0x124 (4)
 [<c03613fe>] populate_rootfs+0x2d/0x3f (16)
 [<c010046b>] init+0x37/0x124 (20)
 [<c0102365>] kernel_thread_helper+0x5/0xb (20)

as suspected, zlib's huft_build() is fun:

  lib/inflate.c:

  #define N_MAX 288       /* maximum number of codes in any set */

  STATIC int huft_build(
  ...
  {

    unsigned v[N_MAX];            /* values in order of bit length */

a whopping 1152 bytes for this local variable alone! The patch below
fixes this, but there are other overflows as well, later in the bootup.

	Ingo

--- linux/lib/inflate.c.orig
+++ linux/lib/inflate.c
@@ -300,7 +300,7 @@ STATIC int huft_build(
   register struct huft *q;      /* points to current table */
   struct huft r;                /* table entry for structure assignment */
   struct huft *u[BMAX];         /* table stack */
-  unsigned v[N_MAX];            /* values in order of bit length */
+  unsigned *v;                  /* values in order of bit length */
   register int w;               /* bits before this table == (l * h) */
   unsigned x[BMAX+1];           /* bit offsets, then code stack */
   unsigned *xp;                 /* pointer into x */
@@ -309,6 +309,10 @@ STATIC int huft_build(
 
 DEBG("huft1 ");
 
+  /* allocate new table */
+  v = (unsigned *)malloc(sizeof(unsigned)*N_MAX);
+  if (!v)
+    return 3;             /* not enough memory */
   /* Generate counts for each bit length */
   memzero(c, sizeof(c));
   p = b;  i = n;
@@ -322,6 +326,7 @@ DEBG("huft1 ");
   {
     *t = (struct huft *)NULL;
     *m = 0;
+    free(v);
     return 0;
   }
 
@@ -347,10 +352,14 @@ DEBG("huft3 ");
 
   /* Adjust last length count to fill out codes, if needed */
   for (y = 1 << j; j < i; j++, y <<= 1)
-    if ((y -= c[j]) < 0)
+    if ((y -= c[j]) < 0) {
+      free(v);
       return 2;                 /* bad input: more codes than bits */
-  if ((y -= c[i]) < 0)
+    }
+  if ((y -= c[i]) < 0) {
+    free(v);
     return 2;
+  }
   c[i] += y;
 
 DEBG("huft4 ");
@@ -422,6 +431,7 @@ DEBG1("3 ");
         {
           if (h)
             huft_free(u[0]);
+          free(v);
           return 3;             /* not enough memory */
         }
 DEBG1("4 ");
@@ -485,6 +495,7 @@ DEBG("h6f ");
 
 DEBG("huft7 ");
 
+  free(v);
   /* Return true (1) if we were given an incomplete table */
   return y != 0 && g != 1;
 }

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 12:46                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Ingo Molnar
  2004-10-19 14:46                         ` Ingo Molnar
@ 2004-10-19 17:22                         ` Adam Heath
  2004-10-19 17:35                           ` Ingo Molnar
  2004-10-19 18:00                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7 Ingo Molnar
                                           ` (3 subsequent siblings)
  5 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-19 17:22 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Tue, 19 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U6 Real-Time Preemption patch:
>
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6
>
> this is a fixes-only release.
>
> found and fixed the 'big bug' that was probably the one causing
> stability problems for a number of people. There was a small window for
> a task double-free race to occur, causing all sorts of crashes later on.
> This bug could trigger on UP and SMP systems alike, on SMP being a bit
> more frequent.

I am still having the same bug(repeatable by running liquidwar) as I reported
with -U5(see my earlier email).

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 17:22                         ` Adam Heath
@ 2004-10-19 17:35                           ` Ingo Molnar
  2004-10-19 18:52                             ` Adam Heath
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 17:35 UTC (permalink / raw)
  To: Adam Heath; +Cc: linux-kernel


* Adam Heath <doogie@debian.org> wrote:

> I am still having the same bug(repeatable by running liquidwar) as I
> reported with -U5(see my earlier email).

ok, this seems to be some questionable code in OSS. It really has no
business up()-ing the inode semaphore - nobody down()-ed it before! This
could be either a bad workaround for a bug/hang someone saw, or an old
VFS assumption that doesnt hold anymore. In any case, could you try the
patch below, does it fix liquidwar?

	Ingo

--- linux/sound/core/oss/pcm_oss.c.orig
+++ linux/sound/core/oss/pcm_oss.c
@@ -2120,9 +2120,7 @@ static ssize_t snd_pcm_oss_write(struct 
 	substream = pcm_oss_file->streams[SNDRV_PCM_STREAM_PLAYBACK];
 	if (substream == NULL)
 		return -ENXIO;
-	up(&file->f_dentry->d_inode->i_sem);
 	result = snd_pcm_oss_write1(substream, buf, count);
-	down(&file->f_dentry->d_inode->i_sem);
 #ifdef OSS_DEBUG
 	printk("pcm_oss: write %li bytes (wrote %li bytes)\n", (long)count, (long)result);
 #endif

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 16:56                               ` Ingo Molnar
@ 2004-10-19 17:49                                 ` Florian Schmidt
  0 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-19 17:49 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Tue, 19 Oct 2004 18:56:46 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> do you get the same pauses if you do 'dmesg -n 1'? Also, are you using
> preempt_thresh or the maximum-searching variant? preempt_thresh can
> generate _tons_ of messages with a low threshold, freezing the system in
> essence for long periods of time.

afaik i use the maximum search:

mango:~# cat /proc/sys/kernel/preempt_thresh 
0
mango:~# cat /proc/sys/kernel/preempt_max_latency 
1841

I'll compile a kernel w/o preempt-timing and tracing. But i will get to it
tomorrow the earliest.

> but this trace is weird:

 [snip]
 
> this doesnt seem like normal behavior. It seems two tasks are
> ping-pong-ing a semaphore but are unable to make any progress. The whole
> thing is non-preemptible because this semaphore was taken while in a 
> PREEMPT_ACTIVE section.
> 
> (i'd say this is the BKL semaphore - it is quite special in that
> regard.)

btw: afaics these long critical sections reports do not correlate to the
pauses X makes (not sure though). I have anther long one. This is from
syslog as i haven't had the tracing enabled at that time:

(IRQ 3/117/CPU#0): new 1385 us maximum-latency critical section.
 => started at timestamp 2293619762: <call_console_drivers+0x76/0x140>
 =>   ended at timestamp 2293621147: <finish_task_switch+0x43/0xb0>
 [<c012f630>] sub_preempt_count+0x60/0x90
 [<c012f31e>] check_preempt_timing+0x15e/0x270
 [<c0114ae3>] finish_task_switch+0x43/0xb0
 [<c012f630>] sub_preempt_count+0x60/0x90
 [<c0114ae3>] finish_task_switch+0x43/0xb0
 [<c0114ae3>] finish_task_switch+0x43/0xb0
 [<c02a7917>] __schedule+0x2d7/0x5d0
 [<c0136faa>] do_irqd+0x5a/0x80
 [<c0112440>] mcount+0x14/0x18
 [<c0136faa>] do_irqd+0x5a/0x80
 [<c012d82a>] kthread+0xaa/0xb0
 [<c0136f50>] do_irqd+0x0/0x80
 [<c012d780>] kthread+0x0/0xb0
 [<c0104099>] kernel_thread_helper+0x5/0xc
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __schedule+0x3b/0x5d0 / (do_irqd+0x5a/0x80)
.. entry 2: print_traces+0x1d/0x80 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 2293621634



Here's a similar (to the one from my last mail) shorter one:

preemption latency trace v1.0.7 on 2.6.9-rc4-mm1-RT-U6
-------------------------------------------------------
 latency: 471 us, entries: 2562 (2562)   |   [VP:1 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: xterm/3155, uid:1000 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: cond_resched+0x23/0x80 <c02a82b3>
 => ended at:   finish_task_switch+0x43/0xb0 <c0114ae3>
=======>
04000001 0.000ms (+0.000ms): __rwsem_deadlock (down_write)
04000000 0.000ms (+0.000ms): schedule (down_write)
04000000 0.000ms (+0.000ms): __schedule (down_write)
04000001 0.000ms (+0.000ms): sched_clock (__schedule)
04000000 0.000ms (+0.000ms): schedule (down_write)
04000000 0.000ms (+0.000ms): __schedule (down_write)
04000001 0.000ms (+0.000ms): sched_clock (__schedule)
04000000 0.001ms (+0.000ms): schedule (down_write)
04000000 0.001ms (+0.000ms): __schedule (down_write)
04000001 0.001ms (+0.000ms): sched_clock (__schedule)
04000000 0.001ms (+0.000ms): schedule (down_write)
04000000 0.001ms (+0.000ms): __schedule (down_write)
04000001 0.001ms (+0.000ms): sched_clock (__schedule)
04000000 0.002ms (+0.000ms): schedule (down_write)
04000000 0.002ms (+0.000ms): __schedule (down_write)
04000001 0.002ms (+0.000ms): sched_clock (__schedule)
04000000 0.002ms (+0.000ms): schedule (down_write)
04000000 0.002ms (+0.000ms): __schedule (down_write)
04000001 0.002ms (+0.000ms): sched_clock (__schedule)
04000000 0.002ms (+0.000ms): schedule (down_write)
04000000 0.002ms (+0.000ms): __schedule (down_write)
04000001 0.003ms (+0.000ms): sched_clock (__schedule)
04000000 0.003ms (+0.000ms): schedule (down_write)
04000000 0.003ms (+0.000ms): __schedule (down_write)
04000001 0.003ms (+0.000ms): sched_clock (__schedule)
04000000 0.003ms (+0.000ms): schedule (down_write)

[many many more]

04000000 0.445ms (+0.000ms): __schedule (down_write)
04000001 0.445ms (+0.000ms): sched_clock (__schedule)
04000000 0.446ms (+0.000ms): schedule (down_write)
04000000 0.446ms (+0.000ms): __schedule (down_write)
04000001 0.446ms (+0.000ms): sched_clock (__schedule)
04000000 0.446ms (+0.000ms): schedule (down_write)
04000000 0.446ms (+0.000ms): __schedule (down_write)
04000001 0.447ms (+0.000ms): sched_clock (__schedule)
04000000 0.447ms (+0.000ms): schedule (down_write)
04000000 0.447ms (+0.000ms): __schedule (down_write)
04000001 0.447ms (+0.000ms): sched_clock (__schedule)
04000000 0.447ms (+0.000ms): schedule (down_write)
04000000 0.447ms (+0.000ms): __schedule (down_write)
04000001 0.448ms (+0.000ms): sched_clock (__schedule)
04000000 0.448ms (+0.000ms): schedule (down_write)
04000000 0.448ms (+0.000ms): __schedule (down_write)
04000001 0.448ms (+0.000ms): sched_clock (__schedule)
04000000 0.448ms (+0.000ms): schedule (down_write)
04000000 0.449ms (+0.000ms): __schedule (down_write)
04000001 0.449ms (+0.000ms): sched_clock (__schedule)
04000000 0.449ms (+0.000ms): schedule (down_write)
04000000 0.449ms (+0.000ms): __schedule (down_write)
04000001 0.449ms (+0.000ms): sched_clock (__schedule)
04000000 0.449ms (+0.000ms): schedule (down_write)
04000000 0.450ms (+0.000ms): __schedule (down_write)
04000001 0.450ms (+0.000ms): sched_clock (__schedule)
04000000 0.450ms (+0.000ms): schedule (down_write)
04000000 0.450ms (+0.000ms): __schedule (down_write)
04000001 0.450ms (+0.000ms): sched_clock (__schedule)
04000000 0.450ms (+0.000ms): schedule (down_write)
04000000 0.451ms (+0.000ms): __schedule (down_write)
04000001 0.451ms (+0.000ms): sched_clock (__schedule)
04000000 0.451ms (+0.000ms): schedule (down_write)
04000000 0.451ms (+0.000ms): __schedule (down_write)
04000001 0.451ms (+0.000ms): sched_clock (__schedule)
04000000 0.452ms (+0.000ms): schedule (down_write)
04000000 0.452ms (+0.000ms): __schedule (down_write)
04000001 0.452ms (+0.000ms): sched_clock (__schedule)
04000000 0.452ms (+0.000ms): schedule (down_write)
04000000 0.452ms (+0.000ms): __schedule (down_write)
04000001 0.452ms (+0.000ms): sched_clock (__schedule)
04000000 0.453ms (+0.000ms): schedule (down_write)
04000000 0.453ms (+0.000ms): __schedule (down_write)
04000001 0.453ms (+0.000ms): sched_clock (__schedule)
04000000 0.453ms (+0.000ms): schedule (down_write)
04000000 0.453ms (+0.000ms): __schedule (down_write)
04000001 0.453ms (+0.000ms): sched_clock (__schedule)
04000000 0.454ms (+0.000ms): schedule (down_write)
04000000 0.454ms (+0.000ms): __schedule (down_write)
04000001 0.454ms (+0.000ms): sched_clock (__schedule)
04000000 0.454ms (+0.000ms): schedule (down_write)
04000000 0.454ms (+0.001ms): __schedule (down_write)
04010000 0.455ms (+0.000ms): do_IRQ (add_preempt_count)
04010000 0.455ms (+0.000ms): do_IRQ (<00000000>)
00010001 0.456ms (+0.001ms): mask_and_ack_8259A (__do_IRQ)
00010001 0.458ms (+0.000ms): redirect_hardirq (__do_IRQ)
00010000 0.458ms (+0.000ms): handle_IRQ_event (__do_IRQ)
00010000 0.458ms (+0.000ms): timer_interrupt (handle_IRQ_event)
00010001 0.458ms (+0.006ms): mark_offset_tsc (timer_interrupt)
00010001 0.464ms (+0.000ms): do_timer (timer_interrupt)
00010001 0.465ms (+0.000ms): update_wall_time (do_timer)
00010001 0.465ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
00010001 0.465ms (+0.000ms): update_process_times (timer_interrupt)
00010001 0.465ms (+0.000ms): update_one_process (update_process_times)
00010001 0.465ms (+0.000ms): run_local_timers (update_process_times)
00010001 0.466ms (+0.000ms): raise_softirq (update_process_times)
00010001 0.466ms (+0.000ms): scheduler_tick (update_process_times)
00010001 0.466ms (+0.000ms): sched_clock (scheduler_tick)
00010002 0.466ms (+0.000ms): task_timeslice (scheduler_tick)
00010002 0.467ms (+0.000ms): dequeue_task (scheduler_tick)
00010002 0.467ms (+0.000ms): effective_prio (scheduler_tick)
00010002 0.467ms (+0.000ms): enqueue_task (scheduler_tick)
00010001 0.468ms (+0.000ms): note_interrupt (__do_IRQ)
00010001 0.468ms (+0.000ms): end_8259A_irq (__do_IRQ)
00010001 0.468ms (+0.000ms): enable_8259A_irq (__do_IRQ)
04010000 0.469ms (+0.000ms): irq_exit (do_IRQ)
04000001 0.469ms (+0.000ms): sched_clock (__schedule)
00000002 0.470ms (+0.000ms): __switch_to (__schedule)
00000002 0.470ms (+0.000ms): finish_task_switch (__schedule)












one more:

preemption latency trace v1.0.7 on 2.6.9-rc4-mm1-RT-U6
-------------------------------------------------------
 latency: 2363 us, entries: 4000 (15429)   |   [VP:1 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: xterm/3155, uid:1000 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: cond_resched+0x23/0x80 <c02a82b3>
 => ended at:   finish_task_switch+0x43/0xb0 <c0114ae3>
=======>
04000001 0.000ms (+0.000ms): __rwsem_deadlock (down_write)
04000000 0.000ms (+0.000ms): schedule (down_write)
04000000 0.000ms (+0.000ms): __schedule (down_write)
04000001 0.000ms (+0.000ms): sched_clock (__schedule)
04000000 0.000ms (+0.000ms): schedule (down_write)
04000000 0.000ms (+0.000ms): __schedule (down_write)

[more]

04000000 0.347ms (+0.000ms): schedule (down_write)
04000000 0.348ms (+0.000ms): __schedule (down_write)
04000001 0.348ms (+0.000ms): sched_clock (__schedule)
04000000 0.348ms (+0.000ms): schedule (down_write)
04000000 0.348ms (+0.000ms): __schedule (down_write)
04000001 0.348ms (+0.000ms): sched_clock (__schedule)
04000000 0.349ms (+0.000ms): schedule (down_write)
04000000 0.349ms (+0.000ms): __schedule (down_write)
04000001 0.349ms (+0.000ms): sched_clock (__schedule)
04000000 0.349ms (+0.000ms): schedule (down_write)
04000000 0.349ms (+0.000ms): __schedule (down_write)
04000001 0.349ms (+0.000ms): sched_clock (__schedule)
04000000 0.350ms (+0.000ms): schedule (down_write)
04000000 0.350ms (+0.000ms): __schedule (down_write)
04000001 0.350ms (+0.000ms): sched_clock (__schedule)
04000000 0.350ms (+0.000ms): schedule (down_write)
04000000 0.350ms (+0.000ms): __schedule (down_write)
04000001 0.351ms (+0.000ms): sched_clock (__schedule)
04000000 0.351ms (+0.000ms): schedule (down_write)
04000000 0.351ms (+0.000ms): __schedule (down_write)
04000001 0.351ms (+0.000ms): sched_clock (__schedule)
04000000 0.352ms (+0.000ms): schedule (down_write)
04000000 0.352ms (+0.000ms): __schedule (down_write)
04010001 0.352ms (+0.000ms): do_IRQ (add_preempt_count)
04010001 0.353ms (+0.000ms): do_IRQ (<00000000>)
00010001 0.353ms (+0.001ms): mask_and_ack_8259A (__do_IRQ)
00010001 0.355ms (+0.000ms): redirect_hardirq (__do_IRQ)
00010000 0.355ms (+0.000ms): handle_IRQ_event (__do_IRQ)
00010000 0.355ms (+0.000ms): timer_interrupt (handle_IRQ_event)
00010001 0.356ms (+0.006ms): mark_offset_tsc (timer_interrupt)
00010001 0.362ms (+0.000ms): do_timer (timer_interrupt)
00010001 0.363ms (+0.000ms): update_wall_time (do_timer)
00010001 0.363ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
00010001 0.363ms (+0.000ms): update_process_times (timer_interrupt)
00010001 0.363ms (+0.000ms): update_one_process (update_process_times)
00010001 0.363ms (+0.000ms): run_local_timers (update_process_times)
00010001 0.363ms (+0.000ms): raise_softirq (update_process_times)
00010001 0.364ms (+0.000ms): scheduler_tick (update_process_times)
00010001 0.364ms (+0.000ms): sched_clock (scheduler_tick)
00010002 0.364ms (+0.000ms): task_timeslice (scheduler_tick)
00010001 0.365ms (+0.000ms): note_interrupt (__do_IRQ)
00010001 0.365ms (+0.000ms): end_8259A_irq (__do_IRQ)
00010001 0.365ms (+0.000ms): enable_8259A_irq (__do_IRQ)
04010001 0.366ms (+0.000ms): irq_exit (do_IRQ)
04000001 0.367ms (+0.000ms): sched_clock (__schedule)
04000000 0.367ms (+0.000ms): schedule (down_write)
04000000 0.367ms (+0.000ms): __schedule (down_write)
04000001 0.367ms (+0.000ms): sched_clock (__schedule)
04000000 0.368ms (+0.000ms): schedule (down_write)
04000000 0.368ms (+0.000ms): __schedule (down_write)
04000001 0.368ms (+0.000ms): sched_clock (__schedule)
04000000 0.368ms (+0.000ms): schedule (down_write)
04000000 0.368ms (+0.000ms): __schedule (down_write)
04000001 0.369ms (+0.000ms): sched_clock (__schedule)
04000000 0.369ms (+0.000ms): schedule (down_write)
04000000 0.369ms (+0.000ms): __schedule (down_write)
04000001 0.369ms (+0.000ms): sched_clock (__schedule)
04000000 0.370ms (+0.000ms): schedule (down_write)
04000000 0.370ms (+0.000ms): __schedule (down_write)
04000001 0.370ms (+0.000ms): sched_clock (__schedule)
04000000 0.370ms (+0.000ms): schedule (down_write)

[more]

04000000 0.797ms (+0.000ms): schedule (down_write)
04000000 0.797ms (+0.000ms): __schedule (down_write)
04000001 0.797ms (+0.000ms): sched_clock (__schedule)
04000000 0.797ms (+0.000ms): schedule (down_write)
04000000 0.798ms (+0.000ms): __schedule (down_write)
04000001 0.798ms (+0.000ms): sched_clock (__schedule)
04000000 0.798ms (+0.000ms): schedule (down_write)
04000000 0.798ms (+0.000ms): __schedule (down_write)
04000001 0.798ms (+0.000ms): sched_clock (__schedule)
04000000 0.799ms (+0.000ms): schedule (down_write)
04000000 0.799ms (+0.000ms): __schedule (down_write)
04000001 0.799ms (+0.000ms): sched_clock (__schedule)
04000000 0.799ms (+0.000ms): schedule (down_write)
04000000 0.799ms (+0.000ms): __schedule (down_write)
04000001 0.800ms (+0.000ms): sched_clock (__schedule)
04000000 0.800ms (+0.000ms): schedule (down_write)
04000000 0.800ms (+0.000ms): __schedule (down_write)
04000001 0.800ms (+877840.005ms): sched_clock (__schedule)



fio

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 16:44                                 ` Thomas Gleixner
@ 2004-10-19 17:58                                   ` Thomas Gleixner
  2004-10-19 18:26                                     ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 17:58 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

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

On Tue, 2004-10-19 at 18:44, Thomas Gleixner wrote:
> On Tue, 2004-10-19 at 17:57, Ingo Molnar wrote:

The laptop boots now. The culprits, which break the boot are:
pci-hotplug and firewire drivers. 

agp loads correct.

No deeper insight yet.

The IPV6 code triggers the irqs_disabled() check in schedule. dmesg
output attached.

tglx


[-- Attachment #2: dmesg-lap.txt --]
[-- Type: text/plain, Size: 15403 bytes --]

0000 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
On node 0 totalpages: 131023
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 126927 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 DELL                                  ) @ 0x000fdea0
ACPI: RSDT (v001 DELL    CPi R   0x27d40113 ASL  0x00000061) @ 0x1fff0000
ACPI: FADT (v001 DELL    CPi R   0x27d40113 ASL  0x00000061) @ 0x1fff0400
ACPI: MADT (v001 DELL    CPi R   0x27d40113 ASL  0x00000047) @ 0x1fff0c00
ACPI: DSDT (v001 INT430 SYSFexxx 0x00001001 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
Initializing CPU#0
Kernel command line: root=/dev/hdc6 ro 
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 3056.985 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 515412k/524092k available (1776k kernel code, 8124k reserved, 811k data, 148k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 6062.08 BogoMIPS (lpj=3031040)
Security Scaffold v1.0.0 initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000
CPU: After vendor identify, caps:  bfebfbff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps:        bfebfbff 00000000 00000000 00000080
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
CPU: Intel Mobile Intel(R) Pentium(R) 4     CPU 3.06GHz stepping 09
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
ksoftirqd started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfcf1e, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040816
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11
ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fe2d0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xe2f4, dseg 0x40
PnPBIOS: 12 nodes reported by PnP BIOS; 12 recorded by driver
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of "lspci" to bjorn.helgaas@hp.com
** so I can fix the driver.
pnp: 00:01: ioport range 0x1000-0x105f could not be reserved
pnp: 00:01: ioport range 0x1060-0x107f has been reserved
pnp: 00:01: ioport range 0x1080-0x10bf has been reserved
pnp: 00:01: ioport range 0x10c0-0x10ff could not be reserved
pnp: 00:01: ioport range 0xf400-0xf4fe has been reserved
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
Initializing Cryptographic API
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
ACPI: PS/2 Keyboard Controller [KBC] at I/O 0x60, 0x66, irq 1
ACPI: PS/2 Mouse Controller [PS2M] at irq 12
i8042.c: Can't read CTR while initializing i8042.
Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 17 (level, low) -> IRQ 17
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 16 (level, low) -> IRQ 16
ICH4: chipset revision 1
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xbfa8-0xbfaf, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: HL-DT-STCD-RW/DVD-ROM GCC-4241N, ATAPI CD/DVD-ROM drive
elevator: using anticipatory as default io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: IC25N040ATMR04-0, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
Probing IDE interface ide4...
ide4: Wait for ready failed before probe !
Probing IDE interface ide5...
ide5: Wait for ready failed before probe !
hdc: max request size: 1024KiB
hdc: 78140160 sectors (40007 MB) w/1740KiB Cache, CHS=16383/255/63, UDMA(100)
hdc: cache flushes supported
 /dev/ide/host0/bus1/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 >
NET: Registered protocol family 2
IP: routing cache hash table of 64 buckets, 18Kbytes
TCP: Hash tables configured (established 512 bind 923)
NET: Registered protocol family 8
NET: Registered protocol family 20
ACPI: (supports S0 S1 S3 S4 S4bios S5)
ACPI wakeup devices: 
 LID PBTN PCI0 USB0 USB1 USB2 USB3 MODM PCIE 
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
EXT3-fs: recovery complete.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 148k freed
NET: Registered protocol family 1
EXT3 FS on hdc6, internal journal
Real Time Clock Driver v1.12
hda: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
b44.c:v0.95 (Aug 3, 2004)
ACPI: PCI interrupt 0000:02:01.0[A] -> GSI 17 (level, low) -> IRQ 17
eth0: Broadcom 4400 10/100BaseT Ethernet 00:0d:56:39:10:9e
device-mapper: 4.1.0-ioctl (2003-12-10) initialised: dm@uk.sistina.com
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdc3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdc7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1f.5 to 64
intel8x0_measure_ac97_clock: measured 49346 usecs
intel8x0: clocking to 48000
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:1d.7: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 23, pci mem 0xf4fffc00
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
PCI: Enabling device 0000:02:04.0 (0000 -> 0002)
ACPI: PCI interrupt 0000:02:04.0[A] -> GSI 16 (level, low) -> IRQ 16
Yenta: CardBus bridge found at 0000:02:04.0 [1028:015f]
Yenta: ISA IRQ mask 0x0cf8, PCI irq 16
Socket status: 30000006
input: PC Speaker
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.0: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 16, io base 0xbf80
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.1: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 19, io base 0xbf40
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1d.2: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 18, io base 0xbf20
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
usb 2-1: new low speed USB device using address 2
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usbcore: registered new driver hiddev
input: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-0000:00:1d.0-1
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1
usbcore: registered new driver usbhid
/home/thomas/work/LibeRTOS/work/2.6.9-rc4-mm1-VP-U4-LRT1/drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
hw_random: RNG not detected
Intel 810 + AC97 Audio, version 1.01, 18:13:38 Oct 19 2004
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1f.6 to 64
MC'97 1 converters and GPIO not ready (0xff00)
b44: eth0: Link is down.
NET: Registered protocol family 17
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is on for TX and on for RX.
Capability LSM initialized
NET: Registered protocol family 10
Disabled Privacy Extensions on device c0353400(lo)
BUG: sleeping function called from invalid context modprobe(3296) at /home/thomas/work/LibeRTOS/work/2.6.9-rc4-mm1-VP-U4-LRT1/lib/rwsem-generic.c:313
in_atomic():1 [00000001], irqs_disabled():0
 [<c0119e85>] __might_sleep+0xba/0xc9
 [<c02bac00>] down_read+0x1b/0x1d1
 [<c0130cd8>] _rw_mutex_read_lock+0x13/0x22
 [<e09b6d36>] ndisc_constructor+0x3d/0x21a [ipv6]
 [<c025bf7f>] neigh_create+0x1dd/0x1e9
 [<c025bc38>] neigh_lookup+0x9e/0x103
 [<e09b3303>] addrconf_dst_alloc+0x164/0x17a [ipv6]
 [<e09aa7ee>] ipv6_add_addr+0xbf/0x26a [ipv6]
 [<e09acd8b>] init_loopback+0x59/0x10f [ipv6]
 [<e09ad220>] addrconf_notify+0xfa/0x190 [ipv6]
 [<c0129358>] notifier_chain_register+0x44/0x4c
 [<c0257160>] register_netdevice_notifier+0x6c/0x6e
 [<e08a830c>] addrconf_init+0xf/0x81 [ipv6]
 [<e08a81c6>] inet6_init+0x13c/0x203 [ipv6]
 [<c0134ee1>] sys_init_module+0x17a/0x227
 [<c01060df>] syscall_call+0x7/0xb
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: ndisc_constructor+0x31/0x21a [ipv6] / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: modprobe/0x04000001/3296
caller is cond_resched+0x58/0x73
 [<c02ba15e>] __sched_text_start+0x56e/0x5be
 [<c02ba833>] cond_resched+0x58/0x73
 [<c0106ee5>] dump_stack+0x1c/0x20
 [<c0119e85>] __might_sleep+0xba/0xc9
 [<c02ba833>] cond_resched+0x58/0x73
 [<c02bac05>] down_read+0x20/0x1d1
 [<c0130cd8>] _rw_mutex_read_lock+0x13/0x22
 [<e09b6d36>] ndisc_constructor+0x3d/0x21a [ipv6]
 [<c025bf7f>] neigh_create+0x1dd/0x1e9
 [<c025bc38>] neigh_lookup+0x9e/0x103
 [<e09b3303>] addrconf_dst_alloc+0x164/0x17a [ipv6]
 [<e09aa7ee>] ipv6_add_addr+0xbf/0x26a [ipv6]
 [<e09acd8b>] init_loopback+0x59/0x10f [ipv6]
 [<e09ad220>] addrconf_notify+0xfa/0x190 [ipv6]
 [<c0129358>] notifier_chain_register+0x44/0x4c
 [<c0257160>] register_netdevice_notifier+0x6c/0x6e
 [<e08a830c>] addrconf_init+0xf/0x81 [ipv6]
 [<e08a81c6>] inet6_init+0x13c/0x203 [ipv6]
 [<c0134ee1>] sys_init_module+0x17a/0x227
 [<c01060df>] syscall_call+0x7/0xb
preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: ndisc_constructor+0x31/0x21a [ipv6] / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

IPv6 over IPv4 tunneling driver
apm: BIOS not found.
lp: driver loaded but no devices found
BUG: sleeping function called from invalid context ksoftirqd/0(2) at /home/thomas/work/LibeRTOS/work/2.6.9-rc4-mm1-VP-U4-LRT1/lib/rwsem-generic.c:313
in_atomic():1 [00000001], irqs_disabled():0
 [<c0119e85>] __might_sleep+0xba/0xc9
 [<c02bac00>] down_read+0x1b/0x1d1
 [<c0130cd8>] _rw_mutex_read_lock+0x13/0x22
 [<e09b6d36>] ndisc_constructor+0x3d/0x21a [ipv6]
 [<c025bf7f>] neigh_create+0x1dd/0x1e9
 [<c025bc38>] neigh_lookup+0x9e/0x103
 [<e09b1eb7>] ndisc_dst_alloc+0x130/0x13a [ipv6]
 [<e09b7b5d>] ndisc_send_rs+0x95/0x4bf [ipv6]
 [<e09a6d7f>] ip6_output+0x0/0x44 [ipv6]
 [<e09b56f4>] fib6_prune_clones+0x27/0x2b [ipv6]
 [<e09ada6b>] addrconf_dad_completed+0xa0/0xe9 [ipv6]
 [<e09ad90f>] addrconf_dad_timer+0x37/0xf3 [ipv6]
 [<c0118e4b>] __wake_up+0x59/0x85
 [<e09ad8d8>] addrconf_dad_timer+0x0/0xf3 [ipv6]
 [<c0125414>] run_timer_softirq+0x11f/0x2db
 [<c01216a9>] ___do_softirq+0x79/0xbc
 [<c01219be>] ksoftirqd+0x0/0xc8
 [<c0121774>] _do_softirq+0x17/0x19
 [<c0121a49>] ksoftirqd+0x8b/0xc8
 [<c0130129>] kthread+0xa5/0xab
 [<c0130084>] kthread+0x0/0xab
 [<c0104285>] kernel_thread_helper+0x5/0xb
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: ndisc_constructor+0x31/0x21a [ipv6] / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
cs: IO port probe 0x0100-0x04ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x0800-0x08ff: excluding 0x800-0x807
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0a00-0x0aff: clean.
apm: BIOS not found.
eth0: no IPv6 routers present
apm: BIOS not found.
/home/thomas/work/LibeRTOS/work/2.6.9-rc4-mm1-VP-U4-LRT1/drivers/usb/input/hid-input.c: event field not found
/home/thomas/work/LibeRTOS/work/2.6.9-rc4-mm1-VP-U4-LRT1/drivers/usb/input/hid-input.c: event field not found

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

* [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 12:46                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Ingo Molnar
  2004-10-19 14:46                         ` Ingo Molnar
  2004-10-19 17:22                         ` Adam Heath
@ 2004-10-19 18:00                         ` Ingo Molnar
  2004-10-19 19:04                           ` Thomas Gleixner
                                             ` (6 more replies)
  2004-10-19 18:54                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Adam Heath
                                           ` (2 subsequent siblings)
  5 siblings, 7 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 18:00 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


i have released the -U7 Real-Time Preemption patch:

  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

this too is a fixes-only release.

Changes since -U6:

 - crash fix: turn off 4K stacks when using RWSEM_DEADLOCK_DETECTION, 
   and tune down the default max # of tasks traced per semaphore. This 
   increases process-stack size and reduces the footprint of lock 
   objects. This should fix the bootup crash reported by Rui Nuno 
   Capela.

 - assert fix: fixed an ide-taskfile scheduling-with-irqs-off assert
   that Rui's .config triggers.

 - assert workaround: disabled PARPORT_1284 for now, this should fix the
   assert seen by Mark H Johnson.

 - NFS fix: clnt.c fix from Thomas Gleixner

 - debugging helper: print stackframe-size in backtraces.

 - large-stackframe fix: inflate.c fix

to create a -U7 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 17:58                                   ` Thomas Gleixner
@ 2004-10-19 18:26                                     ` Ingo Molnar
  2004-10-19 20:04                                       ` Thomas Gleixner
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-19 18:26 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


* Thomas Gleixner <tglx@linutronix.de> wrote:

> The IPV6 code triggers the irqs_disabled() check in schedule. dmesg
> output attached.

ok, does the patch below, ontop of -U7, fix them?

	Ingo

--- linux.old/include/net/protocol.h	
+++ linux.new/include/net/protocol.h	
@@ -83,6 +83,7 @@ extern spinlock_t inet_proto_lock;
 
 #if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
 extern struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
+extern rwlock_t inet6_proto_lock;
 #endif
 
 extern int	inet_add_protocol(struct net_protocol *prot, unsigned char num);
--- linux.old/net/ipv6/af_inet6.c	
+++ linux.new/net/ipv6/af_inet6.c	
@@ -94,7 +94,7 @@ atomic_t inet6_sock_nr;
  * build a new socket.
  */
 static struct list_head inetsw6[SOCK_MAX];
-static spinlock_t inetsw6_lock = SPIN_LOCK_UNLOCKED;
+static rwlock_t inetsw6_lock = RW_LOCK_UNLOCKED;
 
 static void inet6_sock_destruct(struct sock *sk)
 {
@@ -127,7 +127,7 @@ static int inet6_create(struct socket *s
 
 	/* Look for the requested type/protocol pair. */
 	answer = NULL;
-	rcu_read_lock();
+	rcu_read_lock_read(&inetsw6_lock);
 	list_for_each_rcu(p, &inetsw6[sock->type]) {
 		answer = list_entry(p, struct inet_protosw, list);
 
@@ -162,7 +162,7 @@ static int inet6_create(struct socket *s
 	answer_prot = answer->prot;
 	answer_no_check = answer->no_check;
 	answer_flags = answer->flags;
-	rcu_read_unlock();
+	rcu_read_unlock_read(&inetsw6_lock);
 
 	BUG_TRAP(answer_prot->slab != NULL);
 
@@ -242,7 +242,7 @@ static int inet6_create(struct socket *s
 out:
 	return rc;
 out_rcu_unlock:
-	rcu_read_unlock();
+	rcu_read_unlock_read(&inetsw6_lock);
 	goto out;
 }
 
@@ -542,7 +542,7 @@ inet6_register_protosw(struct inet_proto
 	int protocol = p->protocol;
 	struct list_head *last_perm;
 
-	spin_lock_bh(&inetsw6_lock);
+	write_lock_bh(&inetsw6_lock);
 
 	if (p->type >= SOCK_MAX)
 		goto out_illegal;
@@ -573,7 +573,7 @@ inet6_register_protosw(struct inet_proto
 	 */
 	list_add_rcu(&p->list, last_perm);
 out:
-	spin_unlock_bh(&inetsw6_lock);
+	write_unlock_bh(&inetsw6_lock);
 	return;
 
 out_permanent:
@@ -596,9 +596,9 @@ inet6_unregister_protosw(struct inet_pro
 		       "Attempt to unregister permanent protocol %d.\n",
 		       p->protocol);
 	} else {
-		spin_lock_bh(&inetsw6_lock);
+		write_lock_bh(&inetsw6_lock);
 		list_del_rcu(&p->list);
-		spin_unlock_bh(&inetsw6_lock);
+		write_unlock_bh(&inetsw6_lock);
 
 		synchronize_net();
 	}
--- linux.old/net/ipv6/icmp.c	
+++ linux.new/net/ipv6/icmp.c	
@@ -537,11 +537,11 @@ static void icmpv6_notify(struct sk_buff
 
 	hash = nexthdr & (MAX_INET_PROTOS - 1);
 
-	rcu_read_lock();
+	rcu_read_lock_read(&inet6_proto_lock);
 	ipprot = rcu_dereference(inet6_protos[hash]);
 	if (ipprot && ipprot->err_handler)
 		ipprot->err_handler(skb, NULL, type, code, inner_offset, info);
-	rcu_read_unlock();
+	rcu_read_unlock_read(&inet6_proto_lock);
 
 	read_lock(&raw_v6_lock);
 	if ((sk = sk_head(&raw_v6_htable[hash])) != NULL) {
--- linux.old/net/ipv6/ip6_input.c	
+++ linux.new/net/ipv6/ip6_input.c	
@@ -156,7 +156,7 @@ static inline int ip6_input_finish(struc
 		skb->h.raw += (skb->h.raw[1]+1)<<3;
 	}
 
-	rcu_read_lock();
+	rcu_read_lock_read(&raw_v6_lock);
 resubmit:
 	if (!pskb_pull(skb, skb->h.raw - skb->data))
 		goto discard;
@@ -205,12 +205,12 @@ resubmit:
 			kfree_skb(skb);
 		}
 	}
-	rcu_read_unlock();
+	rcu_read_unlock_read(&raw_v6_lock);
 	return 0;
 
 discard:
 	IP6_INC_STATS_BH(IPSTATS_MIB_INDISCARDS);
-	rcu_read_unlock();
+	rcu_read_unlock_read(&raw_v6_lock);
 	kfree_skb(skb);
 	return 0;
 }
--- linux.old/net/ipv6/ndisc.c	
+++ linux.new/net/ipv6/ndisc.c	
@@ -289,17 +289,17 @@ static int ndisc_constructor(struct neig
 	struct neigh_parms *parms;
 	int is_multicast = ipv6_addr_is_multicast(addr);
 
-	rcu_read_lock();
+	rcu_read_lock_read(&addrconf_lock);
 	in6_dev = in6_dev_get(dev);
 	if (in6_dev == NULL) {
-		rcu_read_unlock();
+		rcu_read_unlock_read(&addrconf_lock);
 		return -EINVAL;
 	}
 
 	parms = in6_dev->nd_parms;
 	__neigh_parms_put(neigh->parms);
 	neigh->parms = neigh_parms_clone(parms);
-	rcu_read_unlock();
+	rcu_read_unlock_read(&addrconf_lock);
 
 	neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST;
 	if (dev->hard_header == NULL) {
--- linux.old/net/ipv6/protocol.c	
+++ linux.new/net/ipv6/protocol.c	
@@ -40,14 +40,14 @@
 #include <net/protocol.h>
 
 struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
-static spinlock_t inet6_proto_lock = SPIN_LOCK_UNLOCKED;
+rwlock_t inet6_proto_lock = RW_LOCK_UNLOCKED;
 
 
 int inet6_add_protocol(struct inet6_protocol *prot, unsigned char protocol)
 {
 	int ret, hash = protocol & (MAX_INET_PROTOS - 1);
 
-	spin_lock_bh(&inet6_proto_lock);
+	write_lock_bh(&inet6_proto_lock);
 
 	if (inet6_protos[hash]) {
 		ret = -1;
@@ -56,7 +56,7 @@ int inet6_add_protocol(struct inet6_prot
 		ret = 0;
 	}
 
-	spin_unlock_bh(&inet6_proto_lock);
+	write_unlock_bh(&inet6_proto_lock);
 
 	return ret;
 }
@@ -69,7 +69,7 @@ int inet6_del_protocol(struct inet6_prot
 {
 	int ret, hash = protocol & (MAX_INET_PROTOS - 1);
 
-	spin_lock_bh(&inet6_proto_lock);
+	write_lock_bh(&inet6_proto_lock);
 
 	if (inet6_protos[hash] != prot) {
 		ret = -1;
@@ -78,7 +78,7 @@ int inet6_del_protocol(struct inet6_prot
 		ret = 0;
 	}
 
-	spin_unlock_bh(&inet6_proto_lock);
+	write_unlock_bh(&inet6_proto_lock);
 
 	synchronize_net();
 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 17:35                           ` Ingo Molnar
@ 2004-10-19 18:52                             ` Adam Heath
  2004-10-19 20:59                               ` Lee Revell
  0 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-19 18:52 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Tue, 19 Oct 2004, Ingo Molnar wrote:

>
> * Adam Heath <doogie@debian.org> wrote:
>
> > I am still having the same bug(repeatable by running liquidwar) as I
> > reported with -U5(see my earlier email).
>
> ok, this seems to be some questionable code in OSS. It really has no
> business up()-ing the inode semaphore - nobody down()-ed it before! This
> could be either a bad workaround for a bug/hang someone saw, or an old
> VFS assumption that doesnt hold anymore. In any case, could you try the
> patch below, does it fix liquidwar?

Yup, the below fixes it.  However, this problem *only* started occuring in
-U5.  I've been running liquidwar on all versions(it's my current
game-to-play-when-I-feel-stupid program).

>
> 	Ingo
>
> --- linux/sound/core/oss/pcm_oss.c.orig
> +++ linux/sound/core/oss/pcm_oss.c
> @@ -2120,9 +2120,7 @@ static ssize_t snd_pcm_oss_write(struct
>  	substream = pcm_oss_file->streams[SNDRV_PCM_STREAM_PLAYBACK];
>  	if (substream == NULL)
>  		return -ENXIO;
> -	up(&file->f_dentry->d_inode->i_sem);
>  	result = snd_pcm_oss_write1(substream, buf, count);
> -	down(&file->f_dentry->d_inode->i_sem);
>  #ifdef OSS_DEBUG
>  	printk("pcm_oss: write %li bytes (wrote %li bytes)\n", (long)count, (long)result);
>  #endif
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 12:46                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Ingo Molnar
                                           ` (2 preceding siblings ...)
  2004-10-19 18:00                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7 Ingo Molnar
@ 2004-10-19 18:54                         ` Adam Heath
  2004-10-19 20:52                         ` Michal Schmidt
  2004-10-20 16:31                         ` Adam Heath
  5 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-19 18:54 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Tue, 19 Oct 2004, Ingo Molnar wrote:

> i have released the -U6 Real-Time Preemption patch:

(xterm/1219/CPU#0): new 39188 us maximum-latency critical section.
 => started at timestamp 71898423: <call_console_drivers+0x76/0x140>
 =>   ended at timestamp 71937611: <finish_task_switch+0x43/0xb0>
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c01324de>] check_preempt_timing+0x15e/0x270
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c02a5717>] __sched_text_start+0x2d7/0x5d0
 [<c02a684f>] down_write+0x12f/0x1e0
 [<c0113104>] mcount+0x14/0x18
 [<c02a684f>] down_write+0x12f/0x1e0
 [<c014dd45>] remove_vm_struct+0x45/0xb0
 [<c014fde2>] exit_mmap+0xf2/0x120
 [<c0119b96>] mmput+0x46/0xf0
 [<c0166d8f>] exec_mmap+0xaf/0x140
 [<c0166ffd>] flush_old_exec+0xfd/0x7f0
 [<c015b917>] vfs_read+0xe7/0x140
 [<c0113104>] mcount+0x14/0x18
 [<c0185d7f>] load_elf_binary+0x30f/0xbd0
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c01db739>] up_read+0xf9/0x140
 [<c01323d8>] check_preempt_timing+0x58/0x270
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c0131c6d>] __mcount+0x1d/0x20
 [<c0185a70>] load_elf_binary+0x0/0xbd0
 [<c0167aba>] search_binary_handler+0x19a/0x2e0
 [<c0167dac>] do_execve+0x1ac/0x260
 [<c0104b07>] sys_execve+0x47/0xd0
 [<c0106013>] syscall_call+0x7/0xb
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __sched_text_start+0x3b/0x5d0 / (down_write+0x12f/0x1e0)
.. entry 2: print_traces+0x1d/0x80 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 71938197

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 18:00                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7 Ingo Molnar
@ 2004-10-19 19:04                           ` Thomas Gleixner
  2004-10-19 22:38                             ` Thomas Gleixner
  2004-10-19 23:25                             ` Thomas Gleixner
  2004-10-19 19:57                           ` Bill Huey
                                             ` (5 subsequent siblings)
  6 siblings, 2 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 19:04 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

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

On Tue, 2004-10-19 at 20:00, Ingo Molnar wrote:
> i have released the -U7 Real-Time Preemption patch:

Another simple fix.

tglx


[-- Attachment #2: rawmidi.c.diff --]
[-- Type: text/x-patch, Size: 641 bytes --]

diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U6a/sound/core/rawmidi.c 2.6.9-rc4-mm1-VP-U4-LRT1/sound/core/rawmidi.c
--- 2.6.9-rc4-mm1-RT-U6a/sound/core/rawmidi.c	2004-10-12 09:32:23.000000000 +0200
+++ 2.6.9-rc4-mm1-VP-U4-LRT1/sound/core/rawmidi.c	2004-10-19 20:44:18.000000000 +0200
@@ -134,7 +134,8 @@
 	err = 0;
 	runtime->drain = 1;
 	while (runtime->avail < runtime->buffer_size) {
-		timeout = interruptible_sleep_on_timeout(&runtime->sleep, 10 * HZ);
+		timeout = wait_event_interruptible_timeout(runtime->sleep, 
+				runtime->avail < runtime->buffer_size, 10 * HZ);
 		if (signal_pending(current)) {
 			err = -ERESTARTSYS;
 			break;

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 18:00                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7 Ingo Molnar
  2004-10-19 19:04                           ` Thomas Gleixner
@ 2004-10-19 19:57                           ` Bill Huey
  2004-10-23  0:05                             ` Lee Revell
  2004-10-19 20:46                           ` Rui Nuno Capela
                                             ` (4 subsequent siblings)
  6 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-19 19:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Tue, Oct 19, 2004 at 08:00:59PM +0200, Ingo Molnar wrote:
> 
> i have released the -U7 Real-Time Preemption patch:
> 
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

You should seriously think about using a kind of bitkeeper or CVS stle
system so that multipule folks can dump stuff into it rapidly. This
project is large enough that it needs some kind of facility like that.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 18:26                                     ` Ingo Molnar
@ 2004-10-19 20:04                                       ` Thomas Gleixner
  0 siblings, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 20:04 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Tue, 2004-10-19 at 20:26, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > The IPV6 code triggers the irqs_disabled() check in schedule. dmesg
> > output attached.
> 
> ok, does the patch below, ontop of -U7, fix them?

Yes, it does. Thanks.

tglx

> --- linux.old/include/net/protocol.h	
> +++ linux.new/include/net/protocol.h	
> @@ -83,6 +83,7 @@ extern spinlock_t inet_proto_lock;
>  
>  #if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
>  extern struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
> +extern rwlock_t inet6_proto_lock;
>  #endif
>  
>  extern int	inet_add_protocol(struct net_protocol *prot, unsigned char num);
> --- linux.old/net/ipv6/af_inet6.c	
> +++ linux.new/net/ipv6/af_inet6.c	
> @@ -94,7 +94,7 @@ atomic_t inet6_sock_nr;
>   * build a new socket.
>   */
>  static struct list_head inetsw6[SOCK_MAX];
> -static spinlock_t inetsw6_lock = SPIN_LOCK_UNLOCKED;
> +static rwlock_t inetsw6_lock = RW_LOCK_UNLOCKED;
>  
>  static void inet6_sock_destruct(struct sock *sk)
>  {
> @@ -127,7 +127,7 @@ static int inet6_create(struct socket *s
>  
>  	/* Look for the requested type/protocol pair. */
>  	answer = NULL;
> -	rcu_read_lock();
> +	rcu_read_lock_read(&inetsw6_lock);
>  	list_for_each_rcu(p, &inetsw6[sock->type]) {
>  		answer = list_entry(p, struct inet_protosw, list);
>  
> @@ -162,7 +162,7 @@ static int inet6_create(struct socket *s
>  	answer_prot = answer->prot;
>  	answer_no_check = answer->no_check;
>  	answer_flags = answer->flags;
> -	rcu_read_unlock();
> +	rcu_read_unlock_read(&inetsw6_lock);
>  
>  	BUG_TRAP(answer_prot->slab != NULL);
>  
> @@ -242,7 +242,7 @@ static int inet6_create(struct socket *s
>  out:
>  	return rc;
>  out_rcu_unlock:
> -	rcu_read_unlock();
> +	rcu_read_unlock_read(&inetsw6_lock);
>  	goto out;
>  }
>  
> @@ -542,7 +542,7 @@ inet6_register_protosw(struct inet_proto
>  	int protocol = p->protocol;
>  	struct list_head *last_perm;
>  
> -	spin_lock_bh(&inetsw6_lock);
> +	write_lock_bh(&inetsw6_lock);
>  
>  	if (p->type >= SOCK_MAX)
>  		goto out_illegal;
> @@ -573,7 +573,7 @@ inet6_register_protosw(struct inet_proto
>  	 */
>  	list_add_rcu(&p->list, last_perm);
>  out:
> -	spin_unlock_bh(&inetsw6_lock);
> +	write_unlock_bh(&inetsw6_lock);
>  	return;
>  
>  out_permanent:
> @@ -596,9 +596,9 @@ inet6_unregister_protosw(struct inet_pro
>  		       "Attempt to unregister permanent protocol %d.\n",
>  		       p->protocol);
>  	} else {
> -		spin_lock_bh(&inetsw6_lock);
> +		write_lock_bh(&inetsw6_lock);
>  		list_del_rcu(&p->list);
> -		spin_unlock_bh(&inetsw6_lock);
> +		write_unlock_bh(&inetsw6_lock);
>  
>  		synchronize_net();
>  	}
> --- linux.old/net/ipv6/icmp.c	
> +++ linux.new/net/ipv6/icmp.c	
> @@ -537,11 +537,11 @@ static void icmpv6_notify(struct sk_buff
>  
>  	hash = nexthdr & (MAX_INET_PROTOS - 1);
>  
> -	rcu_read_lock();
> +	rcu_read_lock_read(&inet6_proto_lock);
>  	ipprot = rcu_dereference(inet6_protos[hash]);
>  	if (ipprot && ipprot->err_handler)
>  		ipprot->err_handler(skb, NULL, type, code, inner_offset, info);
> -	rcu_read_unlock();
> +	rcu_read_unlock_read(&inet6_proto_lock);
>  
>  	read_lock(&raw_v6_lock);
>  	if ((sk = sk_head(&raw_v6_htable[hash])) != NULL) {
> --- linux.old/net/ipv6/ip6_input.c	
> +++ linux.new/net/ipv6/ip6_input.c	
> @@ -156,7 +156,7 @@ static inline int ip6_input_finish(struc
>  		skb->h.raw += (skb->h.raw[1]+1)<<3;
>  	}
>  
> -	rcu_read_lock();
> +	rcu_read_lock_read(&raw_v6_lock);
>  resubmit:
>  	if (!pskb_pull(skb, skb->h.raw - skb->data))
>  		goto discard;
> @@ -205,12 +205,12 @@ resubmit:
>  			kfree_skb(skb);
>  		}
>  	}
> -	rcu_read_unlock();
> +	rcu_read_unlock_read(&raw_v6_lock);
>  	return 0;
>  
>  discard:
>  	IP6_INC_STATS_BH(IPSTATS_MIB_INDISCARDS);
> -	rcu_read_unlock();
> +	rcu_read_unlock_read(&raw_v6_lock);
>  	kfree_skb(skb);
>  	return 0;
>  }
> --- linux.old/net/ipv6/ndisc.c	
> +++ linux.new/net/ipv6/ndisc.c	
> @@ -289,17 +289,17 @@ static int ndisc_constructor(struct neig
>  	struct neigh_parms *parms;
>  	int is_multicast = ipv6_addr_is_multicast(addr);
>  
> -	rcu_read_lock();
> +	rcu_read_lock_read(&addrconf_lock);
>  	in6_dev = in6_dev_get(dev);
>  	if (in6_dev == NULL) {
> -		rcu_read_unlock();
> +		rcu_read_unlock_read(&addrconf_lock);
>  		return -EINVAL;
>  	}
>  
>  	parms = in6_dev->nd_parms;
>  	__neigh_parms_put(neigh->parms);
>  	neigh->parms = neigh_parms_clone(parms);
> -	rcu_read_unlock();
> +	rcu_read_unlock_read(&addrconf_lock);
>  
>  	neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST;
>  	if (dev->hard_header == NULL) {
> --- linux.old/net/ipv6/protocol.c	
> +++ linux.new/net/ipv6/protocol.c	
> @@ -40,14 +40,14 @@
>  #include <net/protocol.h>
>  
>  struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
> -static spinlock_t inet6_proto_lock = SPIN_LOCK_UNLOCKED;
> +rwlock_t inet6_proto_lock = RW_LOCK_UNLOCKED;
>  
> 
>  int inet6_add_protocol(struct inet6_protocol *prot, unsigned char protocol)
>  {
>  	int ret, hash = protocol & (MAX_INET_PROTOS - 1);
>  
> -	spin_lock_bh(&inet6_proto_lock);
> +	write_lock_bh(&inet6_proto_lock);
>  
>  	if (inet6_protos[hash]) {
>  		ret = -1;
> @@ -56,7 +56,7 @@ int inet6_add_protocol(struct inet6_prot
>  		ret = 0;
>  	}
>  
> -	spin_unlock_bh(&inet6_proto_lock);
> +	write_unlock_bh(&inet6_proto_lock);
>  
>  	return ret;
>  }
> @@ -69,7 +69,7 @@ int inet6_del_protocol(struct inet6_prot
>  {
>  	int ret, hash = protocol & (MAX_INET_PROTOS - 1);
>  
> -	spin_lock_bh(&inet6_proto_lock);
> +	write_lock_bh(&inet6_proto_lock);
>  
>  	if (inet6_protos[hash] != prot) {
>  		ret = -1;
> @@ -78,7 +78,7 @@ int inet6_del_protocol(struct inet6_prot
>  		ret = 0;
>  	}
>  
> -	spin_unlock_bh(&inet6_proto_lock);
> +	write_unlock_bh(&inet6_proto_lock);
>  
>  	synchronize_net();
>  


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 18:00                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7 Ingo Molnar
  2004-10-19 19:04                           ` Thomas Gleixner
  2004-10-19 19:57                           ` Bill Huey
@ 2004-10-19 20:46                           ` Rui Nuno Capela
  2004-10-19 21:09                             ` Rui Nuno Capela
  2004-10-19 21:30                           ` Rui Nuno Capela
                                             ` (3 subsequent siblings)
  6 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-19 20:46 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

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

Ingo Molnar wrote:
>
> i have released the -U7 Real-Time Preemption patch:
>
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7
>

With U7 I'm now able to boot and go all the way into X/KDE with a
SMP+PREEMPT_REALTIME configured kernel (config.gz attached) and reboot
into it, again and again. Things are getting better, really, but ...

Overall behavior is still unreliable. Many things stop functioning once
and for good (until reboot). The shutdown sequence is also prone to busy
hanging.

As an aside, my greatest complaint is that jackd -R doesn't work at all:

JACK: unable to mlock() port buffers: Cannot allocate memory
jack_create_thread: error -1 switching current thread to rt for
inheritance: Unknown error 4294967295
cannot start watchdog thread
cannot load driver module alsa

Another example, and one of the very few that were verbose on dmesg, while
accessing the floppy disk (subfs mounted), I got:

kernel BUG at fs/buffer.c:2702!
invalid operand: 0000 [#1]
PREEMPT SMP
Modules linked in: nls_iso8859_15 nls_cp860 vfat fat nls_base snd_seq
usbhid ehc
i_hcd intel_mch_agp agpgart uhci_hcd mga snd_usb_usx2y snd_usb_lib
snd_rawmidi s
nd_seq_device snd_hwdep snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd
soundc
ore snd_page_alloc evdev sk98lin w83781d i2c_sensor i2c_isa i2c_i801
i2c_core wa
com usbcore subfs dm_mod
CPU:    0
EIP:    0060:[<c015a9c2>]    Not tainted VLI
EFLAGS: 00010246   (2.6.9-rc4-mm1-RT-U7.0smp)
EIP is at submit_bh+0x119/0x126
eax: 00000004   ebx: f16d683c   ecx: 00000000   edx: f12e2000
esi: f16d683c   edi: 00000000   ebp: f12e3d90   esp: f12e3d78
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process submountd (pid: 11393, threadinfo=f12e2000 task=f6116950)
Stack: 00000000 00000200 00000000 f16d683c fffffffb f64b0800 f12e3da4
c01587e3
       00000000 f16d683c f4675000 f12e3db8 c0158ab1 f16d683c 00000000
00000200
       f12e3e34 f8c7e85b f673d500 00000000 00000200 f4675148 f12e3de8
c02ca60c
Call Trace:
 [<c0105235>] show_stack+0xaf/0xb7 (28)
 [<c01053c5>] show_registers+0x168/0x1dd (56)
 [<c01055ce>] die+0x107/0x18f (64)
 [<c0105aee>] do_invalid_op+0x109/0x10b (188)
 [<c0104e7d>] error_code+0x2d/0x38 (92)
 [<c01587e3>] __bread_slow+0x60/0xb2 (20)
 [<c0158ab1>] __bread+0x33/0x39 (20)
 [<f8c7e85b>] fat_fill_super+0xe6/0x76c [fat] (124)
 [<f8c43d70>] vfat_fill_super+0x30/0x67 [vfat] (32)
 [<c015d220>] get_sb_bdev+0xf1/0x147 (72)
 [<f8c43dd5>] vfat_get_sb+0x2e/0x31 [vfat] (28)
 [<c015d492>] do_kern_mount+0xa5/0x15a (44)
 [<c0172f0d>] do_new_mount+0x71/0xab (52)
 [<c01735e3>] do_mount+0x184/0x1ae (116)
 [<c0173a21>] sys_mount+0x97/0xd6 (48)
 [<c01043b9>] sysenter_past_esp+0x52/0x71 (-8124)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x17/0x70 / (die+0x3f/0x18f)
.. entry 2: print_traces+0x16/0x4c / (show_stack+0xaf/0xb7)

Code: 24 e8 28 08 00 00 8b 45 f0 83 c4 0c 5b 5e 5f 5d c3 0f 0b 8d 0a 86 ea
2d c0 e9 14 ff ff ff 0f 0b 8f 0a 86 ea 2d c0 e9 1c ff ff ff <0f> 0b 8e 0a
86 ea 2d c0 e9 04 ff ff ff 55 89 e5 57 56 31 f6 53
 <3>subfs: submountd execution failure. Error 11


Think it's too early to party, eh? :)
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: config-2.6.9-rc4-mm1-RT-U7.0smp.gz --]
[-- Type: application/x-gzip, Size: 7562 bytes --]

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 12:46                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Ingo Molnar
                                           ` (3 preceding siblings ...)
  2004-10-19 18:54                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Adam Heath
@ 2004-10-19 20:52                         ` Michal Schmidt
  2004-10-20 16:31                         ` Adam Heath
  5 siblings, 0 replies; 951+ messages in thread
From: Michal Schmidt @ 2004-10-19 20:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano

Ingo Molnar wrote:
> i have released the -U6 Real-Time Preemption patch:
>  
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6
> 
>   [...]
> - deadlock bug: fix networking deadlock reported by Matthew L Foster.
>   Restructured the way the RT-RCU locking of ptype_lock is done - it's
>   cleaner and more obvious now (besides being correct). This could also
>   fix the deadlock reported by Michal Schmidt.

Yes, this fixed the deadlock for me.
I'm now going to try -U7.

Michal

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 18:52                             ` Adam Heath
@ 2004-10-19 20:59                               ` Lee Revell
  0 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-19 20:59 UTC (permalink / raw)
  To: Adam Heath; +Cc: Ingo Molnar, linux-kernel

On Tue, 2004-10-19 at 14:52, Adam Heath wrote:
> On Tue, 19 Oct 2004, Ingo Molnar wrote:
> 
> >
> > * Adam Heath <doogie@debian.org> wrote:
> >
> > > I am still having the same bug(repeatable by running liquidwar) as I
> > > reported with -U5(see my earlier email).
> >
> > ok, this seems to be some questionable code in OSS. It really has no
> > business up()-ing the inode semaphore - nobody down()-ed it before! This
> > could be either a bad workaround for a bug/hang someone saw, or an old
> > VFS assumption that doesnt hold anymore. In any case, could you try the
> > patch below, does it fix liquidwar?
> 
> Yup, the below fixes it.  However, this problem *only* started occuring in
> -U5.  I've been running liquidwar on all versions(it's my current
> game-to-play-when-I-feel-stupid program).

The real fix is to use ALSA. :-)

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 20:46                           ` Rui Nuno Capela
@ 2004-10-19 21:09                             ` Rui Nuno Capela
  0 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-19 21:09 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

> Ingo Molnar wrote:
>>
>> i have released the -U7 Real-Time Preemption patch:
>>
>>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7
>>
>
>
> As an aside, my greatest complaint is that jackd -R doesn't work at all:
>
> JACK: unable to mlock() port buffers: Cannot allocate memory
> jack_create_thread: error -1 switching current thread to rt for
> inheritance: Unknown error 4294967295
> cannot start watchdog thread
> cannot load driver module alsa
>

Forget this. The reason is that realtime-lsm module wasn't being loaded.

Sorry.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 18:00                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7 Ingo Molnar
                                             ` (2 preceding siblings ...)
  2004-10-19 20:46                           ` Rui Nuno Capela
@ 2004-10-19 21:30                           ` Rui Nuno Capela
       [not found]                             ` <1098227713.23628.10.camel@krustophenia.net>
  2004-10-19 23:38                           ` Fernando Pablo Lopez-Lezcano
                                             ` (2 subsequent siblings)
  6 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-19 21:30 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Ingo Molnar wrote:
>
> i have released the -U7 Real-Time Preemption patch:
>
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7
>

Not critical, but I'm "consistently" getting stuck while running mkinitrd,
both on SMP (SuSE9.1, reiserfs) and UP (Mdk10.1c, ext3). This was
happening with U6 too.

Anyone care to confirm?


Some more incidents on 2.6.9-rc5-mm1-RT-U7.0smp:

kernel BUG at lib/rwsem-generic.c:130!
invalid operand: 0000 [#1]
PREEMPT SMP
Modules linked in: loop nls_iso8859_15 nls_cp860 vfat fat nls_base snd_seq
usbhi
d ehci_hcd uhci_hcd intel_mch_agp agpgart mga snd_usb_usx2y snd_usb_lib
snd_rawm
idi snd_seq_device snd_hwdep snd_intel8x0 snd_ac97_codec snd_pcm snd_timer
snd s
oundcore snd_page_alloc evdev sk98lin w83781d i2c_sensor i2c_isa i2c_i801
i2c_co
re wacom usbcore subfs dm_mod
CPU:    0
EIP:    0060:[<c01e3e5d>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-RT-U7.0smp)
EIP is at rwsem_owner_del+0x68/0x8c
eax: f41c0a50   ebx: cb736000   ecx: 00000001   edx: 00000001
esi: 00000001   edi: cdf30218   ebp: cb737fa0   esp: cb737f94
ds: 007b   es: 007b   ss: 0068   preempt: 00000003
Process loop0 (pid: 23481, threadinfo=cb736000 task=f71ba7d0)
Stack: cdf3021c cdf30000 cdf30218 cb737fc8 c01e42d0 cdf30218 f71ba7d0
c1806cd4
       c1806820 00000282 f8c839aa cdf30000 cdf30448 cb737fec f8c83a0f
f71ba7d0
       ffffffec 00000000 cdf30218 f8c839aa 00000000 00000000 00000000
c01025c9
Call Trace:
 [<c0105235>] show_stack+0xaf/0xb7 (28)
 [<c01053c5>] show_registers+0x168/0x1dd (56)
 [<c01055ce>] die+0x107/0x18f (64)
 [<c0105aee>] do_invalid_op+0x109/0x10b (188)
 [<c0104e7d>] error_code+0x2d/0x38 (80)
 [<c01e42d0>] up_write+0x57/0x1a1 (40)
 [<f8c83a0f>] loop_thread+0x65/0x11d [loop] (36)
 [<c01025c9>] kernel_thread_helper+0x5/0xb (881623060)
preempt count: 00000004
. 4-level deep critical section nesting:
.. entry 1: _spin_lock+0x17/0x6d / (up_write+0x110/0x1a1)
.. entry 2: _spin_lock+0x17/0x6d / (up_write+0x4f/0x1a1)
.. entry 3: _spin_lock_irqsave+0x17/0x70 / (die+0x3f/0x18f)
.. entry 4: print_traces+0x16/0x4c / (show_stack+0xaf/0xb7)

Code: 00 e0 ff ff 21 e3 8b 44 8f 18 3b 03 74 2a 83 c1 01 89 d6 39 d1 7c ef
8b 15
 60 fa 31 c0 85 d2 74 12 c7 05 60 fa 31 c0 00 00 00 00 <0f> 0b 82 00 0b 96
2e c0
 5b 5e 5f 5d c3 8d 56 ff 39 d1 74 08 8b
 <6>note: loop0[23481] exited with preempt_count 2
BUG: sleeping function called from invalid context loop0(23481) at
lib/rwsem-gen
eric.c:398
in_atomic():1 [00000002], irqs_disabled():0
 [<c010525b>] dump_stack+0x1e/0x20 (20)
 [<c0118408>] __might_sleep+0xb7/0xca (36)
 [<c02ca11c>] down_write+0x1f/0x184 (44)
 [<c011cfbc>] exit_notify+0x26/0x97f (60)
 [<c011db93>] do_exit+0x27e/0x492 (40)
 [<c0105656>] do_divide_error+0x0/0x12c (64)
 [<c0105aee>] do_invalid_op+0x109/0x10b (188)
 [<c0104e7d>] error_code+0x2d/0x38 (80)
 [<c01e42d0>] up_write+0x57/0x1a1 (40)
 [<f8c83a0f>] loop_thread+0x65/0x11d [loop] (36)
 [<c01025c9>] kernel_thread_helper+0x5/0xb (881623060)
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock+0x17/0x6d / (up_write+0x110/0x1a1)
.. entry 2: _spin_lock+0x17/0x6d / (up_write+0x4f/0x1a1)
.. entry 3: print_traces+0x16/0x4c / (dump_stack+0x1e/0x20)

BUG: scheduling while atomic: loop0/0x00000002/23481
caller is do_exit+0x287/0x492
 [<c010525b>] dump_stack+0x1e/0x20 (20)
 [<c02c90d6>] __schedule+0x836/0xc81 (116)
 [<c011db9c>] do_exit+0x287/0x492 (40)
 [<c0105656>] do_divide_error+0x0/0x12c (64)
 [<c0105aee>] do_invalid_op+0x109/0x10b (188)
 [<c0104e7d>] error_code+0x2d/0x38 (80)
 [<c01e42d0>] up_write+0x57/0x1a1 (40)
 [<f8c83a0f>] loop_thread+0x65/0x11d [loop] (36)
 [<c01025c9>] kernel_thread_helper+0x5/0xb (881623060)
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock+0x17/0x6d / (up_write+0x110/0x1a1)
.. entry 2: _spin_lock+0x17/0x6d / (up_write+0x4f/0x1a1)
.. entry 3: print_traces+0x16/0x4c / (dump_stack+0x1e/0x20)


Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 19:04                           ` Thomas Gleixner
@ 2004-10-19 22:38                             ` Thomas Gleixner
  2004-10-19 23:25                             ` Thomas Gleixner
  1 sibling, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 22:38 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

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

On Tue, 2004-10-19 at 21:04, Thomas Gleixner wrote:
> On Tue, 2004-10-19 at 20:00, Ingo Molnar wrote:
> > i have released the -U7 Real-Time Preemption patch:
> 
> Another simple fix.

Another one using wait_for_completion_timeout(). No problems so far.

tglx



[-- Attachment #2: clntlock.c.diff --]
[-- Type: text/x-patch, Size: 1720 bytes --]

diff -urN 2.6.9-rc4-mm1-RT-U7/fs/lockd/clntlock.c 2.6.9-rc4-mm1-RT-U7-work/fs/lockd/clntlock.c
--- 2.6.9-rc4-mm1-RT-U7/fs/lockd/clntlock.c	2004-10-12 09:32:10.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U7-work/fs/lockd/clntlock.c	2004-10-19 21:26:14.000000000 +0200
@@ -6,6 +6,7 @@
  * Copyright (C) 1996, Olaf Kirch <okir@monad.swb.de>
  */
 
+#include <linux/completion.h>
 #include <linux/module.h>
 #include <linux/types.h>
 #include <linux/time.h>
@@ -32,7 +33,7 @@
  */
 struct nlm_wait {
 	struct nlm_wait *	b_next;		/* linked list */
-	wait_queue_head_t	b_wait;		/* where to wait on */
+	struct completion	b_wait;		/* where to wait on */
 	struct nlm_host *	b_host;
 	struct file_lock *	b_lock;		/* local file lock */
 	unsigned short		b_reclaim;	/* got to reclaim lock */
@@ -53,7 +54,7 @@
 
 	block.b_host   = host;
 	block.b_lock   = fl;
-	init_waitqueue_head(&block.b_wait);
+	init_completion(&block.b_wait);
 	block.b_status = NLM_LCK_BLOCKED;
 	block.b_next   = nlm_blocked;
 	nlm_blocked    = &block;
@@ -69,7 +70,8 @@
 	 * a 1 minute timeout would do. See the comment before
 	 * nlmclnt_lock for an explanation.
 	 */
-	sleep_on_timeout(&block.b_wait, 30*HZ);
+	
+	wait_for_completion_timeout(&block.b_wait, 30*HZ);
 
 	for (head = &nlm_blocked; *head; head = &(*head)->b_next) {
 		if (*head == &block) {
@@ -118,7 +120,7 @@
 	 * wake up the caller.
 	 */
 	block->b_status = NLM_LCK_GRANTED;
-	wake_up(&block->b_wait);
+	complete(&block->b_wait);
 
 	return nlm_granted;
 }
@@ -233,7 +235,7 @@
 	for (block = nlm_blocked; block; block = block->b_next) {
 		if (block->b_host == host) {
 			block->b_status = NLM_LCK_DENIED_GRACE_PERIOD;
-			wake_up(&block->b_wait);
+			complete(&block->b_wait);
 		}
 	}
 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 19:04                           ` Thomas Gleixner
  2004-10-19 22:38                             ` Thomas Gleixner
@ 2004-10-19 23:25                             ` Thomas Gleixner
  1 sibling, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 23:25 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

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

On Tue, 2004-10-19 at 21:04, Thomas Gleixner wrote:
> On Tue, 2004-10-19 at 20:00, Ingo Molnar wrote:
> > i have released the -U7 Real-Time Preemption patch:
> 
Nobrainer typo removal. I'm feeling stupid.

tglx



[-- Attachment #2: svc.nobrain.diff --]
[-- Type: text/x-patch, Size: 616 bytes --]

diff -urN 2.6.9-rc4-mm1-RT-U7/fs/lockd/svc.c 2.6.9-rc4-mm1-RT-U7-work/fs/lockd/svc.c
--- 2.6.9-rc4-mm1-RT-U7/fs/lockd/svc.c	2004-10-19 20:29:43.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U7-work/fs/lockd/svc.c	2004-10-20 00:42:20.000000000 +0200
@@ -306,7 +306,7 @@
 	 * Wait for the lockd process to exit, but since we're holding
 	 * the lockd semaphore, we can't wait around forever ...
 	 */
-	if (!wait_event_interruptible_timeout(lockd_exit, 
+	if (wait_event_interruptible_timeout(lockd_exit, 
 					     nlmsvc_pid == 0, HZ) <= 0) {
 		printk(KERN_WARNING 
 			"lockd_down: lockd failed to exit, clearing pid\n");

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
       [not found]                               ` <1098228272.12223.1134.camel@thomas>
@ 2004-10-19 23:34                                 ` Lee Revell
  0 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-19 23:34 UTC (permalink / raw)
  To: tglx
  Cc: Ingo Molnar, linux-kernel, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Tue, 2004-10-19 at 19:24, Thomas Gleixner wrote:
> On Wed, 2004-10-20 at 01:15, Lee Revell wrote:
> > On Tue, 2004-10-19 at 17:30, Rui Nuno Capela wrote:
> > > Ingo Molnar wrote:
> > > >
> > > > i have released the -U7 Real-Time Preemption patch:
> > > >
> > > >   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7
> > > >
> > 
> > Ingo, did you forget to cc: LKML on the U7 announcement, or is the list
> > just slow today?  I checked my mail as well as lkml.org, this does not
> > seem to have made it to the list.
> > 
> 
> Yes, it's slow. Postings drop in in random order with long delays.
> 

Sorry, I screwed up linux-kernel in the cc: list.

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 18:00                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7 Ingo Molnar
                                             ` (3 preceding siblings ...)
  2004-10-19 21:30                           ` Rui Nuno Capela
@ 2004-10-19 23:38                           ` Fernando Pablo Lopez-Lezcano
  2004-10-19 23:39                             ` Thomas Gleixner
  2004-10-20  5:40                           ` Lee Revell
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
  6 siblings, 1 reply; 951+ messages in thread
From: Fernando Pablo Lopez-Lezcano @ 2004-10-19 23:38 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt

On Tue, 2004-10-19 at 11:00, Ingo Molnar wrote:
> i have released the -U7 Real-Time Preemption patch:
> 
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7
> 
> this too is a fixes-only release.

First Ux I try to boot, on install I get this:

WARNING:
/lib/modules/2.6.8-1.520.1rU7.ll.rhfc2.ccrma/kernel/drivers/scsi/aacraid/aacraid.ko needs unknown symbol __you_cannot_kmalloc_that_much
WARNING:
/lib/modules/2.6.8-1.520.1rU7.ll.rhfc2.ccrma/kernel/drivers/message/i2o/i2o_block.ko needs unknown symbol i2o_msg_in_to_virt
WARNING:
/lib/modules/2.6.8-1.520.1rU7.ll.rhfc2.ccrma/kernel/drivers/message/i2o/i2o_core.ko needs unknown symbol i2o_msg_in_to_virt
WARNING:
/lib/modules/2.6.8-1.520.1rU7.ll.rhfc2.ccrma/kernel/drivers/message/i2o/i2o_core.ko needs unknown symbol i2o_msg_out_to_virt
WARNING:
/lib/modules/2.6.8-1.520.1rU7.ll.rhfc2.ccrma/kernel/drivers/message/i2o/i2o_scsi.ko needs unknown symbol i2o_msg_in_to_virt

No luck booting, I get a kernel panic, the last lines printed to the
screen are like this (transcribed by hand, there may be errors):

printk+0x17/0x20 (20)
print_preempt_trace+0x51/0xa0 (12)
print_traces+0x1e/0x40 (24)
show_stack+0x70/0x90 (8)
error_code+0x2d/0x38 (20)
down_write_interruptible+0xba/0x278 (52)
scsi_error_handler+0x98/0x1a0 [scsi_mod] (44)
scsi_error_handler+0x0/0x1a0 [scsi_mod] (284)
kernel_thread_helper+0x5/0x18 (8)

preempt count: 04000008
. 8 level deep critical section nesting:
.. entry 1: down_write_interruptible+0x273/0x278 / (0x0)
.. entry 2: down_write_interruptible+0x5a/0x278 / (0x0)
.. entry 3: __schedule+0x34/0x650 / (0x0)
.. entry 4: __schedule+0xcb/0x650 / (0x0)
.. entry 5: __schedule+0x34/0x650 / (0x0)
.. entry 6: __schedule+0xcb/0x650 / (0x0)
.. entry 7: die+0x36/0x180 / (0x0)
.. entry 8: print_traces+0xd/0x40 / (0x0)
<0> Kernel panic - not syncing: Fatal exception in interrupt

I hope this can be useful...
-- Fernando



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 23:38                           ` Fernando Pablo Lopez-Lezcano
@ 2004-10-19 23:39                             ` Thomas Gleixner
  2004-10-20  5:02                               ` Thomas Gleixner
  0 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-19 23:39 UTC (permalink / raw)
  To: Fernando Pablo Lopez-Lezcano
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt

On Wed, 2004-10-20 at 01:38, Fernando Pablo Lopez-Lezcano wrote:
> On Tue, 2004-10-19 at 11:00, Ingo Molnar wrote:
> > i have released the -U7 Real-Time Preemption patch:
> > 
> >   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7
> > 
> > this too is a fixes-only release.
> 

That's in scsi_error_handler() where a mutex is initialized locked and
then acquired again. This triggers the deadlock/correctness check.

tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 23:39                             ` Thomas Gleixner
@ 2004-10-20  5:02                               ` Thomas Gleixner
  2004-10-20  7:40                                 ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-20  5:02 UTC (permalink / raw)
  To: Fernando Pablo Lopez-Lezcano
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt

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

On Wed, 2004-10-20 at 01:39, Thomas Gleixner wrote:
> That's in scsi_error_handler() where a mutex is initialized locked and
> then acquired again. This triggers the deadlock/correctness check.

Some more fixes

- scsi_error_handler() fix

- device subsystem device_remove locking fix

tglx



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

diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/base/bus.c 2.6.9-rc4-mm1-RT-U7-work/drivers/base/bus.c
--- 2.6.9-rc4-mm1-RT-U7/drivers/base/bus.c	2004-10-12 09:41:05.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U7-work/drivers/base/bus.c	2004-10-20 03:04:29.000000000 +0200
@@ -65,7 +65,7 @@
 static void driver_release(struct kobject * kobj)
 {
 	struct device_driver * drv = to_driver(kobj);
-	up(&drv->unload_sem);
+	complete(&drv->unload_done);
 }
 
 static struct kobj_type ktype_driver = {
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/include/linux/device.h 2.6.9-rc4-mm1-RT-U7-work/include/linux/device.h
--- 2.6.9-rc4-mm1-RT-U7/include/linux/device.h	2004-10-12 09:41:58.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U7-work/include/linux/device.h	2004-10-20 03:05:02.000000000 +0200
@@ -102,7 +102,7 @@
 	char			* name;
 	struct bus_type		* bus;
 
-	struct semaphore	unload_sem;
+	struct completion	unload_done;
 	struct kobject		kobj;
 	struct list_head	devices;
 
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/base/driver.c 2.6.9-rc4-mm1-RT-U7-work/drivers/base/driver.c
--- 2.6.9-rc4-mm1-RT-U7/drivers/base/driver.c	2004-10-12 09:41:05.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U7-work/drivers/base/driver.c	2004-10-20 03:11:20.000000000 +0200
@@ -79,14 +79,13 @@
  *	since most of the things we have to do deal with the bus
  *	structures.
  *
- *	The one interesting aspect is that we initialize @drv->unload_sem
- *	to a locked state here. It will be unlocked when the driver
- *	reference count reaches 0.
+ *	We init the completion strcut here. When the reference 
+ *	count reaches zero, complete() is called from bus_release().
  */
 int driver_register(struct device_driver * drv)
 {
 	INIT_LIST_HEAD(&drv->devices);
-	init_MUTEX_LOCKED(&drv->unload_sem);
+	init_completion(&drv->unload_done);
 	return bus_add_driver(drv);
 }
 
@@ -97,18 +96,16 @@
  *
  *	Again, we pass off most of the work to the bus-level call.
  *
- *	Though, once that is done, we attempt to take @drv->unload_sem.
- *	This will block until the driver refcount reaches 0, and it is
- *	released. Only modular drivers will call this function, and we
+ *	Though, once that is done, we wait until the driver refcount 
+ *	reaches 0, and complete() is called in bus_release().
+ *	Only modular drivers will call this function, and we
  *	have to guarantee that it won't complete, letting the driver
  *	unload until all references are gone.
  */
-
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	down(&drv->unload_sem);
-	up(&drv->unload_sem);
+	wait_for_completion(&drv->unload_done);
 }
 
 /**

[-- Attachment #3: scsi.patch --]
[-- Type: text/x-patch, Size: 2889 bytes --]

diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/scsi/hosts.c 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/hosts.c
--- 2.6.9-rc4-mm1-RT-U7/drivers/scsi/hosts.c	2004-10-12 09:41:34.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/hosts.c	2004-10-20 03:32:10.000000000 +0200
@@ -149,7 +149,7 @@
 		DECLARE_COMPLETION(sem);
 		shost->eh_notify = &sem;
 		shost->eh_kill = 1;
-		up(shost->eh_wait);
+		wake_up(shost->eh_wait);
 		wait_for_completion(&sem);
 		shost->eh_notify = NULL;
 	}
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/scsi/scsi_error.c 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/scsi_error.c
--- 2.6.9-rc4-mm1-RT-U7/drivers/scsi/scsi_error.c	2004-10-19 20:29:46.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/scsi_error.c	2004-10-20 05:31:20.000000000 +0200
@@ -49,7 +49,7 @@
 void scsi_eh_wakeup(struct Scsi_Host *shost)
 {
 	if (shost->host_busy == shost->host_failed) {
-		up(shost->eh_wait);
+		wake_up(shost->eh_wait);
 		SCSI_LOG_ERROR_RECOVERY(5,
 				printk("Waking error handler thread\n"));
 	}
@@ -1599,9 +1599,8 @@
 {
 	struct Scsi_Host *shost = (struct Scsi_Host *) data;
 	int rtn;
-	DECLARE_MUTEX(sem);
+	DECLARE_WAIT_QUEUE_HEAD(eh_wait);
 
-	init_MUTEX_LOCKED(&sem);
 	/*
 	 *    Flush resources
 	 */
@@ -1610,7 +1609,7 @@
 
 	current->flags |= PF_NOFREEZE;
 
-	shost->eh_wait = &sem;
+	shost->eh_wait = &eh_wait;
 	shost->ehandler = current;
 
 	/*
@@ -1632,15 +1631,12 @@
 						  " sleeping\n",shost->host_no));
 
 		/*
-		 * Note - we always use down_interruptible with the semaphore
-		 * even if the module was loaded as part of the kernel.  The
-		 * reason is that down() will cause this thread to be counted
-		 * in the load average as a running process, and down
-		 * interruptible doesn't.  Given that we need to allow this
-		 * thread to die if the driver was loaded as a module, using
-		 * semaphores isn't unreasonable.
+		 * Wait, until somebody decides to wake us due to an error
+		 * or because we should be killed
 		 */
-		down_interruptible(&sem);
+		wait_event_interruptible(eh_wait, shost->eh_kill ||
+				(shost->host_busy == shost->host_failed)); 
+	
 		if (shost->eh_kill)
 			break;
 
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/include/scsi/scsi_host.h 2.6.9-rc4-mm1-RT-U7-work/include/scsi/scsi_host.h
--- 2.6.9-rc4-mm1-RT-U7/include/scsi/scsi_host.h	2004-10-12 09:42:00.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U7-work/include/scsi/scsi_host.h	2004-10-20 03:42:05.000000000 +0200
@@ -396,7 +396,7 @@
 
 	struct list_head	eh_cmd_q;
 	struct task_struct    * ehandler;  /* Error recovery thread. */
-	struct semaphore      * eh_wait;   /* The error recovery thread waits
+	wait_queue_head_t     * eh_wait;   /* The error recovery thread waits
 					      on this. */
 	struct completion     * eh_notify; /* wait for eh to begin or end */
 	struct semaphore      * eh_action; /* Wait for specific actions on the

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 18:00                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7 Ingo Molnar
                                             ` (4 preceding siblings ...)
  2004-10-19 23:38                           ` Fernando Pablo Lopez-Lezcano
@ 2004-10-20  5:40                           ` Lee Revell
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
  6 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-20  5:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Tue, 2004-10-19 at 14:00, Ingo Molnar wrote:
> i have released the -U7 Real-Time Preemption patch:
> 
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7

OK, this one boots but Gnome does not start.  It hangs at "Session
Manager".  The system does not hang, but I never get to my desktop. 
Nothing useful in the logs.

While this was going on I switched to a text console and noticed that if
I enabled/ Caps Lock at just the right moment then _all_ text output
(LOGIN, PASSWORD, etc) would be in caps.  Toggling it a few times seemed
to get rid of the problem.

Any particular debug options I should try?

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-20  5:02                               ` Thomas Gleixner
@ 2004-10-20  7:40                                 ` Ingo Molnar
  2004-10-20  9:57                                   ` Thomas Gleixner
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20  7:40 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Fernando Pablo Lopez-Lezcano, LKML, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt


* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Wed, 2004-10-20 at 01:39, Thomas Gleixner wrote:
> > That's in scsi_error_handler() where a mutex is initialized locked and
> > then acquired again. This triggers the deadlock/correctness check.
> 
> Some more fixes
> 
> - scsi_error_handler() fix
> 
> - device subsystem device_remove locking fix

thanks, i've applied these. The block/loop.c assert reported by Rui
seems to be a similar problem too.

	Ingo

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

* [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-19 18:00                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7 Ingo Molnar
                                             ` (5 preceding siblings ...)
  2004-10-20  5:40                           ` Lee Revell
@ 2004-10-20  9:45                           ` Ingo Molnar
  2004-10-20 10:04                             ` Ingo Molnar
                                               ` (9 more replies)
  6 siblings, 10 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20  9:45 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


i have released the -U8 Real-Time Preemption patch:

  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

this too is a fixes-only release. It includes the many semaphore-abuse
and sleep_on() fixes/improvements from Thomas Gleixner, and it also
includes a couple of semaphore related fixes.

I believe the semaphore fixes should resolve a number of the deadlocks
reported for -U7.

In particular it seems the only sane and reliable way to convert RCU
locking was to allow the following semantics for rwsems: allow reads to
nest, and allow self-read-recursion of a self-write-held semaphore. My
current implementation for this allows semaphore unfairness, but that
can be fixed later on. Most importantly, the RCU to RT-locking
conversions are much more automatic now and map nicely to what the code
is doing upstream. Most of the time they involve a conversion of a
spinlock or semaphore into a rwlock or rwsem. The old code maps to new
code almost automatically, the only manual work needed was to associate
the rcu_read_lock() with the writers-lock that it excludes against,
which is a pretty clear (but not automatic, and hence not automatable)
decision. This way i could convert some more networking code, and
simplify the older changes and hopefully get rid of some deadlocks. The
locking API is still not in its final form, but it's getting closer.

Changes since -U7:

 - deadlock fix: sysfs/driver-base semaphore fixes from Thomas Gleixner

 - deadlock fix: scsi semaphore fixes from Thomas Gleixner

 - NFS sleep_on() fixes from Thomas Gleixner

 - rawmidid.c sleep_on() fix from Thomas Gleixner

 - [ i've added more wait_for_completion_*() primitives, to ease 
     conversion of other semaphore-(ab-)using code. ]

 - make rwsems self-recursive

 - RCU lock conversion: convert rtnl_sem RCU use.

 - netfilter deadlock fix - clean up RCU locking.

to create a -U8 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-20  7:40                                 ` Ingo Molnar
@ 2004-10-20  9:57                                   ` Thomas Gleixner
  2004-10-20 10:27                                     ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-20  9:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Fernando Pablo Lopez-Lezcano, LKML, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt

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

On Wed, 2004-10-20 at 09:40, Ingo Molnar wrote:
> > - scsi_error_handler() fix
> > - device subsystem device_remove locking fix
> 
> thanks, i've applied these. The block/loop.c assert reported by Rui
> seems to be a similar problem too.

Yep, it's all the same scheme. Most of the offending code uses
MUTEX_LOCKED in an init function and plays the down, and up from a
different context game, which triggers the deadlock/owner verify. Not
hard to fix, but at some places it takes a bit, until you see the
intention of the driver hacker. 

The most surprising one was in driver/base. I did not expect that new
2.5/6 code uses those tricks too.

Fixes for aic7xxx and sym53c8xx_2 attached.

tglx


[-- Attachment #2: aic7xxx.diff --]
[-- Type: text/x-patch, Size: 7478 bytes --]

diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/scsi/aic7xxx/aic7xxx_osm.c 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/aic7xxx/aic7xxx_osm.c
--- 2.6.9-rc4-mm1-RT-U7/drivers/scsi/aic7xxx/aic7xxx_osm.c	2004-10-12 09:41:33.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/aic7xxx/aic7xxx_osm.c	2004-10-20 09:33:59.000000000 +0200
@@ -1873,9 +1873,10 @@
 	ahc->platform_data->completeq_timer.data = (u_long)ahc;
 	ahc->platform_data->completeq_timer.function =
 	    (ahc_linux_callback_t *)ahc_linux_thread_run_complete_queue;
-	init_MUTEX_LOCKED(&ahc->platform_data->eh_sem);
-	init_MUTEX_LOCKED(&ahc->platform_data->dv_sem);
-	init_MUTEX_LOCKED(&ahc->platform_data->dv_cmd_sem);
+	init_waitqueue_head(&ahc->platform_data->eh_sem);
+	init_waitqueue_head(&ahc->platform_data->dv_sem);
+	init_waitqueue_head(&ahc->platform_data->dv_cmd_sem);
+	init_completion(&ahc->platform_data->dv_exit);
 	tasklet_init(&ahc->platform_data->runq_tasklet, ahc_runq_tasklet,
 		     (unsigned long)ahc);
 	ahc->seltime = (aic7xxx_seltime & 0x3) << 4;
@@ -2156,7 +2157,7 @@
 		ahc_linux_freeze_simq(ahc);
 
 		/* Wake up the DV kthread */
-		up(&ahc->platform_data->dv_sem);
+		wake_up(&ahc->platform_data->dv_sem);
 	}
 }
 
@@ -2169,39 +2170,22 @@
 	if (ahc->platform_data->dv_pid != 0) {
 		ahc->platform_data->flags |= AHC_DV_SHUTDOWN;
 		ahc_unlock(ahc, &s);
-		up(&ahc->platform_data->dv_sem);
+		wake_up(&ahc->platform_data->dv_sem);
 
-		/*
-		 * Use the eh_sem as an indicator that the
-		 * dv thread is exiting.  Note that the dv
-		 * thread must still return after performing
-		 * the up on our semaphore before it has
-		 * completely exited this module.  Unfortunately,
-		 * there seems to be no easy way to wait for the
-		 * exit of a thread for which you are not the
-		 * parent (dv threads are parented by init).
-		 * Cross your fingers...
-		 */
-		down(&ahc->platform_data->eh_sem);
-
-		/*
-		 * Mark the dv thread as already dead.  This
-		 * avoids attempting to kill it a second time.
-		 * This is necessary because we must kill the
-		 * DV thread before calling ahc_free() in the
-		 * module shutdown case to avoid bogus locking
-		 * in the SCSI mid-layer, but we ahc_free() is
-		 * called without killing the DV thread in the
-		 * instance detach case, so ahc_platform_free()
-		 * calls us again to verify that the DV thread
-		 * is dead.
-		 */
-		ahc->platform_data->dv_pid = 0;
+		/* Wait until the thread has exited */
+		wait_for_completion(&ahc->platform_data->dv_exit);
 	} else {
 		ahc_unlock(ahc, &s);
 	}
 }
 
+#define AHC_WAIT_FOR_WORK \
+	(ahc->platform_data->flags & (AHC_DV_SHUTDOWN | AHC_DV_ACTIVE))
+#define AHC_WAIT_FOR_SIMQ_EMPTY \
+	(!(ahc->platform_data->flags & AHC_DV_WAIT_SIMQ_EMPTY))
+#define AHC_WAIT_FOR_SIMQ_RELEASE \
+	(!(ahc->platform_data->flags & AHC_DV_WAIT_SIMQ_RELEASE))
+
 static int
 ahc_linux_dv_thread(void *data)
 {
@@ -2235,11 +2219,9 @@
 	unlock_kernel();
 
 	while (1) {
-		/*
-		 * Use down_interruptible() rather than down() to
-		 * avoid inclusion in the load average.
-		 */
-		down_interruptible(&ahc->platform_data->dv_sem);
+		/* Wait for work */
+		wait_event_interruptible(ahc->platform_data->dv_sem,
+					 AHC_WAIT_FOR_WORK);
 
 		/* Check to see if we've been signaled to exit */
 		ahc_lock(ahc, &s);
@@ -2262,7 +2244,8 @@
 		while (LIST_FIRST(&ahc->pending_scbs) != NULL) {
 			ahc->platform_data->flags |= AHC_DV_WAIT_SIMQ_EMPTY;
 			ahc_unlock(ahc, &s);
-			down_interruptible(&ahc->platform_data->dv_sem);
+			wait_event_interruptible(ahc->platform_data->dv_sem,
+						 AHC_WAIT_FOR_SIMQ_EMPTY);
 			ahc_lock(ahc, &s);
 		}
 
@@ -2273,7 +2256,8 @@
 		while (AHC_DV_SIMQ_FROZEN(ahc) == 0) {
 			ahc->platform_data->flags |= AHC_DV_WAIT_SIMQ_RELEASE;
 			ahc_unlock(ahc, &s);
-			down_interruptible(&ahc->platform_data->dv_sem);
+			wait_event_interruptible(ahc->platform_data->dv_sem,
+						 AHC_WAIT_FOR_SIMQ_RELEASE);
 			ahc_lock(ahc, &s);
 		}
 		ahc_unlock(ahc, &s);
@@ -2291,7 +2275,9 @@
 		 */
 		ahc_linux_release_simq((u_long)ahc);
 	}
-	up(&ahc->platform_data->eh_sem);
+	/* Mark it as gone */
+	ahc->platform_data->dv_pid = 0;
+	complete(&ahc->platform_data->dv_exit);
 	return (0);
 }
 
@@ -2454,7 +2440,9 @@
 #else
 		spin_unlock_irqrestore(&io_request_lock, s);
 #endif
-		down_interruptible(&ahc->platform_data->dv_cmd_sem);
+		wait_event_interruptible(ahc->platform_data->dv_cmd_sem,
+					 !timer_pending(&cmd->eh_timeout));
+					 
 		/*
 		 * Wait for the SIMQ to be released so that DV is the
 		 * only reason the queue is frozen.
@@ -2463,7 +2451,8 @@
 		while (AHC_DV_SIMQ_FROZEN(ahc) == 0) {
 			ahc->platform_data->flags |= AHC_DV_WAIT_SIMQ_RELEASE;
 			ahc_unlock(ahc, &s);
-			down_interruptible(&ahc->platform_data->dv_sem);
+			wait_event_interruptible(ahc->platform_data->dv_sem,
+						 AHC_WAIT_FOR_SIMQ_RELEASE);
 			ahc_lock(ahc, &s);
 		}
 		ahc_unlock(ahc, &s);
@@ -3404,7 +3393,7 @@
 #endif
 
 	/* Wake up the state machine */
-	up(&ahc->platform_data->dv_cmd_sem);
+	wake_up(&ahc->platform_data->dv_cmd_sem);
 }
 
 static void
@@ -4164,7 +4153,7 @@
 			ahc_set_transaction_status(scb, CAM_CMD_TIMEOUT);
 		if ((ahc->platform_data->flags & AHC_UP_EH_SEMAPHORE) != 0) {
 			ahc->platform_data->flags &= ~AHC_UP_EH_SEMAPHORE;
-			up(&ahc->platform_data->eh_sem);
+			wake_up(&ahc->platform_data->eh_sem);
 		}
 	}
 
@@ -4174,7 +4163,7 @@
 	if ((ahc->platform_data->flags & AHC_DV_WAIT_SIMQ_EMPTY) != 0
 	 && LIST_FIRST(&ahc->pending_scbs) == NULL) {
 		ahc->platform_data->flags &= ~AHC_DV_WAIT_SIMQ_EMPTY;
-		up(&ahc->platform_data->dv_sem);
+		wake_up(&ahc->platform_data->dv_sem);
 	}
 		
 }
@@ -4563,7 +4552,7 @@
 	ahc_lock(ahc, &s);
 	if ((ahc->platform_data->flags & AHC_UP_EH_SEMAPHORE) != 0) {
 		ahc->platform_data->flags &= ~AHC_UP_EH_SEMAPHORE;
-		up(&ahc->platform_data->eh_sem);
+		wake_up(&ahc->platform_data->eh_sem);
 	}
 	ahc_unlock(ahc, &s);
 }
@@ -4600,7 +4589,7 @@
 	if (AHC_DV_SIMQ_FROZEN(ahc)
 	 && ((ahc->platform_data->flags & AHC_DV_WAIT_SIMQ_RELEASE) != 0)) {
 		ahc->platform_data->flags &= ~AHC_DV_WAIT_SIMQ_RELEASE;
-		up(&ahc->platform_data->dv_sem);
+		wake_up(&ahc->platform_data->dv_sem);
 	}
 	ahc_schedule_runq(ahc);
 	ahc_unlock(ahc, &s);
@@ -4952,7 +4941,8 @@
 		timer.function = ahc_linux_sem_timeout;
 		add_timer(&timer);
 		printf("Recovery code sleeping\n");
-		down(&ahc->platform_data->eh_sem);
+		wait_event(ahc->platform_data->eh_sem,
+			   !(ahc->platform_data->flags & AHC_UP_EH_SEMAPHORE));
 		printf("Recovery code awake\n");
         	ret = del_timer_sync(&timer);
 		if (ret == 0) {
diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/scsi/aic7xxx/aic7xxx_osm.h 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/aic7xxx/aic7xxx_osm.h
--- 2.6.9-rc4-mm1-RT-U7/drivers/scsi/aic7xxx/aic7xxx_osm.h	2004-10-12 09:41:33.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/aic7xxx/aic7xxx_osm.h	2004-10-20 09:31:55.000000000 +0200
@@ -534,11 +534,13 @@
 	pid_t			 dv_pid;
 	struct timer_list	 completeq_timer;
 	struct timer_list	 reset_timer;
-	struct semaphore	 eh_sem;
-	struct semaphore	 dv_sem;
-	struct semaphore	 dv_cmd_sem;	/* XXX This needs to be in
-						 * the target struct
+	wait_queue_head_t	 eh_sem;
+	wait_queue_head_t	 dv_sem;
+	wait_queue_head_t	 dv_cmd_sem;	/* XXX This needs to be in
+   						 * the target struct
 						 */
+	struct completion	 dv_exit;
+	
 	struct scsi_device	*dv_scsi_dev;
 	struct Scsi_Host        *host;		/* pointer to scsi host */
 #define AHC_LINUX_NOIRQ	((uint32_t)~0)

[-- Attachment #3: sym_glue.c.diff --]
[-- Type: text/x-patch, Size: 1218 bytes --]

diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U7/drivers/scsi/sym53c8xx_2/sym_glue.c 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/sym53c8xx_2/sym_glue.c
--- 2.6.9-rc4-mm1-RT-U7/drivers/scsi/sym53c8xx_2/sym_glue.c	2004-10-12 09:41:38.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U7-work/drivers/scsi/sym53c8xx_2/sym_glue.c	2004-10-20 10:09:04.000000000 +0200
@@ -135,7 +135,7 @@
  *  It is allocated on the eh thread stack.
  */
 struct sym_eh_wait {
-	struct semaphore sem;
+	struct completion done;
 	struct timer_list timer;
 	void (*old_done)(struct scsi_cmnd *);
 	int to_do;
@@ -798,7 +798,7 @@
 
 	/* Wake up the eh thread if it wants to sleep */
 	if (ep->to_do == SYM_EH_DO_WAIT)
-		up(&ep->sem);
+		complete(&ep->done);
 }
 
 /*
@@ -858,7 +858,7 @@
 	case SYM_EH_DO_IGNORE:
 		break;
 	case SYM_EH_DO_WAIT:
-		init_MUTEX_LOCKED(&ep->sem);
+		init_completion(&ep->done);
 		/* fall through */
 	case SYM_EH_DO_COMPLETE:
 		ep->old_done = cmd->scsi_done;
@@ -909,7 +909,7 @@
 		ep->timed_out = 1;	/* Be pessimistic for once :) */
 		add_timer(&ep->timer);
 		spin_unlock_irq(np->s.host->host_lock);
-		down(&ep->sem);
+		wait_for_completion(&ep->done);
 		spin_lock_irq(np->s.host->host_lock);
 		if (ep->timed_out)
 			sts = -2;

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
@ 2004-10-20 10:04                             ` Ingo Molnar
  2004-10-20 10:32                               ` Rui Nuno Capela
  2004-10-20 10:38                             ` Michal Schmidt
                                               ` (8 subsequent siblings)
  9 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20 10:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


> Changes since -U7:
> 

- fix block-loopback assert reported by Mark H Johnson, Matthew L
  Foster and Rui Nuno Capela. (usually triggers during 'make install' 
  of a kernel compile.)

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-20  9:57                                   ` Thomas Gleixner
@ 2004-10-20 10:27                                     ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20 10:27 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Fernando Pablo Lopez-Lezcano, LKML, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt


* Thomas Gleixner <tglx@linutronix.de> wrote:

> Yep, it's all the same scheme. Most of the offending code uses
> MUTEX_LOCKED in an init function and plays the down, and up from a
> different context game, which triggers the deadlock/owner verify. Not
> hard to fix, but at some places it takes a bit, until you see the
> intention of the driver hacker. 

the NFS ones seemed to be the least clear ones. I'm glad you converted
those already :-)

> The most surprising one was in driver/base. I did not expect that new
> 2.5/6 code uses those tricks too.

it is not strictly a bug, but that technique was discouraged for years -
completions are cleaner and faster for that purpose anyway. (they were
designed for what in the semaphore case is the slowpath.)

> Fixes for aic7xxx and sym53c8xx_2 attached.

Applied. The sym53c8xx_2 looks good. aic7xxx is good too except for a
minor cleanup issue: i've changed all _sem symbols to be _done symbols.
It's not a semaphore anymore, lets avoid the namespace-rotting effect. 
I've put these into -U8 so anyone hitting aic7xxx or sym53c8xx_2 should
re-download the -U8 patch. (others who have already downloaded it should
not bother.)

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 10:04                             ` Ingo Molnar
@ 2004-10-20 10:32                               ` Rui Nuno Capela
  2004-10-20 10:40                                 ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-20 10:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

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

Ingo Molnar wrote:
>
>> Changes since -U7:
>>
>
> - fix block-loopback assert reported by Mark H Johnson, Matthew L
>   Foster and Rui Nuno Capela. (usually triggers during 'make install'
>   of a kernel compile.)
>

Is this fix already on U8 ? I don't seem to get out of mkinitrd (which is
triggered by kernel make install).

OTOH, still on my laptop (P4/UP) I'm getting this very often:

RTNL: assertion failed at net/ipv4/devinet.c (1049)
 [<c0104ee4>] dump_stack+0x1e/0x20 (20)
 [<c02afa2b>] inet_dump_ifaddr+0x135/0x13a (52)
 [<c027a533>] rtnetlink_dump_all+0x92/0xaa (40)
 [<c028117f>] netlink_dump+0x6c/0x211 (56)
 [<c0280f97>] netlink_recvmsg+0x209/0x21b (92)
 [<c0268a40>] sock_recvmsg+0xcc/0xf0 (248)
 [<c026a4cc>] sys_recvmsg+0x110/0x1fb (284)
 [<c026a628>] sys_socketcall+0x71/0x234 (68)
 [<c01040a9>] sysenter_past_esp+0x52/0x71 (-8124)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x16/0x4a / (dump_stack+0x1e/0x20)


And I also found this once:

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:598!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: realtime commoncap snd_seq_oss snd_seq_midi_event
snd_seq snd_pcm_oss snd_mixer_oss snd_usb_usx2y snd_usb_lib snd_rawmidi
snd_seq_device snd_hwdep snd_ali5451 snd_ac97_codec snd_pcm snd_timer
snd_page_alloc snd soundcore prism2_cs p80211 ds yenta_socket pcmcia_core
natsemi crc32 loop subfs evdev ohci_hcd usbcore thermal processor fan
button battery ac
CPU:    0
EIP:    0060:[<c01b7e30>]    Not tainted VLI
EFLAGS: 00010202   (2.6.9-rc4-mm1-RT-U8.0)
EIP is at up_write+0x1d4/0x202
eax: d4edc000   ebx: e003f967   ecx: d4eb8d40   edx: dee04020
esi: de9b4214   edi: de9b443c   ebp: d4eddfcc   esp: d4eddfac
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process loop0 (pid: 6672, threadinfo=d4edc000 task=d4eb8d40)
Stack: c0113b01 00000001 c0384d90 c0384d60 00000282 e003f967 de9b4000
de9b443c
       d4eddfec e003f9c8 d4eb8d40 ffffffec 00000000 e003f967 00000000
00000000
       00000000 c0102305 de9b4000 00000000 00000000
Call Trace:
 [<c0104eb0>] show_stack+0x80/0x96 (28)
 [<c010504b>] show_registers+0x165/0x1de (56)
 [<c010525d>] die+0xf6/0x191 (64)
 [<c0105797>] do_invalid_op+0x10b/0x10d (188)
 [<c0104b0d>] error_code+0x2d/0x38 (100)
 [<e003f9c8>] loop_thread+0x61/0x11b [loop] (32)
 [<c0102305>] kernel_thread_helper+0x5/0xb (722608148)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: die+0x3a/0x191 / (do_invalid_op+0x10b/0x10d)
.. entry 2: print_traces+0x16/0x4a / (show_stack+0x80/0x96)

Code: e8 af f9 ff ff 89 f8 e8 f1 af f5 ff e9 35 ff ff ff 0f 0b a5 00 43 e4
2c c0 e9 da fe ff ff 0f 0b a4 00 43 e4 2c c0 e9 c4 fe ff ff <0f> 0b 56 02
cf 70 2d c0 e9 3c fe ff ff e8 d7 56 10 00 e9 22 ff


(config.gz is attached)

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: config-2.6.9-rc4-mm1-RT-U8.0.gz --]
[-- Type: application/x-gzip-compressed, Size: 8010 bytes --]

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
  2004-10-20 10:04                             ` Ingo Molnar
@ 2004-10-20 10:38                             ` Michal Schmidt
  2004-10-20 10:56                               ` Ingo Molnar
  2004-10-20 12:50                             ` Florian Schmidt
                                               ` (7 subsequent siblings)
  9 siblings, 1 reply; 951+ messages in thread
From: Michal Schmidt @ 2004-10-20 10:38 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano

Ingo Molnar wrote:
> i have released the -U8 Real-Time Preemption patch:
> 
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8
> 

I'm getting these BUGs when I use netconsole with Real-Time Preemption 
(but netconsole works):

kjournald starting.  Commit interval 5 seconds
BUG: sleeping function called from invalid context kjournald(775) at 
kernel/mutex.c:25
in_atomic():0 [00000000], irqs_disabled():1
  [<c0105fbe>] dump_stack+0x1e/0x20 (20)
  [<c01194d8>] __might_sleep+0xb8/0xd0 (36)
  [<c0130bc0>] _mutex_lock+0x20/0x40 (20)
  [<c02675f7>] netpoll_send_skb+0x37/0xc0 (28)
  [<c0231081>] write_msg+0x41/0x60 (36)
  [<c011c208>] __call_console_drivers+0x58/0x60 (32)
  [<c011c326>] call_console_drivers+0x96/0x140 (40)
  [<c011c6e1>] release_console_sem+0x71/0x100 (36)
  [<c011c5b6>] vprintk+0x116/0x180 (36)
  [<c011c498>] printk+0x18/0x20 (16)
  [<c01a31af>] kjournald+0x8f/0x250 (140)
  [<c01032d1>] kernel_thread_helper+0x5/0x14 (141484052)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x18/0x50 / (dump_stack+0x1e/0x20)

EXT3 FS on hda8, <3>BUG: sleeping function called from invalid context 
mount(786) at kernel/mutex.c:25
in_atomic():0 [00000000], irqs_disabled():1
  [<c0105fbe>] dump_stack+0x1e/0x20 (20)
  [<c01194d8>] __might_sleep+0xb8/0xd0 (36)
  [<c0130bc0>] _mutex_lock+0x20/0x40 (20)
  [<c02675f7>] netpoll_send_skb+0x37/0xc0 (28)
  [<c0231081>] write_msg+0x41/0x60 (36)
  [<c011c208>] __call_console_drivers+0x58/0x60 (32)
  [<c011c302>] call_console_drivers+0x72/0x140 (40)
  [<c011c6e1>] release_console_sem+0x71/0x100 (36)
  [<c011c5b6>] vprintk+0x116/0x180 (36)
  [<c011c498>] printk+0x18/0x20 (16)
  [<c01989f2>] ext3_setup_super+0xd2/0x1c0 (80)
  [<c019a5ed>] ext3_remount+0x12d/0x190 (48)
  [<c015d9b0>] do_remount_sb+0xa0/0xf0 (32)
  [<c0173c6d>] do_remount+0x6d/0xc0 (36)
  [<c01745fb>] do_mount+0x19b/0x1b0 (116)
  [<c01749e7>] sys_mount+0x97/0xe0 (48)
  [<c010518f>] syscall_call+0x7/0xb (-8124)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x18/0x50 / (dump_stack+0x1e/0x20)

internal journal


I have hacked the sk98lin driver to support netpoll (I sent the patch to 
netdev), so maybe I did something wrong and these BUGs are my own fault.

Does anybody else use netconsole with Real-Time Preemption?

Michal

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 10:32                               ` Rui Nuno Capela
@ 2004-10-20 10:40                                 ` Ingo Molnar
  2004-10-20 11:31                                   ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20 10:40 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> Ingo Molnar wrote:
> >
> >> Changes since -U7:
> >>
> >
> > - fix block-loopback assert reported by Mark H Johnson, Matthew L
> >   Foster and Rui Nuno Capela. (usually triggers during 'make install'
> >   of a kernel compile.)
> >
> 
> Is this fix already on U8 ? I don't seem to get out of mkinitrd (which
> is triggered by kernel make install).

please re-download -U8, i've updated it a couple of minutes after
uploading it, but apparently not fast enough :-| Sorry!

> OTOH, still on my laptop (P4/UP) I'm getting this very often:
> 
> RTNL: assertion failed at net/ipv4/devinet.c (1049)

yeah - this too was an oversight i fixed in the latest upload.

> ------------[ cut here ]------------
> kernel BUG at lib/rwsem-generic.c:598!

>  [<c0104b0d>] error_code+0x2d/0x38 (100)
>  [<e003f9c8>] loop_thread+0x61/0x11b [loop] (32)
>  [<c0102305>] kernel_thread_helper+0x5/0xb (722608148)

yes, this is the loopback fix. Please-retry with the latest patch.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 10:38                             ` Michal Schmidt
@ 2004-10-20 10:56                               ` Ingo Molnar
  2004-10-20 11:01                                 ` Michal Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20 10:56 UTC (permalink / raw)
  To: Michal Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano


* Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:

> I'm getting these BUGs when I use netconsole with Real-Time Preemption
> (but netconsole works):

you are getting them because interrupts get disabled somewhere in the
path. Do your changes perhaps introduce a local_irq_save() or
local_irq_disable()?

(in PREEMPT_REALTIME spin_lock_irq*() does not disable interrupts for
mutex-based spinlocks, so the only way to get irqs disabled is
explicitly.)

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 10:56                               ` Ingo Molnar
@ 2004-10-20 11:01                                 ` Michal Schmidt
  2004-10-20 12:04                                   ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Michal Schmidt @ 2004-10-20 11:01 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano

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

Ingo Molnar wrote:
> * Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:
>>I'm getting these BUGs when I use netconsole with Real-Time Preemption
>>(but netconsole works):
> 
> 
> you are getting them because interrupts get disabled somewhere in the
> path. Do your changes perhaps introduce a local_irq_save() or
> local_irq_disable()?
> 

I'm attaching my sk98lin patch. It uses disable_irq(). It's inspired by 
8139too.

> (in PREEMPT_REALTIME spin_lock_irq*() does not disable interrupts for
> mutex-based spinlocks, so the only way to get irqs disabled is
> explicitly.)
> 
> 	Ingo

Michal

[-- Attachment #2: sk98lin-netpoll2.diff --]
[-- Type: text/plain, Size: 1190 bytes --]

diff -Nurp linux-2.6.9/drivers/net/sk98lin/skge.c linux-2.6.9-mich/drivers/net/sk98lin/skge.c
--- linux-2.6.9/drivers/net/sk98lin/skge.c	2004-10-18 23:53:22.000000000 +0200
+++ linux-2.6.9-mich/drivers/net/sk98lin/skge.c	2004-10-20 01:09:07.566181320 +0200
@@ -1126,6 +1126,21 @@ SK_U32		IntSrc;		/* interrupts source re
 		return SkIsrRetHandled;
 } /* SkGeIsrOnePort */
 
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/**
+ * SkGePollController - polling receive, for netconsole
+ * @dev: network device
+ *
+ * Polling receive - used by netconsole and other diagnostic tools
+ * to allow network i/o with interrupts disabled.
+ */
+static void SkGePollController(struct net_device *dev)
+{
+	disable_irq(dev->irq);
+	SkGeIsr(dev->irq, dev, NULL);
+	enable_irq(dev->irq);
+}
+#endif
 
 /****************************************************************************
  *
@@ -4960,6 +4975,9 @@ static int __devinit skge_probe_one(stru
 	dev->set_mac_address =	&SkGeSetMacAddr;
 	dev->do_ioctl =		&SkGeIoctl;
 	dev->change_mtu =	&SkGeChangeMtu;
+#ifdef CONFIG_NET_POLL_CONTROLLER
+	dev->poll_controller =	&SkGePollController;
+#endif
 	dev->flags &= 		~IFF_RUNNING;
 	SET_NETDEV_DEV(dev, &pdev->dev);
 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 10:40                                 ` Ingo Molnar
@ 2004-10-20 11:31                                   ` Rui Nuno Capela
  2004-10-20 11:43                                     ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-20 11:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Ingo Molnar wrote:
>
>Rui Nuno Capela wrote:
>> >
>> > - fix block-loopback assert reported by Mark H Johnson, Matthew L
>> >   Foster and Rui Nuno Capela. (usually triggers during 'make install'
>> >   of a kernel compile.)
>> >
>>
>> Is this fix already on U8 ? I don't seem to get out of mkinitrd (which
>> is triggered by kernel make install).
>
> please re-download -U8, i've updated it a couple of minutes after
> uploading it, but apparently not fast enough :-| Sorry!
>

OK. No problem.... and yes, mkinitrd (make install) works again.


>> OTOH, still on my laptop (P4/UP) I'm getting this very often:
>>
>> RTNL: assertion failed at net/ipv4/devinet.c (1049)
>
> yeah - this too was an oversight i fixed in the latest upload.

I don't think so. I still see plenty of those here.

Is there an even more recent U8? I think you should consider add some dot
numbering to each of the uploads... ;)

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 11:31                                   ` Rui Nuno Capela
@ 2004-10-20 11:43                                     ` Ingo Molnar
  2004-10-20 12:40                                       ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20 11:43 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> > please re-download -U8, i've updated it a couple of minutes after
> > uploading it, but apparently not fast enough :-| Sorry!
> >
> 
> OK. No problem.... and yes, mkinitrd (make install) works again.

good.

> >> RTNL: assertion failed at net/ipv4/devinet.c (1049)
> >
> > yeah - this too was an oversight i fixed in the latest upload.
> 
> I don't think so. I still see plenty of those here.
> 
> Is there an even more recent U8? I think you should consider add some
> dot numbering to each of the uploads... ;)

indeed this most likely means there's a newer update :-| Please 
double-check that the one you have is:

 $ md5sum realtime-preempt-2.6.9-rc4-mm1-U8
 b59ae00ca0f45f545519348113af5c4f  realtime-preempt-2.6.9-rc4-mm1-U8

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 11:01                                 ` Michal Schmidt
@ 2004-10-20 12:04                                   ` Ingo Molnar
  2004-10-20 21:34                                     ` Michal Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20 12:04 UTC (permalink / raw)
  To: Michal Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano


* Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:

> Ingo Molnar wrote:
> >* Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:
> >>I'm getting these BUGs when I use netconsole with Real-Time Preemption
> >>(but netconsole works):
> >
> >
> >you are getting them because interrupts get disabled somewhere in the
> >path. Do your changes perhaps introduce a local_irq_save() or
> >local_irq_disable()?
> >
> 
> I'm attaching my sk98lin patch. It uses disable_irq(). It's inspired
> by 8139too.

disable_irq() should work fine though. (it doesnt disable local
interrupts, it only disables that particular irq line.) So something
else disabled interrupts - ah, netconsole.c itself. Does the patch below
fix things up for you?

	Ingo

--- linux/drivers/net/netconsole.c.orig
+++ linux/drivers/net/netconsole.c
@@ -73,7 +73,9 @@ static void write_msg(struct console *co
 	if (!np.dev)
 		return;
 
+#ifndef CONFIG_PREEMPT_REALTIME
 	local_irq_save(flags);
+#endif
 
 	for(left = len; left; ) {
 		frag = min(left, MAX_PRINT_CHUNK);
@@ -82,7 +84,9 @@ static void write_msg(struct console *co
 		left -= frag;
 	}
 
+#ifndef CONFIG_PREEMPT_REALTIME
 	local_irq_restore(flags);
+#endif
 }
 
 static struct console netconsole = {

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 11:43                                     ` Ingo Molnar
@ 2004-10-20 12:40                                       ` Rui Nuno Capela
  0 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-20 12:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Ingo Molnar wrote:
>
>> >> RTNL: assertion failed at net/ipv4/devinet.c (1049)
>> >
>> > yeah - this too was an oversight i fixed in the latest upload.
>>
>> I don't think so. I still see plenty of those here.
>>
>> Is there an even more recent U8? I think you should consider add some
>> dot numbering to each of the uploads... ;)
>
> indeed this most likely means there's a newer update :-| Please
> double-check that the one you have is:
>
>  $ md5sum realtime-preempt-2.6.9-rc4-mm1-U8
>  b59ae00ca0f45f545519348113af5c4f  realtime-preempt-2.6.9-rc4-mm1-U8
>

That was it. Thanks.

Now's some bad news:

I getting the dump below, this time while plugging a flash memory stick,
but right after that the system starts to behave preety bad and
increasingly unresponsive. An hard-boot is almost the end of the (short)
story :(

(e.g. running jackd also hoses the complete system in no reproducible
amount of time--sometimes short, other times long, like a random
time-bomb).


ohci_hcd 0000:00:0f.0: wakeup
usb 2-1: new full speed USB device using address 2
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:598!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: usb_storage vfat fat udf isofs nls_base realtime
commoncap snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss
snd_usb_usx2y snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd_ali5451
snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore prism2_cs
p80211 ds yenta_socket pcmcia_core natsemi crc32 loop subfs evdev ohci_hcd
usbcore thermal processor fan button battery ac
CPU:    0
EIP:    0060:[<c01b7e30>]    Not tainted VLI
EFLAGS: 00010206   (2.6.9-rc4-mm1-RT-U8.3)
EIP is at up_write+0x1d4/0x202
eax: d2b2a000   ebx: 00000292   ecx: d2afe980   edx: d2ad4f40
esi: d7b83b24   edi: dcb21000   ebp: d2b2bd6c   esp: d2b2bd4c
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process usb-stor (pid: 6699, threadinfo=d2b2a000 task=d2ad48b0)
Stack: d2ad48b0 d2b2bd78 c02bea7f 00000001 d2ad48b0 00000292 d2afe980
dcb21000
       d2b2bd84 e01ca139 d2afe980 d2b2bd84 00000292 dcb21138 d2b2bdac
c022ed18
       d2afe980 c022ef1c c0231679 00000000 d2afe9d4 d2afe980 d2aa3800
dcb21000
Call Trace:
 [<c0104eb0>] show_stack+0x80/0x96 (28)
 [<c010504b>] show_registers+0x165/0x1de (56)
 [<c010525d>] die+0xf6/0x191 (64)
 [<c0105797>] do_invalid_op+0x10b/0x10d (188)
 [<c0104b0d>] error_code+0x2d/0x38 (100)
 [<e01ca139>] queuecommand+0x70/0x7c [usb_storage] (24)
 [<c022ed18>] scsi_dispatch_cmd+0x168/0x218 (40)
 [<c02342ed>] scsi_request_fn+0x1ee/0x42b (52)
 [<c0205612>] blk_insert_request+0xcd/0xfb (44)
 [<c0232f4f>] scsi_insert_special_req+0x3b/0x3f (28)
 [<c0233181>] scsi_wait_req+0x61/0x94 (60)
 [<c023529c>] scsi_probe_lun+0x8e/0x240 (68)
 [<c023588f>] scsi_probe_and_add_lun+0xb0/0x1be (48)
 [<c0236015>] scsi_scan_target+0xa4/0x123 (60)
 [<c0236121>] scsi_scan_channel+0x8d/0xa4 (48)
 [<c02361b1>] scsi_scan_host_selected+0x79/0xd4 (44)
 [<c023623d>] scsi_scan_host+0x31/0x33 (28)
 [<e01cccbd>] usb_stor_scan_thread+0x144/0x155 [usb_storage] (96)
 [<c0102305>] kernel_thread_helper+0x5/0xb (760037396)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: die+0x3a/0x191 / (do_invalid_op+0x10b/0x10d)
.. entry 2: print_traces+0x16/0x4a / (show_stack+0x80/0x96)

Code: e8 af f9 ff ff 89 f8 e8 f1 af f5 ff e9 35 ff ff ff 0f 0b a5 00 e3 e8
2c c0 e9 da fe ff ff 0f 0b a4 00 e3 e8 2c c0 e9 c4 fe ff ff <0f> 0b 56 02
6f 75 2d c0 e9 3c fe ff ff e8 7f 5b 10 00 e9 22 ff

Bye.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
  2004-10-20 10:04                             ` Ingo Molnar
  2004-10-20 10:38                             ` Michal Schmidt
@ 2004-10-20 12:50                             ` Florian Schmidt
  2004-10-20 12:55                               ` Ingo Molnar
  2004-10-20 12:52                             ` Lorenzo Allegrucci
                                               ` (6 subsequent siblings)
  9 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-20 12:50 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Wed, 20 Oct 2004 11:45:08 +0200
Ingo Molnar <mingo@elte.hu> wrote:

>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

Hi,

i just wanted to let you know that with U8 i still experience the "pauses" i
reported on U6, too. I would guess that it's some scheduler thing as jackd
running SCHED_FIFO and all its clients (at least the audio threads running
SCHED_FIFO) are not affected by the pauses (i don't see any xruns from jackd
and audio processing happily goes along without audible dropouts).

Also it seems that /proc/sys/kernel/trace_enabled == 1 is not the only thing
being able to trigger the pauses. With U6 i also experienced them with
trace_enabled == 0. I have to add though that it took quite a while for them
to kick in (hours) after setting trace_enabled to 0. So my conclusion is
that trace_enabled == 1 just increases the probability of such pauses by
several magnitudes (with 1 i get about one of these pauses per 2-10 minutes,
with 0 it took several hours for the first pause to occur and then they
stayed less frequent than with 1).

Ah and i forgot: dmesg -n 1 does not help..

flo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
                                               ` (2 preceding siblings ...)
  2004-10-20 12:50                             ` Florian Schmidt
@ 2004-10-20 12:52                             ` Lorenzo Allegrucci
  2004-10-20 12:56                               ` Ingo Molnar
  2004-10-20 16:27                             ` Adam Heath
                                               ` (5 subsequent siblings)
  9 siblings, 1 reply; 951+ messages in thread
From: Lorenzo Allegrucci @ 2004-10-20 12:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Wednesday 20 October 2004 11:45, Ingo Molnar wrote:
> 
> i have released the -U8 Real-Time Preemption patch:
> 
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:598!
invalid operand: 0000 [#1]
PREEMPT 
Modules linked in: irtty_sir sir_dev irda crc_ccitt usbcore lp ipv6 dm_mod it87 i2c_isa i2c
CPU:    0
EIP:    0060:[<c01dfa5b>]    Not tainted VLI
EFLAGS: 00010287   (2.6.9-rc4-mm1-RT-U8) 
EIP is at up_write+0x1eb/0x200
eax: de848000   ebx: df3a255c   ecx: 0000001f   edx: c14e3260
esi: df3a24c8   edi: de848000   ebp: de849f7c   esp: de849f5c
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process kIrDAd (pid: 1295, threadinfo=de848000 task=df3d6110)
Stack: e09119bb de849f74 c0111590 df3a2400 0000001f df3a255c e0915000 de848000 
       de849f94 e09119bb df3a2400 00000282 de849fc4 00000000 de849fec e0911ae2 
       e09129c2 de849fb8 00000000 df3d6110 c01148d0 00000000 00000000 de84ff08 
Call Trace:
 [<e09119bb>] run_irda_queue+0x5b/0xd0 [sir_dev] (4)
 [<c0111590>] mcount+0x14/0x18 (8)
 [<e09119bb>] run_irda_queue+0x5b/0xd0 [sir_dev] (28)
 [<e0911ae2>] irda_thread+0xb2/0xf0 [sir_dev] (24)
 [<c01148d0>] default_wake_function+0x0/0x20 (20)
 [<c010612a>] ret_from_fork+0x6/0x14 (16)
 [<c01148d0>] default_wake_function+0x0/0x20 (16)
 [<e0911a30>] irda_thread+0x0/0xf0 [sir_dev] (24)
 [<c0104319>] kernel_thread_helper+0x5/0xc (12)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: die+0x3f/0x1a0 / (do_invalid_op+0x106/0x110)
.. entry 2: print_traces+0x1d/0x80 / (show_stack+0x83/0xa0)

Code: ff e9 44 ff ff ff 0f 0b a5 00 13 ce 2e c0 eb b6 0f 0b a4 00 13 ce 2e c0 eb a5 c7 04 2
 (events/0/3/CPU#0): new 785 us maximum-latency critical section.
 => started at timestamp 193385865: <kernel_fpu_begin+0x21/0x60>
 =>   ended at timestamp 193386650: <_mmx_memcpy+0x131/0x180>
 [<c012f070>] sub_preempt_count+0x60/0x90 (4)
 [<c012ed5e>] check_preempt_timing+0x15e/0x270 (8)
 [<c01e1a11>] _mmx_memcpy+0x131/0x180 (8)
 [<c012f070>] sub_preempt_count+0x60/0x90 (64)
 [<c01e1a11>] _mmx_memcpy+0x131/0x180 (8)
 [<c01e1a11>] _mmx_memcpy+0x131/0x180 (16)
 [<c01ee1d0>] vgacon_save_screen+0x80/0x90 (28)
 [<c021ba89>] redraw_screen+0x199/0x270 (28)
 [<c012e4ed>] __mcount+0x1d/0x20 (12)
 [<c0216d61>] complete_change_console+0x11/0x100 (4)
 [<c021ec86>] console_callback+0xe6/0xf0 (4)
 [<c0216d89>] complete_change_console+0x39/0x100 (28)
 [<c021ec86>] console_callback+0xe6/0xf0 (28)
 [<c0128e63>] worker_thread+0x1d3/0x2a0 (20)
 [<c021eba0>] console_callback+0x0/0xf0 (28)
 [<c01148d0>] default_wake_function+0x0/0x20 (28)
 [<c01148d0>] default_wake_function+0x0/0x20 (32)
 [<c0111590>] mcount+0x14/0x18 (12)
 [<c012d26a>] kthread+0xaa/0xb0 (28)
 [<c0128c90>] worker_thread+0x0/0x2a0 (20)
 [<c012d1c0>] kthread+0x0/0xb0 (12)
 [<c0104319>] kernel_thread_helper+0x5/0xc (16)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: kernel_fpu_begin+0x21/0x60 / (_mmx_memcpy+0x36/0x180)
.. entry 2: print_traces+0x1d/0x80 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 193387119

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 12:50                             ` Florian Schmidt
@ 2004-10-20 12:55                               ` Ingo Molnar
  2004-10-20 13:25                                 ` Florian Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20 12:55 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> i just wanted to let you know that with U8 i still experience the
> "pauses" i reported on U6, too. I would guess that it's some scheduler
> thing as jackd running SCHED_FIFO and all its clients (at least the
> audio threads running SCHED_FIFO) are not affected by the pauses (i
> don't see any xruns from jackd and audio processing happily goes along
> without audible dropouts).

ok.

> Also it seems that /proc/sys/kernel/trace_enabled == 1 is not the only
> thing being able to trigger the pauses. With U6 i also experienced
> them with trace_enabled == 0. I have to add though that it took quite
> a while for them to kick in (hours) after setting trace_enabled to 0.
> So my conclusion is that trace_enabled == 1 just increases the
> probability of such pauses by several magnitudes (with 1 i get about
> one of these pauses per 2-10 minutes, with 0 it took several hours for
> the first pause to occur and then they stayed less frequent than with
> 1).

i dont think it's caused by trace_enabled - the trace you sent last time
clearly showed erratic behavior. There's one piece of code i suspect in
particular - could you try the patch below ontop of -U8? (i have
compile- and boot- tested it)

	Ingo

--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -2764,6 +2764,8 @@ need_resched:
 		else
 			deactivate_task(prev, rq);
 	}
+	if (preempt_count() & PREEMPT_ACTIVE)
+		sub_preempt_count(PREEMPT_ACTIVE);
 	if (unlikely(prev->flags & PF_DEAD)) {
 		BUG_ON(prev->state != TASK_RUNNING);
 		prev->state = __TASK_DEAD;
@@ -2940,6 +2942,7 @@ asmlinkage void __sched preempt_schedule
 		return;
 
 need_resched:
+	local_irq_disable();
 	add_preempt_count(PREEMPT_ACTIVE);
 	/*
 	 * We keep the big kernel semaphore locked, but we
@@ -2950,11 +2953,10 @@ need_resched:
 	saved_lock_depth = task->lock_depth;
 	task->lock_depth = -1;
 #endif
-	schedule();
+	__schedule();
 #ifdef CONFIG_PREEMPT_BKL
 	task->lock_depth = saved_lock_depth;
 #endif
-	sub_preempt_count(PREEMPT_ACTIVE);
 
 	/* we could miss a preemption opportunity between schedule and now */
 	barrier();
@@ -3002,7 +3004,6 @@ need_resched:
 #ifdef CONFIG_PREEMPT_BKL
 	task->lock_depth = saved_lock_depth;
 #endif
-	sub_preempt_count(PREEMPT_ACTIVE);
 
 	/* we could miss a preemption opportunity between schedule and now */
 	barrier();
@@ -3842,9 +3843,9 @@ static inline void __cond_resched(void)
 	if (preempt_count() & PREEMPT_ACTIVE)
 		return;
 	do {
+		local_irq_disable();
 		add_preempt_count(PREEMPT_ACTIVE);
-		schedule();
-		sub_preempt_count(PREEMPT_ACTIVE);
+		__schedule();
 	} while (need_resched());
 }
 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 12:52                             ` Lorenzo Allegrucci
@ 2004-10-20 12:56                               ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20 12:56 UTC (permalink / raw)
  To: Lorenzo Allegrucci
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Lorenzo Allegrucci <l_allegrucci@yahoo.it> wrote:

> Process kIrDAd (pid: 1295, threadinfo=de848000 task=df3d6110)

> Call Trace:
>  [<e09119bb>] run_irda_queue+0x5b/0xd0 [sir_dev] (4)
>  [<c0111590>] mcount+0x14/0x18 (8)
>  [<e09119bb>] run_irda_queue+0x5b/0xd0 [sir_dev] (28)
>  [<e0911ae2>] irda_thread+0xb2/0xf0 [sir_dev] (24)

ok - IRDA too needs fixing. Disable CONFIG_IRDA for the time being.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 13:25                                 ` Florian Schmidt
@ 2004-10-20 13:24                                   ` Ingo Molnar
  2004-10-20 14:24                                   ` Florian Schmidt
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20 13:24 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> > i dont think it's caused by trace_enabled - the trace you sent last time
> > clearly showed erratic behavior. There's one piece of code i suspect in
> > particular - could you try the patch below ontop of -U8? (i have
> > compile- and boot- tested it)
> 
> mango:/usr/src/linux-2.6.9-rc4-mm1-U8# patch -p1 </home/tapas/foo.patch 
> patching file kernel/sched.c
> Hunk #5 succeeded at 3843 with fuzz 1.
> 
> building anyways, reporting later..

never worry about a fuzz when applying patches - as long as you dont get
a reject it should be ok.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 12:55                               ` Ingo Molnar
@ 2004-10-20 13:25                                 ` Florian Schmidt
  2004-10-20 13:24                                   ` Ingo Molnar
  2004-10-20 14:24                                   ` Florian Schmidt
  0 siblings, 2 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-20 13:25 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Wed, 20 Oct 2004 14:55:00 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> i dont think it's caused by trace_enabled - the trace you sent last time
> clearly showed erratic behavior. There's one piece of code i suspect in
> particular - could you try the patch below ontop of -U8? (i have
> compile- and boot- tested it)

mango:/usr/src/linux-2.6.9-rc4-mm1-U8# patch -p1 </home/tapas/foo.patch 
patching file kernel/sched.c
Hunk #5 succeeded at 3843 with fuzz 1.

building anyways, reporting later..

flo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 14:24                                   ` Florian Schmidt
@ 2004-10-20 14:18                                     ` Ingo Molnar
  2004-10-20 14:53                                       ` Florian Schmidt
  2004-10-20 15:37                                       ` Lee Revell
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-20 14:18 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> Hi,
> 
> it seems that the pauses went away with that patch. [...]

great! I've uploaded -U8.1 with this fix included:

  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8.1

> And on this bootup the pauses are still gone, but as soon as i echo'ed
> 1 into trace_enabled the mouse started to become very skippy (update
> freq at about 3hz). Keyboard is fine though.. putting trace_enabled
> back to 0 doesn't fix it. I suppose it's just a matter of time until
> the next lockup. We'll see though..
> 
> Syslog only sees critical section timing reports, no BUG's afaics.

note that the keyboard and USB interrupts are SCHED_OTHER by default, so
they could be delayed quite long depending on the workload. To avoid
that i'd suggest to:

        chrt --fifo --pid 30 `pidof 'IRQ 1'`
        chrt --fifo --pid 30 `pidof 'IRQ 12'`

(do this for every IRQ you have for input devices.) This puts them below
jackd's priority (which is FIFO 50 iirc) but above all SCHED_OTHER
tasks. The soundcard IRQ i guess you have chrt-ed already?

or did you have them on SCHED_FIFO already?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 13:25                                 ` Florian Schmidt
  2004-10-20 13:24                                   ` Ingo Molnar
@ 2004-10-20 14:24                                   ` Florian Schmidt
  2004-10-20 14:18                                     ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-20 14:24 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Wed, 20 Oct 2004 15:25:07 +0200
Florian Schmidt <mista.tapas@gmx.net> wrote:

> On Wed, 20 Oct 2004 14:55:00 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > i dont think it's caused by trace_enabled - the trace you sent last time
> > clearly showed erratic behavior. There's one piece of code i suspect in
> > particular - could you try the patch below ontop of -U8? (i have
> > compile- and boot- tested it)
> 
> mango:/usr/src/linux-2.6.9-rc4-mm1-U8# patch -p1 </home/tapas/foo.patch 
> patching file kernel/sched.c
> Hunk #5 succeeded at 3843 with fuzz 1.
> 
> building anyways, reporting later..

Hi,

it seems that the pauses went away with that patch. The system is showing a
different weird behaviour now. On last bootup the machine slowly died away
(first my email program froze upon checking for mail, then starting top
would just hang the respective xterm. ps still ran and procuced output [i
didn't capture it though, doh], other stuff would hang, too. upon
ctrl-alt-bkspc to kill the x server, it all locked up.. i have no serial
console or other machine to test if it was still up in any way.

And on this bootup the pauses are still gone, but as soon as i echo'ed 1
into trace_enabled the mouse started to become very skippy (update freq at
about 3hz). Keyboard is fine though.. putting trace_enabled back to 0
doesn't fix it. I suppose it's just a matter of time until the next lockup.
We'll see though..

Syslog only sees critical section timing reports, no BUG's afaics.

flo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 14:18                                     ` Ingo Molnar
@ 2004-10-20 14:53                                       ` Florian Schmidt
  2004-10-20 15:08                                         ` Florian Schmidt
  2004-10-20 15:37                                       ` Lee Revell
  1 sibling, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-20 14:53 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Wed, 20 Oct 2004 16:18:22 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> note that the keyboard and USB interrupts are SCHED_OTHER by default, so
> they could be delayed quite long depending on the workload. To avoid
> that i'd suggest to:
> 
>         chrt --fifo --pid 30 `pidof 'IRQ 1'`
>         chrt --fifo --pid 30 `pidof 'IRQ 12'`
> 
> (do this for every IRQ you have for input devices.) This puts them below
> jackd's priority (which is FIFO 50 iirc) but above all SCHED_OTHER
> tasks. The soundcard IRQ i guess you have chrt-ed already?
> 
> or did you have them on SCHED_FIFO already?

setting them to SCHED_FIFO even with a prio of 99 won't help. will try
rebooting to see if it's reproducable 

flo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 14:53                                       ` Florian Schmidt
@ 2004-10-20 15:08                                         ` Florian Schmidt
  0 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-20 15:08 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Wed, 20 Oct 2004 16:53:26 +0200
Florian Schmidt <mista.tapas@gmx.net> wrote:

> setting them to SCHED_FIFO even with a prio of 99 won't help. will try
> rebooting to see if it's reproducable 
> 
> flo

ok, it seems it was coincidence that the mouse skipping started at the time
of my echo 1 > trace_enabled.. This time it just started sometime after
boot. The scheduler class of the different irq's seems to have no influence
[i experimented with SCHED_FIFO and SCHED_OTHER for irq 1, 8, 12 and 3 and 10
[the latter two are my soundcards irq's].

~$ cat /proc/interrupts 
           CPU0       
  0:     480317          XT-PIC  timer  0/80317
  1:       1731          XT-PIC  i8042  0/1731
  2:          0          XT-PIC  cascade  0/0
  3:      10828          XT-PIC  CS46XX  0/10828
  5:        390          XT-PIC  eth0  0/390
  8:          4          XT-PIC  rtc  0/4
 10:     251556          XT-PIC  SiS SI7012  0/51556
 12:      16605          XT-PIC  i8042  0/16604
 14:       1151          XT-PIC  ide0  0/1151
 15:      26537          XT-PIC  ide1  0/26537
NMI:          0 
ERR:          0

Btw: i just experienced two pauses again, so the patch didn't really fix it
:( hrmm..

I get the feeling that something indeterministic is going on. Still no BUG's
in either dmesg output nor in the syslog.

 flo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 14:18                                     ` Ingo Molnar
  2004-10-20 14:53                                       ` Florian Schmidt
@ 2004-10-20 15:37                                       ` Lee Revell
  1 sibling, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-20 15:37 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Florian Schmidt, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Wed, 2004-10-20 at 10:18, Ingo Molnar wrote:
> note that the keyboard and USB interrupts are SCHED_OTHER by default, so
> they could be delayed quite long depending on the workload.

Why is this the default behavior?  It seems like you would want all IRQ
threads to be SCHED_FIFO by default.   Otherwise it seems like the
scheduler could decide to run a normal userspace process (like, say, X)
while an IRQ thread is runnable.

Is it really a good idea for IRQ threads to be subject to the whims of
the scheduler?

Also, on modern machines, this would effectively make all IRQ threads
SCHED_OTHER because the USB port shares an interrupt with everything:

  0:   36676353          XT-PIC  timer  0/76353
  1:       8759          XT-PIC  i8042  5/8759
  2:          0          XT-PIC  cascade  0/0
  8:          4          XT-PIC  rtc  0/4
 10:          0          XT-PIC  uhci_hcd  0/0
 11:     210713          XT-PIC  uhci_hcd, eth0  0/10713
 12:          0          XT-PIC  uhci_hcd  0/0
 15:      79277          XT-PIC  ide1  0/79276
NMI:          0
ERR:          0

Lee



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
                                               ` (3 preceding siblings ...)
  2004-10-20 12:52                             ` Lorenzo Allegrucci
@ 2004-10-20 16:27                             ` Adam Heath
  2004-10-21 16:59                               ` Adam Heath
  2004-10-20 17:49                             ` Alexander Batyrshin
                                               ` (4 subsequent siblings)
  9 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-10-20 16:27 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Wed, 20 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U8 Real-Time Preemption patch:
>
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8

Grr.  I got this -U8 mail *before* I got the -U7 mail.

All thruout these U# kernels, I get stalls in X(everything pauses, not sure if
remote pings stop).  Nothing shows in dmesg when this occurs.

I had been running rc kernels for awhile, without these problems.  I had not
run any mm kernels, but I have run all the U kernels(but not U7).

Compiling/rebooting.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6
  2004-10-19 12:46                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Ingo Molnar
                                           ` (4 preceding siblings ...)
  2004-10-19 20:52                         ` Michal Schmidt
@ 2004-10-20 16:31                         ` Adam Heath
  5 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-20 16:31 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Tue, 19 Oct 2004, Ingo Molnar wrote:

>
> i have released the -U6 Real-Time Preemption patch:
>
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U6

Got these high-latency values during the night on U6(haven't booted U8 yet).

IRQ 5/431/CPU#0): 612 us critical section violates 100 us threshold.
 => started at timestamp 4167601478: <call_console_drivers+0x76/0x140>
 =>   ended at timestamp 4167602090: <finish_task_switch+0x43/0xb0>
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c01324de>] check_preempt_timing+0x15e/0x270
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c02a5717>] __sched_text_start+0x2d7/0x5d0
 [<c0113104>] mcount+0x14/0x18
 [<c013bdfa>] do_irqd+0x5a/0x80
 [<c01309ea>] kthread+0xaa/0xb0
 [<c013bda0>] do_irqd+0x0/0x80
 [<c0130940>] kthread+0x0/0xb0
 [<c0104099>] kernel_thread_helper+0x5/0xc
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __sched_text_start+0x3b/0x5d0 / (do_irqd+0x5a/0x80)
.. entry 2: print_traces+0x1d/0x80 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 4167602447

(IRQ 5/431/CPU#0): 34875 us critical section violates 100 us threshold.
 => started at timestamp 4167608224: <call_console_drivers+0x76/0x140>
 =>   ended at timestamp 4167643099: <finish_task_switch+0x43/0xb0>
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c01324de>] check_preempt_timing+0x15e/0x270
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c02a5717>] __sched_text_start+0x2d7/0x5d0
 [<c0113104>] mcount+0x14/0x18
 [<c013bdfa>] do_irqd+0x5a/0x80
 [<c01309ea>] kthread+0xaa/0xb0
 [<c013bda0>] do_irqd+0x0/0x80
 [<c0130940>] kthread+0x0/0xb0
 [<c0104099>] kernel_thread_helper+0x5/0xc
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __sched_text_start+0x3b/0x5d0 / (do_irqd+0x5a/0x80)
.. entry 2: print_traces+0x1d/0x80 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 4167643459

(IRQ 1/18/CPU#0): 30560 us critical section violates 100 us threshold.
 => started at timestamp 4167647182: <call_console_drivers+0x76/0x140>
 =>   ended at timestamp 4167677742: <finish_task_switch+0x43/0xb0>
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c01324de>] check_preempt_timing+0x15e/0x270
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c02a5717>] __sched_text_start+0x2d7/0x5d0
 [<c0113104>] mcount+0x14/0x18
 [<c013bdfa>] do_irqd+0x5a/0x80
 [<c01309ea>] kthread+0xaa/0xb0
 [<c013bda0>] do_irqd+0x0/0x80
 [<c0130940>] kthread+0x0/0xb0
 [<c0104099>] kernel_thread_helper+0x5/0xc
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __sched_text_start+0x3b/0x5d0 / (do_irqd+0x5a/0x80)
.. entry 2: print_traces+0x1d/0x80 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 4167678099

(bash/10595/CPU#0): 33546 us critical section violates 100 us threshold.
 => started at timestamp 4167681248: <call_console_drivers+0x76/0x140>
 =>   ended at timestamp 4167714794: <finish_task_switch+0x43/0xb0>
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c01324de>] check_preempt_timing+0x15e/0x270
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c01327f0>] sub_preempt_count+0x60/0x90
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c0117ca3>] finish_task_switch+0x43/0xb0
 [<c02a5717>] __sched_text_start+0x2d7/0x5d0
 [<c02a684f>] down_write+0x12f/0x1e0
 [<c0113104>] mcount+0x14/0x18
 [<c02a684f>] down_write+0x12f/0x1e0
 [<c01182bb>] lock_kernel+0x2b/0x40
 [<c016f122>] sys_ioctl+0x52/0x230
 [<c0106013>] syscall_call+0x7/0xb
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __sched_text_start+0x3b/0x5d0 / (down_write+0x12f/0x1e0)
.. entry 2: print_traces+0x1d/0x80 / (dump_stack+0x23/0x30)

 =>   dump-end timestamp 4167715168


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
                                               ` (4 preceding siblings ...)
  2004-10-20 16:27                             ` Adam Heath
@ 2004-10-20 17:49                             ` Alexander Batyrshin
  2004-10-20 19:02                               ` Adam Heath
                                                 ` (3 more replies)
  2004-10-20 21:19                             ` Esben Nielsen
                                               ` (3 subsequent siblings)
  9 siblings, 4 replies; 951+ messages in thread
From: Alexander Batyrshin @ 2004-10-20 17:49 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

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



Ingo Molnar wrote:
> i have released the -U8 Real-Time Preemption patch:
> 
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8
> 

used i386/defconfig

1. at boot
[...skip...]
hda: 78242976 sectors (40060 MB) w/2048KiB Cache, CHS=16383/255/63, 
UDMA(100)
  hda: hda1 hda2 hda3 hda4 < hda5 >
BUG: semaphore recursion deadlock detected!
.. current task khpsbpkt/723 is already holding c04610c0.
00001f23 00001f2f c04e8de9 00000086 00000009 00000000 c011b552 00000020
        00000400 c03b3efa dfdc9f70 dfdc9f50 0000000c dfdc78f0 c011b430 
c03b3efa
        dfdc9f70 c01052a5 c03b3efa c03b3efa 00000000 dfdc78f0 dfdc78f0 
c01fd364
Call Trace:
  [<c012caa4>] __kernel_text_address+0x2e/0x37 (24)
  [<c01051c9>] show_trace+0x4e/0xcc (12)
  [<c01052c9>] show_stack+0x82/0x97 (36)
  [<c01fd364>] __rwsem_deadlock+0xd9/0x135 (24)
  [<c039e2a0>] down_write_interruptible+0xe6/0x202 (48)
  [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (48)
  [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
  [<c01024d1>] kernel_thread_helper+0x5/0xb (4)
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)
[...skip...]

2.
if execute
``for i in `seq 1 9999`; do nohup bash >/dev/null 2>&1 & done'',
then you'll get something like:
[...skip...]
Warning: dev (pts0) tty->count(16) != #fd's(8) in tty_open
Warning: dev (pts0) tty->count(16) != #fd's(11) in tty_open
Warning: dev (pts0) tty->count(17) != #fd's(13) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(16) in release_dev
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(17) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(16) != #fd's(19) in release_dev
Warning: dev (pts0) tty->count(15) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(18) in tty_open
Warning: dev (pts0) tty->count(14) != #fd's(19) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(12) != #fd's(18) in tty_open
Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(28) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(13) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(13) in release_dev
Warning: dev (pts0) tty->count(527) != #fd's(12) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(12) in release_dev
Warning: dev (pts0) tty->count(538) != #fd's(28) in release_dev
Warning: dev (pts0) tty->count(537) != #fd's(528) in tty_open
Warning: dev (pts0) tty->count(537) != #fd's(527) in release_dev
Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(536) != #fd's(527) in release_dev
Warning: dev (pts0) tty->count(535) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(535) != #fd's(530) in tty_open
[...skip...]
Warning: dev (pts0) tty->count(11) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(10) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(9) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(8) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(7) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(6) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(5) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(4) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(3) != #fd's(71) in release_dev
eggcups: page allocation failure. order:1, mode:0x20
  [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
  [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
  [<c014719c>] kmem_getpages+0x25/0xe0 (8)
[...skip...]

I'v tested it against linux-2.6.9-rc4-mm1 => all was ok

See full logs in attachments

  -bash

[-- Attachment #2: U8-smp1-0.txt --]
[-- Type: text/plain, Size: 18539 bytes --]

Linux version 2.6.9-rc4-mm1-RT-U8 (bash@devnull.rtsoft) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #3 SMP Wed Oct 20 16:26:38 MSD 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001ff30000 (usable)
 BIOS-e820: 000000001ff30000 - 000000001ff40000 (ACPI data)
 BIOS-e820: 000000001ff40000 - 000000001fff0000 (ACPI NVS)
 BIOS-e820: 000000001fff0000 - 0000000020000000 (reserved)
 BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000ff780
DMI 2.3 present.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:3 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:3 APIC version 20
Using ACPI for processor (LAPIC) configuration information
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: ASUSTeK  Product ID: P4P800SE     APIC at: 0xFEE00000
I/O APIC #13 Version 32 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 2
Built 1 zonelists
Initializing CPU#0
Kernel command line: root=/dev/hda2 console=ttyS0,57600
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 2798.899 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 512196k/523456k available (2687k kernel code, 10700k reserved, 1089k data, 184k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03
per-CPU timeslice cutoff: 2926.33 usecs.
task migration cache decay timeout: 3 msecs.
Booting processor 1/1 eip 2000
Initializing CPU#1
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03
Total of 2 processors activated (11108.35 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
checking TSC synchronization across 2 CPUs: passed.
ksoftirqd started up.
Brought up 2 CPUs
ksoftirqd started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/24d0] at 0000:00:1f.0
PCI->APIC IRQ transform: (B0,I29,P0) -> 16
PCI->APIC IRQ transform: (B0,I29,P1) -> 19
PCI->APIC IRQ transform: (B0,I29,P2) -> 18
PCI->APIC IRQ transform: (B0,I29,P0) -> 16
PCI->APIC IRQ transform: (B0,I29,P3) -> 23
PCI->APIC IRQ transform: (B0,I31,P0) -> 18
PCI->APIC IRQ transform: (B0,I31,P1) -> 17
PCI->APIC IRQ transform: (B0,I31,P1) -> 17
PCI->APIC IRQ transform: (B1,I0,P0) -> 16
PCI->APIC IRQ transform: (B2,I5,P0) -> 22
Machine check exception polling timer started.
audit: initializing netlink socket (disabled)
audit(1098277485.061:0): initialized
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
lp: driver loaded but no devices found
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 865 Chipset.
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 64M @ 0xf8000000
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
parport0: PC-style at 0x378 [PCSPP(,...)]
lp0: using parport0 (polling).
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
elevator: using anticipatory as default io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
eth0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
      PrefPort:A  RlmtMode:Check Link State
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH5: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio
hda: SAMSUNG SP0411N, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 1024KiB
hda: 78242976 sectors (40060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
 hda: hda1 hda2 hda3 hda4 < hda5 >
BUG: semaphore recursion deadlock detected!
.. current task khpsbpkt/723 is already holding c04610c0.
00001f23 00001f2f c04e8de9 00000086 00000009 00000000 c011b552 00000020 
       00000400 c03b3efa dfdc9f70 dfdc9f50 0000000c dfdc78f0 c011b430 c03b3efa 
       dfdc9f70 c01052a5 c03b3efa c03b3efa 00000000 dfdc78f0 dfdc78f0 c01fd364 
Call Trace:
 [<c012caa4>] __kernel_text_address+0x2e/0x37 (24)
 [<c01051c9>] show_trace+0x4e/0xcc (12)
 [<c01052c9>] show_stack+0x82/0x97 (36)
 [<c01fd364>] __rwsem_deadlock+0xd9/0x135 (24)
 [<c039e2a0>] down_write_interruptible+0xe6/0x202 (48)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (48)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:498!
invalid operand: 0000 [#1]
PREEMPT SMP 
Modules linked in:
CPU:    1
EIP:    0060:[<c039e2b7>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-RT-U8) 
EIP is at down_write_interruptible+0xfd/0x202
eax: 00000001   ebx: c04610c0   ecx: dfdc8000   edx: 00000001
esi: dfdc78f0   edi: c04610c4   ebp: dfdc9fc0   esp: dfdc9fb4
ds: 007b   es: 007b   ss: 0068   preempt: 00000003
Process khpsbpkt (pid: 723, threadinfo=dfdc8000 task=dfdc78f0)
Stack: c04610c0 000001d6 c04610c0 c04610cc c04610cc dfdc78f0 00000002 dfdc8000 
       00000000 00000000 00000000 c029dd80 c03cd95b ffffffff c029dd55 c01024d1 
       00000000 00000000 00000000 
Call Trace:
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (48)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)
preempt count: 00000004
. 4-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 4: print_traces+0x17/0x50 / (0x0)

Code: 44 24 0c 89 68 04 89 2a 89 54 24 10 89 1c 24 e8 eb ef e5 ff 85 c0 74 1b a1 2c e0 41 c0 85 c0 74 12 c7 05 2c e0 41 c0 00 00 00 00 <0f> 0b f2 01 cf 73 3c c0 89 9e 1c 06 00 00 9c 58 c1 e8 09 83 f0 
 <3>BUG: scheduling while atomic: khpsbpkt/0x04000002/723
ieee1394: raw1394: /dev/raw1394 device initialized
ehci_hcd 0000:00:1d.7: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 23, pci mem 0xfebffc00
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v2.2
uhci_hcd 0000:00:1d.0: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1
caller is cond_resched+0x5e/0x7f
 [<c039d128>] __sched_text_start+0x6e0/0x730 (8)
 [<c039daa9>] cond_resched+0x5e/0x7f (8)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (56)
 [<c0105aff>] do_invalid_op+0x0/0xf7<7>PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 16, io base 0xef00
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.1: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2
 (16)
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 19, io base 0xef20
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.2: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3
 [<c039daa9>] cond_resched+0x5e/0x7f<7>PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 18, io base 0xef40
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.3: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4
 (8)
 [<c039dee7>]<7>PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: irq 16, io base 0xef80
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
 down_read+0x33/0x18a (16)
 [<c0110963>] smp_apic_timer_interrupt+0x6d/0xe2 (12)
 [<c039e92b>] _spin_unlock_irq+0x18/0x2e (8)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (16)
 [<c011bab5>] profile_task_exit+0x15/0x3e (4)
 [<c011dab4>] do_exit+0x18/0x3b1 (20)
 [<c011007b>] flush_tlb_all+0x26/0x65 (12)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (16)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (60)
 [<c011b644>] release_console_sem+0x78/0xb7 (28)
 [<c011b552>] vprintk+0x11e/0x15b (28)
 [<c01052c9>] show_stack+0x82/0x97 (56)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (52)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (56)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86<6>input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)
preempt count: 04000003
Advanced Linux Sound Architecture Driver Version 1.0.6 (Sun Aug 15 07:17:53 2004 UTC).
. 3-level deep critical section nesting:
PCI: Setting latency timer of device 0000:00:1f.5 to 64
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)

note: khpsbpkt[723] exited with preempt_count 2
BUG: scheduling while atomic: khpsbpkt/0x04000002/723
caller is cond_resched+0x5e/0x7f
 [<c039d128>] __sched_text_start+0x6e0/0x730 (8)
 [<c039daa9>] cond_resched+0x5e/0x7f (8)
 [<c01202d4>] __do_softirq+0x36/0x88 (36)
 [<c039daa9>] cond_resched+0x5e/0x7f (44)
 [<c039e068>] down_write+0x2a/0x17c (16)
 [<c011d22e>] exit_notify+0x28/0x896 (40)
 [<c011b552>] vprintk+0x11e/0x15b (24)
 [<c011dd81>] do_exit+0x2e5/0x3b1 (44)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (28)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (60)
 [<c011b644>] release_console_sem+0x78/0xb7 (28)
 [<c011b552>] vprintk+0x11e/0x15b (28)
 [<c01052c9>] show_stack+0x82/0x97 (56)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (52)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (56)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)
preempt count: 04000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: khpsbpkt/0x00000002/723
caller is do_exit+0x2ee/0x3b1
 [<c039d128>] __sched_text_start+0x6e0/0x730 (8)
 [<c011dd8a>] do_exit+0x2ee/0x3b1 (8)
 [<c011d486>] exit_notify+0x280/0x896 (12)
 [<c011dd8a>] do_exit+0x2ee/0x3b1 (68)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (28)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (60)
 [<c011b644>] release_console_sem+0x78/0xb7<6>intel8x0_measure_ac97_clock: measured 50107 usecs
intel8x0: clocking to 48000
ALSA device list:
  #0: Intel ICH5 with AD1985 at 0xfebff800, irq 17
oprofile: using NMI interrupt.
 (28)
 [<c011b552>] vprintk+0x11e/0x15b<6>NET: Registered protocol family 2
 (28)
 [<c01052c9>] show_stack+0x82/0x97 (56)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (52)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (56)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)

------------[ cut here ]------------
kernel BUG at kernel/sched.c:2768!
invalid operand: 0000 [#2]
PREEMPT SMP 
Modules linked in:
CPU:    1
EIP:    0060:[<c039d094>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-RT-U8) 
EIP is at __sched_text_start+0x64c/0x730
eax: 00000001   ebx: dfdc8000   ecx: dfdc78f0   edx: c14340bc
esi: dfdc78f0   edi: dfdc7a60   ebp: dfdc9e58   esp: dfdc9e08
ds: 007b   es: 007b   ss: 0068   preempt: 00000005
Process khpsbpkt (pid: 723, threadinfo=dfdc8000 task=dfdc78f0)
Stack: dfdc78f0 c1433820 00000002 000002d3 c011d486 c04a6d00 00000011 00000286 
       00000033 dfdc7950 dfdc7994 c1433820 0f5d9fc7 77b2f71c 00000001 dfdc78f0 
       dfdc7a5c c165c780 dfdc78f0 dfdc7db8 dfdc9fc0 c011dd8a dfdc78f0 00000000 
Call Trace:
 [<c011d486>] exit_notify+0x280/0x896 (20)
 [<c011dd8a>] do_exit+0x2ee/0x3b1 (68)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (28)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (60)
 [<c011b644>] release_console_sem+0x78/0xb7 (28)
 [<c011b552>] vprintk+0x11e/0x15b (28)
 [<c01052c9>] show_stack+0x82/0x97 (56)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (52)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (56)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)
preempt count: 00000006
. 6-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: __sched_text_start+0x36/0x730 / (0x0)
.. entry 4: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 5: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 6: print_traces+0x17/0x50 / (0x0)

Code: 8b 45 dc 8b 50 08 eb c7 8b 01 85 c0 75 1d 8b 7d ec c7 07 20 00 00 00 89 3c 24 8b 45 dc 89 44 24 04 e8 5b 7b d7 ff e9 fe fa ff ff <0f> 0b d0 0a 82 5c 3b c0 eb d9 8b 7d ec c7 07 00 00 00 00 e9 d9 
 <3>BUG: scheduling while atomic: khpsbpkt/0x04000004/723
caller is cond_resched+0x5e/0x7f
 [<c039d128>] __sched_text_start+0x6e0/0x730 (8)
 [<c039daa9>] cond_resched+0x5e/0x7f (8)
 [<c0116664>] scheduler_tick+0x183/0x517 (28)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (28)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (16)
 [<c039daa9>] cond_resched+0x5e/0x7f (8)
 [<c039dee7>] down_read+0x33/0x18a (16)
 [<c0110963>] smp_apic_timer_interrupt+0x6d/0xe2 (12)
 [<c039e92b>] _spin_unlock_irq+0x18/0x2e (8)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (16)
 [<c011bab5>] profile_task_exit+0x15/0x3e (4)
 [<c011dab4>] do_exit+0x18/0x3b1 (20)
 [<c011007b>] flush_tlb_all+0x26/0x65 (12)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (16)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039d094>] __sched_text_start+0x64c/0x730 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039d094>] __sched_text_start+0x64c/0x730 (60)
 [<c011b644>] release_console_sem+0x78/0xb7 (84)
 [<c011b552>] vprintk+0x11e/0x15b (28)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c011007b>] flush_tlb_all+0x26/0x65 (40)
 [<c039d094>] __sched_text_start+0x64c/0x730 (12)
 [<c011d486>] exit_notify+0x280/0x896 (28)
 [<c011dd8a>] do_exit+0x2ee/0x3b1 (68)
 [<c0105aff>] do_invalid_op+0x0/0xf7 (28)
 [<c0105700>] do_divide_error+0x0/0x117 (8)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (40)
 [<c01142ca>] fixup_exception+0x16/0x34 (8)
 [<c0105bf4>] do_invalid_op+0xf5/0xf7 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (60)
 [<c011b644>] release_console_sem+0x78/0xb7 (28)
 [<c011b552>] vprintk+0x11e/0x15b (28)
 [<c01052c9>] show_stack+0x82/0x97 (56)
 [<c0104f21>] error_code+0x2d/0x38 (12)
 [<c039e2b7>] down_write_interruptible+0xfd/0x202 (52)
 [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (56)
 [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
 [<c01024d1>] kernel_thread_helper+0x5/0xb (4)
preempt count: 04000005
. 5-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: _spin_lock+0x19/0x6d / (0x0)
.. entry 3: __sched_text_start+0x36/0x730 / (0x0)
.. entry 4: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 5: print_traces+0x17/0x50 / (0x0)


[-- Attachment #3: U8-smp4-noieee.txt --]
[-- Type: text/plain, Size: 69802 bytes --]

Linux version 2.6.9-rc4-mm1-RT-U8 (bash@devnull.rtsoft) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #11 SMP Wed Oct 20 18:49:11 MSD 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001ff30000 (usable)
 BIOS-e820: 000000001ff30000 - 000000001ff40000 (ACPI data)
 BIOS-e820: 000000001ff40000 - 000000001fff0000 (ACPI NVS)
 BIOS-e820: 000000001fff0000 - 0000000020000000 (reserved)
 BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000ff780
DMI 2.3 present.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:3 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:3 APIC version 20
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
Initializing CPU#0
Kernel command line: root=/dev/hda2 console=ttyS0,57600
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 2798.919 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 512132k/523456k available (2689k kernel code, 10764k reserved, 1111k data, 192k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03
per-CPU timeslice cutoff: 2926.33 usecs.
task migration cache decay timeout: 3 msecs.
Booting processor 1/1 eip 3000
Initializing CPU#1
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03
Total of 2 processors activated (11108.35 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
ksoftirqd started up.
Brought up 2 CPUs
ksoftirqd started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040816
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of "lspci" to bjorn.helgaas@hp.com
** so I can fix the driver.
Machine check exception polling timer started.
audit: initializing netlink socket (disabled)
audit(1098284016.319:0): initialized
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
ACPI: Power Button (FF) [PWRF]
ACPI: Processor [CPU1] (supports C1)
ACPI: Processor [CPU2] (supports C1)
lp: driver loaded but no devices found
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel 865 Chipset.
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 64M @ 0xf8000000
ACPI: PS/2 Keyboard Controller [PS2K] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [PS2M] at irq 12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
parport0: PC-style at 0x378 [PCSPP(,...)]
lp0: using parport0 (polling).
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
ACPI: Floppy Controller [FDC] at I/O 0x3f0-0x3f5, 0x3f7 irq 6 dma channel 2
elevator: using anticipatory as default io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH5: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio
hda: SAMSUNG SP0411N, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 1024KiB
hda: 78242976 sectors (40060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
 hda: hda1 hda2 hda3 hda4 < hda5 >
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:1d.7: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
ehci_hcd 0000:00:1d.7: irq 23, pci mem 0xfebffc00
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.0: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1
uhci_hcd 0000:00:1d.0: irq 16, io base 0xef00
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.1: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2
uhci_hcd 0000:00:1d.1: irq 19, io base 0xef20
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1d.2: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3
uhci_hcd 0000:00:1d.2: irq 18, io base 0xef40
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.3: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4
uhci_hcd 0000:00:1d.3: irq 16, io base 0xef80
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
Advanced Linux Sound Architecture Driver Version 1.0.6 (Sun Aug 15 07:17:53 2004 UTC).
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 17
AC'97 0 analog subsections not ready
intel8x0_measure_ac97_clock: measured 49987 usecs
intel8x0: clocking to 48000
ALSA device list:
  #0: Intel ICH5 with AD1985 at 0xfebff800, irq 17
oprofile: using NMI interrupt.
NET: Registered protocol family 2
IP: routing cache hash table of 128 buckets, 21Kbytes
TCP: Hash tables configured (established 1024 bind 1560)
ip_conntrack version 2.1 (4089 buckets, 32712 max) - 308 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.  http://snowman.net/projects/ipt_recent/
arp_tables: (C) 2002 David S. Miller
NET: Registered protocol family 1
NET: Registered protocol family 17
Starting balanced_irq
ACPI: (supports S0 S1 S3 S4 S5)
ACPI wakeup devices: 
P0P4 MC97 USB1 USB2 USB3 USB4 EUSB PS2K PS2M ILAN 
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 192k freed
[...skip...]
Warning: dev (pts0) tty->count(16) != #fd's(8) in tty_open
Warning: dev (pts0) tty->count(16) != #fd's(11) in tty_open
Warning: dev (pts0) tty->count(17) != #fd's(13) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(16) in release_dev
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(17) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(16) != #fd's(19) in release_dev
Warning: dev (pts0) tty->count(15) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(18) in tty_open
Warning: dev (pts0) tty->count(14) != #fd's(19) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(13) != #fd's(17) in release_dev
Warning: dev (pts0) tty->count(12) != #fd's(18) in tty_open
Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
Warning: dev (pts0) tty->count(28) != #fd's(16) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(13) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(13) in release_dev
Warning: dev (pts0) tty->count(527) != #fd's(12) in tty_open
Warning: dev (pts0) tty->count(528) != #fd's(12) in release_dev
Warning: dev (pts0) tty->count(538) != #fd's(28) in release_dev
Warning: dev (pts0) tty->count(537) != #fd's(528) in tty_open
Warning: dev (pts0) tty->count(537) != #fd's(527) in release_dev
Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(536) != #fd's(527) in release_dev
Warning: dev (pts0) tty->count(535) != #fd's(527) in tty_open
Warning: dev (pts0) tty->count(535) != #fd's(530) in tty_open
[...skip...]
Warning: dev (pts0) tty->count(11) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(10) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(9) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(8) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(7) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(6) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(5) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(4) != #fd's(71) in release_dev
Warning: dev (pts0) tty->count(3) != #fd's(71) in release_dev
eggcups: page allocation failure. order:1, mode:0x20
 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0143645>] buffered_rmqueue+0x89/0x1f4 (28)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (48)
 [<c039e226>] cond_resched+0x20/0x7f (32)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f019>] _spin_unlock+0x12/0x2d (16)
 [<c039f019>] _spin_unlock+0x12/0x2d (16)
 [<c0147f5e>] cache_grow+0x147/0x16f (8)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (28)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20
 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20
 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20
 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20
 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20
 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20
 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20
 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20
 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

eggcups: page allocation failure. order:1, mode:0x20
 [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
 [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
 [<c014719c>] kmem_getpages+0x25/0xe0 (8)
 [<c0147ee1>] cache_grow+0xca/0x16f (24)
 [<c0148067>] cache_alloc_refill+0xe1/0x230 (52)
 [<c01484a4>] __kmalloc+0x76/0x98 (48)
 [<c0325521>] pskb_expand_head+0x51/0x123 (24)
 [<c032a8ae>] skb_checksum_help+0x103/0x114 (40)
 [<c037a8d7>] ip_nat_fn+0x203/0x215 (36)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c03352bb>] nf_iterate+0x71/0xa5 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (20)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (16)
 [<c03355b9>] nf_hook_slow+0x77/0x125 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (28)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c034131a>] ip_finish_output+0x24c/0x251 (4)
 [<c0343c16>] ip_finish_output2+0x0/0x1fa (24)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0343c01>] dst_output+0x14/0x29 (4)
 [<c033561e>] nf_hook_slow+0xdc/0x125 (8)
 [<c0343bed>] dst_output+0x0/0x29 (28)
 [<c0341a9e>] ip_queue_xmit+0x51d/0x61c (32)
 [<c0343bed>] dst_output+0x0/0x29 (24)
 [<c0324ee0>] kfree_skbmem+0x24/0x2c (36)
 [<c0324f81>] __kfree_skb+0x99/0xf9 (16)
 [<c034d71c>] tcp_ack_saw_tstamp+0x22/0x57 (8)
 [<c034df0b>] tcp_clean_rtx_queue+0x40b/0x433 (16)
 [<c0324610>] sk_reset_timer+0x1f/0x2f (16)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (52)
 [<c035306c>] tcp_transmit_skb+0x521/0x8da (52)
 [<c0353f06>] tcp_write_xmit+0x16a/0x2c7 (72)
 [<c039e226>] cond_resched+0x20/0x7f (16)
 [<c03473fa>] tcp_sendmsg+0x541/0x1260 (40)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (20)
 [<c039f0e1>] _spin_unlock_irq+0x12/0x2e (48)
 [<c036a404>] inet_sendmsg+0x4d/0x59 (28)
 [<c0320fce>] sock_sendmsg+0xe5/0x100 (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (72)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c0133550>] autoremove_wake_function+0x0/0x57 (52)
 [<c0320d33>] sockfd_lookup+0x1c/0x77 (32)
 [<c0322424>] sys_sendto+0xe3/0xfe (20)
 [<c03221c3>] sys_connect+0x91/0xb1 (68)
 [<c0324ae2>] sock_common_setsockopt+0x36/0x3a (96)
 [<c0322476>] sys_send+0x37/0x3b (40)
 [<c0322ce9>] sys_socketcall+0x139/0x256 (28)
 [<c0105259>] sysenter_past_esp+0x52/0x71 (64)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x50 / (0x0)

Warning: trace overflow for c0414d40 (32), increase RWSEM_MAX_OWNERS
... disabling semaphore tracing and deadlock detection.
BUG: sleeping function called from invalid context bash(24154) at drivers/block/ll_rw_blk.c:1283
in_atomic():1 [00000001], irqs_disabled():1
 [<c011c4c7>] __might_sleep+0xbb/0xc9 (8)
 [<c026d24f>] generic_unplug_device+0x1f/0x50 (36)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling with irqs disabled: bash/0x04000001/24154
caller is cond_resched+0x5e/0x7f
 [<c039d99f>] schedule+0x6c/0xb9 (8)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (24)
 [<c026d254>] generic_unplug_device+0x24/0x50 (16)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x04000001/24154
caller is cond_resched+0x5e/0x7f
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c011f16e>] vprintk+0x11e/0x15b (12)
 [<c0106116>] dump_stack+0x1c/0x20 (56)
 [<c039d99f>] schedule+0x6c/0xb9 (16)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (24)
 [<c026d254>] generic_unplug_device+0x24/0x50 (16)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (116)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: sleeping function called from invalid context bash(24154) at lib/rwsem-generic.c:319
in_atomic():1 [00000001], irqs_disabled():0
 [<c011c4c7>] __might_sleep+0xbb/0xc9 (8)
 [<c039e69d>] down_read+0x2e/0x18a (36)
 [<c015587d>] swap_unplug_io_fn+0x19/0xb5 (40)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x04000001/24154
caller is cond_resched+0x5e/0x7f
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c011f16e>] vprintk+0x11e/0x15b (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c0106116>] dump_stack+0x1c/0x20 (40)
 [<c039e264>] cond_resched+0x5e/0x7f (36)
 [<c039e6a2>] down_read+0x33/0x18a (16)
 [<c015587d>] swap_unplug_io_fn+0x19/0xb5 (40)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (116)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (116)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: sleeping function called from invalid context bash(24154) at lib/rwsem-generic.c:319
in_atomic():1 [00000001], irqs_disabled():0
 [<c011c4c7>] __might_sleep+0xbb/0xc9 (8)
 [<c039e69d>] down_read+0x2e/0x18a (36)
 [<c015587d>] swap_unplug_io_fn+0x19/0xb5 (40)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x04000001/24154
caller is cond_resched+0x5e/0x7f
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c011f16e>] vprintk+0x11e/0x15b (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c0106116>] dump_stack+0x1c/0x20 (40)
 [<c039e264>] cond_resched+0x5e/0x7f (36)
 [<c039e6a2>] down_read+0x33/0x18a (16)
 [<c015587d>] swap_unplug_io_fn+0x19/0xb5 (40)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (116)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039f019>] _spin_unlock+0x12/0x2d (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (52)
 [<c039e2c8>] io_schedule+0x26/0x30 (36)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: sleeping function called from invalid context bash(24154) at lib/rwsem-generic.c:319
in_atomic():1 [00000001], irqs_disabled():0
 [<c011c4c7>] __might_sleep+0xbb/0xc9 (8)
 [<c039f019>] _spin_unlock+0x12/0x2d (24)
 [<c039e69d>] down_read+0x2e/0x18a (12)
 [<c015587d>] swap_unplug_io_fn+0x19/0xb5 (40)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039f019>] _spin_unlock+0x12/0x2d (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (52)
 [<c039e2c8>] io_schedule+0x26/0x30 (36)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (116)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is down_write+0x14d/0x17c
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e946>] down_write+0x14d/0x17c (8)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c039e946>] down_write+0x14d/0x17c (52)
 [<c026d262>] generic_unplug_device+0x32/0x50 (40)
 [<c026d29b>] blk_backing_dev_unplug+0x1b/0x1d (16)
 [<c01558bc>] swap_unplug_io_fn+0x58/0xb5 (8)
 [<c0162583>] block_sync_page+0x4f/0x58 (36)
 [<c013e5c4>] sync_page+0x50/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is io_schedule+0x26/0x30
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e2c8>] io_schedule+0x26/0x30 (8)
 [<c039f019>] _spin_unlock+0x12/0x2d (28)
 [<c039f019>] _spin_unlock+0x12/0x2d (52)
 [<c039e2c8>] io_schedule+0x26/0x30 (36)
 [<c013e5b8>] sync_page+0x44/0x59 (12)
 [<c039e5c0>] __wait_on_bit_lock+0x53/0x61 (8)
 [<c013e574>] sync_page+0x0/0x59 (8)
 [<c013ed4b>] __lock_page+0xa3/0xab (20)
 [<c01335a7>] wake_bit_function+0x0/0x55 (24)
 [<c01335a7>] wake_bit_function+0x0/0x55 (32)
 [<c014e9ce>] do_swap_page+0x219/0x2da (20)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: sleeping function called from invalid context bash(24154) at kernel/mutex.c:25
in_atomic():1 [00000001], irqs_disabled():0
 [<c011c4c7>] __might_sleep+0xbb/0xc9 (8)
 [<c0133970>] _mutex_lock+0x1f/0x3b (36)
 [<c014e847>] do_swap_page+0x92/0x2da (16)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x04000001/24154
caller is cond_resched+0x5e/0x7f
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c039e264>] cond_resched+0x5e/0x7f (8)
 [<c011f16e>] vprintk+0x11e/0x15b (24)
 [<c0133f74>] check_preempt_timing+0x70/0x1aa (16)
 [<c0106116>] dump_stack+0x1c/0x20 (40)
 [<c039e264>] cond_resched+0x5e/0x7f (36)
 [<c0133975>] _mutex_lock+0x24/0x3b (16)
 [<c014e847>] do_swap_page+0x92/0x2da (16)
 [<c014f175>] handle_mm_fault+0xdf/0x18e (52)
 [<c0117355>] do_page_fault+0x1be/0x595 (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (60)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c0117197>] do_page_fault+0x0/0x595 (12)
 [<c0105d3d>] error_code+0x2d/0x38 (8)
 [<c010521f>] sysenter_past_esp+0x18/0x71 (52)
preempt count: 04000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

BUG: scheduling while atomic: bash/0x00000001/24154
caller is do_exit+0x2ee/0x3b1
 [<c039d8e3>] __sched_text_start+0xbef/0xc3f (8)
 [<c01219a6>] do_exit+0x2ee/0x3b1 (8)
 [<c01210a2>] exit_notify+0x280/0x896 (48)
 [<c01219a6>] do_exit+0x2ee/0x3b1 (68)
 [<c0121b82>] do_group_exit+0x91/0xb5 (36)
 [<c012acfd>] get_signal_to_deliver+0x1bf/0x396 (24)
 [<c01050ea>] do_signal+0xe3/0x11b (48)
 [<c039f019>] _spin_unlock+0x12/0x2d (40)
 [<c015d40e>] vfs_read+0xbf/0x12a (88)
 [<c015d6df>] sys_read+0x51/0x80 (44)
 [<c010517a>] do_notify_resume+0x58/0x5a (28)
 [<c01052f7>] work_notifysig+0x13/0x18 (12)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)

INIT: Switching to runlevel: 6
INIT: Sending processes the TERM signal
Stopping atd: [  OK  ]
Stopping keytable:  [  OK  ]
Stopping cups: [  OK  ]
Shutting down xfs: [  OK  ]
Shutting down console mouse services: [  OK  ]
Stopping sshd:[  OK  ]
Shutting down sendmail: [  OK  ]
Shutting down sm-client: [  OK  ]
Stopping xinetd: [  OK  ]
Stopping crond: [  OK  ]
Saving random seed:  [  OK  ]
Stopping NFS statd: 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 17:49                             ` Alexander Batyrshin
@ 2004-10-20 19:02                               ` Adam Heath
  2004-10-20 22:35                               ` Daniel Walker
                                                 ` (2 subsequent siblings)
  3 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-20 19:02 UTC (permalink / raw)
  To: Alexander Batyrshin; +Cc: Ingo Molnar, linux-kernel

On Wed, 20 Oct 2004, Alexander Batyrshin wrote:

>
>
> Ingo Molnar wrote:
> > i have released the -U8 Real-Time Preemption patch:
> >
> >   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8
> >
>
> 2.
> if execute
> ``for i in `seq 1 9999`; do nohup bash >/dev/null 2>&1 & done'',
> then you'll get something like:
> [...skip...]
> Warning: dev (pts0) tty->count(16) != #fd's(8) in tty_open
> Warning: dev (pts0) tty->count(16) != #fd's(11) in tty_open
> Warning: dev (pts0) tty->count(17) != #fd's(13) in tty_open
> Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
> Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
> Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
> Warning: dev (pts0) tty->count(19) != #fd's(16) in tty_open
> Warning: dev (pts0) tty->count(19) != #fd's(16) in release_dev
> Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
> Warning: dev (pts0) tty->count(18) != #fd's(16) in tty_open
> Warning: dev (pts0) tty->count(19) != #fd's(17) in tty_open
> Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
> Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
> Warning: dev (pts0) tty->count(18) != #fd's(17) in tty_open
> Warning: dev (pts0) tty->count(19) != #fd's(17) in release_dev
> Warning: dev (pts0) tty->count(17) != #fd's(18) in release_dev
> Warning: dev (pts0) tty->count(16) != #fd's(19) in release_dev
> Warning: dev (pts0) tty->count(15) != #fd's(18) in release_dev
> Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
> Warning: dev (pts0) tty->count(14) != #fd's(18) in release_dev
> Warning: dev (pts0) tty->count(13) != #fd's(18) in tty_open
> Warning: dev (pts0) tty->count(14) != #fd's(19) in release_dev
> Warning: dev (pts0) tty->count(13) != #fd's(18) in release_dev
> Warning: dev (pts0) tty->count(13) != #fd's(17) in release_dev
> Warning: dev (pts0) tty->count(12) != #fd's(18) in tty_open
> Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
> Warning: dev (pts0) tty->count(12) != #fd's(18) in release_dev
> Warning: dev (pts0) tty->count(28) != #fd's(16) in tty_open
> Warning: dev (pts0) tty->count(528) != #fd's(13) in tty_open
> Warning: dev (pts0) tty->count(528) != #fd's(13) in release_dev
> Warning: dev (pts0) tty->count(527) != #fd's(12) in tty_open
> Warning: dev (pts0) tty->count(528) != #fd's(12) in release_dev
> Warning: dev (pts0) tty->count(538) != #fd's(28) in release_dev
> Warning: dev (pts0) tty->count(537) != #fd's(528) in tty_open
> Warning: dev (pts0) tty->count(537) != #fd's(527) in release_dev
> Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
> Warning: dev (pts0) tty->count(536) != #fd's(527) in tty_open
> Warning: dev (pts0) tty->count(536) != #fd's(527) in release_dev
> Warning: dev (pts0) tty->count(535) != #fd's(527) in tty_open
> Warning: dev (pts0) tty->count(535) != #fd's(530) in tty_open
> [...skip...]
> Warning: dev (pts0) tty->count(11) != #fd's(71) in release_dev
> Warning: dev (pts0) tty->count(10) != #fd's(71) in release_dev
> Warning: dev (pts0) tty->count(9) != #fd's(71) in release_dev
> Warning: dev (pts0) tty->count(8) != #fd's(71) in release_dev
> Warning: dev (pts0) tty->count(7) != #fd's(71) in release_dev
> Warning: dev (pts0) tty->count(6) != #fd's(71) in release_dev
> Warning: dev (pts0) tty->count(5) != #fd's(71) in release_dev
> Warning: dev (pts0) tty->count(4) != #fd's(71) in release_dev
> Warning: dev (pts0) tty->count(3) != #fd's(71) in release_dev
> eggcups: page allocation failure. order:1, mode:0x20
>   [<c01439d8>] __alloc_pages+0x228/0x3ff (8)
>   [<c0143bce>] __get_free_pages+0x1f/0x3b (68)
>   [<c014719c>] kmem_getpages+0x25/0xe0 (8)
> [...skip...]

I got something like this too, just now.  Not doing anything special(tty7
holds xdm).

Warning: dev (pts7) tty->count(4) != #fd's(3) in tty_open
Warning: dev (pts7) tty->count(4) != #fd's(3) in release_dev

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
                                               ` (5 preceding siblings ...)
  2004-10-20 17:49                             ` Alexander Batyrshin
@ 2004-10-20 21:19                             ` Esben Nielsen
  2004-10-21  0:32                             ` Fernando Pablo Lopez-Lezcano
                                               ` (2 subsequent siblings)
  9 siblings, 0 replies; 951+ messages in thread
From: Esben Nielsen @ 2004-10-20 21:19 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano

Hi,
 I finally got around to get my labtop up running with this. It works -
nearly that is - X even started up!

When I start the network I get the trace below. And my network runs
awfully slowly. Could seem like the interrupt doesn't work correctly....

Regards,
Esben

Oct 20 21:45:53 localhost kernel: e100: Intel(R) PRO/100 Network Driver,
3.1.4-k
2-NAPI
Oct 20 21:45:53 localhost kernel: e100: Copyright(c) 1999-2004 Intel
Corporation
Oct 20 21:45:53 localhost kernel: ACPI: PCI interrupt 0000:00:09.0[A] ->
GSI 11 
(level, low) -> IRQ 11
Oct 20 21:45:53 localhost kernel: e100: eth0: e100_probe: addr 0x41280000,
irq 1
1, MAC addr 00:D0:59:2D:91:84
Oct 20 21:45:53 localhost kernel: ip/1988: BUG in enable_irq at
/misc/frodo_opt3
/simlo/Linux-RT/linux-2.6.9-rc4-mm1-rt-u8.1/kernel/irq/manage.c:111
Oct 20 21:45:53 localhost kernel:  [<c013614e>] enable_irq+0xee/0x100 (12)
Oct 20 21:45:53 localhost kernel:  [<d089741e>] e100_up+0x10e/0x200 [e100]
(48)
Oct 20 21:45:54 localhost kernel:  [<d08987c0>] e100_open+0x30/0x80 [e100]
(48)
Oct 20 21:45:54 localhost kernel:  [<c010fe00>] mcount+0x14/0x18 (12)
Oct 20 21:45:54 localhost kernel:  [<c02ea108>] dev_open+0x88/0xa0 (20)
Oct 20 21:45:54 localhost kernel:  [<c02eb82d>]
dev_change_flags+0x5d/0x140 (28)
Oct 20 21:45:54 localhost kernel:  [<c02e976e>] __dev_get_by_name+0xe/0xd0
(8)
Oct 20 21:45:54 localhost kernel:  [<c03293b7>] devinet_ioctl+0x277/0x6e0
(28)
Oct 20 21:45:54 localhost kernel:  [<c032b834>] inet_ioctl+0x64/0xb0 (108)
Oct 20 21:45:54 localhost kernel:  [<c02e0ae8>] sock_ioctl+0xc8/0x250 (28)
Oct 20 21:45:54 localhost kernel:  [<c016a319>] sys_ioctl+0xc9/0x230 (32)
Oct 20 21:45:54 localhost kernel:  [<c01046fd>]
sysenter_past_esp+0x52/0x71 (44)
Oct 20 21:45:54 localhost kernel: preempt count: 00000002
Oct 20 21:45:54 localhost kernel: . 2-level deep critical section nesting:
Oct 20 21:45:54 localhost kernel: .. entry 1: enable_irq+0x2e/0x100 /
(e100_up+0
x10e/0x200 [e100])
Oct 20 21:45:54 localhost kernel: .. entry 2: print_traces+0x1d/0x60 /
(dump_sta
ck+0x23/0x30)
Oct 20 21:45:54 localhost kernel: 
Oct 20 21:45:54 localhost kernel: e100: eth0: e100_watchdog: link up, 
10Mbps, ha



On Wed, 20 Oct 2004, Ingo Molnar wrote:

> 
> i have released the -U8 Real-Time Preemption patch:
> 
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8
> 
> this too is a fixes-only release. It includes the many semaphore-abuse
> and sleep_on() fixes/improvements from Thomas Gleixner, and it also
> includes a couple of semaphore related fixes.
> 
> I believe the semaphore fixes should resolve a number of the deadlocks
> reported for -U7.
> 
> In particular it seems the only sane and reliable way to convert RCU
> locking was to allow the following semantics for rwsems: allow reads to
> nest, and allow self-read-recursion of a self-write-held semaphore. My
> current implementation for this allows semaphore unfairness, but that
> can be fixed later on. Most importantly, the RCU to RT-locking
> conversions are much more automatic now and map nicely to what the code
> is doing upstream. Most of the time they involve a conversion of a
> spinlock or semaphore into a rwlock or rwsem. The old code maps to new
> code almost automatically, the only manual work needed was to associate
> the rcu_read_lock() with the writers-lock that it excludes against,
> which is a pretty clear (but not automatic, and hence not automatable)
> decision. This way i could convert some more networking code, and
> simplify the older changes and hopefully get rid of some deadlocks. The
> locking API is still not in its final form, but it's getting closer.
> 
> Changes since -U7:
> 
>  - deadlock fix: sysfs/driver-base semaphore fixes from Thomas Gleixner
> 
>  - deadlock fix: scsi semaphore fixes from Thomas Gleixner
> 
>  - NFS sleep_on() fixes from Thomas Gleixner
> 
>  - rawmidid.c sleep_on() fix from Thomas Gleixner
> 
>  - [ i've added more wait_for_completion_*() primitives, to ease 
>      conversion of other semaphore-(ab-)using code. ]
> 
>  - make rwsems self-recursive
> 
>  - RCU lock conversion: convert rtnl_sem RCU use.
> 
>  - netfilter deadlock fix - clean up RCU locking.
> 
> to create a -U8 tree from scratch, the patching order is:
> 
>    http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
>  + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
>  + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
>  + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8
> 
> 	Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 12:04                                   ` Ingo Molnar
@ 2004-10-20 21:34                                     ` Michal Schmidt
  2004-10-21  8:12                                       ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Michal Schmidt @ 2004-10-20 21:34 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano

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

Ingo Molnar wrote:
> disable_irq() should work fine though. (it doesnt disable local
> interrupts, it only disables that particular irq line.) So something
> else disabled interrupts - ah, netconsole.c itself. Does the patch below
> fix things up for you?
> 
> 	Ingo
 > [patch snipped]

That patch was not enough. The BUGs were still showing up the same as 
before.
I tried to debug it myself. I've found an interesting thing in 
kernel/printk.c:release_console_sem(). There is the following sequence:

   spin_lock_irqsave(&logbuf_lock, flags);
   /* ... some code ... */
   spin_unlock(&logbuf_lock);
   call_console_drivers(...);
   local_irq_restore(flags);

I know very little about locking, but I didn't like this two-phased 
unlock. So I replaced it with a single spin_unlock_irqrestore. Patch 
attached.
I'm almost certain that there is a reason for the two-phased unlocking 
and that this patch will break something, but so far it works for me. 
netconsole now works without complaining.

Michal

[-- Attachment #2: printk-console-sem.diff --]
[-- Type: text/x-patch, Size: 609 bytes --]

diff -Nurp linux-2.6.9-rc4-mm1-RT-U8/kernel/printk.c linux-2.6.9-rc4-mm1-RT-U8-m/kernel/printk.c
--- linux-2.6.9-rc4-mm1-RT-U8/kernel/printk.c	2004-10-20 22:20:55.000000000 +0200
+++ linux-2.6.9-rc4-mm1-RT-U8-m/kernel/printk.c	2004-10-20 22:24:40.000000000 +0200
@@ -646,9 +646,8 @@ void release_console_sem(void)
 		_con_start = con_start;
 		_log_end = log_end;
 		con_start = log_end;		/* Flush */
-		spin_unlock(&logbuf_lock);
+		spin_unlock_irqrestore(&logbuf_lock, flags);
 		call_console_drivers(_con_start, _log_end);
-		local_irq_restore(flags);
 	}
 	console_locked = 0;
 	console_may_schedule = 0;

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 17:49                             ` Alexander Batyrshin
  2004-10-20 19:02                               ` Adam Heath
@ 2004-10-20 22:35                               ` Daniel Walker
  2004-10-22 13:19                               ` Ingo Molnar
  2004-10-22 13:48                               ` Ingo Molnar
  3 siblings, 0 replies; 951+ messages in thread
From: Daniel Walker @ 2004-10-20 22:35 UTC (permalink / raw)
  To: linux-kernel

On Wed, 2004-10-20 at 10:49, Alexander Batyrshin wrote:
> Ingo Molnar wrote:
> > i have released the -U8 Real-Time Preemption patch:
> > 
> >   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8
> > 
> 
> used i386/defconfig
> 
> 1. at boot
> [...skip...]
> hda: 78242976 sectors (40060 MB) w/2048KiB Cache, CHS=16383/255/63, 
> UDMA(100)
>   hda: hda1 hda2 hda3 hda4 < hda5 >
> BUG: semaphore recursion deadlock detected!
> .. current task khpsbpkt/723 is already holding c04610c0.
> 00001f23 00001f2f c04e8de9 00000086 00000009 00000000 c011b552 00000020
>         00000400 c03b3efa dfdc9f70 dfdc9f50 0000000c dfdc78f0 c011b430 
> c03b3efa
>         dfdc9f70 c01052a5 c03b3efa c03b3efa 00000000 dfdc78f0 dfdc78f0 
> c01fd364
> Call Trace:
>   [<c012caa4>] __kernel_text_address+0x2e/0x37 (24)
>   [<c01051c9>] show_trace+0x4e/0xcc (12)
>   [<c01052c9>] show_stack+0x82/0x97 (36)
>   [<c01fd364>] __rwsem_deadlock+0xd9/0x135 (24)
>   [<c039e2a0>] down_write_interruptible+0xe6/0x202 (48)
>   [<c029dd80>] hpsbpkt_thread+0x2b/0x86 (48)
>   [<c029dd55>] hpsbpkt_thread+0x0/0x86 (12)
>   [<c01024d1>] kernel_thread_helper+0x5/0xb (4)
> preempt count: 00000003
> . 3-level deep critical section nesting:
> .. entry 1: _spin_lock_irqsave+0x19/0x74 / (0x0)
> .. entry 2: _spin_lock+0x19/0x6d / (0x0)
> .. entry 3: print_traces+0x17/0x50 / (0x0)
> [...skip...]


This looks related to IEEE1394 . It has a deadlock in it. Try turning it
off..



Daniel


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
                                               ` (6 preceding siblings ...)
  2004-10-20 21:19                             ` Esben Nielsen
@ 2004-10-21  0:32                             ` Fernando Pablo Lopez-Lezcano
  2004-10-21  9:12                             ` Rui Nuno Capela
  2004-10-21 13:27                             ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Ingo Molnar
  9 siblings, 0 replies; 951+ messages in thread
From: Fernando Pablo Lopez-Lezcano @ 2004-10-21  0:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt

On Wed, 2004-10-20 at 02:45, Ingo Molnar wrote:
> i have released the -U8 Real-Time Preemption patch:
> 
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8
> 
> this too is a fixes-only release.

A bit late, but a short report. I managed to boot into U8.1 (Athlon64 up
machine). But only if I turn off kudzu (the hardware discovery program
in FC2). If I leave it on, I get tons of kernel error or warning
messages on the console, they scroll too fast for me to read, once that
starts the machine is pretty much stuck - the messages keep scrolling
but that's about it. I have not managed to capture the output to see
what they say...

If I boot without kudzu I can use sound, but I have not done yet any
latency testing. 

-- Fernando



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 21:34                                     ` Michal Schmidt
@ 2004-10-21  8:12                                       ` Ingo Molnar
  2004-10-21  8:18                                         ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21  8:12 UTC (permalink / raw)
  To: Michal Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano


* Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:

> That patch was not enough. The BUGs were still showing up the same as
> before. I tried to debug it myself. I've found an interesting thing in
> kernel/printk.c:release_console_sem(). There is the following
> sequence:
> 
>   spin_lock_irqsave(&logbuf_lock, flags);
>   /* ... some code ... */
>   spin_unlock(&logbuf_lock);
>   call_console_drivers(...);
>   local_irq_restore(flags);
> 
> I know very little about locking, but I didn't like this two-phased
> unlock. So I replaced it with a single spin_unlock_irqrestore. Patch
> attached. I'm almost certain that there is a reason for the two-phased
> unlocking and that this patch will break something, but so far it
> works for me.  netconsole now works without complaining.

ah, indeed. Note that this is still not enough - please try to add a
local_irq_enable() to netconsole.c's console-write function - does that
fix it equally well for you?

the reason is that if we crash within an irqs-off section then
netconsole will still be called with interrupts disabled and will
trigger the assert.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  8:12                                       ` Ingo Molnar
@ 2004-10-21  8:18                                         ` Ingo Molnar
  2004-10-21  8:20                                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21  8:18 UTC (permalink / raw)
  To: Michal Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano


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

> ah, indeed. Note that this is still not enough - please try to add a
> local_irq_enable() to netconsole.c's console-write function - does
> that fix it equally well for you?
> 
> the reason is that if we crash within an irqs-off section then
> netconsole will still be called with interrupts disabled and will
> trigger the assert.

i've added your patch to my tree, plus the extra local_irq_enable(),
this should also fix fbcon - so no changes needed to netconsole.c. All
of these problems will go away if/when the console code goes away from
raw spinlocks.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  8:18                                         ` Ingo Molnar
@ 2004-10-21  8:20                                           ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21  8:20 UTC (permalink / raw)
  To: Michal Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano


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

> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > ah, indeed. Note that this is still not enough - please try to add a
> > local_irq_enable() to netconsole.c's console-write function - does
> > that fix it equally well for you?
> > 
> > the reason is that if we crash within an irqs-off section then
> > netconsole will still be called with interrupts disabled and will
> > trigger the assert.
> 
> i've added your patch to my tree, plus the extra local_irq_enable(),
> this should also fix fbcon - so no changes needed to netconsole.c. All
> of these problems will go away if/when the console code goes away from
> raw spinlocks.

actually ... i think i'll add the local_irq_enable() to netconsole.c and
fbcon, that way the VGA and serial consoles can still keep interrupts
disabled. That could make the difference between a debuggable and
undebuggable crash ...

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
                                               ` (7 preceding siblings ...)
  2004-10-21  0:32                             ` Fernando Pablo Lopez-Lezcano
@ 2004-10-21  9:12                             ` Rui Nuno Capela
  2004-10-21  9:16                               ` Thomas Gleixner
                                                 ` (3 more replies)
  2004-10-21 13:27                             ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Ingo Molnar
  9 siblings, 4 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-21  9:12 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

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

Ingo Molnar wrote:
>
> i have released the -U8 Real-Time Preemption patch:
>
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8
>

Hi,

   I'm posting this time about to report my current status of my two
boxes, regarding the realtime-preempt-2.6.9-rc4-mm1-U8 patch. So it
seems that now the positions have been somewhat reversed. Respective
config.gz are attached.


a) Desktop P4 2.80C@3.3Ghz SMP/HT (SuSE 9.1 Pro)
   config-2.6.9-rc4-mm1-RT-U8.0smp.gz

   This is apparently but surprinsingly OK, as everything seems to work
flawlessly, besides some quirks on the onboard NIC (sk98lin) that only
shows up initially but stabilizes later on. Indeed, U8 is the first
SMP+PREEMPT_REALTIME encarnation that runs at all and is fairly
workable on this machine. This is a relief.


b) Laptop P4 2.533Ghz UP (Mandrake 10.1c)
   config-2.6.9-rc4-mm1-RT-U8.1.gz

   This box was known to work without major issues until U4. With U8 it's
a real pain. Once trivial operations turns out fatal now. Running jackd
-R, which has been a flagship before, now freezes the whole system in
no time. (I'll take some netconsole capture sessions later)

   One of the signs that there's real trouble in here can be seen on the
following complete dmesg output (which was even a miracle to be
captured at all). This shows the complete bootstrap and init sequences
and at the end one fatal crash while plugging an USB flash memory stick
(usb-storage). This has been already reported earlier yesterday, but I
just want to make it here, as the evidence-at-hand.

   After this precise occurence, the system becomes very flaky, unreliable
and often ends up freezing to death.


Hope this helps (me)

Bye now.
--
Linux version 2.6.9-rc4-mm1-RT-U8.1 (root@lambda) (gcc version 3.4.1
(Mandrakelinux (Alpha 3.4.1-3mdk)) #1 Thu Oct 21 09:08:18 WEST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001f770000 (usable)
 BIOS-e820: 000000001f770000 - 000000001f77f000 (ACPI data)
 BIOS-e820: 000000001f77f000 - 000000001f780000 (ACPI NVS)
 BIOS-e820: 000000001f780000 - 000000001f800000 (reserved)
 BIOS-e820: 000000002f780000 - 000000002f800000 (reserved)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
503MB LOWMEM available.
On node 0 totalpages: 128880
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 124784 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 PTLTD                                 ) @ 0x000f6c70
ACPI: RSDT (v001 PTLTD    RSDT   0x06040000  LTP 0x00000000) @ 0x1f7783fd
ACPI: FADT (v001 ATI    Salmon   0x06040000 ATI  0x000f4240) @ 0x1f77ef64
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x06040000  LTP 0x00000001) @ 0x1f77efd8
ACPI: DSDT (v001    ATI MS2_1535 0x06040000 MSFT 0x0100000e) @ 0x00000000
Built 1 zonelists
No local APIC present or hardware disabled
Initializing CPU#0
Kernel command line: BOOT_IMAGE=linux-RT-U8.1 ro root=305 devfs=nomount
acpi=on
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 2525.698 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 507728k/515520k available (1791k kernel code, 7300k reserved, 591k
data, 152k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 4931.58 BogoMIPS (lpj=2465792)
Security Scaffold v1.0.0 initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: bfebf9ff 00000000 00000000 00000000
CPU: After vendor identify, caps:  bfebf9ff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps:        bfebf9ff 00000000 00000000 00000080
CPU: Intel(R) Pentium(R) 4 CPU 2.53GHz stepping 07
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: IRQ9 SCI: Edge set to Level Trigger.
ksoftirqd started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfd88b, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040816
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Link [LNK0] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK1] (IRQs 7 *10)
ACPI: PCI Interrupt Link [LNK2] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK3] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK4] (IRQs 7 *10)
ACPI: PCI Interrupt Link [LNK5] (IRQs 7 *11)
ACPI: PCI Interrupt Link [LNK6] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK7] (IRQs *5)
ACPI: PCI Interrupt Link [LNK8] (IRQs 7 *10)
ACPI: Embedded Controller [EC0] (gpe 24)
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of "lspci" to bjorn.helgaas@hp.com
** so I can fix the driver.
Simple Boot Flag at 0x37 set to 0x1
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
Activating ISA DMA hang workarounds.
Real Time Clock Driver v1.12
ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [MSE0] at irq 12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
PCI: Enabling device 0000:00:08.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNK6] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI interrupt 0000:00:08.0[A] -> GSI 10 (level, low) -> IRQ 10
ttyS0 at I/O 0x1428 (irq = 10) is a 8250
ttyS2 at I/O 0x1440 (irq = 10) is a 8250
ttyS3 at I/O 0x1450 (irq = 10) is a 8250
ttyS4 at I/O 0x1460 (irq = 10) is a 8250
ttyS5 at I/O 0x1470 (irq = 10) is a 8250
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
ACPI: Floppy Controller [FDC] at I/O 0x3f0-0x3f5, 0x3f7 irq 6 dma channel 2
elevator: using anticipatory as default io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller at PCI slot 0000:00:10.0
ACPI: PCI interrupt 0000:00:10.0[A]: no GSI
ALI15X3: chipset revision 196
ALI15X3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x2000-0x2007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x2008-0x200f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: IC25N040ATCS04-0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: HL-DT-STCD-RW/DVD DRIVE GCC-4240N, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
Probing IDE interface ide4...
ide4: Wait for ready failed before probe !
Probing IDE interface ide5...
ide5: Wait for ready failed before probe !
hda: max request size: 128KiB
hda: 78140160 sectors (40007 MB) w/1768KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes not supported
 /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 >
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, DMA
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
Synaptics Touchpad, model: 1
 Firmware: 5.8
 Sensor: 35
 new absolute packet format
 Touchpad has extended capability bits
 -> multifinger detection
 -> palm detection
input: SynPS/2 Synaptics TouchPad on isa0060/serio1
NET: Registered protocol family 2
IP: routing cache hash table of 128 buckets, 20Kbytes
TCP: Hash tables configured (established 1024 bind 1638)
NET: Registered protocol family 1
NET: Registered protocol family 17
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 152k freed
kjournald starting.  Commit interval 5 seconds
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Processor [CPU0] (supports C1 C2)
ACPI: Thermal Zone [THRM] (52 C)
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [LNK8] enabled at IRQ 10
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 10 (level, low) -> IRQ 10
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: irq 10, pci mem 0xd4000000
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ACPI: PCI Interrupt Link [LNK4] enabled at IRQ 10
ACPI: PCI interrupt 0000:00:0f.0[A] -> GSI 10 (level, low) -> IRQ 10
ohci_hcd 0000:00:0f.0: OHCI Host Controller
ohci_hcd 0000:00:0f.0: irq 10, pci mem 0xd4009000
ohci_hcd 0000:00:0f.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
usb usb2: string descriptor 0 read error: -113
usb usb2: string descriptor 0 read error: -113
usb usb2: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
usb usb2: string descriptor 0 read error: -113
usb usb2: string descriptor 0 read error: -113
usb usb2: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
usb usb1: string descriptor 0 read error: -113
EXT3 FS on hda5, internal journal
Adding 506008k swap on /dev/hda6.  Priority:-1 extents:1
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
subfs 0.9
loop: loaded (max 8 devices)
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002
  originally by Donald Becker <becker@scyld.com>
  http://www.scyld.com/network/natsemi.html
  2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 10
ACPI: PCI interrupt 0000:00:12.0[A] -> GSI 10 (level, low) -> IRQ 10
natsemi eth0: NatSemi DP8381[56] at 0xd400a000 (0000:00:12.0),
00:0b:cd:85:0f:54, IRQ 10, port TP.
Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
PCI: Enabling device 0000:00:0a.0 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNK5] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 11 (level, low) -> IRQ 11
Yenta: CardBus bridge found at 0000:00:0a.0 [103c:0850]
Yenta: ISA IRQ mask 0x00b8, PCI irq 11
Socket status: 30000007
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x408-0x40f 0x480-0x48f
0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
prism2_cs: Ignoring new-style parameters in presence of obsolete ones
prism2cs_init: prism2_cs.o: 0.2.1-pre22 Loaded
prism2cs_init: dev_info is: prism2_cs
PCI: Enabling device 0000:00:06.0 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNK7] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI interrupt 0000:00:06.0[A] -> GSI 5 (level, low) -> IRQ 5
usbcore: registered new driver snd-usb-usx2y
Realtime LSM initialized (group 81, mlock=1)
mtrr: no more MTRRs available
ohci_hcd 0000:00:0f.0: wakeup
usb 2-1: new full speed USB device using address 2
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:598!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: usb_storage realtime commoncap snd_seq_oss
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_usb_usx2y
snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd_ali5451
snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore prism2_cs
p80211 ds yenta_socket pcmcia_core natsemi crc32 loop subfs evdev ohci_hcd
usbcore thermal processor fan button battery ac
CPU:    0
EIP:    0060:[<c01b7e24>]    Not tainted VLI
EFLAGS: 00010202   (2.6.9-rc4-mm1-RT-U8.1)
EIP is at up_write+0x1d4/0x202
eax: d4dce000   ebx: 00000292   ecx: d4e18980   edx: d52da030
esi: d4e69e24   edi: d5803400   ebp: d4dcfd6c   esp: d4dcfd4c
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process usb-stor (pid: 6630, threadinfo=d4dce000 task=d4dcd8f0)
Stack: d4dcd8f0 d4dcfd78 c02bea7a 00000001 d4dcd8f0 00000292 d4e18980
d5803400
       d4dcfd84 e018e139 d4e18980 d4dcfd84 00000292 d58034b8 d4dcfdac
c022ed0c
       d4e18980 c022ef10 c023166d 00000000 d4e189d4 d4e18980 dcf21000
d5803400
Call Trace:
 [<c0104eb0>] show_stack+0x80/0x96 (28)
 [<c010504b>] show_registers+0x165/0x1de (56)
 [<c010525d>] die+0xf6/0x191 (64)
 [<c0105797>] do_invalid_op+0x10b/0x10d (188)
 [<c0104b0d>] error_code+0x2d/0x38 (100)
 [<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)
 [<c022ed0c>] scsi_dispatch_cmd+0x168/0x218 (40)
 [<c02342e1>] scsi_request_fn+0x1ee/0x42b (52)
 [<c0205606>] blk_insert_request+0xcd/0xfb (44)
 [<c0232f43>] scsi_insert_special_req+0x3b/0x3f (28)
 [<c0233175>] scsi_wait_req+0x61/0x94 (60)
 [<c0235290>] scsi_probe_lun+0x8e/0x240 (68)
 [<c0235883>] scsi_probe_and_add_lun+0xb0/0x1be (48)
 [<c0236009>] scsi_scan_target+0xa4/0x123 (60)
 [<c0236115>] scsi_scan_channel+0x8d/0xa4 (48)
 [<c02361a5>] scsi_scan_host_selected+0x79/0xd4 (44)
 [<c0236231>] scsi_scan_host+0x31/0x33 (28)
 [<e0190cbd>] usb_stor_scan_thread+0x144/0x155 [usb_storage] (96)
 [<c0102305>] kernel_thread_helper+0x5/0xb (723714068)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: die+0x3a/0x191 / (do_invalid_op+0x10b/0x10d)
.. entry 2: print_traces+0x16/0x4a / (show_stack+0x80/0x96)

Code: e8 af f9 ff ff 89 f8 e8 fd af f5 ff e9 35 ff ff ff 0f 0b a5 00 e3 e8
2c c0 e9 da fe ff ff 0f 0b a4 00 e3 e8 2c c0 e9 c4 fe ff ff <0f> 0b 56 02
6f 75 2d c0 e9 3c fe ff ff e8 a8 5b 10 00 e9 22 ff
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: config-2.6.9-rc4-mm1-RT-U8.0smp.gz --]
[-- Type: application/x-gzip-compressed, Size: 7590 bytes --]

[-- Attachment #3: config-2.6.9-rc4-mm1-RT-U8.1.gz --]
[-- Type: application/x-gzip-compressed, Size: 8276 bytes --]

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:12                             ` Rui Nuno Capela
@ 2004-10-21  9:16                               ` Thomas Gleixner
  2004-10-21  9:35                                 ` Christoph Hellwig
  2004-10-21  9:53                                 ` Jens Axboe
  2004-10-21  9:18                               ` Ingo Molnar
                                                 ` (2 subsequent siblings)
  3 siblings, 2 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21  9:16 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 11:12, Rui Nuno Capela wrote:
>  [<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)

As I already pointed out, this is a problem due to up(sema) in
queuecommand. That's one of the semaphore abuse points, which needs to
be fixed. 

The problem is that semaphores are hold by Process A and released by
Process B, which makes Ingo's checks trigger

tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:12                             ` Rui Nuno Capela
  2004-10-21  9:16                               ` Thomas Gleixner
@ 2004-10-21  9:18                               ` Ingo Molnar
  2004-10-21 10:26                                 ` Rui Nuno Capela
  2004-10-21  9:55                               ` Thomas Gleixner
  2004-10-21 13:03                               ` Rui Nuno Capela
  3 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21  9:18 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

>    One of the signs that there's real trouble in here can be seen on
> the following complete dmesg output (which was even a miracle to be
> captured at all). This shows the complete bootstrap and init sequences
> and at the end one fatal crash while plugging an USB flash memory
> stick (usb-storage). This has been already reported earlier yesterday,
> but I just want to make it here, as the evidence-at-hand.
> 
>    After this precise occurence, the system becomes very flaky,
> unreliable and often ends up freezing to death.

for the sake of testing could you disable CONFIG_USB and see whether the
instability is truly directly related to the USB crash, as you suspect?
Such a kernel crash can often destabilize other parts of the kernel.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:16                               ` Thomas Gleixner
@ 2004-10-21  9:35                                 ` Christoph Hellwig
  2004-10-21  9:44                                   ` Ingo Molnar
  2004-10-21  9:47                                   ` Thomas Gleixner
  2004-10-21  9:53                                 ` Jens Axboe
  1 sibling, 2 replies; 951+ messages in thread
From: Christoph Hellwig @ 2004-10-21  9:35 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 11:16:30AM +0200, Thomas Gleixner wrote:
> On Thu, 2004-10-21 at 11:12, Rui Nuno Capela wrote:
> >  [<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)
> 
> As I already pointed out, this is a problem due to up(sema) in
> queuecommand. That's one of the semaphore abuse points, which needs to
> be fixed. 
> 
> The problem is that semaphores are hold by Process A and released by
> Process B, which makes Ingo's checks trigger

Which is perfectly valid for a semaphore.


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:35                                 ` Christoph Hellwig
@ 2004-10-21  9:44                                   ` Ingo Molnar
  2004-10-21  9:47                                     ` Christoph Hellwig
  2004-10-21  9:47                                   ` Thomas Gleixner
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21  9:44 UTC (permalink / raw)
  To: Christoph Hellwig, Thomas Gleixner, Rui Nuno Capela, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Christoph Hellwig <hch@infradead.org> wrote:

> > The problem is that semaphores are hold by Process A and released by
> > Process B, which makes Ingo's checks trigger
> 
> Which is perfectly valid for a semaphore.

yes, it is valid and perfectly fine code, but i'm trying to separate out
the simple 'mutex' functionality (99% of the semaphore users are just
that) and implement a 'counted semaphore' separately. This removes a
number of implementational constraints from mutexes.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:44                                   ` Ingo Molnar
@ 2004-10-21  9:47                                     ` Christoph Hellwig
  2004-10-21 10:03                                       ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Christoph Hellwig @ 2004-10-21  9:47 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Christoph Hellwig, Thomas Gleixner, Rui Nuno Capela, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 11:44:38AM +0200, Ingo Molnar wrote:
> 
> * Christoph Hellwig <hch@infradead.org> wrote:
> 
> > > The problem is that semaphores are hold by Process A and released by
> > > Process B, which makes Ingo's checks trigger
> > 
> > Which is perfectly valid for a semaphore.
> 
> yes, it is valid and perfectly fine code, but i'm trying to separate out
> the simple 'mutex' functionality (99% of the semaphore users are just
> that) and implement a 'counted semaphore' separately. This removes a
> number of implementational constraints from mutexes.

So leave the good old struct semaphore alone and introduce a mutex_t..


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:35                                 ` Christoph Hellwig
  2004-10-21  9:44                                   ` Ingo Molnar
@ 2004-10-21  9:47                                   ` Thomas Gleixner
  1 sibling, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21  9:47 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 11:35, Christoph Hellwig wrote:
> On Thu, Oct 21, 2004 at 11:16:30AM +0200, Thomas Gleixner wrote:
> > On Thu, 2004-10-21 at 11:12, Rui Nuno Capela wrote:
> > >  [<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)
> > 
> > As I already pointed out, this is a problem due to up(sema) in
> > queuecommand. That's one of the semaphore abuse points, which needs to
> > be fixed. 
> > 
> > The problem is that semaphores are hold by Process A and released by
> > Process B, which makes Ingo's checks trigger
> 
> Which is perfectly valid for a semaphore.
> 

In fact this is used where wait_for_completion() is the correct thing to
do. It's not waiting for a resource. It's waiting for completion of a
commoand.

tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:16                               ` Thomas Gleixner
  2004-10-21  9:35                                 ` Christoph Hellwig
@ 2004-10-21  9:53                                 ` Jens Axboe
  2004-10-21  9:54                                   ` Thomas Gleixner
  1 sibling, 1 reply; 951+ messages in thread
From: Jens Axboe @ 2004-10-21  9:53 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21 2004, Thomas Gleixner wrote:
> On Thu, 2004-10-21 at 11:12, Rui Nuno Capela wrote:
> >  [<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)
> 
> As I already pointed out, this is a problem due to up(sema) in
> queuecommand. That's one of the semaphore abuse points, which needs to
> be fixed. 
> 
> The problem is that semaphores are hold by Process A and released by
> Process B, which makes Ingo's checks trigger

That's utter crap, it's perfectly valid use.

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:53                                 ` Jens Axboe
@ 2004-10-21  9:54                                   ` Thomas Gleixner
  2004-10-21 10:11                                     ` Jens Axboe
  0 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21  9:54 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 11:53, Jens Axboe wrote:
> On Thu, Oct 21 2004, Thomas Gleixner wrote:
> > On Thu, 2004-10-21 at 11:12, Rui Nuno Capela wrote:
> > >  [<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)
> > 
> > As I already pointed out, this is a problem due to up(sema) in
> > queuecommand. That's one of the semaphore abuse points, which needs to
> > be fixed. 
> > 
> > The problem is that semaphores are hold by Process A and released by
> > Process B, which makes Ingo's checks trigger
> 
> That's utter crap, it's perfectly valid use.

It's not!

>From the code:

         init_MUTEX_LOCKED(&(us->sema));

This is used to wait for command completion and therefor we have the
completion API. It was used this way because the ancestor of completion
(sleep_on) was racy !

tglx





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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:12                             ` Rui Nuno Capela
  2004-10-21  9:16                               ` Thomas Gleixner
  2004-10-21  9:18                               ` Ingo Molnar
@ 2004-10-21  9:55                               ` Thomas Gleixner
  2004-10-21 13:03                               ` Rui Nuno Capela
  3 siblings, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21  9:55 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 11:12, Rui Nuno Capela wrote:

Can you try that one ?

diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/scsiglue.c
2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/scsiglue.c
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/scsiglue.c	2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/scsiglue.c	2004-10-21
11:45:14.000000000 +0200
@@ -187,7 +187,7 @@
 	us->srb = srb;
 
 	/* wake up the process task */
-	up(&(us->sema));
+	complete(&(us->done));
 
 	return 0;
 }
diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.c
2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.c
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.c	2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.c	2004-10-21
11:45:34.000000000 +0200
@@ -299,7 +299,7 @@
 
 	for(;;) {
 		US_DEBUGP("*** thread sleeping.\n");
-		if(down_interruptible(&us->sema))
+		if(wait_for_completion_interruptible(&us->done))
 			break;
 			
 		US_DEBUGP("*** thread awakened.\n");
@@ -941,7 +941,7 @@
 	}
 	memset(us, 0, sizeof(struct us_data));
 	init_MUTEX(&(us->dev_semaphore));
-	init_MUTEX_LOCKED(&(us->sema));
+	init_completion(&(us->done));
 	init_completion(&(us->notify));
 	init_waitqueue_head(&us->dev_reset_wait);
 	init_waitqueue_head(&us->scsi_scan_wait);
diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.h
2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.h
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.h	2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.h	2004-10-21
11:45:13.000000000 +0200
@@ -159,8 +159,8 @@
 	dma_addr_t		iobuf_dma;
 
 	/* mutual exclusion and synchronization structures */
-	struct semaphore	sema;		 /* to sleep thread on   */
-	struct completion	notify;		 /* thread begin/end	 */
+	struct completion	done;   	 /* to sleep thread on   */
+	struct completion	notify; 	 /* thread begin/end	 */
 	wait_queue_head_t	dev_reset_wait;  /* wait during reset    */
 	wait_queue_head_t	scsi_scan_wait;	 /* wait before scanning */
 	struct completion	scsi_scan_done;	 /* scan thread end	 */



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:47                                     ` Christoph Hellwig
@ 2004-10-21 10:03                                       ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21 10:03 UTC (permalink / raw)
  To: Christoph Hellwig, Thomas Gleixner, Rui Nuno Capela, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Christoph Hellwig <hch@infradead.org> wrote:

> > yes, it is valid and perfectly fine code, but i'm trying to separate out
> > the simple 'mutex' functionality (99% of the semaphore users are just
> > that) and implement a 'counted semaphore' separately. This removes a
> > number of implementational constraints from mutexes.
> 
> So leave the good old struct semaphore alone and introduce a mutex_t..

with nearly 1000 'struct semaphore' references in the kernel and 980 of
them being simple mutex use this is rather impractical. So i instead
went for safely detecting the 20 non-mutex uses and converting those
places. (Btw., 90% of those 20 cases can be detected safely at
compile-time (and link-time) by removing DECLARE_MUTEX_LOCKED and making
sema_init() a macro that only allows constant values of 0 and 1 and
produces a link error for other cases.)

this work is still incomplete so i'm not arguing for upstream inclusion.

(But while we did this a couple of places did turn out to use semaphores
for completion which is inefficient - we converted those to completions
and are contributing those changes to mainline. But this issue is
totally orthogonal to the issue of counted semaphores.)

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:54                                   ` Thomas Gleixner
@ 2004-10-21 10:11                                     ` Jens Axboe
  2004-10-21 10:11                                       ` Thomas Gleixner
                                                         ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Jens Axboe @ 2004-10-21 10:11 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21 2004, Thomas Gleixner wrote:
> On Thu, 2004-10-21 at 11:53, Jens Axboe wrote:
> > On Thu, Oct 21 2004, Thomas Gleixner wrote:
> > > On Thu, 2004-10-21 at 11:12, Rui Nuno Capela wrote:
> > > >  [<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)
> > > 
> > > As I already pointed out, this is a problem due to up(sema) in
> > > queuecommand. That's one of the semaphore abuse points, which needs to
> > > be fixed. 
> > > 
> > > The problem is that semaphores are hold by Process A and released by
> > > Process B, which makes Ingo's checks trigger
> > 
> > That's utter crap, it's perfectly valid use.
> 
> It's not!
> 
> >From the code:
> 
>          init_MUTEX_LOCKED(&(us->sema));
> 
> This is used to wait for command completion and therefor we have the
> completion API. It was used this way because the ancestor of completion
> (sleep_on) was racy !

I didn't look at the USB code, I'm just saying that it's perfectly valid
use of a semaphore the pattern you describe (process A holding it,
process B releasing it).

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 10:11                                     ` Jens Axboe
@ 2004-10-21 10:11                                       ` Thomas Gleixner
  2004-10-21 10:42                                         ` Ingo Molnar
  2004-10-21 11:11                                         ` Jens Axboe
  2004-10-21 10:18                                       ` Ingo Molnar
  2004-10-21 19:58                                       ` Bill Huey
  2 siblings, 2 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21 10:11 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 12:11, Jens Axboe wrote:
> On Thu, Oct 21 2004, Thomas Gleixner wrote:
> > On Thu, 2004-10-21 at 11:53, Jens Axboe wrote:
> > > On Thu, Oct 21 2004, Thomas Gleixner wrote:
> > > > On Thu, 2004-10-21 at 11:12, Rui Nuno Capela wrote:
> > > > >  [<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)
> > > > 
> > > > As I already pointed out, this is a problem due to up(sema) in
> > > > queuecommand. That's one of the semaphore abuse points, which needs to
> > > > be fixed. 
> > > > 
> > > > The problem is that semaphores are hold by Process A and released by
> > > > Process B, which makes Ingo's checks trigger
> > > 
> > > That's utter crap, it's perfectly valid use.
> > 
> > It's not!
> > 
> > >From the code:
> > 
> >          init_MUTEX_LOCKED(&(us->sema));
> > 
> > This is used to wait for command completion and therefor we have the
> > completion API. It was used this way because the ancestor of completion
> > (sleep_on) was racy !
> 
> I didn't look at the USB code, I'm just saying that it's perfectly valid
> use of a semaphore the pattern you describe (process A holding it,
> process B releasing it).

Yeah, for a semaphore it is, but not for a mutex.

IMHO, this is not clearly seperated and therefor produces a lot of
confusion.

tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 10:11                                     ` Jens Axboe
  2004-10-21 10:11                                       ` Thomas Gleixner
@ 2004-10-21 10:18                                       ` Ingo Molnar
  2004-10-21 10:34                                         ` Jens Axboe
  2004-10-21 19:58                                       ` Bill Huey
  2 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21 10:18 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Thomas Gleixner, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Jens Axboe <axboe@suse.de> wrote:

> I didn't look at the USB code, I'm just saying that it's perfectly
> valid use of a semaphore the pattern you describe (process A holding
> it, process B releasing it).

yes, that is perfectly true, and sorry if we gave you the wrong
impression.

the goal of these patches is to do a semaphore->completion conversion in
cases where the semaphore was used for completion purposes. It's a bit
faster and more readable but not a 'bugfix' in any way. (another set of
patches are converting sleep_on() uses to wait_event*() plus waitqueues
- those can in fact be considered bugfixes in some cases.)

typically the cases where semaphores are held by one task and released
by another task happens coincide with this used-for-completion scenario.

[ the different-owner assert that triggers in my PREEMPT_REALTIME tree
is for completely different reasons and has no impact on upstream at
all. (It merely means 'Ingo does some weird stuff again, pester him, not
others'.) ]

	Ingo

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

* Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3
  2004-10-18  3:50                                 ` OGAWA Hirofumi
@ 2004-10-21 10:24                                   ` Dominik Karall
  0 siblings, 0 replies; 951+ messages in thread
From: Dominik Karall @ 2004-10-21 10:24 UTC (permalink / raw)
  To: OGAWA Hirofumi
  Cc: Lee Revell, Ingo Molnar, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Daniel Walker, Bill Huey,
	Andrew Morton, Adam Heath, Lorenzo Allegrucci, Andrew Rodland

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

On Monday 18 October 2004 05:50, OGAWA Hirofumi wrote:
> Dominik Karall <dominik.karall@gmx.net> writes:
> > yes, the bug only occurs on a specific file.
> > as the bug is present in -mm1 (without vp) too, i applied your patch to
> > that one. here is the output:
> >
> > fat_cache_check: id 0, contig 6415, fclus 38231, dclus 1010103
> > contig 6416, fclus 38231, dclus 1010103
> > contig 0, fclus 32, dclus 603964
> > contig 1, fclus 30, dclus 603960
> > contig 7, fclus 22, dclus 603950
> > contig 4, fclus 17, dclus 603943
> > contig 1, fclus 15, dclus 603940
> > contig 6, fclus 8, dclus 603931
> > contig 0, fclus 7, dclus 603929
>
> Thanks. Seems good. There is no inconsistency in cache.
>
> > and the movie starts to play in mplayer without problems. tell me if
> > you need more debugging!
>
> Can you please try the patch again? This patch should tell who added
> the cache.
>
> Thanks.

sorry, but i can't reproduce the bug again. even after a reboot the file works 
as normal. but i didn't changed anything on the file.
if the bug appears again, i will apply the patch and let you know!

best regards,
dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:18                               ` Ingo Molnar
@ 2004-10-21 10:26                                 ` Rui Nuno Capela
  2004-10-21 11:20                                   ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-21 10:26 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Ingo Molnar wrote:
>
> * Rui Nuno Capela <rncbc@rncbc.org> wrote:
>
>>    One of the signs that there's real trouble in here can be seen on
>> the following complete dmesg output (which was even a miracle to be
>> captured at all). This shows the complete bootstrap and init sequences
>> and at the end one fatal crash while plugging an USB flash memory
>> stick (usb-storage). This has been already reported earlier yesterday,
>> but I just want to make it here, as the evidence-at-hand.
>>
>>    After this precise occurence, the system becomes very flaky,
>> unreliable and often ends up freezing to death.
>
> for the sake of testing could you disable CONFIG_USB and see whether the
> instability is truly directly related to the USB crash, as you suspect?
> Such a kernel crash can often destabilize other parts of the kernel.
>

Just tested with CONFIG_USB off, and can't test the usb-storage crash, of
course. However, jackd  is still freezing to death. No console, nor syslog
output can be found. The system just dies sometime after some jack client
is launched. Will try further.

I'm on the way to test Thomas Gleixner's patch...

BBL
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 10:18                                       ` Ingo Molnar
@ 2004-10-21 10:34                                         ` Jens Axboe
  0 siblings, 0 replies; 951+ messages in thread
From: Jens Axboe @ 2004-10-21 10:34 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21 2004, Ingo Molnar wrote:
> 
> * Jens Axboe <axboe@suse.de> wrote:
> 
> > I didn't look at the USB code, I'm just saying that it's perfectly
> > valid use of a semaphore the pattern you describe (process A holding
> > it, process B releasing it).
> 
> yes, that is perfectly true, and sorry if we gave you the wrong
> impression.
> 
> the goal of these patches is to do a semaphore->completion conversion in
> cases where the semaphore was used for completion purposes. It's a bit
> faster and more readable but not a 'bugfix' in any way. (another set of
> patches are converting sleep_on() uses to wait_event*() plus waitqueues
> - those can in fact be considered bugfixes in some cases.)
> 
> typically the cases where semaphores are held by one task and released
> by another task happens coincide with this used-for-completion scenario.

Thanks for the explanation, I can agree with that.

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 10:11                                       ` Thomas Gleixner
@ 2004-10-21 10:42                                         ` Ingo Molnar
  2004-10-21 11:59                                           ` john cooper
  2004-10-21 11:11                                         ` Jens Axboe
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21 10:42 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Jens Axboe, Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Thomas Gleixner <tglx@linutronix.de> wrote:

> > > This is used to wait for command completion and therefor we have the
> > > completion API. It was used this way because the ancestor of completion
> > > (sleep_on) was racy !
> > 
> > I didn't look at the USB code, I'm just saying that it's perfectly valid
> > use of a semaphore the pattern you describe (process A holding it,
> > process B releasing it).
> 
> Yeah, for a semaphore it is, but not for a mutex.

but mutexes dont exist in upstream Linux as a separate entity. (they
exist in my tree but that's another ballgame.)

> IMHO, this is not clearly seperated and therefor produces a lot of
> confusion.

if used to complete some work then semaphores are indeed a tad unclean
and slightly slower than completions - but they are fully correct kernel
code. And there are much worse offenders of cleanliness around.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 10:11                                       ` Thomas Gleixner
  2004-10-21 10:42                                         ` Ingo Molnar
@ 2004-10-21 11:11                                         ` Jens Axboe
  2004-10-21 11:18                                           ` Thomas Gleixner
  1 sibling, 1 reply; 951+ messages in thread
From: Jens Axboe @ 2004-10-21 11:11 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21 2004, Thomas Gleixner wrote:
> On Thu, 2004-10-21 at 12:11, Jens Axboe wrote:
> > On Thu, Oct 21 2004, Thomas Gleixner wrote:
> > > On Thu, 2004-10-21 at 11:53, Jens Axboe wrote:
> > > > On Thu, Oct 21 2004, Thomas Gleixner wrote:
> > > > > On Thu, 2004-10-21 at 11:12, Rui Nuno Capela wrote:
> > > > > >  [<e018e139>] queuecommand+0x70/0x7c [usb_storage] (24)
> > > > > 
> > > > > As I already pointed out, this is a problem due to up(sema) in
> > > > > queuecommand. That's one of the semaphore abuse points, which needs to
> > > > > be fixed. 
> > > > > 
> > > > > The problem is that semaphores are hold by Process A and released by
> > > > > Process B, which makes Ingo's checks trigger
> > > > 
> > > > That's utter crap, it's perfectly valid use.
> > > 
> > > It's not!
> > > 
> > > >From the code:
> > > 
> > >          init_MUTEX_LOCKED(&(us->sema));
> > > 
> > > This is used to wait for command completion and therefor we have the
> > > completion API. It was used this way because the ancestor of completion
> > > (sleep_on) was racy !
> > 
> > I didn't look at the USB code, I'm just saying that it's perfectly valid
> > use of a semaphore the pattern you describe (process A holding it,
> > process B releasing it).
> 
> Yeah, for a semaphore it is, but not for a mutex.
> 
> IMHO, this is not clearly seperated and therefor produces a lot of
> confusion.

Semaphore and mutex has always been the same thing in Linux. Apparently
this isn't so in Ingos tree, you should make a clear distinction on
which you are discussing.

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 11:11                                         ` Jens Axboe
@ 2004-10-21 11:18                                           ` Thomas Gleixner
  0 siblings, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21 11:18 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 13:11, Jens Axboe wrote:
> > 
> > IMHO, this is not clearly seperated and therefor produces a lot of
> > confusion.
> 
> Semaphore and mutex has always been the same thing in Linux. Apparently
> this isn't so in Ingos tree, you should make a clear distinction on
> which you are discussing.

I agree, but this thread is discussing Ingo's tree :)

I know that semaphores and mutexes are the same, but that's something
which should be seperated IMHO. 

Ingo's changes reviel a couple of places where completion or wait_event
is more clean, than using a mutex. That's all I'm talking about. Sorry,
if I did not express it clearly enough or even used a wrong expression. 

The points, which we identify are not wrong from the view point when
they were coded. They use a mutex to wait for completion, which is
functional by the mutex implementation and common use in the kernel.

Part of this discussion is the given mixup in the kernel, which is
functionally correct, but if a mutex is changed to a real mutex then it
is wrong in the semantical sense.

tglx




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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 10:26                                 ` Rui Nuno Capela
@ 2004-10-21 11:20                                   ` Rui Nuno Capela
  0 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-21 11:20 UTC (permalink / raw)
  To: Ingo Molnar, Thomas Gleixner
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

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

>>
>> for the sake of testing could you disable CONFIG_USB and see whether the
>> instability is truly directly related to the USB crash, as you suspect?
>> Such a kernel crash can often destabilize other parts of the kernel.
>>
>
> Just tested with CONFIG_USB off, and can't test the usb-storage crash, of
> course. However, jackd  is still freezing to death. No console, nor syslog
> output can be found. The system just dies sometime after some jack client
> is launched. Will try further.
>
> I'm on the way to test Thomas Gleixner's patch...
>

OK. Thomas patch solves the usb-storage crash, but I added an oneliner
change to it, to make it build. Corrected patch is appended.

Thanks.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: realtime-preempt-2.6.9-rc4-mm1-U8.1_usb-storage.patch --]
[-- Type: text/plain, Size: 2163 bytes --]

diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/scsiglue.c
2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/scsiglue.c
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/scsiglue.c	2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/scsiglue.c	2004-10-21
11:45:14.000000000 +0200
@@ -187,7 +187,7 @@
 	us->srb = srb;
 
 	/* wake up the process task */
-	up(&(us->sema));
+	complete(&(us->done));
 
 	return 0;
 }
diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.c
2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.c
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.c	2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.c	2004-10-21
11:45:34.000000000 +0200
@@ -299,7 +299,7 @@
 
 	for(;;) {
 		US_DEBUGP("*** thread sleeping.\n");
-		if(down_interruptible(&us->sema))
+		if(wait_for_completion_interruptible(&us->done))
 			break;
 			
 		US_DEBUGP("*** thread awakened.\n");
@@ -845,7 +845,7 @@
 		scsi_unlock(us->host);
 		up(&us->dev_semaphore);
 
-		up(&us->sema);
+		complete(&us->done);
 		wait_for_completion(&us->notify);
 	}

@@ -941,7 +941,7 @@
 	}
 	memset(us, 0, sizeof(struct us_data));
 	init_MUTEX(&(us->dev_semaphore));
-	init_MUTEX_LOCKED(&(us->sema));
+	init_completion(&(us->done));
 	init_completion(&(us->notify));
 	init_waitqueue_head(&us->dev_reset_wait);
 	init_waitqueue_head(&us->scsi_scan_wait);
diff -urN 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.h
2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.h
--- 2.6.9-rc4-mm1-RT-U8/drivers/usb/storage/usb.h	2004-10-12
09:41:44.000000000 +0200
+++ 2.6.9-rc4-mm1-RT-U8.1/drivers/usb/storage/usb.h	2004-10-21
11:45:13.000000000 +0200
@@ -159,8 +159,8 @@
 	dma_addr_t		iobuf_dma;
 
 	/* mutual exclusion and synchronization structures */
-	struct semaphore	sema;		 /* to sleep thread on   */
-	struct completion	notify;		 /* thread begin/end	 */
+	struct completion	done;   	 /* to sleep thread on   */
+	struct completion	notify; 	 /* thread begin/end	 */
 	wait_queue_head_t	dev_reset_wait;  /* wait during reset    */
 	wait_queue_head_t	scsi_scan_wait;	 /* wait before scanning */
 	struct completion	scsi_scan_done;	 /* scan thread end	 */

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 10:42                                         ` Ingo Molnar
@ 2004-10-21 11:59                                           ` john cooper
  2004-10-21 14:16                                             ` Esben Nielsen
  0 siblings, 1 reply; 951+ messages in thread
From: john cooper @ 2004-10-21 11:59 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Jens Axboe, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	john cooper

Ingo Molnar wrote:

>* Thomas Gleixner <tglx@linutronix.de> wrote:
>
>
>>Yeah, for a semaphore it is, but not for a mutex.
>>
>
>but mutexes dont exist in upstream Linux as a separate entity. (they
>exist in my tree but that's another ballgame.)
>
Mutexes layered on existing semaphores seems convenient
at the moment. However a more native mutex mechanism
which tracks ownership would provide a basis for PI as
well as further instrumentation. This may not be an
issue at the present but I don't think it is too far
off.

-john




-- 
john.cooper@timesys.com


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21  9:12                             ` Rui Nuno Capela
                                                 ` (2 preceding siblings ...)
  2004-10-21  9:55                               ` Thomas Gleixner
@ 2004-10-21 13:03                               ` Rui Nuno Capela
  2004-10-21 13:41                                 ` Ingo Molnar
  2004-10-22 10:15                                 ` Rui Nuno Capela
  3 siblings, 2 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-21 13:03 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Rui Nuno Capela wrote:
> Ingo Molnar wrote:
>>
>> i have released the -U8 Real-Time Preemption patch:
>>
>>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8
>>
> [...]
>
> b) Laptop P4 2.533Ghz UP (Mandrake 10.1c)
>    config-2.6.9-rc4-mm1-RT-U8.1.gz
>
>    This box was known to work without major issues until U4. With U8 it's
> a real pain. Once trivial operations turns out fatal now. Running jackd
> -R, which has been a flagship before, now freezes the whole system in
> no time. (I'll take some netconsole capture sessions later)
>

OK.

Now that the usb-storage crash has been ironed out, thanks to Thomas
Gleixner's patch, I proceeded with some local experiments regarding the
jackd -R issue.

The fact is jackd -R (realtime mode; SCHED_FIFO) hosing the system, and
thats exposed as soon as some jack audio client application enters into
the chain.

Running jackd non-realtime (SCHED_OTHER) does not expose this problem, so
I think it's a scheduling related one.

With a default scenario, with all IRQ handlers under SCHED_OTHER
scheduling class and default priority, running jackd -R freezes completely
the system. Only a hard-reset or power-off is the way out.

Then I try tweaking the keyboard (IRQs 1,12), rtc (IRQ 8) and soundcard
(IRQ 5) scheduling policies to SCHED_FIFO and priority to something higher
than jackd's (e.g. chrt --fifo 60).

This way, running jack -R still hoses the system, in a somewhat less
egoistic manner, but still seems that it's the only process running on the
system taking full control of it. The evidence I could find was that
jackd's verbose output keeps pumping, as it would usually, but all the
rest poor things freeze to death. This time however, magic SysRq is of
some use, barely thanks to the i8042 IRQ scheduling promotion.

So it all seems that jackd -R is not crashing, nor anything else, for this
matter.

I really hate to say this, but this should be investigated for the RT
patch sake, obviously because the only purpose I find to it is precisely
running jackd -R, and I can swear it has been near perfection until U4
inclusive (think it was called VP back then :).

I hope I'm not the only one.

(IIRC Florian Schmidt was experiencing something similar, like system
intermitence, pauses, whatever, while also running jackd -R.)

Strange enough, all this is running on another SMP/HT box of mine, without
major issues. Guess that SMP makes the difference here.

But wait, now I remember to notice something there yet: running some jack
clients (e.g. fluidsynth) is much more expensive than usual wrt.CPU usage,
reaching very unusual levels above 40% sustained (this is actual CPU% as
reported by procps tools, not the DSP usage as reported by jack itself).
IMHO the SMP/HT effect just seems to mask the real trouble, as the
increased cost affects only one of the (virtual) CPUs.

I wonder if this does ring some bell out there. :)

Cheers,
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
                                               ` (8 preceding siblings ...)
  2004-10-21  9:12                             ` Rui Nuno Capela
@ 2004-10-21 13:27                             ` Ingo Molnar
  2004-10-21 14:22                               ` Thomas Gleixner
                                                 ` (7 more replies)
  9 siblings, 8 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21 13:27 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


i have released the -U9 Real-Time Preemption patch, which can be
downloaded from:

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

this too is a fixes-only release. It includes more driver fixes and
improvements from Thomas Gleixner.

Changes since -U8.1:

 - USB semaphore->completion conversion from Thomas Gleixner

 - netconsole fixes from Michal Schmidt

 - fbcon fixes

 - added counted semaphores, this is now used by firewire, XFS and ACPI. 
   This could fix the firewire breakage - but testing would be welcome.

 - PREEMPT_ACTIVE irqs-enabled critical path removal.

 - fixed irqs-off raw spinlock primitives on UP: they enabled irqs 
   before enabling preemption, creating a window for an interrupt to
   slip in and increase the critical path.

 - made the deadlock detector not crash the current process - it will
   just hang. This produces far nicer log output while still not
   endangering stability. Also, fixed a bug in the detector that happens 
   if the trace buffer overflows.

 - made the atomic-counter-underflow detector non-fatal as well, for the
   same reasons.

to create a -U9 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U9

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 13:03                               ` Rui Nuno Capela
@ 2004-10-21 13:41                                 ` Ingo Molnar
  2004-10-21 13:53                                   ` Ingo Molnar
  2004-10-22 10:15                                 ` Rui Nuno Capela
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21 13:41 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> The fact is jackd -R (realtime mode; SCHED_FIFO) hosing the system,
> and thats exposed as soon as some jack audio client application enters
> into the chain.
> 
> Running jackd non-realtime (SCHED_OTHER) does not expose this problem,
> so I think it's a scheduling related one.

i tried to pole jackd a little bit (just using things like
jack_freewheel and jack_impulse_grabber - i dont even know what they 
do), and got jackd into some sort of userspace loop:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2558 root      16   0 27900 1852 2152 S 97.8  0.8   2:36.38 jackd

attaching gdb to it shows:

 Loaded symbols for /usr/local/lib/jack/jack_oss.so
 0xffffe410 in ?? ()
 (gdb) bt
 #0  0xffffe410 in ?? ()
 #1  0xbffff7f8 in ?? ()
 #2  0x00000a67 in ?? ()
 #3  0x00000000 in ?? ()
 #4  0x4db8adf8 in pthread_join () from /lib/tls/libpthread.so.0
 #5  0xb77d6e66 in oss_driver_stop (driver=0x8055938) at  oss_driver.c:696
 #6  0x0804ba03 in jack_engine_delete (engine=0x805c308) at  engine.c:2466
 #7  0x0804ade7 in main (argc=3, argv=0xbffffb44) at jackd.c:207
 (gdb)

it's looping somewhere in the pthread code, and it does no system-calls
at all and thus no scheduling as well.

i dont know much about jackit, and it could easily be that something in
this kernel broke its interaction with pthread, but it seems to me that
this loop is in userspace and is only 'fatal' if the looping thread runs
at SCHED_FIFO priority. Could someone with more jackit experience try to
figure out what's going on here?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 13:41                                 ` Ingo Molnar
@ 2004-10-21 13:53                                   ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21 13:53 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


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

> i tried to pole jackd a little bit (just using things like
> jack_freewheel and jack_impulse_grabber - i dont even know what they 
> do), and got jackd into some sort of userspace loop:
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  2558 root      16   0 27900 1852 2152 S 97.8  0.8   2:36.38 jackd

ah ... i should have guessed that "jack_freewheel y" puts jackd into ...
freewheeling mode. So this is by design.

i still suspect that it's some sort of userspace loop causing the jackd
problems - just that under SCHED_OTHER you dont normally notice it,
while with jack -R it's fatal.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 11:59                                           ` john cooper
@ 2004-10-21 14:16                                             ` Esben Nielsen
  2004-10-21 14:52                                               ` john cooper
  0 siblings, 1 reply; 951+ messages in thread
From: Esben Nielsen @ 2004-10-21 14:16 UTC (permalink / raw)
  To: john cooper
  Cc: Ingo Molnar, Thomas Gleixner, Jens Axboe, Rui Nuno Capela, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, 21 Oct 2004, john cooper wrote:

> Ingo Molnar wrote:
> 
> >* Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> >
> >>Yeah, for a semaphore it is, but not for a mutex.
> >>
> >
> >but mutexes dont exist in upstream Linux as a separate entity. (they
> >exist in my tree but that's another ballgame.)
> >
> Mutexes layered on existing semaphores seems convenient
> at the moment. However a more native mutex mechanism
> which tracks ownership would provide a basis for PI as
> well as further instrumentation. This may not be an
> issue at the present but I don't think it is too far
> off.
> 
> -john
> 

Actually you need to have another kind of semaphore based on a new kind of
wait-queue: Priority based. I.e. the task with the highest priority get
woken up first. Then on top of that you build your mutex.

I was planning to start to look at it and try to see if I could get
anything to work, but I must admit I haven't got much further than
just getting Igno's -U8.1 up running.

An idea I had was to make a macro in list.h called
 list_insert_sorted(list, element, condition_statement)
and use that in this kind of wait_queue...

To get a mutex with priority inheritance add an element pointing to the
current owner and a field where you store the owners original priority
which it has to be set back to when it relases the mutex (I am not sure
how this will work out if someone holds several mutexes!)

Regards,
Esben



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 13:27                             ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Ingo Molnar
@ 2004-10-21 14:22                               ` Thomas Gleixner
  2004-10-21 14:43                                 ` Thomas Gleixner
  2004-10-21 15:41                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 HOTFIX Thomas Gleixner
                                                 ` (6 subsequent siblings)
  7 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21 14:22 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 15:27, Ingo Molnar wrote:
> i have released the -U9 Real-Time Preemption patch, which can be
> downloaded from:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 

impi watchdog conversion to completion api.

tglx

diff --exclude='*~' -urN
2.6.9-rc4-mm1-RT-U9/drivers/char/ipmi/ipmi_watchdog.c
2.6.9-rc4-mm1-U9-E0/drivers/char/ipmi/ipmi_watchdog.c
--- 2.6.9-rc4-mm1-RT-U9/drivers/char/ipmi/ipmi_watchdog.c	2004-10-21
15:47:23.000000000 +0200
+++ 2.6.9-rc4-mm1-U9-E0/drivers/char/ipmi/ipmi_watchdog.c	2004-10-21
15:41:53.000000000 +0200
@@ -386,16 +386,16 @@
    when both messages are free. */
 static atomic_t heartbeat_tofree = ATOMIC_INIT(0);
 static DECLARE_MUTEX(heartbeat_lock);
-static DECLARE_MUTEX(heartbeat_wait_lock);
+static DECLARE_COMPLETION(heartbeat_received);
 static void heartbeat_free_smi(struct ipmi_smi_msg *msg)
 {
     if (atomic_dec_and_test(&heartbeat_tofree))
-	    up(&heartbeat_wait_lock);
+	    complete(&heartbeat_received);
 }
 static void heartbeat_free_recv(struct ipmi_recv_msg *msg)
 {
     if (atomic_dec_and_test(&heartbeat_tofree))
-	    up(&heartbeat_wait_lock);
+	    complete(&heartbeat_received);
 }
 static struct ipmi_smi_msg heartbeat_smi_msg =
 {
@@ -473,7 +473,7 @@
 	}
 
 	/* Wait for the heartbeat to be sent. */
-	down(&heartbeat_wait_lock);
+	wait_for_completion(&heartbeat_received);
 
 	if (heartbeat_recv_msg.msg.data[0] != 0) {
 	    /* Got an error in the heartbeat response.  It was already



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 14:22                               ` Thomas Gleixner
@ 2004-10-21 14:43                                 ` Thomas Gleixner
  0 siblings, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21 14:43 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 16:22, Thomas Gleixner wrote:
> On Thu, 2004-10-21 at 15:27, Ingo Molnar wrote:
> > i have released the -U9 Real-Time Preemption patch, which can be
> > downloaded from:
> > 
> >   http://redhat.com/~mingo/realtime-preempt/
> > 
> 
> impi watchdog conversion to completion api.

Sorry, I copied the wrong file to the correct place.

tglx

diff --exclude='*~' -urN
2.6.9-rc4-mm1-RT-U9/drivers/char/ipmi/ipmi_watchdog.c
2.6.9-rc4-mm1-U9-E0/drivers/char/ipmi/ipmi_watchdog.c
--- 2.6.9-rc4-mm1-RT-U9/drivers/char/ipmi/ipmi_watchdog.c	2004-10-21
15:47:23.000000000 +0200
+++ 2.6.9-rc4-mm1-U9-E0/drivers/char/ipmi/ipmi_watchdog.c	2004-10-21
16:25:14.000000000 +0200
@@ -47,6 +47,7 @@
 #include <linux/reboot.h>
 #include <linux/wait.h>
 #include <linux/poll.h>
+#include <linux/completion.h>
 #ifdef CONFIG_X86_LOCAL_APIC
 #include <asm/apic.h>
 #endif
@@ -386,16 +387,16 @@
    when both messages are free. */
 static atomic_t heartbeat_tofree = ATOMIC_INIT(0);
 static DECLARE_MUTEX(heartbeat_lock);
-static DECLARE_MUTEX(heartbeat_wait_lock);
+static DECLARE_COMPLETION(heartbeat_received);
 static void heartbeat_free_smi(struct ipmi_smi_msg *msg)
 {
     if (atomic_dec_and_test(&heartbeat_tofree))
-	    up(&heartbeat_wait_lock);
+	    complete(&heartbeat_received);
 }
 static void heartbeat_free_recv(struct ipmi_recv_msg *msg)
 {
     if (atomic_dec_and_test(&heartbeat_tofree))
-	    up(&heartbeat_wait_lock);
+	    complete(&heartbeat_received);
 }
 static struct ipmi_smi_msg heartbeat_smi_msg =
 {
@@ -473,7 +474,7 @@
 	}
 
 	/* Wait for the heartbeat to be sent. */
-	down(&heartbeat_wait_lock);
+	wait_for_completion(&heartbeat_received);
 
 	if (heartbeat_recv_msg.msg.data[0] != 0) {
 	    /* Got an error in the heartbeat response.  It was already
@@ -944,7 +945,6 @@
 {
 	int rv;
 
-	init_MUTEX_LOCKED(&heartbeat_wait_lock);
 	printk(KERN_INFO PFX "driver version "
 	       IPMI_WATCHDOG_VERSION "\n");
 



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 14:16                                             ` Esben Nielsen
@ 2004-10-21 14:52                                               ` john cooper
  2004-10-21 15:47                                                 ` Eugeny S. Mints
  0 siblings, 1 reply; 951+ messages in thread
From: john cooper @ 2004-10-21 14:52 UTC (permalink / raw)
  To: Esben Nielsen
  Cc: Ingo Molnar, Thomas Gleixner, Jens Axboe, Rui Nuno Capela, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	john cooper

Esben Nielsen wrote:

>On Thu, 21 Oct 2004, john cooper wrote:
>
>>Mutexes layered on existing semaphores seems convenient
>>at the moment. However a more native mutex mechanism
>>which tracks ownership would provide a basis for PI as
>>well as further instrumentation. This may not be an
>>issue at the present but I don't think it is too far
>>off.
>>
>>-john
>>
>>
>
>Actually you need to have another kind of semaphore based on a new kind of
>wait-queue: Priority based. I.e. the task with the highest priority get
>woken up first. Then on top of that you build your mutex.
>
That more/less falls out of the PI mechanism. Though it
appears conserving per-mutex data footprint and O(1)
behavior are going to be at odds.

>I was planning to start to look at it and try to see if I could get
>anything to work, but I must admit I haven't got much further than
>just getting Igno's -U8.1 up running.
>
I myself wonder whether Ingo is 1 or N people.

>To get a mutex with priority inheritance add an element pointing to the
>current owner and a field where you store the owners original priority
>which it has to be set back to when it relases the mutex (I am not sure
>how this will work out if someone holds several mutexes!)
>
A task holding several mutexes shouldn't be an issue.
Though per task an ownership list needs to be maintained
in descending priority order such that the effective PI
can be resolved from all task owned mutexes.

Also a multiple ownership model is needed for the case of
shared-reader locks. This results in a list of owners
where the list element can maintain per-mutex task ownership
as well as per-task mutex ownerships.

It is tempting to re-implement the wheel here but existing
works are well on their way:

http://developer.osdl.org/dev/robustmutexes

-john

-- 
john.cooper@timesys.com


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 HOTFIX
  2004-10-21 13:27                             ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Ingo Molnar
  2004-10-21 14:22                               ` Thomas Gleixner
@ 2004-10-21 15:41                               ` Thomas Gleixner
  2004-10-21 15:58                                 ` Ingo Molnar
  2004-10-21 15:43                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Michal Schmidt
                                                 ` (5 subsequent siblings)
  7 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21 15:41 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 15:27, Ingo Molnar wrote:
> i have released the -U9 Real-Time Preemption patch, which can be
> downloaded from:

tglx

diff --exclude='*~' -urN 2.6.9-rc4-mm1-RT-U9/kernel/sched.c
2.6.9-rc4-mm1-U9-E0/kernel/sched.c
--- 2.6.9-rc4-mm1-RT-U9/kernel/sched.c	2004-10-21 15:47:21.000000000
+0200
+++ 2.6.9-rc4-mm1-U9-E0/kernel/sched.c	2004-10-21 17:17:44.000000000
+0200
@@ -3185,9 +3185,9 @@
 			__set_current_state(TASK_UNINTERRUPTIBLE);
 			spin_unlock_irq(&x->wait.lock);
 			timeout = schedule_timeout(timeout);
+			spin_lock_irq(&x->wait.lock);
 			if (!timeout)
 				goto out;
-			spin_lock_irq(&x->wait.lock);
 		} while (!x->done);
 		__remove_wait_queue(&x->wait, &wait);
 	}
@@ -3250,8 +3250,10 @@
 			}
 			__set_current_state(TASK_INTERRUPTIBLE);
 			spin_unlock_irq(&x->wait.lock);
-			schedule();
-			spin_lock_irq(&x->wait.lock);
+			timeout = schedule_timeout(timeout);
+ 			spin_lock_irq(&x->wait.lock);
+			if (!timeout)
+				goto out;
 		} while (!x->done);
 		__remove_wait_queue(&x->wait, &wait);
 	}



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 13:27                             ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Ingo Molnar
  2004-10-21 14:22                               ` Thomas Gleixner
  2004-10-21 15:41                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 HOTFIX Thomas Gleixner
@ 2004-10-21 15:43                               ` Michal Schmidt
  2004-10-21 16:00                                 ` Ingo Molnar
  2004-10-21 18:06                               ` Gunther Persoons
                                                 ` (4 subsequent siblings)
  7 siblings, 1 reply; 951+ messages in thread
From: Michal Schmidt @ 2004-10-21 15:43 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano

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

Ingo Molnar wrote:
> 
>  - netconsole fixes from Michal Schmidt
> 

The #ifdef is not right. Patch attached.

Michal

[-- Attachment #2: netconsole-ifdef.diff --]
[-- Type: text/x-patch, Size: 443 bytes --]

--- linux-2.6.9-rc4-mm1-U9.1/drivers/net/netconsole.c	2004-10-21 17:14:22.000000000 +0200
+++ linux-2.6.9-rc4-mm1-U9.1-mich/drivers/net/netconsole.c	2004-10-21 17:15:09.000000000 +0200
@@ -74,7 +74,7 @@ static void write_msg(struct console *co
 		return;
 
 	local_irq_save(flags);
-#ifdef PREEMPT_REALTIME
+#ifdef CONFIG_PREEMPT_REALTIME
 	/*
 	 * A bit hairy. Netconsole uses mutexes (indirectly) and
 	 * thus must have interrupts enabled:

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 14:52                                               ` john cooper
@ 2004-10-21 15:47                                                 ` Eugeny S. Mints
  2004-10-21 16:49                                                   ` john cooper
  2004-10-21 17:41                                                   ` Scott Wood
  0 siblings, 2 replies; 951+ messages in thread
From: Eugeny S. Mints @ 2004-10-21 15:47 UTC (permalink / raw)
  To: john cooper
  Cc: Esben Nielsen, Ingo Molnar, Thomas Gleixner, Jens Axboe,
	Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

john cooper wrote:
> Esben Nielsen wrote:
> 
>> On Thu, 21 Oct 2004, john cooper wrote:
>>
>>> Mutexes layered on existing semaphores seems convenient
>>> at the moment. However a more native mutex mechanism
>>> which tracks ownership would provide a basis for PI as
>>> well as further instrumentation. This may not be an
>>> issue at the present but I don't think it is too far
>>> off.
>>>
>>> -john
>>>
>>>
>>
>> Actually you need to have another kind of semaphore based on a new 
>> kind of
>> wait-queue: Priority based. I.e. the task with the highest priority get
>> woken up first. Then on top of that you build your mutex.
>>
> That more/less falls out of the PI mechanism. Though it
> appears conserving per-mutex data footprint and O(1)
> behavior are going to be at odds.
> 
>> I was planning to start to look at it and try to see if I could get
>> anything to work, but I must admit I haven't got much further than
>> just getting Igno's -U8.1 up running.
>>
> I myself wonder whether Ingo is 1 or N people.
> 
>> To get a mutex with priority inheritance add an element pointing to the
>> current owner and a field where you store the owners original priority
>> which it has to be set back to when it relases the mutex (I am not sure
>> how this will work out if someone holds several mutexes!)
>>
> A task holding several mutexes shouldn't be an issue.
> Though per task an ownership list needs to be maintained
> in descending priority order such that the effective PI
> can be resolved from all task owned mutexes.

Seems it is too coplex model at least for the first step. The one of 
possible trade-offs coming on mind is to trace the number of resources 
(mutexes) held by a process and to restore original priority only when 
resource count reaches 0. This is one of the sollutions accepted by RTOS 
guys.

The other concern with PI is that most likely PI should be prohibited 
for utilization with locks which are used in the way similar to "waiting 
completition" - i.e. if PI is employed on a mutex it is prohibited to 
release it if a process is not the owner of the mutex.

> 
> Also a multiple ownership model is needed for the case of
> shared-reader locks. This results in a list of owners
> where the list element can maintain per-mutex task ownership
> as well as per-task mutex ownerships.
> It is tempting to re-implement the wheel here but existing
> works are well on their way:
> 
> http://developer.osdl.org/dev/robustmutexes

It is definitly non-trivial work to adapt this approach - there are a 
lot of issues.

				Eugeny
> -john
> 



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 HOTFIX
  2004-10-21 15:41                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 HOTFIX Thomas Gleixner
@ 2004-10-21 15:58                                 ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21 15:58 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

* Thomas Gleixner <tglx@linutronix.de> wrote:

> +			spin_lock_irq(&x->wait.lock);
>  			if (!timeout)
>  				goto out;
> -			spin_lock_irq(&x->wait.lock);

> -			schedule();
> -			spin_lock_irq(&x->wait.lock);
> +			timeout = schedule_timeout(timeout);
> + 			spin_lock_irq(&x->wait.lock);
> +			if (!timeout)
> +				goto out;

yeah. I've added these fixes and uploaded -U9.2.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 15:43                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Michal Schmidt
@ 2004-10-21 16:00                                 ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21 16:00 UTC (permalink / raw)
  To: Michal Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano


* Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:

> Ingo Molnar wrote:
> >
> > - netconsole fixes from Michal Schmidt
> >
> 
> The #ifdef is not right. Patch attached.

indeed - i've added this to -U9.2 too.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 18:06                               ` Gunther Persoons
@ 2004-10-21 16:40                                 ` Ingo Molnar
  2004-10-21 17:54                                   ` Nikita Danilov
  2004-10-21 20:21                                   ` Gunther Persoons
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-21 16:40 UTC (permalink / raw)
  To: Gunther Persoons; +Cc: linux-kernel


* Gunther Persoons <gunther_persoons@spymac.com> wrote:

> The kernel booted now with my firewire card plugged in. However when i
> try to mount my reiser4 partition i get following error
> 
> BUG: semaphore recursion deadlock detected!
> .. current task mount/10514 is already holding ccb5bb4c.

> [<c0344760>] down_write+0x103/0x1a6 (48)
> [<d0b26a08>] kcond_wait+0xaa/0xac [reiser4] (36)
> [<d0b280b0>] start_ktxnmgrd+0x98/0x9a [reiser4] (36)
> [<d0b33716>] reiser4_fill_super+0x3b/0x71 [reiser4] (28)
> [<d0b2d569>] reiser4_get_sb+0x2f/0x33 [reiser4] (68)
> [<c016061a>] do_kern_mount+0x4f/0xc0 (4)
> [<c0175945>] do_new_mount+0x9c/0xe1 (36)
> [<c0175feb>] do_mount+0x145/0x194 (44)
> [<c0176459>] sys_mount+0x9f/0xe0 (32)
> [<c01060b1>] sysenter_past_esp+0x52/0x71 (44)

reiser4 has some pretty ugly locking abstraction called kcond, i took a
look but it doesnt seem simple to convert it. Reiserfs should really use
a normal Linux waitqueue and nothing more...

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 15:47                                                 ` Eugeny S. Mints
@ 2004-10-21 16:49                                                   ` john cooper
  2004-10-21 17:33                                                     ` Scott Wood
  2004-10-21 17:54                                                     ` Eugeny S. Mints
  2004-10-21 17:41                                                   ` Scott Wood
  1 sibling, 2 replies; 951+ messages in thread
From: john cooper @ 2004-10-21 16:49 UTC (permalink / raw)
  To: Eugeny S. Mints
  Cc: Esben Nielsen, Ingo Molnar, Thomas Gleixner, Jens Axboe,
	Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, john cooper

Eugeny S. Mints wrote:

> john cooper wrote:
>
>> A task holding several mutexes shouldn't be an issue.
>> Though per task an ownership list needs to be maintained
>> in descending priority order such that the effective PI
>> can be resolved from all task owned mutexes.
>
>
> Seems it is too coplex model at least for the first step. The one of 
> possible trade-offs coming on mind is to trace the number of resources 
> (mutexes) held by a process and to restore original priority only when 
> resource count reaches 0. This is one of the sollutions accepted by 
> RTOS guys.

It would seem a mutex ownership list still needs to be maintained.
Doing so in unordered priority will give a small fixed insertion
time, but will require an exhaustive search in order to calculate
maximum priority. Doing so in priority order will require an
average of #mutex_owned / 2 for the insertion, and gives a fixed
time for maximum priority calculation. The latter appears to offer
a performance benefit to the degree the incoming priorities are
random.

> The other concern with PI is that most likely PI should be prohibited 
> for utilization with locks which are used in the way similar to 
> "waiting completition" - i.e. if PI is employed on a mutex it is 
> prohibited to release it if a process is not the owner of the mutex.

Yes, that type of usage breaks the notion of ownership.
It would be a error for a task to attempt relinquishing
a mutex which it had not acquired and was holding at the
time of unlock.

>> http://developer.osdl.org/dev/robustmutexes
>
>
> It is definitly non-trivial work to adapt this approach - there are a 
> lot of issues.

I should have qualified that reference. Those folks are
addressing more than PI mutexes. Indeed their goal is
support of fast user mutexes which offer detection of mutex
owners gone astray (exited, killed, etc..). It is the kernel
component of the work to which I was referring.

-john


-- 
john.cooper@timesys.com


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 16:27                             ` Adam Heath
@ 2004-10-21 16:59                               ` Adam Heath
  0 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-21 16:59 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Wed, 20 Oct 2004, Adam Heath wrote:

> On Wed, 20 Oct 2004, Ingo Molnar wrote:
>
> >
> > i have released the -U8 Real-Time Preemption patch:
> >
> >   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8
>
> Grr.  I got this -U8 mail *before* I got the -U7 mail.
>
> All thruout these U# kernels, I get stalls in X(everything pauses, not sure if
> remote pings stop).  Nothing shows in dmesg when this occurs.

Got some input on this.

Heavy disk and/or network i/o seems to cause the pauses.  Doing a copy over
nfs(writing to disk), or using scp gives me 1-2 MB/s.  If I boot plain rc4, I
get full network speed(10-11 MB/s with nfs, 5-8 MB/s with scp).

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 16:49                                                   ` john cooper
@ 2004-10-21 17:33                                                     ` Scott Wood
  2004-10-21 18:09                                                       ` john cooper
  2004-10-21 18:10                                                       ` Eugeny S. Mints
  2004-10-21 17:54                                                     ` Eugeny S. Mints
  1 sibling, 2 replies; 951+ messages in thread
From: Scott Wood @ 2004-10-21 17:33 UTC (permalink / raw)
  To: john cooper
  Cc: Eugeny S. Mints, Esben Nielsen, Ingo Molnar, Thomas Gleixner,
	Jens Axboe, Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 12:49:30PM -0400, john cooper wrote:
> It would seem a mutex ownership list still needs to be maintained.
> Doing so in unordered priority will give a small fixed insertion
> time, but will require an exhaustive search in order to calculate
> maximum priority. Doing so in priority order will require an
> average of #mutex_owned / 2 for the insertion, and gives a fixed
> time for maximum priority calculation. The latter appears to offer
> a performance benefit to the degree the incoming priorities are
> random.

If you keep it in priority order, then you're paying the O(n) cost
every time you acquire a lock.  If you keep it unordered and only
search it when you need to recalculate a task's priority after a lock
has been released (or priorities have been changed), you pay the cost
much less often.  Plus, the number of locks held by any given thread
should generally be very small.

-Scott

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 15:47                                                 ` Eugeny S. Mints
  2004-10-21 16:49                                                   ` john cooper
@ 2004-10-21 17:41                                                   ` Scott Wood
  1 sibling, 0 replies; 951+ messages in thread
From: Scott Wood @ 2004-10-21 17:41 UTC (permalink / raw)
  To: Eugeny S. Mints
  Cc: john cooper, Esben Nielsen, Ingo Molnar, Thomas Gleixner,
	Jens Axboe, Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 07:47:29PM +0400, Eugeny S. Mints wrote:
> Seems it is too coplex model at least for the first step. The one of 
> possible trade-offs coming on mind is to trace the number of resources 
> (mutexes) held by a process and to restore original priority only when 
> resource count reaches 0. This is one of the sollutions accepted by RTOS 
> guys.

That complicates analysis, though, since you now have to look at all
critical sections that the shared-with-high-priority-threads critical
sections nest in.  IMHO, it's important that the inherited priority
be given up as soon as the resource is released.

-Scott

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 16:49                                                   ` john cooper
  2004-10-21 17:33                                                     ` Scott Wood
@ 2004-10-21 17:54                                                     ` Eugeny S. Mints
  1 sibling, 0 replies; 951+ messages in thread
From: Eugeny S. Mints @ 2004-10-21 17:54 UTC (permalink / raw)
  To: john cooper
  Cc: Esben Nielsen, Ingo Molnar, Thomas Gleixner, Jens Axboe,
	Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Ext-Rt-Dev@Mvista. Com

john cooper wrote:
> Eugeny S. Mints wrote:
> 
>> john cooper wrote:
>>
>>> A task holding several mutexes shouldn't be an issue.
>>> Though per task an ownership list needs to be maintained
>>> in descending priority order such that the effective PI
>>> can be resolved from all task owned mutexes.
>>
>>
>>
>> Seems it is too coplex model at least for the first step. The one of 
>> possible trade-offs coming on mind is to trace the number of resources 
>> (mutexes) held by a process and to restore original priority only when 
>> resource count reaches 0. This is one of the sollutions accepted by 
>> RTOS guys.
> 
> 
> It would seem a mutex ownership list still needs to be maintained.
> Doing so in unordered priority will give a small fixed insertion
> time, but will require an exhaustive search in order to calculate
> maximum priority. Doing so in priority order will require an
> average of #mutex_owned / 2 for the insertion, and gives a fixed
> time for maximum priority calculation. The latter appears to offer
> a performance benefit to the degree the incoming priorities are
> random.

Yes, definilty, I 100% agree with you - I have _not_ disputed the 
priority list approach at all.

>> The other concern with PI is that most likely PI should be prohibited 
>> for utilization with locks which are used in the way similar to 
>> "waiting completition" - i.e. if PI is employed on a mutex it is 
>> prohibited to release it if a process is not the owner of the mutex.
> 
> 
> Yes, that type of usage breaks the notion of ownership.
> It would be a error for a task to attempt relinquishing
> a mutex which it had not acquired and was holding at the
> time of unlock.

exactly

>>> http://developer.osdl.org/dev/robustmutexes
>>
>>
>>
>> It is definitly non-trivial work to adapt this approach - there are a 
>> lot of issues.
> 
> 
> I should have qualified that reference. Those folks are
> addressing more than PI mutexes. Indeed their goal is
> support of fast user mutexes which offer detection of mutex
> owners gone astray (exited, killed, etc..). It is the kernel
> component of the work to which I was referring.

Ok, I've also talked about kernel component not user space one. User 
space approach with robustness, fast uncontented obtaining, etc looks 
very attractive but both kernel and user space parts have their issues -
though I took a glance to the project about 2 months ago.

			Eugeny



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 16:40                                 ` Ingo Molnar
@ 2004-10-21 17:54                                   ` Nikita Danilov
  2004-10-22 10:22                                     ` Ingo Molnar
  2004-10-21 20:21                                   ` Gunther Persoons
  1 sibling, 1 reply; 951+ messages in thread
From: Nikita Danilov @ 2004-10-21 17:54 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Gunther Persoons, linux-kernel

Ingo Molnar writes:
 > 
 > * Gunther Persoons <gunther_persoons@spymac.com> wrote:
 > 
 > > The kernel booted now with my firewire card plugged in. However when i
 > > try to mount my reiser4 partition i get following error
 > > 
 > > BUG: semaphore recursion deadlock detected!
 > > .. current task mount/10514 is already holding ccb5bb4c.
 > 
 > > [<c0344760>] down_write+0x103/0x1a6 (48)
 > > [<d0b26a08>] kcond_wait+0xaa/0xac [reiser4] (36)
 > > [<d0b280b0>] start_ktxnmgrd+0x98/0x9a [reiser4] (36)
 > > [<d0b33716>] reiser4_fill_super+0x3b/0x71 [reiser4] (28)
 > > [<d0b2d569>] reiser4_get_sb+0x2f/0x33 [reiser4] (68)
 > > [<c016061a>] do_kern_mount+0x4f/0xc0 (4)
 > > [<c0175945>] do_new_mount+0x9c/0xe1 (36)
 > > [<c0175feb>] do_mount+0x145/0x194 (44)
 > > [<c0176459>] sys_mount+0x9f/0xe0 (32)
 > > [<c01060b1>] sysenter_past_esp+0x52/0x71 (44)
 > 
 > reiser4 has some pretty ugly locking abstraction called kcond, i took a

It's fairly standard condition variable.

 > look but it doesnt seem simple to convert it. Reiserfs should really use
 > a normal Linux waitqueue and nothing more...

Why? Condition variable is very well known and widely used concept. In
the area of their applicability (where predicate whose change is waited
upon is protected by a single lock) they provide clean and easily
recognizable synchronization device.

Real problem in this case is failure of "semaphore deadlock detection"
to cope with perfectly legal semaphore usage (down() by thread T1, up()
by thread T2). As one possible solution kcond can be re-written on top
of beloved "normal Linux waitqueue".

Nikita.
 
 > 
 > 	Ingo


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 13:27                             ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Ingo Molnar
                                                 ` (2 preceding siblings ...)
  2004-10-21 15:43                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Michal Schmidt
@ 2004-10-21 18:06                               ` Gunther Persoons
  2004-10-21 16:40                                 ` Ingo Molnar
  2004-10-21 18:07                               ` K.R. Foley
                                                 ` (3 subsequent siblings)
  7 siblings, 1 reply; 951+ messages in thread
From: Gunther Persoons @ 2004-10-21 18:06 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Ingo Molnar wrote:

>i have released the -U9 Real-Time Preemption patch, which can be
>downloaded from:
>
>  http://redhat.com/~mingo/realtime-preempt/
>
>this too is a fixes-only release. It includes more driver fixes and
>improvements from Thomas Gleixner.
>
>Changes since -U8.1:
>
> - USB semaphore->completion conversion from Thomas Gleixner
>
> - netconsole fixes from Michal Schmidt
>
> - fbcon fixes
>
> - added counted semaphores, this is now used by firewire, XFS and ACPI. 
>   This could fix the firewire breakage - but testing would be welcome.
>
> - PREEMPT_ACTIVE irqs-enabled critical path removal.
>
> - fixed irqs-off raw spinlock primitives on UP: they enabled irqs 
>   before enabling preemption, creating a window for an interrupt to
>   slip in and increase the critical path.
>
> - made the deadlock detector not crash the current process - it will
>   just hang. This produces far nicer log output while still not
>   endangering stability. Also, fixed a bug in the detector that happens 
>   if the trace buffer overflows.
>
> - made the atomic-counter-underflow detector non-fatal as well, for the
>   same reasons.
>
>to create a -U9 tree from scratch, the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
> + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
> + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
> + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U9
>
>	Ingo
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
Hey,

The kernel booted now with my firewire card plugged in. However when i 
try to mount my reiser4 partition i get following error

BUG: semaphore recursion deadlock detected!
.. current task mount/10514 is already holding ccb5bb4c.
c022d6cb cf25d8f0 ccb5bae8 00002912 ccb5bb4c 00000000 ccb5bb48 ccb5a000
       ccb5bb4c cf25d8f0 00000000 ccb5bb48 c0344760 ccb5bb4c 0000019d 
ccb5bb50
       ccb5bb50 cf25d8f0 00000002 ccabdc00 ccb5bb4c d0b26a08 ccabdd4c 
c0120005
Call Trace:
 [<c022d6cb>] __rwsem_deadlock+0xd9/0x12d (4)
 [<c0344760>] down_write+0x103/0x1a6 (48)
 [<d0b26a08>] kcond_wait+0xaa/0xac [reiser4] (36)
 [<c0120005>] do_fork+0x133/0x18a (8)
 [<c03443a8>] out_of_line_wait_on_bit+0x91/0x99 (32)
 [<c0134273>] wake_bit_function+0x0/0x55 (28)
 [<c0134c36>] check_preempt_timing+0x6e/0x1a4 (16)
 [<c034471a>] down_write+0xbd/0x1a6 (56)
 [<c034471a>] down_write+0xbd/0x1a6 (12)
 [<d0b280b0>] start_ktxnmgrd+0x98/0x9a [reiser4] (36)
 [<d0b33716>] reiser4_fill_super+0x3b/0x71 [reiser4] (28)
 [<c0160854>] sb_set_blocksize+0x2e/0x5d (588)
 [<c01603fd>] get_sb_bdev+0xf9/0x132 (24)
 [<d0b2d569>] reiser4_get_sb+0x2f/0x33 [reiser4] (68)
 [<d0b336db>] reiser4_fill_super+0x0/0x71 [reiser4] (20)
 [<c016061a>] do_kern_mount+0x4f/0xc0 (4)
 [<c0175945>] do_new_mount+0x9c/0xe1 (36)
 [<c0175feb>] do_mount+0x145/0x194 (44)
 [<c034471a>] down_write+0xbd/0x1a6 (48)
 [<c0175e4d>] copy_mount_options+0x63/0xbc (32)
 [<c0176459>] sys_mount+0x9f/0xe0 (32)
 [<c01060b1>] sysenter_past_esp+0x52/0x71 (44)
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x1a1/0x1a6 / (0x0)
.. entry 2: down_write+0x6a/0x1a6 / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)

------------[ cut here ]------------
kernel BUG at lib/rwsem-generic.c:601!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: reiser4 airo_cs airo ohci_hcd ehci_hcd 8139cp mii 
ohci1394 ieee1394 snd_intel8x0 snd_ac97_codec usbhid uhci_hcd intel_agp 
agpgart snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device 
snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd usbcore 
vfat fat
CPU:    0
EIP:    0060:[<c022dc15>]    Not tainted VLI
EFLAGS: 00010202   (2.6.9-rc4-mm1-RT-U9.1)
EIP is at up_write+0x1dc/0x1e9
eax: cca0a000   ebx: ccb5bb48   ecx: 0000002f   edx: cf25d8f0
esi: ccb5bb4c   edi: ccabdc00   ebp: cf1ad970   esp: cca0bf84
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process ktxnmgrd (pid: 10544, threadinfo=cca0a000 task=cf1ad970)
Stack: 00000001 cf1ad970 ccabdc00 cf1ad970 ccb5bb48 ccabdc00 ccabdc00 
cf1ad970
       d0b26b9f ccabdc00 cdf87000 ccabdd4c d0b27de5 ccabdc00 c0105fda 
cf205260
       d0b27d4c 00000000 cc9d5400 00000000 00000000 00000000 cca0a000 
d0b27d4c
Call Trace:
 [<d0b26b9f>] kcond_broadcast+0x23/0x46 [reiser4] (36)
 [<d0b27de5>] ktxnmgrd+0x99/0x22c [reiser4] (16)
 [<c0105fda>] ret_from_fork+0x6/0x14 (8)
 [<d0b27d4c>] ktxnmgrd+0x0/0x22c [reiser4] (8)
 [<d0b27d4c>] ktxnmgrd+0x0/0x22c [reiser4] (28)
 [<c01042a9>] kernel_thread_helper+0x5/0xb (16)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: die+0x39/0x198 / (0x0)
.. entry 2: print_traces+0x17/0x50 / (0x0)


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 13:27                             ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Ingo Molnar
                                                 ` (3 preceding siblings ...)
  2004-10-21 18:06                               ` Gunther Persoons
@ 2004-10-21 18:07                               ` K.R. Foley
  2004-10-21 18:40                                 ` Thomas Gleixner
  2004-10-22 11:54                                 ` Ingo Molnar
  2004-10-21 18:34                               ` Adam Heath
                                                 ` (2 subsequent siblings)
  7 siblings, 2 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-21 18:07 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

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

Ingo Molnar wrote:
> i have released the -U9 Real-Time Preemption patch, which can be
> downloaded from:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 

Finally a patch that I can get booted on my older SMP system at home 
again. More correctly it is U9.2. I have been having problems with these 
hanging after U5. Haven't had a ton of time to try to track down the 
problems and didn't want to report problems without having done enough 
troubleshooting. Anyway, I got this while booting U9.2.

kr


[-- Attachment #2: tulipbug.txt --]
[-- Type: text/plain, Size: 2124 bytes --]

Oct 21 12:33:22 porky kernel: BUG: atomic counter underflow at:
Oct 21 12:33:22 porky kernel:  [<c0254dd8>] qdisc_destroy+0x98/0xa0 (12)
Oct 21 12:33:22 porky kernel:  [<c0254fed>] dev_shutdown+0x3d/0xa0 (16)
Oct 21 12:33:22 porky kernel:  [<c024773b>] unregister_netdevice+0x13b/0x280 (28)
Oct 21 12:33:22 porky netfs: Mounting other filesystems:  succeeded
Oct 21 12:33:22 porky kernel:  [<c0112fb0>] mcount+0x14/0x18 (12)
Oct 21 12:33:22 porky kernel:  [<e09a6160>] tulip_remove_one+0x0/0xa0 [tulip] (4)
Oct 21 12:33:22 porky kernel:  [<c02058de>] unregister_netdev+0x1e/0x30 (24)
Oct 21 12:33:22 porky kernel:  [<e09a618f>] tulip_remove_one+0x2f/0xa0 [tulip] (16)
Oct 21 12:33:22 porky kernel:  [<c01f2907>] device_release_driver+0x67/0x70 (8)
Oct 21 12:33:22 porky kernel:  [<c0112fb0>] mcount+0x14/0x18 (8)
Oct 21 12:33:22 porky kernel:  [<c01c4e26>] pci_device_remove+0x76/0x80 (20)
Oct 21 12:33:22 porky kernel:  [<c01f573b>] device_detach_shutdown+0xb/0x40 (12)
Oct 21 12:33:22 porky kernel:  [<c01f2907>] device_release_driver+0x67/0x70 (12)
Oct 21 12:33:22 porky kernel:  [<c01f293b>] driver_detach+0x2b/0x40 (24)
Oct 21 12:33:22 porky kernel:  [<c01f2daf>] bus_remove_driver+0x3f/0x70 (20)
Oct 21 12:33:22 porky kernel:  [<c01f32b9>] driver_unregister+0x19/0x30 (20)
Oct 21 12:33:22 porky kernel:  [<c01c50cc>] pci_unregister_driver+0x1c/0x30 (16)
Oct 21 12:33:22 porky kernel:  [<e09a7767>] tulip_cleanup+0x17/0x1b [tulip] (16)
Oct 21 12:33:22 porky kernel:  [<c0139801>] sys_delete_module+0x121/0x150 (12)
Oct 21 12:33:22 porky kernel:  [<c01531a1>] sys_munmap+0x51/0x60 (64)
Oct 21 12:33:22 porky kernel:  [<c0116a20>] do_page_fault+0x0/0x660 (16)
Oct 21 12:33:22 porky kernel:  [<c0106719>] sysenter_past_esp+0x52/0x71 (16)
Oct 21 12:33:22 porky kernel: preempt count: 00000001
Oct 21 12:33:22 porky kernel: . 1-level deep critical section nesting:
Oct 21 12:33:22 porky kernel: .. entry 1: print_traces+0x1d/0x60 / (dump_stack+0x23/0x30)
Oct 21 12:33:22 porky kernel: 
Oct 21 12:33:22 porky kernel: tulip 0000:04:0a.0: Device was removed without properly calling pci_disable_device(). This may need fixing.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 17:33                                                     ` Scott Wood
@ 2004-10-21 18:09                                                       ` john cooper
  2004-10-21 18:47                                                         ` Scott Wood
  2004-10-21 18:10                                                       ` Eugeny S. Mints
  1 sibling, 1 reply; 951+ messages in thread
From: john cooper @ 2004-10-21 18:09 UTC (permalink / raw)
  To: Scott Wood
  Cc: Eugeny S. Mints, Esben Nielsen, Ingo Molnar, Thomas Gleixner,
	Jens Axboe, Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, john cooper

Scott Wood wrote:

>On Thu, Oct 21, 2004 at 12:49:30PM -0400, john cooper wrote:
>
>>It would seem a mutex ownership list still needs to be maintained.
>>Doing so in unordered priority will give a small fixed insertion
>>time, but will require an exhaustive search in order to calculate
>>maximum priority. Doing so in priority order will require an
>>average of #mutex_owned / 2 for the insertion, and gives a fixed
>>time for maximum priority calculation. The latter appears to offer
>>a performance benefit to the degree the incoming priorities are
>>random.
>>
>
>If you keep it in priority order, then you're paying the O(n) cost
>every time you acquire a lock.  If you keep it unordered and only
>search it when you need to recalculate a task's priority after a lock
>has been released (or priorities have been changed), you pay the cost
>much less often.
>
That's true for the case where the current priority is
somewhere else handy (likely) and we don't need to traverse
the list for other reasons such as allowing/disallowing
recursive acquisition of a mutex by a given task.

>Plus, the number of locks held by any given thread
>should generally be very small.
>
I agree, it is likely in the noise. The list length and
manipulation of the mutex waiter list overshadows this.

-john



-- 
john.cooper@timesys.com


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 17:33                                                     ` Scott Wood
  2004-10-21 18:09                                                       ` john cooper
@ 2004-10-21 18:10                                                       ` Eugeny S. Mints
  2004-10-21 18:29                                                         ` Scott Wood
  1 sibling, 1 reply; 951+ messages in thread
From: Eugeny S. Mints @ 2004-10-21 18:10 UTC (permalink / raw)
  To: Scott Wood
  Cc: john cooper, Esben Nielsen, Ingo Molnar, Thomas Gleixner,
	Jens Axboe, Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Ext-Rt-Dev@Mvista. Com

Scott Wood wrote:
> On Thu, Oct 21, 2004 at 12:49:30PM -0400, john cooper wrote:
> 
>>It would seem a mutex ownership list still needs to be maintained.
>>Doing so in unordered priority will give a small fixed insertion
>>time, but will require an exhaustive search in order to calculate
>>maximum priority. Doing so in priority order will require an
>>average of #mutex_owned / 2 for the insertion, and gives a fixed
>>time for maximum priority calculation. The latter appears to offer
>>a performance benefit to the degree the incoming priorities are
>>random.
> 
> 
> If you keep it in priority order, then you're paying the O(n) cost
> every time you acquire a lock.  If you keep it unordered and only
> search it when you need to recalculate a task's priority after a lock
> has been released (or priorities have been changed), you pay the cost
> much less often.  Plus, the number of locks held by any given thread
> should generally be very small.
As to locks held by any given thread - it's not always true - take a 
look at mm/filemap.c locks nesting map in comments.

                        Eugeny




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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 18:10                                                       ` Eugeny S. Mints
@ 2004-10-21 18:29                                                         ` Scott Wood
  0 siblings, 0 replies; 951+ messages in thread
From: Scott Wood @ 2004-10-21 18:29 UTC (permalink / raw)
  To: Eugeny S. Mints
  Cc: Scott Wood, john cooper, Esben Nielsen, Ingo Molnar,
	Thomas Gleixner, Jens Axboe, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Ext-Rt-Dev@Mvista. Com

On Thu, Oct 21, 2004 at 10:10:17PM +0400, Eugeny S. Mints wrote:
> Scott Wood wrote:
> >If you keep it in priority order, then you're paying the O(n) cost
> >every time you acquire a lock.  If you keep it unordered and only
> >search it when you need to recalculate a task's priority after a lock
> >has been released (or priorities have been changed), you pay the cost
> >much less often.  Plus, the number of locks held by any given thread
> >should generally be very small.
> As to locks held by any given thread - it's not always true - take a 
> look at mm/filemap.c locks nesting map in comments.

I guess it depends on the definition of "very small" and "generally".
:-)

A nesting of 5 locks is pushing the limits of "very small", but it's
still no big deal to iterate over once in a while.

-Scott

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 13:27                             ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Ingo Molnar
                                                 ` (4 preceding siblings ...)
  2004-10-21 18:07                               ` K.R. Foley
@ 2004-10-21 18:34                               ` Adam Heath
  2004-10-21 20:06                               ` Michal Schmidt
  2004-10-22 13:35                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3 Ingo Molnar
  7 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-10-21 18:34 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, 21 Oct 2004, Ingo Molnar wrote:

>  + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U9

For those using kernel-package, I just submitted a patch to allow for
uppercase versions.

http://bugs.debian.org/277680

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 18:07                               ` K.R. Foley
@ 2004-10-21 18:40                                 ` Thomas Gleixner
  2004-10-21 18:57                                   ` K.R. Foley
  2004-10-21 19:09                                   ` K.R. Foley
  2004-10-22 11:54                                 ` Ingo Molnar
  1 sibling, 2 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21 18:40 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 20:07, K.R. Foley wrote:
> Ingo Molnar wrote:
> > i have released the -U9 Real-Time Preemption patch, which can be
> > downloaded from:
> > 
> >   http://redhat.com/~mingo/realtime-preempt/
> > 
> 
> Finally a patch that I can get booted on my older SMP system at home 
> again. More correctly it is U9.2. I have been having problems with these 
> hanging after U5. Haven't had a ton of time to try to track down the 
> problems and didn't want to report problems without having done enough 
> troubleshooting. Anyway, I got this while booting U9.2.

I guess, you don't have a tulip network card in your box, as the module
is removed.

The question is, if it got registered correctly before the removal.

tglx

> Oct 21 12:33:22 porky kernel: BUG: atomic counter underflow at:
> Oct 21 12:33:22 porky kernel:  [<c0254dd8>] qdisc_destroy+0x98/0xa0 (12)
> Oct 21 12:33:22 porky kernel:  [<c0254fed>] dev_shutdown+0x3d/0xa0 (16)
> Oct 21 12:33:22 porky kernel:  [<c024773b>] unregister_netdevice+0x13b/0x280 (28)
> Oct 21 12:33:22 porky netfs: Mounting other filesystems:  succeeded
> Oct 21 12:33:22 porky kernel:  [<c0112fb0>] mcount+0x14/0x18 (12)
> Oct 21 12:33:22 porky kernel:  [<e09a6160>] tulip_remove_one+0x0/0xa0 [tulip] (4)
> Oct 21 12:33:22 porky kernel:  [<c02058de>] unregister_netdev+0x1e/0x30 (24)
> Oct 21 12:33:22 porky kernel:  [<e09a618f>] tulip_remove_one+0x2f/0xa0 [tulip] (16)
> Oct 21 12:33:22 porky kernel:  [<c01f2907>] device_release_driver+0x67/0x70 (8)
> Oct 21 12:33:22 porky kernel:  [<c0112fb0>] mcount+0x14/0x18 (8)
> Oct 21 12:33:22 porky kernel:  [<c01c4e26>] pci_device_remove+0x76/0x80 (20)
> Oct 21 12:33:22 porky kernel:  [<c01f573b>] device_detach_shutdown+0xb/0x40 (12)
> Oct 21 12:33:22 porky kernel:  [<c01f2907>] device_release_driver+0x67/0x70 (12)
> Oct 21 12:33:22 porky kernel:  [<c01f293b>] driver_detach+0x2b/0x40 (24)
> Oct 21 12:33:22 porky kernel:  [<c01f2daf>] bus_remove_driver+0x3f/0x70 (20)
> Oct 21 12:33:22 porky kernel:  [<c01f32b9>] driver_unregister+0x19/0x30 (20)
> Oct 21 12:33:22 porky kernel:  [<c01c50cc>] pci_unregister_driver+0x1c/0x30 (16)
> Oct 21 12:33:22 porky kernel:  [<e09a7767>] tulip_cleanup+0x17/0x1b [tulip] (16)
> Oct 21 12:33:22 porky kernel:  [<c0139801>] sys_delete_module+0x121/0x150 (12)
> Oct 21 12:33:22 porky kernel:  [<c01531a1>] sys_munmap+0x51/0x60 (64)
> Oct 21 12:33:22 porky kernel:  [<c0116a20>] do_page_fault+0x0/0x660 (16)
> Oct 21 12:33:22 porky kernel:  [<c0106719>] sysenter_past_esp+0x52/0x71 (16)
> Oct 21 12:33:22 porky kernel: preempt count: 00000001
> Oct 21 12:33:22 porky kernel: . 1-level deep critical section nesting:
> Oct 21 12:33:22 porky kernel: .. entry 1: print_traces+0x1d/0x60 / (dump_stack+0x23/0x30)
> Oct 21 12:33:22 porky kernel: 
> Oct 21 12:33:22 porky kernel: tulip 0000:04:0a.0: Device was removed without properly calling pci_disable_device(). This may need fixing.


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 18:09                                                       ` john cooper
@ 2004-10-21 18:47                                                         ` Scott Wood
  2004-10-21 20:18                                                           ` john cooper
  2004-10-21 21:01                                                           ` Esben Nielsen
  0 siblings, 2 replies; 951+ messages in thread
From: Scott Wood @ 2004-10-21 18:47 UTC (permalink / raw)
  To: john cooper
  Cc: Scott Wood, Eugeny S. Mints, Esben Nielsen, Ingo Molnar,
	Thomas Gleixner, Jens Axboe, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 02:09:19PM -0400, john cooper wrote:
> Scott Wood wrote:
> >If you keep it in priority order, then you're paying the O(n) cost
> >every time you acquire a lock. 

I partially take this back; depending on how it's implemented, you
can get away with only adding it to the list once contention occurs.

> That's true for the case where the current priority is
> somewhere else handy (likely) and we don't need to traverse
> the list for other reasons such as allowing/disallowing
> recursive acquisition of a mutex by a given task.

How would maintaining priority order make it faster to check for
recursive usage?  You'd be looking for a specific mutex rather than
the highest priority blocker.  You could also check the per-mutex
list of owners (which you'll need to implement PI on rwlocks), to
avoid needing to add to the locks-held list in non-contended cases.

On uniprocessor, one may wish to turn rwlocks into recursive non-rw
mutexes, where recursion checking would use a single owner field.

Also, keeping it in priority order would introduce yet another place
that assumes of a linear priority scheme.  At some point, it may be
desireable to implement other schemes, such as maintaining per-CPU
priorities to deal with inheriting from CPU-bound tasks without
introducing said tasks' priorities on other CPUs.

-Scott

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 18:40                                 ` Thomas Gleixner
@ 2004-10-21 18:57                                   ` K.R. Foley
  2004-10-21 18:57                                     ` Thomas Gleixner
  2004-10-21 19:09                                   ` K.R. Foley
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-21 18:57 UTC (permalink / raw)
  To: tglx
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Thomas Gleixner wrote:
> On Thu, 2004-10-21 at 20:07, K.R. Foley wrote:
> 
>>Ingo Molnar wrote:
>>
>>>i have released the -U9 Real-Time Preemption patch, which can be
>>>downloaded from:
>>>
>>>  http://redhat.com/~mingo/realtime-preempt/
>>>
>>
>>Finally a patch that I can get booted on my older SMP system at home 
>>again. More correctly it is U9.2. I have been having problems with these 
>>hanging after U5. Haven't had a ton of time to try to track down the 
>>problems and didn't want to report problems without having done enough 
>>troubleshooting. Anyway, I got this while booting U9.2.
> 
> 
> I guess, you don't have a tulip network card in your box, as the module
> is removed.
> 
> The question is, if it got registered correctly before the removal.
> 
> tglx

Actually I do have the tulip card in the box and I am pulling this stuff 
from the logs over that connection now. Here are the next lines from the 
log that might help.

Oct 21 12:33:22 porky kernel: tulip 0000:04:0a.0: Device was removed 
without pro
perly calling pci_disable_device(). This may need fixing.
Oct 21 12:33:22 porky kernel: hda: ATAPI 48X CD-ROM CD-R/RW drive, 
8192kB Cache,
  UDMA(33)
Oct 21 12:33:22 porky kernel: Uniform CD-ROM driver Revision: 3.20
Oct 21 12:33:22 porky kernel: hdc: ATAPI 48X CD-ROM drive, 120kB Cache, 
UDMA(33)
Oct 21 12:33:22 porky kernel: ip_tables: (C) 2000-2002 Netfilter core team
Oct 21 12:33:22 porky kernel: Linux Tulip driver version 1.1.13 (May 11, 
2002)
Oct 21 12:33:22 porky kernel: PCI: Found IRQ 5 for device 0000:04:0a.0
Oct 21 12:33:22 porky kernel: PCI: Sharing IRQ 5 with 0000:04:05.1
Oct 21 12:33:22 porky kernel: tulip0:  EEPROM default media type Autosense.
Oct 21 12:33:22 porky kernel: tulip0:  Index #0 - Media MII (#11) 
described by a
  21140 MII PHY (1) block.
Oct 21 12:33:22 porky kernel: tulip0:  MII transceiver #3 config 3100 
status 780
9 advertising 01e1.
Oct 21 12:33:22 porky kernel: eth0: Digital DS21140 Tulip rev 32 at 
0xe480, 00:0
0:C0:7F:A0:E9, IRQ 5.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 18:57                                   ` K.R. Foley
@ 2004-10-21 18:57                                     ` Thomas Gleixner
  2004-10-21 19:25                                       ` K.R. Foley
  2004-10-22 14:12                                       ` K.R. Foley
  0 siblings, 2 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21 18:57 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 20:57, K.R. Foley wrote:
> > I guess, you don't have a tulip network card in your box, as the module
> > is removed.
> > 
> > The question is, if it got registered correctly before the removal.
>
> Actually I do have the tulip card in the box and I am pulling this stuff 
> from the logs over that connection now. Here are the next lines from the 
> log that might help.

Not really. We must figure out, why sys_delete_module is called. 

[<e09a7767>] tulip_cleanup+0x17/0x1b [tulip] (16)
[<c0139801>] sys_delete_module+0x121/0x150 (12)   <<--------
[<c01531a1>] sys_munmap+0x51/0x60 (64)
[<c0116a20>] do_page_fault+0x0/0x660 (16)
[<c0106719>] sysenter_past_esp+0x52/0x71 (16)

> Oct 21 12:33:22 porky kernel: tulip 0000:04:0a.0: Device was removed 
> without pro
> perly calling pci_disable_device(). This may need fixing.

This one is a result of the BUG()

tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 18:40                                 ` Thomas Gleixner
  2004-10-21 18:57                                   ` K.R. Foley
@ 2004-10-21 19:09                                   ` K.R. Foley
  1 sibling, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-21 19:09 UTC (permalink / raw)
  To: tglx
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Thomas Gleixner wrote:
> On Thu, 2004-10-21 at 20:07, K.R. Foley wrote:
> 
>>Ingo Molnar wrote:
>>
>>>i have released the -U9 Real-Time Preemption patch, which can be
>>>downloaded from:
>>>
>>>  http://redhat.com/~mingo/realtime-preempt/
>>>
>>
>>Finally a patch that I can get booted on my older SMP system at home 
>>again. More correctly it is U9.2. I have been having problems with these 
>>hanging after U5. Haven't had a ton of time to try to track down the 
>>problems and didn't want to report problems without having done enough 
>>troubleshooting. Anyway, I got this while booting U9.2.
> 
> 
> I guess, you don't have a tulip network card in your box, as the module
> is removed.
> 
> The question is, if it got registered correctly before the removal.
> 
> tglx

Actually I do have the tulip card in the box and I am pulling this stuff
from the logs over that connection now. Here are the next lines from the
log that might help.


Sorry brainfart before completing that thought. It is not unusual for 
the tulip to get loaded, unloaded,loaded again when this system starts 
up. Not sure why. It has never really caused me any problems so I 
haven't bothered figuring it out.

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 18:57                                     ` Thomas Gleixner
@ 2004-10-21 19:25                                       ` K.R. Foley
  2004-10-22 14:12                                       ` K.R. Foley
  1 sibling, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-21 19:25 UTC (permalink / raw)
  To: tglx
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Thomas Gleixner wrote:
> On Thu, 2004-10-21 at 20:57, K.R. Foley wrote:
> 
>>>I guess, you don't have a tulip network card in your box, as the module
>>>is removed.
>>>
>>>The question is, if it got registered correctly before the removal.
>>
>>Actually I do have the tulip card in the box and I am pulling this stuff 
>>from the logs over that connection now. Here are the next lines from the 
>>log that might help.
> 
> 
> Not really. We must figure out, why sys_delete_module is called. 

Understand. I did not mean the log would help figure it out, but that it 
would explain that the card really is present. :)

My guess is that it is prematurely unloading the driver before it's 
fully registered, like you said. The question is why? Also I am not in 
front of the system right now so I can't unload the module to see if it 
generates the error again, but I will try it when I get home.


> 
> [<e09a7767>] tulip_cleanup+0x17/0x1b [tulip] (16)
> [<c0139801>] sys_delete_module+0x121/0x150 (12)   <<--------
> [<c01531a1>] sys_munmap+0x51/0x60 (64)
> [<c0116a20>] do_page_fault+0x0/0x660 (16)
> [<c0106719>] sysenter_past_esp+0x52/0x71 (16)
> 
> 
>>Oct 21 12:33:22 porky kernel: tulip 0000:04:0a.0: Device was removed 
>>without pro
>>perly calling pci_disable_device(). This may need fixing.
> 
> 
> This one is a result of the BUG()
> 
> tglx
> 
> 
> 


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 10:11                                     ` Jens Axboe
  2004-10-21 10:11                                       ` Thomas Gleixner
  2004-10-21 10:18                                       ` Ingo Molnar
@ 2004-10-21 19:58                                       ` Bill Huey
  2004-10-21 20:14                                         ` Jens Axboe
  2 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-21 19:58 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 12:11:03PM +0200, Jens Axboe wrote:
> I didn't look at the USB code, I'm just saying that it's perfectly valid
> use of a semaphore the pattern you describe (process A holding it,
> process B releasing it).

A lot of things are perfectly "valid" in the Linux kernel regarding
stuff like that are a bit irregular. But the preemption work about
to stress these things in ways that was never designed to which is
why these patches are needed. Having a clear use of various locking
conventions is key to getting this system to behave in a predictable
manner. Quite simply, Linux was never targetted to do this and the
sloppiness is showing so it's got to be removed.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 13:27                             ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Ingo Molnar
                                                 ` (5 preceding siblings ...)
  2004-10-21 18:34                               ` Adam Heath
@ 2004-10-21 20:06                               ` Michal Schmidt
  2004-10-22 13:35                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3 Ingo Molnar
  7 siblings, 0 replies; 951+ messages in thread
From: Michal Schmidt @ 2004-10-21 20:06 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano

Ingo Molnar wrote:
> i have released the -U9 Real-Time Preemption patch, which can be
> downloaded from:
> 
>   http://redhat.com/~mingo/realtime-preempt/

I have a reproducible BUG which I first hit in -U9 and it's in -U9.2 
too. It occurs always when a packet hits a REJECT rule in the INPUT 
chain of iptables.
To reproduce: iptables -I INPUT 1 -p tcp --dport 666 -j REJECT
...and telnet your TCP port 666 from the network.


BUG: semaphore recursion deadlock detected!
.. current task ksoftirqd/0/2 is already holding f890a6d4.
c0414ec4 f7c27f64 0000012c 00000001 f7c26000 00000000 f7c27f9c c0121687
        c03c8118 c0121758 c0121ae4 0000000a c03c8118 f7c26000 f7c26000 
00000000
        f7c27fa4 c0121770 f7c27fbc c0121ae4 00000001 fffffff6 f7c26000 
f7c25f70
Call Trace:
  [<c0121687>] ___do_softirq+0x87/0xd0 (32)
  [<c0121758>] _do_softirq+0x8/0x30 (8)
  [<c0121ae4>] ksoftirqd+0x94/0xe0 (4)
  [<c0121770>] _do_softirq+0x20/0x30 (28)
  [<c0121ae4>] ksoftirqd+0x94/0xe0 (8)
  [<c013116a>] kthread+0xaa/0xb0 (24)
  [<c0121a50>] ksoftirqd+0x0/0xe0 (20)
  [<c01310c0>] kthread+0x0/0xb0 (12)
  [<c0103319>] kernel_thread_helper+0x5/0xc (16)
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: down_write+0x1a4/0x1b0 / (ipt_do_table+0x6a/0x330 [ip_tables])
.. entry 2: down_write+0x72/0x1b0 / (ipt_do_table+0x6a/0x330 [ip_tables])
.. entry 3: print_traces+0x1d/0x90 / (show_stack+0x83/0xa0)


Michal

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 19:58                                       ` Bill Huey
@ 2004-10-21 20:14                                         ` Jens Axboe
  2004-10-21 20:24                                           ` Bill Huey
  0 siblings, 1 reply; 951+ messages in thread
From: Jens Axboe @ 2004-10-21 20:14 UTC (permalink / raw)
  To: Bill Huey
  Cc: Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21 2004, Bill Huey wrote:
> On Thu, Oct 21, 2004 at 12:11:03PM +0200, Jens Axboe wrote:
> > I didn't look at the USB code, I'm just saying that it's perfectly valid
> > use of a semaphore the pattern you describe (process A holding it,
> > process B releasing it).
> 
> A lot of things are perfectly "valid" in the Linux kernel regarding
> stuff like that are a bit irregular. But the preemption work about
> to stress these things in ways that was never designed to which is
> why these patches are needed. Having a clear use of various locking
> conventions is key to getting this system to behave in a predictable
> manner. Quite simply, Linux was never targetted to do this and the
> sloppiness is showing so it's got to be removed.

I have to disagree, I don't think the above use is either convoluted or
sloppy in any way. Now that we have the completion structure, certain
things are surely better implemented as such. But the old use is
perfectly valid and logical, imho.

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 18:47                                                         ` Scott Wood
@ 2004-10-21 20:18                                                           ` john cooper
  2004-10-21 21:12                                                             ` Scott Wood
  2004-10-21 21:01                                                           ` Esben Nielsen
  1 sibling, 1 reply; 951+ messages in thread
From: john cooper @ 2004-10-21 20:18 UTC (permalink / raw)
  To: Scott Wood
  Cc: Eugeny S. Mints, Esben Nielsen, Ingo Molnar, Thomas Gleixner,
	Jens Axboe, Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, john cooper

Scott Wood wrote:

>On Thu, Oct 21, 2004 at 02:09:19PM -0400, john cooper wrote:
>
>>That's true for the case where the current priority is
>>somewhere else handy (likely) and we don't need to traverse
>>the list for other reasons such as allowing/disallowing
>>recursive acquisition of a mutex by a given task.
>>
>
>How would maintaining priority order make it faster to check for
>recursive usage?  
>
It wouldn't. My point was an exhaustive traversal may be
needed for other reasons with an insertion sort being
near free.

Yet considering the cost to maintain these lists in priority
order with multiple spinlock acquisition sequences due to how
the aggregate data structure must be traversed/ordered,
I haven't yet convinced myself either way.

>On uniprocessor, one may wish to turn rwlocks into recursive non-rw
>mutexes, where recursion checking would use a single owner field.
>
It isn't obvious to me how this would address the case of a
task holding a reader lock on mx-A then blocking on mx-B.
Another task attempting to acquire a reader lock on mx-A would
block rather than immediately acquiring the lock.

-john


-- 
john.cooper@timesys.com


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 16:40                                 ` Ingo Molnar
  2004-10-21 17:54                                   ` Nikita Danilov
@ 2004-10-21 20:21                                   ` Gunther Persoons
  1 sibling, 0 replies; 951+ messages in thread
From: Gunther Persoons @ 2004-10-21 20:21 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Ingo Molnar wrote:

>* Gunther Persoons <gunther_persoons@spymac.com> wrote:
>
>  
>
>>The kernel booted now with my firewire card plugged in. However when i
>>try to mount my reiser4 partition i get following error
>>
>>BUG: semaphore recursion deadlock detected!
>>.. current task mount/10514 is already holding ccb5bb4c.
>>    
>>
>
>  
>
>>[<c0344760>] down_write+0x103/0x1a6 (48)
>>[<d0b26a08>] kcond_wait+0xaa/0xac [reiser4] (36)
>>[<d0b280b0>] start_ktxnmgrd+0x98/0x9a [reiser4] (36)
>>[<d0b33716>] reiser4_fill_super+0x3b/0x71 [reiser4] (28)
>>[<d0b2d569>] reiser4_get_sb+0x2f/0x33 [reiser4] (68)
>>[<c016061a>] do_kern_mount+0x4f/0xc0 (4)
>>[<c0175945>] do_new_mount+0x9c/0xe1 (36)
>>[<c0175feb>] do_mount+0x145/0x194 (44)
>>[<c0176459>] sys_mount+0x9f/0xe0 (32)
>>[<c01060b1>] sysenter_past_esp+0x52/0x71 (44)
>>    
>>
>
>reiser4 has some pretty ugly locking abstraction called kcond, i took a
>look but it doesnt seem simple to convert it. Reiserfs should really use
>a normal Linux waitqueue and nothing more...
>
>	Ingo
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
Got a second error, while compiling a new kernel my network connection 
got down

BUG: semaphore recursion deadlock detected!
.. current task eth0/10202 is already holding cc9345ac.
cc9345ac c03433b7 cfe51260 ccb5e000 cc9345ac cd11c740 ccb5ff8c ffffe000
       c034490c cc9345ac 000001d9 cc9345b0 cc9345b0 cd11c740 00000002 
cc9343e0
       ccb5e000 cc934644 ffffe000 d0a7a136 c5fcd280 cc934000 ccb5e000 
c0105fda
Call Trace:
 [<c03433b7>] __sched_text_start+0x2e3/0x5e2 (8)
 [<c034490c>] down_write_interruptible+0x109/0x243 (28)
 [<d0a7a136>] airo_thread+0x82/0x2a0 [airo] (44)
 [<c0105fda>] ret_from_fork+0x6/0x14 (16)
 [<c011d046>] default_wake_function+0x0/0x12 (12)
 [<d0a7a0b4>] airo_thread+0x0/0x2a0 [airo] (24)
 [<c01042a9>] kernel_thread_helper+0x5/0xb (16)
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: down_write_interruptible+0x23e/0x243 / (0x0)
.. entry 2: down_write_interruptible+0x6c/0x243 / (0x0)
.. entry 3: print_traces+0x17/0x50 / (0x0)



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 20:14                                         ` Jens Axboe
@ 2004-10-21 20:24                                           ` Bill Huey
  2004-10-21 20:33                                             ` Jens Axboe
  2004-10-21 22:42                                             ` Timothy Miller
  0 siblings, 2 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-21 20:24 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Bill Huey, Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 10:14:43PM +0200, Jens Axboe wrote:
> On Thu, Oct 21 2004, Bill Huey wrote:
> > A lot of things are perfectly "valid" in the Linux kernel regarding
> > stuff like that are a bit irregular. But the preemption work about
> > to stress these things in ways that was never designed to which is
> > why these patches are needed. Having a clear use of various locking
> > conventions is key to getting this system to behave in a predictable
> > manner. Quite simply, Linux was never targetted to do this and the
> > sloppiness is showing so it's got to be removed.
> 
> I have to disagree, I don't think the above use is either convoluted or
> sloppy in any way. Now that we have the completion structure, certain
> things are surely better implemented as such. But the old use is
> perfectly valid and logical, imho.

You use a semaphore to protect data, a completion isn't protecting data
but preserving a certain kind of wait ordering in the code. The
possibility of overloading the current mutex_t for PI makes for a conceptual
mismatch when used in this case since having a kind of priority for
completions is a bit odd. It's better to flat out use a completion
instead, IMO.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 20:24                                           ` Bill Huey
@ 2004-10-21 20:33                                             ` Jens Axboe
  2004-10-21 20:38                                               ` Bill Huey
  2004-10-21 22:42                                             ` Timothy Miller
  1 sibling, 1 reply; 951+ messages in thread
From: Jens Axboe @ 2004-10-21 20:33 UTC (permalink / raw)
  To: Bill Huey
  Cc: Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21 2004, Bill Huey wrote:
> On Thu, Oct 21, 2004 at 10:14:43PM +0200, Jens Axboe wrote:
> > On Thu, Oct 21 2004, Bill Huey wrote:
> > > A lot of things are perfectly "valid" in the Linux kernel regarding
> > > stuff like that are a bit irregular. But the preemption work about
> > > to stress these things in ways that was never designed to which is
> > > why these patches are needed. Having a clear use of various locking
> > > conventions is key to getting this system to behave in a predictable
> > > manner. Quite simply, Linux was never targetted to do this and the
> > > sloppiness is showing so it's got to be removed.
> > 
> > I have to disagree, I don't think the above use is either convoluted or
> > sloppy in any way. Now that we have the completion structure, certain
> > things are surely better implemented as such. But the old use is
> > perfectly valid and logical, imho.
> 
> You use a semaphore to protect data, a completion isn't protecting data
> but preserving a certain kind of wait ordering in the code. The
> possibility of overloading the current mutex_t for PI makes for a conceptual
> mismatch when used in this case since having a kind of priority for
> completions is a bit odd. It's better to flat out use a completion
> instead, IMO.

Linux semaphores (being counted) have always been a fine fit for things
like the loop use, where you get to down it 10 times because you have 10
items pending. I know this isn't the traditional mutex and that it
doesn't protect data as such, but is was never abuse. It isn't overload.
Doing it with a traditional mutex (I'm assuming this is what mutex_t is
in Ingos tree) would be overload and a bad idea, indeed.

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 20:33                                             ` Jens Axboe
@ 2004-10-21 20:38                                               ` Bill Huey
  2004-10-21 20:43                                                 ` Thomas Gleixner
                                                                   ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-21 20:38 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Bill Huey, Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 10:33:50PM +0200, Jens Axboe wrote:
> On Thu, Oct 21 2004, Bill Huey wrote:
> > You use a semaphore to protect data, a completion isn't protecting data
> > but preserving a certain kind of wait ordering in the code. The
> > possibility of overloading the current mutex_t for PI makes for a conceptual
> > mismatch when used in this case since having a kind of priority for
> > completions is a bit odd. It's better to flat out use a completion
> > instead, IMO.
> 
> Linux semaphores (being counted) have always been a fine fit for things
> like the loop use, where you get to down it 10 times because you have 10
> items pending. I know this isn't the traditional mutex and that it
> doesn't protect data as such, but is was never abuse. It isn't overload.
> Doing it with a traditional mutex (I'm assuming this is what mutex_t is
> in Ingos tree) would be overload and a bad idea, indeed.

Well, this is something that's got to be considered by the larger Linux
community and whether these conventions are to be kept or removed. It's
a larger issue than what can be address in Ingo's preemption patch, but
with inevitable need for something like this in the kernel (hard RT)
it's really unavoidable collision. IMO, it's got to go, which is a nasty
change.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 20:38                                               ` Bill Huey
@ 2004-10-21 20:43                                                 ` Thomas Gleixner
  2004-10-21 23:06                                                   ` Bill Huey
  2004-10-22  6:24                                                   ` Jens Axboe
  2004-10-21 20:49                                                 ` Bill Huey
  2004-10-22  6:19                                                 ` Jens Axboe
  2 siblings, 2 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21 20:43 UTC (permalink / raw)
  To: Bill Huey
  Cc: Jens Axboe, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, 2004-10-21 at 22:38, Bill Huey wrote:
> On Thu, Oct 21, 2004 at 10:33:50PM +0200, Jens Axboe wrote:
> > On Thu, Oct 21 2004, Bill Huey wrote:
> > > You use a semaphore to protect data, a completion isn't protecting data
> > > but preserving a certain kind of wait ordering in the code. The
> > > possibility of overloading the current mutex_t for PI makes for a conceptual
> > > mismatch when used in this case since having a kind of priority for
> > > completions is a bit odd. It's better to flat out use a completion
> > > instead, IMO.
> > 
> > Linux semaphores (being counted) have always been a fine fit for things
> > like the loop use, where you get to down it 10 times because you have 10
> > items pending. I know this isn't the traditional mutex and that it
> > doesn't protect data as such, but is was never abuse. It isn't overload.
> > Doing it with a traditional mutex (I'm assuming this is what mutex_t is
> > in Ingos tree) would be overload and a bad idea, indeed.
> 
> Well, this is something that's got to be considered by the larger Linux
> community and whether these conventions are to be kept or removed. It's
> a larger issue than what can be address in Ingo's preemption patch, but
> with inevitable need for something like this in the kernel (hard RT)
> it's really unavoidable collision. IMO, it's got to go, which is a nasty
> change.
> 

Hey, let's stop this here.

You are both (in)correct :)

1. It makes no sense to discuss, why X has been considered correct for
time T.

2. Counted semaphores are a valid use and should be marked explicit as
counted semaphores.

3. Using mutexes and semaphores for event and completion signalling
should be converted to the appropriate interfaces. 

A bunch of work, but not really hard.

tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 20:38                                               ` Bill Huey
  2004-10-21 20:43                                                 ` Thomas Gleixner
@ 2004-10-21 20:49                                                 ` Bill Huey
  2004-10-22  6:19                                                 ` Jens Axboe
  2 siblings, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-21 20:49 UTC (permalink / raw)
  To: Bill Huey
  Cc: Jens Axboe, Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 01:38:21PM -0700, Bill Huey wrote:
> On Thu, Oct 21, 2004 at 10:33:50PM +0200, Jens Axboe wrote:
> > Linux semaphores (being counted) have always been a fine fit for things
> > like the loop use, where you get to down it 10 times because you have 10
> > items pending. I know this isn't the traditional mutex and that it
> > doesn't protect data as such, but is was never abuse. It isn't overload.
> > Doing it with a traditional mutex (I'm assuming this is what mutex_t is
> > in Ingos tree) would be overload and a bad idea, indeed.
> 
> Well, this is something that's got to be considered by the larger Linux
> community and whether these conventions are to be kept or removed. It's
> a larger issue than what can be address in Ingo's preemption patch, but
> with inevitable need for something like this in the kernel (hard RT)
> it's really unavoidable collision. IMO, it's got to go, which is a nasty
> change.

But this is a non-fatal case. I'll see if I can change this logic to not
completely die when this case is detected.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 18:47                                                         ` Scott Wood
  2004-10-21 20:18                                                           ` john cooper
@ 2004-10-21 21:01                                                           ` Esben Nielsen
  2004-10-21 21:52                                                             ` Scott Wood
  2004-10-22  0:46                                                             ` john cooper
  1 sibling, 2 replies; 951+ messages in thread
From: Esben Nielsen @ 2004-10-21 21:01 UTC (permalink / raw)
  To: Scott Wood
  Cc: john cooper, Eugeny S. Mints, Ingo Molnar, Thomas Gleixner,
	Jens Axboe, Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano



Esben Nielsen
Work:
 Cotas Computer Technology A/S
 Paludan Mullersvej 82
 8200 Aarhus N 
Private
 Moellegade 7A, 3., 4
 8000 Aarhus C
Phone: 
 +45 86 12 73 79
Mobile:
 +45 27 13 10 05


On Thu, 21 Oct 2004, Scott Wood wrote:

> On Thu, Oct 21, 2004 at 02:09:19PM -0400, john cooper wrote:
> > Scott Wood wrote:
> > >If you keep it in priority order, then you're paying the O(n) cost
> > >every time you acquire a lock. 
> 
> I partially take this back; depending on how it's implemented, you
> can get away with only adding it to the list once contention occurs.
>

You can implement the full scheduler structure in each mutex. That would
be O(1) but would take take quite a lot of memory.

On the other hand a sorted list will not take more memory than now but
will appear to be O(n) when inserting into the list. However, on a UP
machine no lower priority task will run when higher priority tasks runs.
I.e. you will always add to the beginning of the list. That is assuming
ofcourse that nobody will sleep while holding a mutex - which is a bad
bahaviour. And if you try to take another mutex, while holding one already
and you have to block, the holder of the second mutex will be moved up to
your priority. I.e. it will block the CPU for any lower priority task...

I don't know what it would be on SMP systems though...

 
> > That's true for the case whe~re the current priority is
> > somewhere else handy (likely) and we don't need to traverse
> > the list for other reasons such as allowing/disallowing
> > recursive acquisition of a mutex by a given task.
> 
> How would maintaining priority order make it faster to check for
> recursive usage?  You'd be looking for a specific mutex rather than
> the highest priority blocker.  You could also check the per-mutex
> list of owners (which you'll need to implement PI on rwlocks), to
> avoid needing to add to the locks-held list in non-contended cases.
> 
> On uniprocessor, one may wish to turn rwlocks into recursive non-rw
> mutexes, where recursion checking would use a single owner field.
>


Why not use a simple counter? The mutex protects it's own memory area.
Anyway, I am not sure recursive acquisition is such a good idea: It will
make the mutex more expensive to use and promote sloppy coding where you
don't really know what mutexes are held right now. When you are building a
subsystem you can send around a flag in the argument saying whether you
have taken the lock or not. If you call into other systems, where you
can't add a parameter to each function, you should release your mutex(es)
anyway! I think it is better that the sloppy coder discoveres that he
deadlocks on himself before getting other sub-systems involved :-)

> Also, keeping it in priority order would introduce yet another place
> that assumes of a linear priority scheme.  At some point, it may be
> desireable to implement other schemes, such as maintaining per-CPU
> priorities to deal with inheriting from CPU-bound tasks without
> introducing said tasks' priorities on other CPUs.
>

I am not sure this at all make sense on a SMP system. For performance
reasons I think that one should stick to ordinary semaphores and in a lot
of places spin-locks on such a system. Even with a dedicated RTOS you have
to design your system from the bottum up to get a good real-time
behaviour - and it depends a lot on the application of which you can only
have one! That is very far from the world of SMP servers.

The ones who can use all the fancy mutexes are really embedded developer
(like myself) who need a robust RTOS but also drivers for a lot of
hardware, a good TCP/IP stack, firewall, good filesystems etc. which the
commercial vendors have a hard time delivering all at once. 

On the desktop it can lead to good performance of multimedia but as soon
as you want to use two applications, which considers themselves multimedia
and thus gives themselves high priority, it wont work.

I must also say, that from my perspective low latencies is not the issue.
The issue is predictability: I must be able to create threads and know
they can't all the sudden be preempted by all kinds of things. I.e. if I
give them higher priority than all the "normal" stuff and all shared
resources between my tasks and the "normal" stuff are locked with mutexes
using prirority inheritance and only for fixed amount of time, I am in the
clear. It is also important that all interrupts and spin-locks are only
held for a fixed amount of time - but as long as that time is lower than
the maximum latency and is bounded in occurance I don't really
care. Forinstance a driver servicing a serial channel wont hurt being run
in interrupt context as it is really limited how much CPU it can take
overall.

> -Scott

Esben


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 20:18                                                           ` john cooper
@ 2004-10-21 21:12                                                             ` Scott Wood
  2004-10-21 22:15                                                               ` john cooper
  0 siblings, 1 reply; 951+ messages in thread
From: Scott Wood @ 2004-10-21 21:12 UTC (permalink / raw)
  To: john cooper
  Cc: Scott Wood, Eugeny S. Mints, Esben Nielsen, Ingo Molnar,
	Thomas Gleixner, Jens Axboe, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 04:18:12PM -0400, john cooper wrote:
> Scott Wood wrote:
> >How would maintaining priority order make it faster to check for
> >recursive usage?  
> >
> It wouldn't. My point was an exhaustive traversal may be
> needed for other reasons with an insertion sort being
> near free.
> 
> Yet considering the cost to maintain these lists in priority
> order with multiple spinlock acquisition sequences due to how
> the aggregate data structure must be traversed/ordered,
> I haven't yet convinced myself either way.

Another issue is that if you keep them in order, you have to fix the
list whenever an owner of a listed mutex changes its priority.

> >On uniprocessor, one may wish to turn rwlocks into recursive non-rw
> >mutexes, where recursion checking would use a single owner field.
> >
> It isn't obvious to me how this would address the case of a
> task holding a reader lock on mx-A then blocking on mx-B.
> Another task attempting to acquire a reader lock on mx-A would
> block rather than immediately acquiring the lock.

Yes.  However, the contention case should not be optimized at the
expense of the common case, which can be faster for non-rwlock
implementations when PI is involved.  On SMP, you'd be introducing a
bottleneck by taking away rwlocks, but on UP it's only an issue when
you get preempted or block in a critical section.

There could be problems if some code tries to acquire read locks
out-of-order, believing that it can't deadlock that way (if the
writers don't nest), but that's a problem anyway unless there's a
reasonable way of implementing PI without limiting the number of
concurrent readers (they have to be stored somewhere, and the
alternatives of setting a hard limit on mutexes-per-thread or doing
dynamic allocation inside the lock function are worse).

-Scott

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 21:01                                                           ` Esben Nielsen
@ 2004-10-21 21:52                                                             ` Scott Wood
  2004-10-22  0:46                                                             ` john cooper
  1 sibling, 0 replies; 951+ messages in thread
From: Scott Wood @ 2004-10-21 21:52 UTC (permalink / raw)
  To: Esben Nielsen
  Cc: Scott Wood, john cooper, Eugeny S. Mints, Ingo Molnar,
	Thomas Gleixner, Jens Axboe, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 11:01:21PM +0200, Esben Nielsen wrote:
> You can implement the full scheduler structure in each mutex. That would
> be O(1) but would take take quite a lot of memory.

Are you talking about the thread's locks-held list, or the mutex's
blocked-threads list?  In the latter case, you could cut down on the
memory usage by allocating one such structure for each thread upon
creation, placing it into a pool, and associating them with a mutex
when it's contended (as you can't have more contended mutexes than
you have threads).  It's still a lot heavier than a linked list,
though.

In either case, you'd need to do whatever adjustments to the
scheduler's data structures are necessary whenever a task's priority
changes (including via PI).  It's worth it for at least one of the
lists, as if neither locks-held nor threads-blocked is kept in order,
priority recalculation becomes O(n^2) to find the highest priority
blocker among all held mutexes.  Ordering threads-blocked seems to
make more sense, as you don't have the imbalance between the
frequency adding to the list and searching the list.

> On the other hand a sorted list will not take more memory than now but
> will appear to be O(n) when inserting into the list. However, on a UP
> machine no lower priority task will run when higher priority tasks runs.
> I.e. you will always add to the beginning of the list. That is assuming
> ofcourse that nobody will sleep while holding a mutex - which is a bad
> bahaviour.

It's bad, but inevitable if this is also used to provide PI mutexes
to userspace.

> > On uniprocessor, one may wish to turn rwlocks into recursive non-rw
> > mutexes, where recursion checking would use a single owner field.
> >
> 
> 
> Why not use a simple counter? 

You'd need a counter as well, but you first have to check the owner
to make sure that the count reflects the calling thread's activity
rather than some other thread.

> The mutex protects it's own memory area.
> Anyway, I am not sure recursive acquisition is such a good idea: It will
> make the mutex more expensive to use and promote sloppy coding where you
> don't really know what mutexes are held right now.

I agree, but current code assumes rwlocks can be recursively obtained
for reading (unless that's changed recently).

> I am not sure this at all make sense on a SMP system. For performance
> reasons I think that one should stick to ordinary semaphores and in a lot
> of places spin-locks on such a system. Even with a dedicated RTOS you have
> to design your system from the bottum up to get a good real-time
> behaviour - and it depends a lot on the application of which you can only
> have one! That is very far from the world of SMP servers.

Things get weird on SMP, but it's possible to produce reasonable
real-time behavior, and there are people out there who are interested
in it.

> The ones who can use all the fancy mutexes are really embedded developer
> (like myself) who need a robust RTOS but also drivers for a lot of
> hardware, a good TCP/IP stack, firewall, good filesystems etc. which the
> commercial vendors have a hard time delivering all at once. 

And some embedded devices also need a lot of CPU power, and some of
those use SMP.

> On the desktop it can lead to good performance of multimedia but as soon
> as you want to use two applications, which considers themselves multimedia
> and thus gives themselves high priority, it wont work.

It can be made to work if you have CPU reservations, or some other
way of ensuring that the applications take their CPU in
appropriately sized chunks.

-Scott

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 21:12                                                             ` Scott Wood
@ 2004-10-21 22:15                                                               ` john cooper
  2004-10-21 22:30                                                                 ` Scott Wood
  0 siblings, 1 reply; 951+ messages in thread
From: john cooper @ 2004-10-21 22:15 UTC (permalink / raw)
  To: Scott Wood
  Cc: Eugeny S. Mints, Esben Nielsen, Ingo Molnar, Thomas Gleixner,
	Jens Axboe, Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, john cooper

Scott Wood wrote:

>On Thu, Oct 21, 2004 at 04:18:12PM -0400, john cooper wrote:
>
>>Yet considering the cost to maintain these lists in priority
>>order with multiple spinlock acquisition sequences due to how
>>the aggregate data structure must be traversed/ordered,
>>I haven't yet convinced myself either way.
>>
>
>Another issue is that if you keep them in order, you have to fix the
>list whenever an owner of a listed mutex changes its priority.
>
Yes, but my concern was having to backoff in out-of-sequence
spinlock acquisition paths. Looking at it again if the canonical
lock acquisition sequence is a task's mutex-owned list then a
mutex's task-owned list, the nondeterministic backoff (if any)
gets pushed to the case of a waiter blocking on the lock.

>>It isn't obvious to me how this would address the case of a
>>task holding a reader lock on mx-A then blocking on mx-B.
>>Another task attempting to acquire a reader lock on mx-A would
>>block rather than immediately acquiring the lock.
>>
>
>Yes.  However, the contention case should not be optimized at the
>expense of the common case, which can be faster for non-rwlock
>implementations when PI is involved.  On SMP, you'd be introducing a
>bottleneck by taking away rwlocks, but on UP it's only an issue when
>you get preempted or block in a critical section.
>
My concern is removing what should be available reader
concurrency for the mutex in question. I can't assess
how un/common that may be over all application scenarios.

-john


-- 
john.cooper@timesys.com


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 22:15                                                               ` john cooper
@ 2004-10-21 22:30                                                                 ` Scott Wood
  2004-10-21 22:55                                                                   ` john cooper
  0 siblings, 1 reply; 951+ messages in thread
From: Scott Wood @ 2004-10-21 22:30 UTC (permalink / raw)
  To: john cooper
  Cc: Scott Wood, Eugeny S. Mints, Esben Nielsen, Ingo Molnar,
	Thomas Gleixner, Jens Axboe, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 06:15:00PM -0400, john cooper wrote:
> Yes, but my concern was having to backoff in out-of-sequence
> spinlock acquisition paths. 

Out-of-sequence acquisition is a bug, unless the caller uses trylocks
and handles backoff itself.

-Scott

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 20:24                                           ` Bill Huey
  2004-10-21 20:33                                             ` Jens Axboe
@ 2004-10-21 22:42                                             ` Timothy Miller
  2004-10-21 23:01                                               ` Thomas Gleixner
  1 sibling, 1 reply; 951+ messages in thread
From: Timothy Miller @ 2004-10-21 22:42 UTC (permalink / raw)
  To: Bill Huey (hui)
  Cc: Jens Axboe, Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano



Bill Huey (hui) wrote:

> 
> 
> You use a semaphore to protect data, a completion isn't protecting data
> but preserving a certain kind of wait ordering in the code. The
> possibility of overloading the current mutex_t for PI makes for a conceptual
> mismatch when used in this case since having a kind of priority for
> completions is a bit odd. It's better to flat out use a completion
> instead, IMO.
> 


Could you please define "completion" for me in this context?

Thanks.


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 22:30                                                                 ` Scott Wood
@ 2004-10-21 22:55                                                                   ` john cooper
  0 siblings, 0 replies; 951+ messages in thread
From: john cooper @ 2004-10-21 22:55 UTC (permalink / raw)
  To: Scott Wood
  Cc: Eugeny S. Mints, Esben Nielsen, Ingo Molnar, Thomas Gleixner,
	Jens Axboe, Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, john cooper

Scott Wood wrote:

>On Thu, Oct 21, 2004 at 06:15:00PM -0400, john cooper wrote:
>
>>Yes, but my concern was having to backoff in out-of-sequence
>>spinlock acquisition paths. 
>>
>
>Out-of-sequence acquisition is a bug, unless the caller uses trylocks
>and handles backoff itself.
>
Understood -- we may be getting hung up on terminology here.

Rather the issue was whether the nondeterministic out-of-sequence
backoff could be pushed to a noncritical path. I believe so.
It is further likely a backoff would not be needed as the
a path acquiring a mutex's task-owned list lock during a
priority promotion scan shouldn't have reason to acquire any
task's mutex-owned list lock. The latter list would only need
to be locked at time of successful mutex acquisition/free.

-john

-- 
john.cooper@timesys.com


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 22:42                                             ` Timothy Miller
@ 2004-10-21 23:01                                               ` Thomas Gleixner
  0 siblings, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-21 23:01 UTC (permalink / raw)
  To: Timothy Miller
  Cc: Bill Huey (hui),
	Jens Axboe, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Fri, 2004-10-22 at 00:42, Timothy Miller wrote:
> Bill Huey (hui) wrote:
> > You use a semaphore to protect data, a completion isn't protecting data
> > but preserving a certain kind of wait ordering in the code. The
> > possibility of overloading the current mutex_t for PI makes for a conceptual
> > mismatch when used in this case since having a kind of priority for
> > completions is a bit odd. It's better to flat out use a completion
> > instead, IMO.
> > 
> 
> 
> Could you please define "completion" for me in this context?

A triggers B to exit and must wait until B has exited. It waits for
completion of exit.

A triggers B to execute a command and must wait until B has done so.  It
waits for completion of the command.

Mutexes are used for that, but that's not the intended functionality of
a mutex. Of course it works as long as you do no owner checks on the
mutexes.

A {
	init_MUTEX_LOCKED(m)
	trigger B
	down(m)	<----- recursion, because A owns it already
}

The completion is designed for that and should be used IMHO. Mutexe were
used for that, because the ancestors of completion, sleep_on...(), are
racy.

tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 20:43                                                 ` Thomas Gleixner
@ 2004-10-21 23:06                                                   ` Bill Huey
  2004-10-22  6:24                                                   ` Jens Axboe
  1 sibling, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-21 23:06 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Bill Huey, Jens Axboe, Rui Nuno Capela, Ingo Molnar, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21, 2004 at 10:43:41PM +0200, Thomas Gleixner wrote:
> Hey, let's stop this here.
> 
> You are both (in)correct :)
> 
> 1. It makes no sense to discuss, why X has been considered correct for
> time T.
> 
> 2. Counted semaphores are a valid use and should be marked explicit as
> counted semaphores.
> 
> 3. Using mutexes and semaphores for event and completion signalling
> should be converted to the appropriate interfaces. 
> 
> A bunch of work, but not really hard.

What's the verdict ? leave the lock detector alone or change it ?

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 21:01                                                           ` Esben Nielsen
  2004-10-21 21:52                                                             ` Scott Wood
@ 2004-10-22  0:46                                                             ` john cooper
  1 sibling, 0 replies; 951+ messages in thread
From: john cooper @ 2004-10-22  0:46 UTC (permalink / raw)
  To: Esben Nielsen
  Cc: Scott Wood, Eugeny S. Mints, Ingo Molnar, Thomas Gleixner,
	Jens Axboe, Rui Nuno Capela, LKML, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, john cooper

Esben Nielsen wrote:

>Anyway, I am not sure recursive acquisition is such a good idea: It will
>make the mutex more expensive to use and promote sloppy coding where you
>don't really know what mutexes are held right now.
>
In my experience I haven't quite found this to be the case.
Rather allowing a lock/mutex/etc.. to be recursively acquired
within a given path can greatly simplify APIs. Such as
cases where a primitive acquires a lock internally which is
also know by and suited to protect data in the caller's context.
This avoids the "who has the lock?" information which must
otherwise get stuffed into the API. Nested function calls
simply observe correct lock usage at their respective levels
and all unwinds correctly.

The one notable place where this doesn't work is where
locks must be conditionally acquired in an out-of-order sequence.
However often these cases can be pushed out of the externally
visible API. Another operational consideration is maintaining
debug information in the lock. Keeping track of where each
lock acquisition was made is at odds with a fixed sized lock
data footprint. Still recursive acquisitions scale only
with available stack space so a fair upper limit approximation
is possible when running on fixed size stacks. Note I'm
refering to single-owner spinlocks/mutexes here rather than
reader/write locks.

>I think it is better that the sloppy coder discoveres that he
>deadlocks on himself before getting other sub-systems involved :-)
>
I agree. But I don't think the above precludes doing so.
Detecting violations of unbalanced lock/unlock calls isn't
really different than for non-recursive primitives.

-john

-- 
john.cooper@timesys.com


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 20:38                                               ` Bill Huey
  2004-10-21 20:43                                                 ` Thomas Gleixner
  2004-10-21 20:49                                                 ` Bill Huey
@ 2004-10-22  6:19                                                 ` Jens Axboe
  2004-10-22  7:29                                                   ` Ingo Molnar
  2004-10-22  8:50                                                   ` Bill Huey
  2 siblings, 2 replies; 951+ messages in thread
From: Jens Axboe @ 2004-10-22  6:19 UTC (permalink / raw)
  To: Bill Huey
  Cc: Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21 2004, Bill Huey wrote:
> On Thu, Oct 21, 2004 at 10:33:50PM +0200, Jens Axboe wrote:
> > On Thu, Oct 21 2004, Bill Huey wrote:
> > > You use a semaphore to protect data, a completion isn't protecting data
> > > but preserving a certain kind of wait ordering in the code. The
> > > possibility of overloading the current mutex_t for PI makes for a conceptual
> > > mismatch when used in this case since having a kind of priority for
> > > completions is a bit odd. It's better to flat out use a completion
> > > instead, IMO.
> > 
> > Linux semaphores (being counted) have always been a fine fit for things
> > like the loop use, where you get to down it 10 times because you have 10
> > items pending. I know this isn't the traditional mutex and that it
> > doesn't protect data as such, but is was never abuse. It isn't overload.
> > Doing it with a traditional mutex (I'm assuming this is what mutex_t is
> > in Ingos tree) would be overload and a bad idea, indeed.
> 
> Well, this is something that's got to be considered by the larger Linux
> community and whether these conventions are to be kept or removed. It's
> a larger issue than what can be address in Ingo's preemption patch, but
> with inevitable need for something like this in the kernel (hard RT)
> it's really unavoidable collision. IMO, it's got to go, which is a nasty
> change.

It has to go, why? Because your deadlock detection breaks? Doesn't seem
a very strong reason to me at all, sorry.

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 20:43                                                 ` Thomas Gleixner
  2004-10-21 23:06                                                   ` Bill Huey
@ 2004-10-22  6:24                                                   ` Jens Axboe
  1 sibling, 0 replies; 951+ messages in thread
From: Jens Axboe @ 2004-10-22  6:24 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Bill Huey, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Thu, Oct 21 2004, Thomas Gleixner wrote:
> On Thu, 2004-10-21 at 22:38, Bill Huey wrote:
> > On Thu, Oct 21, 2004 at 10:33:50PM +0200, Jens Axboe wrote:
> > > On Thu, Oct 21 2004, Bill Huey wrote:
> > > > You use a semaphore to protect data, a completion isn't protecting data
> > > > but preserving a certain kind of wait ordering in the code. The
> > > > possibility of overloading the current mutex_t for PI makes for a conceptual
> > > > mismatch when used in this case since having a kind of priority for
> > > > completions is a bit odd. It's better to flat out use a completion
> > > > instead, IMO.
> > > 
> > > Linux semaphores (being counted) have always been a fine fit for things
> > > like the loop use, where you get to down it 10 times because you have 10
> > > items pending. I know this isn't the traditional mutex and that it
> > > doesn't protect data as such, but is was never abuse. It isn't overload.
> > > Doing it with a traditional mutex (I'm assuming this is what mutex_t is
> > > in Ingos tree) would be overload and a bad idea, indeed.
> > 
> > Well, this is something that's got to be considered by the larger Linux
> > community and whether these conventions are to be kept or removed. It's
> > a larger issue than what can be address in Ingo's preemption patch, but
> > with inevitable need for something like this in the kernel (hard RT)
> > it's really unavoidable collision. IMO, it's got to go, which is a nasty
> > change.
> > 
> 
> Hey, let's stop this here.
> 
> You are both (in)correct :)
> 
> 1. It makes no sense to discuss, why X has been considered correct for
> time T.

Because it is correct. Debating that it's now incorrect because it
inconveniently happens to make some detection scheme harder is silly.

> 2. Counted semaphores are a valid use and should be marked explicit as
> counted semaphores.

Indeed

> 3. Using mutexes and semaphores for event and completion signalling
> should be converted to the appropriate interfaces. 

Agree. Do you test all your conversions? Whole-sale conversions like
this tend to break at least some of the drivers. And that's totally
unacceptable, breaking a working solution because of something that's
not really a bug.

> A bunch of work, but not really hard.

Not if you don't test it.

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  6:19                                                 ` Jens Axboe
@ 2004-10-22  7:29                                                   ` Ingo Molnar
  2004-10-22  8:01                                                     ` Jens Axboe
  2004-10-22  8:50                                                   ` Bill Huey
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22  7:29 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Bill Huey, Thomas Gleixner, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Jens Axboe <axboe@suse.de> wrote:

> It has to go, why? Because your deadlock detection breaks? Doesn't
> seem a very strong reason to me at all, sorry.

no, this is no reason at all. I'm really sorry this issue came up in
this context because now people appear to be arguing this as some sort
of policy issue, implying that is somehow improper to use mutexes
instead of completions, which it clearly is _not_. I very much wanted to
avoid this particular type of flamewar :-)

Using mutexes for completion purposes is perfectly fine kernel code. 
Full stop.

Using completions instead of mutexes in certain cases has some minor
advantages for two simple reasons: it's slighly faster and it's also
more readable.

here's an example: initially i made the scheduler's migration logic use
semaphores in that fashion and Linus made me change it to completions,
because, and i quote Linus here:

 [...]
 Btw, should you not use completions here?

 Completions are optimized for the sleep (ie contention) case, while
 semaphores are optimized for the non-contention case. It also makes 
 more "sense" from a conceptual angle (you're waiting for something to
 complete, not asking for an exclusive thing).
 [...]

and i have to say the migration code did become cleaner. To signal some
sort of event it's a more intuitive _symbol_ _name_ to use 'complete()'
and 'wait_for_completion()' than to use 'up()' and 'down()'.

[ If you truly do not agree with this contention then please just look
at one simple conversion we did and check out the previous and the new
logic, by reading the full previous code and the full resulting code. I
do believe that if anyone at that point still thinks that the
semaphore-based code is just as readable (in that context!) as the
completion-based code that then his brains are not made of neurons but
silicon :) ]

but it has never been kernel policy to not allow the use of mutexes that
way! In some cases it's somewhat cleaner to use completions (and if
something is cleaner in Linux then in most cases it's faster as well),
but it's a judgement thing just like it's judgement thing whether to use
kmalloc() or get_free_pages(). Both are correct for the generic problem
of 'allocate some kernel RAM', but optimized for two different types of
uses.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  7:29                                                   ` Ingo Molnar
@ 2004-10-22  8:01                                                     ` Jens Axboe
  2004-10-22  8:13                                                       ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Jens Axboe @ 2004-10-22  8:01 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, Thomas Gleixner, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Fri, Oct 22 2004, Ingo Molnar wrote:
> 
> * Jens Axboe <axboe@suse.de> wrote:
> 
> > It has to go, why? Because your deadlock detection breaks? Doesn't
> > seem a very strong reason to me at all, sorry.
> 
> no, this is no reason at all. I'm really sorry this issue came up in
> this context because now people appear to be arguing this as some sort
> of policy issue, implying that is somehow improper to use mutexes
> instead of completions, which it clearly is _not_. I very much wanted to
> avoid this particular type of flamewar :-)
> 
> Using mutexes for completion purposes is perfectly fine kernel code. 
> Full stop.
> 
> Using completions instead of mutexes in certain cases has some minor
> advantages for two simple reasons: it's slighly faster and it's also
> more readable.
> 
> here's an example: initially i made the scheduler's migration logic use
> semaphores in that fashion and Linus made me change it to completions,
> because, and i quote Linus here:
> 
>  [...]
>  Btw, should you not use completions here?
> 
>  Completions are optimized for the sleep (ie contention) case, while
>  semaphores are optimized for the non-contention case. It also makes 
>  more "sense" from a conceptual angle (you're waiting for something to
>  complete, not asking for an exclusive thing).
>  [...]
> 
> and i have to say the migration code did become cleaner. To signal some
> sort of event it's a more intuitive _symbol_ _name_ to use 'complete()'
> and 'wait_for_completion()' than to use 'up()' and 'down()'.
> 
> [ If you truly do not agree with this contention then please just look
> at one simple conversion we did and check out the previous and the new
> logic, by reading the full previous code and the full resulting code. I
> do believe that if anyone at that point still thinks that the
> semaphore-based code is just as readable (in that context!) as the
> completion-based code that then his brains are not made of neurons but
> silicon :) ]

I fully agree with everything in your mail so far. What annoyed me is
some people advocating their changes under the false pretense that
existing use was broken, which it isn't.

completions _do_ make cleaner code for the intended case. But your
writing above is very clear and already explains that very well.

Lets put the issue to rest and get back to more productive work!

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  8:01                                                     ` Jens Axboe
@ 2004-10-22  8:13                                                       ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22  8:13 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Bill Huey, Thomas Gleixner, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Jens Axboe <axboe@suse.de> wrote:

> I fully agree with everything in your mail so far. What annoyed me is
> some people advocating their changes under the false pretense that
> existing use was broken, which it isn't.

yeah, and i have to say that such advocacy mostly comes from the natural
desire to solve those _other_ problems that non-standard locking designs
have with Linux mutexes. But those problems are that of the other trees
alone, not upstream's :) Suggesting that those problems are in any way
upstream's problem, even if well-intentioned, can be quite offensive.

> completions _do_ make cleaner code for the intended case. But your
> writing above is very clear and already explains that very well.
> 
> Lets put the issue to rest and get back to more productive work!

/me rejoices :)

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  6:19                                                 ` Jens Axboe
  2004-10-22  7:29                                                   ` Ingo Molnar
@ 2004-10-22  8:50                                                   ` Bill Huey
  2004-10-22  8:59                                                     ` Jens Axboe
                                                                       ` (2 more replies)
  1 sibling, 3 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-22  8:50 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Bill Huey, Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Fri, Oct 22, 2004 at 08:19:01AM +0200, Jens Axboe wrote:
> It has to go, why? Because your deadlock detection breaks? Doesn't seem
> a very strong reason to me at all, sorry.

The deadlock detector is needed. Whether you understand that or not is
irrelevant to the current work that's being done. And your idiot attacks
against it doesn't correct these issues nor does it gain credibility
with the audience that does find it useful.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  8:50                                                   ` Bill Huey
@ 2004-10-22  8:59                                                     ` Jens Axboe
  2004-10-22  9:06                                                       ` Bill Huey
  2004-10-22  9:00                                                     ` Ingo Molnar
  2004-10-22 10:21                                                     ` Christoph Hellwig
  2 siblings, 1 reply; 951+ messages in thread
From: Jens Axboe @ 2004-10-22  8:59 UTC (permalink / raw)
  To: Bill Huey
  Cc: Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Fri, Oct 22 2004, Bill Huey wrote:
> On Fri, Oct 22, 2004 at 08:19:01AM +0200, Jens Axboe wrote:
> > It has to go, why? Because your deadlock detection breaks? Doesn't seem
> > a very strong reason to me at all, sorry.
> 
> The deadlock detector is needed. Whether you understand that or not is
> irrelevant to the current work that's being done. And your idiot attacks
> against it doesn't correct these issues nor does it gain credibility
> with the audience that does find it useful.

*plonk*

If you can't stand criticism without resorting to feeble personal
attacks, I suggest you go elsewhere.

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  8:50                                                   ` Bill Huey
  2004-10-22  8:59                                                     ` Jens Axboe
@ 2004-10-22  9:00                                                     ` Ingo Molnar
  2004-10-22 10:21                                                     ` Christoph Hellwig
  2 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22  9:00 UTC (permalink / raw)
  To: Bill Huey
  Cc: Jens Axboe, Thomas Gleixner, Rui Nuno Capela, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Bill Huey <bhuey@lnxw.com> wrote:

> On Fri, Oct 22, 2004 at 08:19:01AM +0200, Jens Axboe wrote:
> > It has to go, why? Because your deadlock detection breaks? Doesn't seem
> > a very strong reason to me at all, sorry.
> 
> The deadlock detector is needed. Whether you understand that or not is
> irrelevant to the current work that's being done. And your idiot
> attacks against it doesn't correct these issues nor does it gain
> credibility with the audience that does find it useful.

oh no!

/me watches the flames fan out again as a bushfire

do you expect there to be any meaningful technical discussion resulting
out of you calling Jens' (valid) comments 'idiot attacks'? Fact is,
upstream couldnt care less about PREEMPT_REALTIME and/or the deadlock
detector at this point. Upstream _never_ cared about any not yet merged
(and in this case, completely unfinished) feature.

/me apologizes to Jens

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  8:59                                                     ` Jens Axboe
@ 2004-10-22  9:06                                                       ` Bill Huey
  2004-10-22  9:09                                                         ` Bill Huey
                                                                           ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-22  9:06 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Bill Huey, Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Fri, Oct 22, 2004 at 10:59:28AM +0200, Jens Axboe wrote:
> On Fri, Oct 22 2004, Bill Huey wrote:
> > On Fri, Oct 22, 2004 at 08:19:01AM +0200, Jens Axboe wrote:
> > > It has to go, why? Because your deadlock detection breaks? Doesn't seem
> > > a very strong reason to me at all, sorry.
> > 
> > The deadlock detector is needed. Whether you understand that or not is
> > irrelevant to the current work that's being done. And your idiot attacks
> > against it doesn't correct these issues nor does it gain credibility
> > with the audience that does find it useful.
> 
> *plonk*
> 
> If you can't stand criticism without resorting to feeble personal
> attacks, I suggest you go elsewhere.

Then stick to the topic at hand, suggest positive changes, and cut the
crap with implied personal attacks like the above. If you hadn't pull
the discussion to that point, I wouldn't have reacted that way. It's
completely juvenile behavior from you and you can't expect me or
anybody else to take it sitting down.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  9:06                                                       ` Bill Huey
@ 2004-10-22  9:09                                                         ` Bill Huey
  2004-10-22  9:20                                                           ` Jens Axboe
  2004-10-22  9:17                                                         ` Jens Axboe
  2004-10-22  9:23                                                         ` Thomas Gleixner
  2 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-22  9:09 UTC (permalink / raw)
  To: Bill Huey
  Cc: Jens Axboe, Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Fri, Oct 22, 2004 at 02:06:37AM -0700, Bill Huey wrote:
> On Fri, Oct 22, 2004 at 10:59:28AM +0200, Jens Axboe wrote:
> > *plonk*
> > 
> > If you can't stand criticism without resorting to feeble personal
> > attacks, I suggest you go elsewhere.
> 
> Then stick to the topic at hand, suggest positive changes, and cut the
> crap with implied personal attacks like the above. If you hadn't pull
> the discussion to that point, I wouldn't have reacted that way. It's
> completely juvenile behavior from you and you can't expect me or
> anybody else to take it sitting down.

This is also email, so misunderstanding and misinterpretations do
happen. If that's the case, then I'm sorry to misunderstand you and then
get upset, but next time be more specific about improving this code and
other things related to it.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  9:06                                                       ` Bill Huey
  2004-10-22  9:09                                                         ` Bill Huey
@ 2004-10-22  9:17                                                         ` Jens Axboe
  2004-10-22  9:23                                                         ` Thomas Gleixner
  2 siblings, 0 replies; 951+ messages in thread
From: Jens Axboe @ 2004-10-22  9:17 UTC (permalink / raw)
  To: Bill Huey
  Cc: Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Fri, Oct 22 2004, Bill Huey wrote:
> On Fri, Oct 22, 2004 at 10:59:28AM +0200, Jens Axboe wrote:
> > On Fri, Oct 22 2004, Bill Huey wrote:
> > > On Fri, Oct 22, 2004 at 08:19:01AM +0200, Jens Axboe wrote:
> > > > It has to go, why? Because your deadlock detection breaks? Doesn't seem
> > > > a very strong reason to me at all, sorry.
> > > 
> > > The deadlock detector is needed. Whether you understand that or not is
> > > irrelevant to the current work that's being done. And your idiot attacks
> > > against it doesn't correct these issues nor does it gain credibility
> > > with the audience that does find it useful.
> > 
> > *plonk*
> > 
> > If you can't stand criticism without resorting to feeble personal
> > attacks, I suggest you go elsewhere.
> 
> Then stick to the topic at hand, suggest positive changes, and cut the
> crap with implied personal attacks like the above. If you hadn't pull
> the discussion to that point, I wouldn't have reacted that way. It's
> completely juvenile behavior from you and you can't expect me or
> anybody else to take it sitting down.

What mails are you reading?!

Personally, I could not care less about the deadlock detection. If it's
a priority for you personally or due to corporate reasons, fine, but
don't involve me.

I have made no attacks on your deadlock detection other than to state
the obvious - that it has cases where it triggers on perfectly legit
code. If you read that as "implied personal attacks" or "juvenile
behaviour" then you need to grow thicker skin. The only personal attacks
here are the ones coming from you.

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  9:09                                                         ` Bill Huey
@ 2004-10-22  9:20                                                           ` Jens Axboe
  2004-10-22  9:24                                                             ` Bill Huey
  0 siblings, 1 reply; 951+ messages in thread
From: Jens Axboe @ 2004-10-22  9:20 UTC (permalink / raw)
  To: Bill Huey
  Cc: Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Fri, Oct 22 2004, Bill Huey wrote:
> On Fri, Oct 22, 2004 at 02:06:37AM -0700, Bill Huey wrote:
> > On Fri, Oct 22, 2004 at 10:59:28AM +0200, Jens Axboe wrote:
> > > *plonk*
> > > 
> > > If you can't stand criticism without resorting to feeble personal
> > > attacks, I suggest you go elsewhere.
> > 
> > Then stick to the topic at hand, suggest positive changes, and cut the
> > crap with implied personal attacks like the above. If you hadn't pull
> > the discussion to that point, I wouldn't have reacted that way. It's
> > completely juvenile behavior from you and you can't expect me or
> > anybody else to take it sitting down.
> 
> This is also email, so misunderstanding and misinterpretations do
> happen. If that's the case, then I'm sorry to misunderstand you and then
> get upset, but next time be more specific about improving this code and
> other things related to it.

I've been as clear as I know how on the matter of semaphore use in
Linux. I've made no comments at all on improving your deadlock
detection scheme.

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  9:06                                                       ` Bill Huey
  2004-10-22  9:09                                                         ` Bill Huey
  2004-10-22  9:17                                                         ` Jens Axboe
@ 2004-10-22  9:23                                                         ` Thomas Gleixner
  2 siblings, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-22  9:23 UTC (permalink / raw)
  To: Bill Huey
  Cc: Jens Axboe, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Fri, 2004-10-22 at 11:06, Bill Huey wrote:
> On Fri, Oct 22, 2004 at 10:59:28AM +0200, Jens Axboe wrote:
> > On Fri, Oct 22 2004, Bill Huey wrote:
> > > On Fri, Oct 22, 2004 at 08:19:01AM +0200, Jens Axboe wrote:
> > > > It has to go, why? Because your deadlock detection breaks? Doesn't seem
> > > > a very strong reason to me at all, sorry.
> > > 
> > > The deadlock detector is needed. Whether you understand that or not is
> > > irrelevant to the current work that's being done. And your idiot attacks
> > > against it doesn't correct these issues nor does it gain credibility
> > > with the audience that does find it useful.
> > 
> > *plonk*
> > 
> > If you can't stand criticism without resorting to feeble personal
> > attacks, I suggest you go elsewhere.
> 
> Then stick to the topic at hand, suggest positive changes, and cut the
> crap with implied personal attacks like the above. If you hadn't pull
> the discussion to that point, I wouldn't have reacted that way. It's
> completely juvenile behavior from you and you can't expect me or
> anybody else to take it sitting down.

Stop that now !

You have started personal attacks.

This flame was already off. What the heck are you trying to achieve with
this ?

tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  9:20                                                           ` Jens Axboe
@ 2004-10-22  9:24                                                             ` Bill Huey
  2004-10-22  9:31                                                               ` Jens Axboe
  0 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-22  9:24 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Bill Huey, Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML,
	Lee Revell, mark_h_johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Fri, Oct 22, 2004 at 11:20:59AM +0200, Jens Axboe wrote:
> I've been as clear as I know how on the matter of semaphore use in
> Linux. I've made no comments at all on improving your deadlock
> detection scheme.

True, but "...deadlock detection breaks" is a negative comment about
the deadlock detector without a positive suggestion to change it, is
it not ? if so, then suggest a change to be made and it'll get
implementated somehow.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  9:24                                                             ` Bill Huey
@ 2004-10-22  9:31                                                               ` Jens Axboe
  0 siblings, 0 replies; 951+ messages in thread
From: Jens Axboe @ 2004-10-22  9:31 UTC (permalink / raw)
  To: Bill Huey
  Cc: Thomas Gleixner, Rui Nuno Capela, Ingo Molnar, LKML, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Fri, Oct 22 2004, Bill Huey wrote:
> On Fri, Oct 22, 2004 at 11:20:59AM +0200, Jens Axboe wrote:
> > I've been as clear as I know how on the matter of semaphore use in
> > Linux. I've made no comments at all on improving your deadlock
> > detection scheme.
> 
> True, but "...deadlock detection breaks" is a negative comment about
> the deadlock detector without a positive suggestion to change it, is
> it not ? if so, then suggest a change to be made and it'll get
> implementated somehow.

It's a statement about the deadlock detection which is true, it's not a
negative comment. A negative comment would be something ala "the
deadlock detection code is crap". Note, to avoid further confusion in
this thread: I have not read the deadlock detection code, nor do I
intend to. The sentence is only an example of what a negative comment
would look like, in no way does it reflect my view of the deadlock
detection code. End disclaimer.

As I said, I have no personal motivation to work on the deadlock
detection. My interest in the thread pertained only to code in the
kernel and its use of semaphores - something that we already cleared up
many mails ago.

So, please, lets just end it here. This branch of the thread has already
dragged on for way too long.

-- 
Jens Axboe


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-21 13:03                               ` Rui Nuno Capela
  2004-10-21 13:41                                 ` Ingo Molnar
@ 2004-10-22 10:15                                 ` Rui Nuno Capela
  1 sibling, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-22 10:15 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

> Rui Nuno Capela wrote:
>> Ingo Molnar wrote:
>>>
>>> i have released the -U8 Real-Time Preemption patch:
>>>
>>>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U8
>>>
> [...]
>
> The fact is jackd -R (realtime mode; SCHED_FIFO) hosing the system, and
> thats exposed as soon as some jack audio client application enters into
> the chain.
>
> Running jackd non-realtime (SCHED_OTHER) does not expose this problem, so
> I think it's a scheduling related one.
>
> [...]


After some trial-and-error cycle, changing kernel configuration options, I
come to believe the obvious, that this jackd -R nasty behavior seems to be
present (only) if PREEMPT_REALTIME is set (Y).

When PREEMPT_REALTIME is not set (N), it just runs and I can throw any
client at 'jackd -R' without hosing the whole system. However, I'm seeing
plenty of these:

BUG: scheduling while atomic: jackd/0x00000002/3968
caller is schedule_timeout+0x5a/0xa8
 [<c0104ec8>] dump_stack+0x1e/0x20 (20)
 [<c02cd6d2>] __schedule+0x4c4/0x69e (76)
 [<c02ce45f>] schedule_timeout+0x5a/0xa8 (60)
 [<c0169c75>] do_poll+0x9b/0xb9 (48)
 [<c0169e02>] sys_poll+0x16f/0x225 (76)
 [<c010408d>] sysenter_past_esp+0x52/0x71 (-8124)
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: ipc_lock_writer+0x2f/0xae / (sys_shmctl+0x88/0x895)
.. entry 2: ipc_lock_writer+0xa3/0xae / (sys_shmctl+0x88/0x895)
.. entry 3: print_traces+0x16/0x4a / (dump_stack+0x1e/0x20)

BUG: sleeping function called from invalid context jackd(3968) at
mm/slab.c:2055
in_atomic():1 [00000002], irqs_disabled():0
 [<c0104ec8>] dump_stack+0x1e/0x20 (20)
 [<c011505f>] __might_sleep+0xb2/0xc5 (36)
 [<c013e7f8>] __kmalloc+0xa3/0xaa (28)
 [<c0169d60>] sys_poll+0xcd/0x225 (76)
 [<c010408d>] sysenter_past_esp+0x52/0x71 (-8124)
preempt count: 00000003
. 3-level deep critical section nesting:
.. entry 1: ipc_lock_writer+0x2f/0xae / (sys_shmctl+0x88/0x895)
.. entry 2: ipc_lock_writer+0xa3/0xae / (sys_shmctl+0x88/0x895)
.. entry 3: print_traces+0x16/0x4a / (dump_stack+0x1e/0x20)



OTOH, I do get in some trouble elsewhere, but not related to jackd. For
example, the system hangs on udev, never managed to shutdown cleanly, and
some system monitoring applications just keeps failing completely (e.g.
gkrellm).

But I found this on late init:

BUG: Unable to handle kernel NULL pointer dereference at virtual address
00000000
 printing eip:
c01cbb7d
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: realtime commoncap snd_seq_oss snd_seq_midi_event
snd_seq snd_pcm_oss snd_mixer_oss snd_usb_usx2y snd_usb_lib snd_rawmidi
snd_seq_device snd_hwdep snd_ali5451 snd_ac97_codec snd_pcm snd_timer
snd_page_alloc snd soundcore prism2_cs p80211 ds yenta_socket pcmcia_core
natsemi crc32 loop subfs evdev ohci_hcd usbcore thermal processor fan
button battery ac
CPU:    0
EIP:    0060:[<c01cbb7d>]    Not tainted VLI
EFLAGS: 00210246   (2.6.9-rc4-mm1-U9.2)
EIP is at acpi_os_signal_semaphore+0x30/0x4e
eax: df75b700   ebx: 00000001   ecx: 00000000   edx: 00000010
esi: c155c400   edi: 00000000   ebp: de48dd9c   esp: de48dd98
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process kdeinit (pid: 3862, threadinfo=de48c000 task=de5af400)
Stack: df750700 de48ddac c01d4b88 df74b160 00000001 de48ddc4 c01d67a2
df750700
       df750700 c155c400 c155c400 de48ddd8 c01d3abe df750700 c155c400
00000000
       de48ddf8 c01cd2e2 c155c400 00000000 c149c820 c155c400 c155c5ec
00000000
Call Trace:
 [<c0104e94>] show_stack+0x80/0x96 (28)
 [<c010502f>] show_registers+0x165/0x1de (56)
 [<c0105241>] die+0xf6/0x191 (64)
 [<c01123ab>] do_page_fault+0x483/0x6a4 (212)
 [<c0104af1>] error_code+0x2d/0x38 (72)
 [<c01d4b88>] acpi_ex_system_release_mutex+0x28/0x2a (16)
 [<c01d67a2>] acpi_ex_release_mutex+0x135/0x154 (24)
 [<c01d3abe>] acpi_ex_opcode_1A_0T_0R+0x2a/0x92 (20)
 [<c01cd2e2>] acpi_ds_exec_end_op+0xb4/0x28e (32)
 [<c01db23e>] acpi_ps_parse_loop+0x528/0x810 (40)
 [<c01db57d>] acpi_ps_parse_aml+0x57/0x1c2 (32)
 [<c01dbea5>] acpi_psx_execute+0x15d/0x1c4 (28)
 [<c01d914d>] acpi_ns_execute_control_method+0x41/0x51 (20)
 [<c01d90f2>] acpi_ns_evaluate_by_handle+0x74/0x8e (16)
 [<c01d8fed>] acpi_ns_evaluate_relative+0xa9/0xc5 (32)
 [<c01d88a5>] acpi_evaluate_object+0xfd/0x1ae (52)
 [<c01cbedd>] acpi_evaluate_integer+0x32/0x4f (52)
 [<e001a06c>] acpi_button_state_seq_show+0x27/0x64 [button] (32)
 [<c0175562>] seq_read+0xd3/0x2cf (60)
 [<c015461c>] vfs_read+0xc1/0x13a (44)
 [<c015490b>] sys_read+0x4b/0x75 (44)
 [<c010408d>] sysenter_past_esp+0x52/0x71 (-8124)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: die+0x3a/0x191 / (do_page_fault+0x483/0x6a4)
.. entry 2: print_traces+0x16/0x4a / (show_stack+0x80/0x96)

Code: 4d 08 8b 5d 0c 85 c9 0f 94 c2 85 db 0f 94 c0 09 d0 ba 01 10 00 00 a8
01 75 28 83 fb 01 66 ba 10 00 77 1f ff 01 0f 8e d2 00 00 00 <8b> 01 48 7e
10 68 29 7e 2e c0 e8 5a c3 f4 ff 5b e8 18 93 f3 ff


As it seemed an ACPI issue, I turned it off and the troubles went away.
Again, all this is happening with PREEMPT_REALTIME off.

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-22  8:50                                                   ` Bill Huey
  2004-10-22  8:59                                                     ` Jens Axboe
  2004-10-22  9:00                                                     ` Ingo Molnar
@ 2004-10-22 10:21                                                     ` Christoph Hellwig
  2 siblings, 0 replies; 951+ messages in thread
From: Christoph Hellwig @ 2004-10-22 10:21 UTC (permalink / raw)
  To: Bill Huey; +Cc: LKML

On Fri, Oct 22, 2004 at 01:50:07AM -0700, Bill Huey wrote:
> On Fri, Oct 22, 2004 at 08:19:01AM +0200, Jens Axboe wrote:
> > It has to go, why? Because your deadlock detection breaks? Doesn't seem
> > a very strong reason to me at all, sorry.
> 
> The deadlock detector is needed. Whether you understand that or not is
> irrelevant to the current work that's being done. And your idiot attacks
> against it doesn't correct these issues nor does it gain credibility
> with the audience that does find it useful.

*plonk*


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 17:54                                   ` Nikita Danilov
@ 2004-10-22 10:22                                     ` Ingo Molnar
  2004-10-22 11:50                                       ` Nikita Danilov
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 10:22 UTC (permalink / raw)
  To: Nikita Danilov; +Cc: Gunther Persoons, linux-kernel


* Nikita Danilov <nikita@clusterfs.com> wrote:

>  > look but it doesnt seem simple to convert it. Reiserfs should really use
>  > a normal Linux waitqueue and nothing more...
> 
> Why? Condition variable is very well known and widely used concept. In
> the area of their applicability (where predicate whose change is
> waited upon is protected by a single lock) they provide clean and
> easily recognizable synchronization device.

sorry, but just look at the kcond code and compare the 'fastpath' with
say the fastpath of Linux semaphores or waitqueue handling.

condition variables (here i dont mean your code specifically, but the
general pthread concept) are simply trying to achieve too much via a
single object, which increases their complexity quite significantly.

Separating out a few select atomic synchronization primitives that can
be used for each appropriate purpose does the job equally well.

condition variables are fine if you 1) already know them from userspace
and 2) want to use a single locking abstraction for everything. It is
thus also a kitchen-sink primitive that is inevitably slow and complex.
I still have to see a locking problem where condvars are the
cleanest/simplest answer, and i've yet to see a locking problem where
condvars are not the slowest answer ;)

of course this too is valid kernel code so i'm not complaining at all.
It was simply too complex to be converted at first sight to
PREEMPT_REALTIME.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-22 10:22                                     ` Ingo Molnar
@ 2004-10-22 11:50                                       ` Nikita Danilov
  2004-10-22 11:57                                         ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Nikita Danilov @ 2004-10-22 11:50 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Gunther Persoons, linux-kernel

Ingo Molnar writes:
 > 
 > * Nikita Danilov <nikita@clusterfs.com> wrote:
 > 
 > >  > look but it doesnt seem simple to convert it. Reiserfs should really use
 > >  > a normal Linux waitqueue and nothing more...
 > > 
 > > Why? Condition variable is very well known and widely used concept. In
 > > the area of their applicability (where predicate whose change is
 > > waited upon is protected by a single lock) they provide clean and
 > > easily recognizable synchronization device.
 > 
 > sorry, but just look at the kcond code and compare the 'fastpath' with
 > say the fastpath of Linux semaphores or waitqueue handling.

Agree completely. kcond implementation is very inefficient. But it's
"obviously correct" at that. Idea was to optimize it later, when we
would have time for this. Didn't happen so far.
 
 > 
 > condition variables (here i dont mean your code specifically, but the
 > general pthread concept) are simply trying to achieve too much via a
 > single object, which increases their complexity quite significantly.

This is quite questionable. Where is this complexity? Standard condition
variable usage looks like

    spin_lock(&lock);
    while (!predicate)
        kcond_wait(&cond_var, &lock);
    /*
     * at this point predicate is true and @lock is held
     */

This can, of course, be implemented with wait-queues, but:

 - condition variables are used idiomatically, and hence, contain strong
   hint about what code tries to achieve.

 - their API is designed to match their (rather narrow) usage. For
   example, kcond_wait() takes lock as an argument and can (given proper
   debugging support in the spin-lock implementation) check that this lock
   is actually locked by the calling thread.

 > 
 > Separating out a few select atomic synchronization primitives that can
 > be used for each appropriate purpose does the job equally well.

Difference between a condition variable and "atomic synchronization
primitives" is like difference between a spin-lock and open-coded Dekker
algorithm: both provide you with mutual exclusion, but the former gives
one distinct clue about what is going on.

Umm... I have better example: every algorithm can be coded without loop
statements, with goto-s only. And (given proper programmer) goto
produces better assembly than while(). Does this constitutes an argument
in favor of throwing away all these wimpy loops that no Real Programmer
should use?

 > 
 > condition variables are fine if you 1) already know them from userspace
 > and 2) want to use a single locking abstraction for everything. It is
 > thus also a kitchen-sink primitive that is inevitably slow and complex.
 > I still have to see a locking problem where condvars are the
 > cleanest/simplest answer, and i've yet to see a locking problem where
 > condvars are not the slowest answer ;)

A kernel daemon that waits for some work to do is an example.

(And just to fight what seems to be common misconception: condition
variables were not introduced by POSIX committee, they are much older
than that. As all synchronization primitives they originate from the
kernel land.)

 > 
 > of course this too is valid kernel 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 18:07                               ` K.R. Foley
  2004-10-21 18:40                                 ` Thomas Gleixner
@ 2004-10-22 11:54                                 ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 11:54 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, K.R. Foley


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

> Oct 21 12:33:22 porky kernel: BUG: atomic counter underflow at:
> Oct 21 12:33:22 porky kernel:  [<c0254dd8>] qdisc_destroy+0x98/0xa0 (12)
> Oct 21 12:33:22 porky kernel:  [<c0254fed>] dev_shutdown+0x3d/0xa0 (16)
> Oct 21 12:33:22 porky kernel:  [<c024773b>] unregister_netdevice+0x13b/0x280 (28)
> Oct 21 12:33:22 porky netfs: Mounting other filesystems:  succeeded
> Oct 21 12:33:22 porky kernel:  [<c0112fb0>] mcount+0x14/0x18 (12)
> Oct 21 12:33:22 porky kernel:  [<e09a6160>] tulip_remove_one+0x0/0xa0 [tulip] (4)
> Oct 21 12:33:22 porky kernel:  [<c02058de>] unregister_netdev+0x1e/0x30 (24)
> Oct 21 12:33:22 porky kernel:  [<e09a618f>] tulip_remove_one+0x2f/0xa0 [tulip] (16)
> Oct 21 12:33:22 porky kernel:  [<c01f2907>] device_release_driver+0x67/0x70 (8)
> Oct 21 12:33:22 porky kernel:  [<c0112fb0>] mcount+0x14/0x18 (8)
> Oct 21 12:33:22 porky kernel:  [<c01c4e26>] pci_device_remove+0x76/0x80 (20)
> Oct 21 12:33:22 porky kernel:  [<c01f573b>] device_detach_shutdown+0xb/0x40 (12)
> Oct 21 12:33:22 porky kernel:  [<c01f2907>] device_release_driver+0x67/0x70 (12)
> Oct 21 12:33:22 porky kernel:  [<c01f293b>] driver_detach+0x2b/0x40 (24)
> Oct 21 12:33:22 porky kernel:  [<c01f2daf>] bus_remove_driver+0x3f/0x70 (20)
> Oct 21 12:33:22 porky kernel:  [<c01f32b9>] driver_unregister+0x19/0x30 (20)
> Oct 21 12:33:22 porky kernel:  [<c01c50cc>] pci_unregister_driver+0x1c/0x30 (16)
> Oct 21 12:33:22 porky kernel:  [<e09a7767>] tulip_cleanup+0x17/0x1b [tulip] (16)
> Oct 21 12:33:22 porky kernel:  [<c0139801>] sys_delete_module+0x121/0x150 (12)
> Oct 21 12:33:22 porky kernel:  [<c01531a1>] sys_munmap+0x51/0x60 (64)
> Oct 21 12:33:22 porky kernel:  [<c0116a20>] do_page_fault+0x0/0x660 (16)
> Oct 21 12:33:22 porky kernel:  [<c0106719>] sysenter_past_esp+0x52/0x71 (16)

i think this is an upstream bug that the atomic-counter debugging assert
triggers. Jeff, the assert above shows qdisc->refcnt underflowing from 0
to -1. So the qdisc_destroy() [or dev_shutdown()?] use is inbalanced. 
Plus rtl8139 is doing this too, see the log below. The upstream kernel
does not notice this condition. Or is ->refcnt allowed to underflow?

	Ingo

Oct 20 16:47:18 localhost kernel: BUG: atomic counter underflow at:
Oct 20 16:47:18 localhost kernel:  [<c02b8d88>] qdisc_destroy+0x98/0xa0 (12)
Oct 20 16:47:18 localhost kernel:  [<c02b8f9d>] dev_shutdown+0x3d/0xa0 (16)
Oct 20 16:47:18 localhost kernel:  [<c02aa38b>] unregister_netdevice+0x13b/0x280 (28)
Oct 20 16:47:18 localhost kernel:  [<c01148b0>] mcount+0x14/0x18 (8)
Oct 20 16:47:18 localhost kernel:  [<e0836b10>] rtl8139_remove_one+0x0/0xa0 [8139too] (4)
Oct 20 16:47:18 localhost kernel:  [<c0241f8e>] unregister_netdev+0x1e/0x30 (24)
Oct 20 16:47:18 localhost kernel:  [<e0836b3a>] rtl8139_remove_one+0x2a/0xa0 [8139too] (16)
Oct 20 16:47:18 localhost kernel:  [<c01148b0>] mcount+0x14/0x18 (12)
Oct 20 16:47:18 localhost kernel:  [<c01e4016>] pci_device_remove+0x76/0x80 (20)
Oct 20 16:47:18 localhost kernel:  [<c02306cb>] device_detach_shutdown+0xb/0x40 (12)
Oct 20 16:47:18 localhost kernel:  [<c022d817>] device_release_driver+0x67/0x70 (12)
Oct 20 16:47:18 localhost kernel:  [<c022d84b>] driver_detach+0x2b/0x40 (24)
Oct 20 16:47:18 localhost kernel:  [<c022dcbf>] bus_remove_driver+0x3f/0x70 (20)
Oct 20 16:47:18 localhost kernel:  [<c022e1c9>] driver_unregister+0x19/0x30 (20)
Oct 20 16:47:18 localhost kernel:  [<c01e42bc>] pci_unregister_driver+0x1c/0x30 (16)
Oct 20 16:47:18 localhost kernel:  [<e0838b07>] rtl8139_cleanup_module+0x17/0x1b [8139too] (16)
Oct 20 16:47:18 localhost kernel:  [<c013c8d1>] sys_delete_module+0x121/0x150 (12)
Oct 20 16:47:18 localhost kernel:  [<c01596a4>] sys_munmap+0x54/0x70 (64)
Oct 20 16:47:18 localhost kernel:  [<c0118560>] do_page_fault+0x0/0x6d0 (16)
Oct 20 16:47:18 localhost kernel:  [<c0107b49>] sysenter_past_esp+0x52/0x71 (16)

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-22 11:50                                       ` Nikita Danilov
@ 2004-10-22 11:57                                         ` Ingo Molnar
  2004-10-22 12:27                                           ` Nikita Danilov
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 11:57 UTC (permalink / raw)
  To: Nikita Danilov; +Cc: Gunther Persoons, linux-kernel


* Nikita Danilov <nikita@clusterfs.com> wrote:

>  > condition variables are fine if you 1) already know them from userspace
>  > and 2) want to use a single locking abstraction for everything. It is
>  > thus also a kitchen-sink primitive that is inevitably slow and complex.
>  > I still have to see a locking problem where condvars are the
>  > cleanest/simplest answer, and i've yet to see a locking problem where
>  > condvars are not the slowest answer ;)
> 
> A kernel daemon that waits for some work to do is an example.

what type of work - could you be a bit more specific?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-22 11:57                                         ` Ingo Molnar
@ 2004-10-22 12:27                                           ` Nikita Danilov
  2004-10-22 12:42                                             ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Nikita Danilov @ 2004-10-22 12:27 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Gunther Persoons, linux-kernel

Ingo Molnar writes:
 > 
 > * Nikita Danilov <nikita@clusterfs.com> wrote:
 > 
 > >  > condition variables are fine if you 1) already know them from userspace
 > >  > and 2) want to use a single locking abstraction for everything. It is
 > >  > thus also a kitchen-sink primitive that is inevitably slow and complex.
 > >  > I still have to see a locking problem where condvars are the
 > >  > cleanest/simplest answer, and i've yet to see a locking problem where
 > >  > condvars are not the slowest answer ;)
 > > 
 > > A kernel daemon that waits for some work to do is an example.
 > 
 > what type of work - could you be a bit more specific?

Take a loop in fs/cifs/cifsfs.c:cifs_oplock_thread() (I won't copy it
here to avoid you all going blind). It can be recoded as

    while(1) {
        spin_lock(&GlobalMid_Lock);
        while (list_empty(&GlobalOplock_Q)) {
             if (kcond_timedwait(&SomeCIFSCVAR, &GlobalMid_Lock, HZ) == -EINTR) {
                     spin_unlock(&GlobalMid_Lock);
                     complete_and_exit(&cifs_oplock_exited, 0);
             }
        }
        oplock_item = list_entry(GlobalOplock_Q.next, struct oplock_q_entry, qhead);
        /* do stuff with oplock_item ... */
        spin_unlock(&GlobalMid_Lock);
        ....
    }

Point is that this is very stylistic usage---easily recognizable.

 > 
 > 	Ingo

Nikita.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-22 12:27                                           ` Nikita Danilov
@ 2004-10-22 12:42                                             ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 12:42 UTC (permalink / raw)
  To: Nikita Danilov; +Cc: Gunther Persoons, linux-kernel


* Nikita Danilov <nikita@clusterfs.com> wrote:

>  > > A kernel daemon that waits for some work to do is an example.
>  > 
>  > what type of work - could you be a bit more specific?
> 
> Take a loop in fs/cifs/cifsfs.c:cifs_oplock_thread() (I won't copy it
> here to avoid you all going blind). It can be recoded as
> 
>     while(1) {
>         spin_lock(&GlobalMid_Lock);
>         while (list_empty(&GlobalOplock_Q)) {
>              if (kcond_timedwait(&SomeCIFSCVAR, &GlobalMid_Lock, HZ) == -EINTR) {
>                      spin_unlock(&GlobalMid_Lock);
>                      complete_and_exit(&cifs_oplock_exited, 0);
>              }
>         }
>         oplock_item = list_entry(GlobalOplock_Q.next, struct oplock_q_entry, qhead);
>         /* do stuff with oplock_item ... */
>         spin_unlock(&GlobalMid_Lock);
>         ....
>     }

in this particular case i'd use a workqueue, which would simplify this
down to something like:

	workqueue_handler()
	{	
		spin_lock(&GlobalMid_Lock);
		oplock_item = list_entry(GlobalOplock_Q.next, ...);
		/* do stuff with oplock_item */
		spin_unlock(&GlobalMid_Lock);
	}

and instead of playing games with signals to exit the worker thread, i'd
use destroy_workqueue().

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 17:49                             ` Alexander Batyrshin
  2004-10-20 19:02                               ` Adam Heath
  2004-10-20 22:35                               ` Daniel Walker
@ 2004-10-22 13:19                               ` Ingo Molnar
  2004-10-22 13:48                               ` Ingo Molnar
  3 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 13:19 UTC (permalink / raw)
  To: Alexander Batyrshin; +Cc: linux-kernel


* Alexander Batyrshin <abatyrshin@ru.mvista.com> wrote:

> used i386/defconfig

> BUG: semaphore recursion deadlock detected!
> .. current task khpsbpkt/723 is already holding c04610c0.

ok, this should be fixed in -U9.2.

> 2.
> if execute
> ``for i in `seq 1 9999`; do nohup bash >/dev/null 2>&1 & done'',
> then you'll get something like:
> [...skip...]
> Warning: dev (pts0) tty->count(16) != #fd's(8) in tty_open
> Warning: dev (pts0) tty->count(16) != #fd's(11) in tty_open

> I'v tested it against linux-2.6.9-rc4-mm1 => all was ok

i have trouble reproducing this myself. Can you still trigger it under
-U9.2? If yes then could you check whether this still happens with a the
same .config but with CONFIG_SMP turned off? This smells like a locking
bug/breakage in the tty layer that we dont detect. You have all the
relevant debug options turned on, correct? (DEBUG_PREEMPT and
RWSEM_DEADLOCK_DETECT)

	Ingo

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

* [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3
  2004-10-21 13:27                             ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Ingo Molnar
                                                 ` (6 preceding siblings ...)
  2004-10-21 20:06                               ` Michal Schmidt
@ 2004-10-22 13:35                               ` Ingo Molnar
  2004-10-22 15:50                                 ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10 Ingo Molnar
  2004-10-22 18:41                                 ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3 Alexander Batyrshin
  7 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 13:35 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


i have released the -U9.3 Real-Time Preemption patch, which can be
downloaded from:

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

this too is a fixes-only release.

Changes since -U9.2:

 - tons more driver/mutex/completion conversion done by Thomas Gleixner 
   for: ppp, ipmi, parport/ieeee1284, scsi, hotplug, and more.

 - iptables/netfilter deadlock fix, this should fix the bug reported by 
   Michal Schmidt.

 - .config housekeeping: disallow the turning off of PREEMPT_BKL when 
   PREEMPT_REALTIME is on. This solves the build error reported by 
   Matthew L Foster.

 - print the full stacktrace of the current task in the deadlock 
   detector and dont use show_stack(). This explains some of the weird
   partial stackdumps reported.

 - some more minor updates to the case when the deadlock detector turns
   itself off due to reaching the limit. We kept the spinlock locked.

to create a -U9.3 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc4.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/2.6.9-rc4-mm1.bz2
 + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U9.3

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
  2004-10-20 17:49                             ` Alexander Batyrshin
                                                 ` (2 preceding siblings ...)
  2004-10-22 13:19                               ` Ingo Molnar
@ 2004-10-22 13:48                               ` Ingo Molnar
  3 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 13:48 UTC (permalink / raw)
  To: Alexander Batyrshin; +Cc: linux-kernel


* Alexander Batyrshin <abatyrshin@ru.mvista.com> wrote:

> 2.
> if execute
> ``for i in `seq 1 9999`; do nohup bash >/dev/null 2>&1 & done'',
> then you'll get something like:
> [...skip...]
> Warning: dev (pts0) tty->count(16) != #fd's(8) in tty_open
> Warning: dev (pts0) tty->count(16) != #fd's(11) in tty_open

btw., where did you run the test - over ssh or in an xterm?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-21 18:57                                     ` Thomas Gleixner
  2004-10-21 19:25                                       ` K.R. Foley
@ 2004-10-22 14:12                                       ` K.R. Foley
  2004-10-22 14:43                                         ` Thomas Gleixner
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-22 14:12 UTC (permalink / raw)
  To: tglx
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Thomas Gleixner wrote:
> On Thu, 2004-10-21 at 20:57, K.R. Foley wrote:
> 
>>>I guess, you don't have a tulip network card in your box, as the module
>>>is removed.
>>>
>>>The question is, if it got registered correctly before the removal.
>>
>>Actually I do have the tulip card in the box and I am pulling this stuff 
>>from the logs over that connection now. Here are the next lines from the 
>>log that might help.
> 
> 

More info on this:

As mentioned before, I get this on boot (every boot):

Oct 21 12:33:22 porky kernel: Linux Tulip driver version 1.1.13 (May 11, 
2002)
Oct 21 12:33:22 porky kernel: PCI: Found IRQ 5 for device 0000:04:0a.0
Oct 21 12:33:22 porky kernel: PCI: Sharing IRQ 5 with 0000:04:05.1
Oct 21 12:33:22 porky kernel: tulip0:  EEPROM default media type Autosense.
Oct 21 12:33:22 porky kernel: tulip0:  Index #0 - Media MII (#11) 
described by a 21140 MII PHY (1) block.
Oct 21 12:33:22 porky kernel: tulip0:  MII transceiver #3 config 3100 
status 7809 advertising 01e1.
Oct 21 12:33:22 porky kernel: eth0: Digital DS21140 Tulip rev 32 at 
0xe480, 00:00:C0:7F:A0:E9, IRQ 5.
Oct 21 12:33:22 porky kernel: BUG: atomic counter underflow at:
Oct 21 12:33:22 porky kernel:  [<c0254dd8>] qdisc_destroy+0x98/0xa0 (12)
Oct 21 12:33:22 porky kernel:  [<c0254fed>] dev_shutdown+0x3d/0xa0 (16)
Oct 21 12:33:22 porky kernel:  [<c024773b>] 
unregister_netdevice+0x13b/0x280 (28)
Oct 21 12:33:22 porky netfs: Mounting other filesystems:  succeeded
Oct 21 12:33:22 porky kernel:  [<c0112fb0>] mcount+0x14/0x18 (12)
Oct 21 12:33:22 porky kernel:  [<e09a6160>] tulip_remove_one+0x0/0xa0 
[tulip] (4)
Oct 21 12:33:22 porky kernel:  [<c02058de>] unregister_netdev+0x1e/0x30 (24)
Oct 21 12:33:22 porky kernel:  [<e09a618f>] tulip_remove_one+0x2f/0xa0 
[tulip] (16)
Oct 21 12:33:22 porky kernel:  [<c01f2907>] 
device_release_driver+0x67/0x70 (8)
Oct 21 12:33:22 porky kernel:  [<c0112fb0>] mcount+0x14/0x18 (8)
Oct 21 12:33:22 porky kernel:  [<c01c4e26>] pci_device_remove+0x76/0x80 (20)
Oct 21 12:33:22 porky kernel:  [<c01f573b>] 
device_detach_shutdown+0xb/0x40 (12)
Oct 21 12:33:22 porky kernel:  [<c01f2907>] 
device_release_driver+0x67/0x70 (12)
Oct 21 12:33:22 porky kernel:  [<c01f293b>] driver_detach+0x2b/0x40 (24)
Oct 21 12:33:22 porky kernel:  [<c01f2daf>] bus_remove_driver+0x3f/0x70 (20)
Oct 21 12:33:22 porky kernel:  [<c01f32b9>] driver_unregister+0x19/0x30 (20)
Oct 21 12:33:22 porky kernel:  [<c01c50cc>] 
pci_unregister_driver+0x1c/0x30 (16)
Oct 21 12:33:22 porky kernel:  [<e09a7767>] tulip_cleanup+0x17/0x1b 
[tulip] (16)
Oct 21 12:33:22 porky kernel:  [<c0139801>] 
sys_delete_module+0x121/0x150 (12)
Oct 21 12:33:22 porky kernel:  [<c01531a1>] sys_munmap+0x51/0x60 (64)
Oct 21 12:33:22 porky kernel:  [<c0116a20>] do_page_fault+0x0/0x660 (16)
Oct 21 12:33:22 porky kernel:  [<c0106719>] sysenter_past_esp+0x52/0x71 (16)
Oct 21 12:33:22 porky kernel: preempt count: 00000001
Oct 21 12:33:22 porky kernel: . 1-level deep critical section nesting:
Oct 21 12:33:22 porky kernel: .. entry 1: print_traces+0x1d/0x60 / 
(dump_stack+0x23/0x30)
Oct 21 12:33:22 porky kernel:
Oct 21 12:33:22 porky kernel: tulip 0000:04:0a.0: Device was removed 
without properly calling pci_disable_device(). This may need fixing.

I am not sure why the tulip driver is being loaded,unloaded,reloaded 
every time on boot? Anyway, I wanted to check to see if I could generate 
the above bug on subsequent unloads of the module. I downed the network 
and the unloaded the tulip module. I did get the message below when 
unloading the module but no "BUG: atomic counter underflow" message.

Oct 22 05:43:33 porky kernel: tulip 0000:04:0a.0: Device was removed 
without properly calling pci_disable_device(). This may need fixing.
Oct 22 05:43:33 porky net.agent[921]: remove event not handled

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-22 14:12                                       ` K.R. Foley
@ 2004-10-22 14:43                                         ` Thomas Gleixner
  2004-10-22 15:15                                           ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-22 14:43 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Fri, 2004-10-22 at 16:12, K.R. Foley wrote:
> I am not sure why the tulip driver is being loaded,unloaded,reloaded 
> every time on boot? Anyway, I wanted to check to see if I could generate 
> the above bug on subsequent unloads of the module. I downed the network 
> and the unloaded the tulip module. I did get the message below when 
> unloading the module but no "BUG: atomic counter underflow" message.
> 
> Oct 22 05:43:33 porky kernel: tulip 0000:04:0a.0: Device was removed 
> without properly calling pci_disable_device(). This may need fixing.
> Oct 22 05:43:33 porky net.agent[921]: remove event not handled

Can you please verify this against vanilla 2.6.9 and 2.6.9-mm1 ?

tglx



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-22 14:43                                         ` Thomas Gleixner
@ 2004-10-22 15:15                                           ` K.R. Foley
  2004-10-22 15:57                                             ` Thomas Gleixner
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-22 15:15 UTC (permalink / raw)
  To: tglx
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Thomas Gleixner wrote:
> On Fri, 2004-10-22 at 16:12, K.R. Foley wrote:
> 
>>I am not sure why the tulip driver is being loaded,unloaded,reloaded 
>>every time on boot? Anyway, I wanted to check to see if I could generate 
>>the above bug on subsequent unloads of the module. I downed the network 
>>and the unloaded the tulip module. I did get the message below when 
>>unloading the module but no "BUG: atomic counter underflow" message.
>>
>>Oct 22 05:43:33 porky kernel: tulip 0000:04:0a.0: Device was removed 
>>without properly calling pci_disable_device(). This may need fixing.
>>Oct 22 05:43:33 porky net.agent[921]: remove event not handled
> 
> 
> Can you please verify this against vanilla 2.6.9 and 2.6.9-mm1 ?
> 
> tglx
> 

I will verify it against 2.6.9 when I get time. I did verify the "Device 
was removed without properly calling pci_disable_device(). This may need 
fixing." message is generated with 2.6.9-rc3-mm3 without preempt 
patches. Also thanks to Mark Johnson's suggestion I verified that the 
reason the driver is being loaded twice is because kudzu is loading it 
once then unloading it.

kr


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

* [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10
  2004-10-22 13:35                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3 Ingo Molnar
@ 2004-10-22 15:50                                 ` Ingo Molnar
  2004-10-22 16:47                                   ` Gene Heskett
                                                     ` (2 more replies)
  2004-10-22 18:41                                 ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3 Alexander Batyrshin
  1 sibling, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 15:50 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano


i have released the -U10 Real-Time Preemption patch, which can be
downloaded from:
 
  http://redhat.com/~mingo/realtime-preempt/

this is purely a rebasing of -U9.3 to 2.6.9-mm1.

to create a -U10 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/2.6.9-mm1.bz2
 + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-U10

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-22 15:15                                           ` K.R. Foley
@ 2004-10-22 15:57                                             ` Thomas Gleixner
  2004-10-22 16:51                                               ` Ingo Molnar
  2004-10-22 17:44                                               ` K.R. Foley
  0 siblings, 2 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-22 15:57 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Fri, 2004-10-22 at 17:15, K.R. Foley wrote:
> Thomas Gleixner wrote:
> > On Fri, 2004-10-22 at 16:12, K.R. Foley wrote:
> > 
> >>I am not sure why the tulip driver is being loaded,unloaded,reloaded 
> >>every time on boot? Anyway, I wanted to check to see if I could generate 
> >>the above bug on subsequent unloads of the module. I downed the network 
> >>and the unloaded the tulip module. I did get the message below when 
> >>unloading the module but no "BUG: atomic counter underflow" message.
> >>
> >>Oct 22 05:43:33 porky kernel: tulip 0000:04:0a.0: Device was removed 
> >>without properly calling pci_disable_device(). This may need fixing.
> >>Oct 22 05:43:33 porky net.agent[921]: remove event not handled
> > 
> > 
> > Can you please verify this against vanilla 2.6.9 and 2.6.9-mm1 ?
> > 
> > tglx
> > 
> 
> I will verify it against 2.6.9 when I get time. I did verify the "Device 
> was removed without properly calling pci_disable_device(). This may need 
> fixing." message is generated with 2.6.9-rc3-mm3 without preempt 
> patches. Also thanks to Mark Johnson's suggestion I verified that the 
> reason the driver is being loaded twice is because kudzu is loading it 
> once then unloading it.
> 
> kr

--- 2.6.9-rc4-mm1/drivers/net/tulip/tulip_core.c	2004-10-12
09:41:27.000000000 +0200
+++ 2.6.9-rc4-mm1-U9-E0/drivers/net/tulip/tulip_core.c	2004-10-22
17:54:31.000000000 +0200
@@ -1784,6 +1784,7 @@
 #endif
 	free_netdev (dev);
 	pci_release_regions (pdev);
+	pci_disable_device (pdev);
 	pci_set_drvdata (pdev, NULL);
 
 	/* pci_power_off (pdev, -1); */



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10
  2004-10-22 16:51                                     ` Ingo Molnar
@ 2004-10-22 16:19                                       ` Jeff V. Merkey
  2004-10-22 17:27                                         ` Russell Miller
  2004-10-22 21:47                                         ` Gene Heskett
  0 siblings, 2 replies; 951+ messages in thread
From: Jeff V. Merkey @ 2004-10-22 16:19 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Gene Heskett, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Ingo Molnar wrote:

>* Gene Heskett <gene.heskett@verizon.net> wrote:
>
>  
>
>>As sort of the ultimate dummy test, I'm building this right now.  The
>>only oddments so far are a bunch of deprecated variable warnings,
>>quite a few but many are dups.
>>    
>>
>
>these warnings are present in -mm1 too.
>
>	Ingo
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
Hey Ingo,

Bite Me.

:-)

Jeff

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10
  2004-10-22 15:50                                 ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10 Ingo Molnar
@ 2004-10-22 16:47                                   ` Gene Heskett
  2004-10-22 16:51                                     ` Ingo Molnar
  2004-10-22 17:56                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Ingo Molnar
  2004-10-22 21:44                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10 Gene Heskett
  2 siblings, 1 reply; 951+ messages in thread
From: Gene Heskett @ 2004-10-22 16:47 UTC (permalink / raw)
  To: linux-kernel
  Cc: Ingo Molnar, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Friday 22 October 2004 11:50, Ingo Molnar wrote:
>i have released the -U10 Real-Time Preemption patch, which can be
>downloaded from:
>
>  http://redhat.com/~mingo/realtime-preempt/
>
>this is purely a rebasing of -U9.3 to 2.6.9-mm1.
>
>to create a -U10 tree from scratch, the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
> +
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.
>6.9-mm1/2.6.9-mm1.bz2 +
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm
>1-U10
>
> Ingo

As sort of the ultimate dummy test, I'm building this right now.  The 
only oddments so far are a bunch of deprecated variable warnings, 
quite a few but many are dups.

I'll repost after I've tried it.

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

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10
  2004-10-22 17:27                                         ` Russell Miller
@ 2004-10-22 16:48                                           ` Jeff V. Merkey
  0 siblings, 0 replies; 951+ messages in thread
From: Jeff V. Merkey @ 2004-10-22 16:48 UTC (permalink / raw)
  To: Russell Miller; +Cc: linux-kernel

Russell Miller wrote:

>Hey, Jeff,
>
>This is a very high traffic list.  If you have nothing constructive to say, 
>don't say it.  
>--Russell
>
>  
>
I'll stick to bugs from now own Russell.  Please forward the same to 
Ingo .... 

Jeff

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10
  2004-10-22 16:47                                   ` Gene Heskett
@ 2004-10-22 16:51                                     ` Ingo Molnar
  2004-10-22 16:19                                       ` Jeff V. Merkey
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 16:51 UTC (permalink / raw)
  To: Gene Heskett
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Gene Heskett <gene.heskett@verizon.net> wrote:

> As sort of the ultimate dummy test, I'm building this right now.  The
> only oddments so far are a bunch of deprecated variable warnings,
> quite a few but many are dups.

these warnings are present in -mm1 too.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-22 15:57                                             ` Thomas Gleixner
@ 2004-10-22 16:51                                               ` Ingo Molnar
  2004-10-22 17:44                                               ` K.R. Foley
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 16:51 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: K.R. Foley, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano


* Thomas Gleixner <tglx@linutronix.de> wrote:

> --- 2.6.9-rc4-mm1/drivers/net/tulip/tulip_core.c	2004-10-12

>  	pci_release_regions (pdev);
> +	pci_disable_device (pdev);
>  	pci_set_drvdata (pdev, NULL);

i've uploaded -U10.1 with this fix included plus a fix to the tg3 and
3c59x drivers. (the drivers would disable interrupts in
hard_start_xmit). I've also added debugging code to catch future
instances of this network driver related problem.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10
  2004-10-22 16:19                                       ` Jeff V. Merkey
@ 2004-10-22 17:27                                         ` Russell Miller
  2004-10-22 16:48                                           ` Jeff V. Merkey
  2004-10-22 21:47                                         ` Gene Heskett
  1 sibling, 1 reply; 951+ messages in thread
From: Russell Miller @ 2004-10-22 17:27 UTC (permalink / raw)
  To: Jeff V. Merkey; +Cc: linux-kernel

On Friday 22 October 2004 11:19, Jeff V. Merkey wrote:

> Hey Ingo,
>
> Bite Me.
>
> :-)
>
Hey, Jeff,

This is a very high traffic list.  If you have nothing constructive to say, 
don't say it.  Many here are already not happy with your attitude already, 
you're not helping.

For my part, you're getting a shiny new procmail entry right to dave null.  
I'm sick of it.

Sorry, everyone else, for adding to the noise.  But someone's gotta say it.

--Russell

-- 

Russell Miller - rmiller@duskglow.com - Le Mars, IA
Duskglow Consulting - Helping companies just like you to succeed for ~ 10 yrs.
http://www.duskglow.com - 712-546-5886

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9
  2004-10-22 15:57                                             ` Thomas Gleixner
  2004-10-22 16:51                                               ` Ingo Molnar
@ 2004-10-22 17:44                                               ` K.R. Foley
  1 sibling, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-22 17:44 UTC (permalink / raw)
  To: tglx
  Cc: Ingo Molnar, LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

Thomas Gleixner wrote:
> On Fri, 2004-10-22 at 17:15, K.R. Foley wrote:
> 
>>Thomas Gleixner wrote:
>>
>>>On Fri, 2004-10-22 at 16:12, K.R. Foley wrote:
>>>
>>>
>>>>I am not sure why the tulip driver is being loaded,unloaded,reloaded 
>>>>every time on boot? Anyway, I wanted to check to see if I could generate 
>>>>the above bug on subsequent unloads of the module. I downed the network 
>>>>and the unloaded the tulip module. I did get the message below when 
>>>>unloading the module but no "BUG: atomic counter underflow" message.
>>>>
>>>>Oct 22 05:43:33 porky kernel: tulip 0000:04:0a.0: Device was removed 
>>>>without properly calling pci_disable_device(). This may need fixing.
>>>>Oct 22 05:43:33 porky net.agent[921]: remove event not handled
>>>
>>>
>>>Can you please verify this against vanilla 2.6.9 and 2.6.9-mm1 ?
>>>
>>>tglx
>>>
>>
>>I will verify it against 2.6.9 when I get time. I did verify the "Device 
>>was removed without properly calling pci_disable_device(). This may need 
>>fixing." message is generated with 2.6.9-rc3-mm3 without preempt 
>>patches. Also thanks to Mark Johnson's suggestion I verified that the 
>>reason the driver is being loaded twice is because kudzu is loading it 
>>once then unloading it.
>>
>>kr
> 
> 
> --- 2.6.9-rc4-mm1/drivers/net/tulip/tulip_core.c	2004-10-12
> 09:41:27.000000000 +0200
> +++ 2.6.9-rc4-mm1-U9-E0/drivers/net/tulip/tulip_core.c	2004-10-22
> 17:54:31.000000000 +0200
> @@ -1784,6 +1784,7 @@
>  #endif
>  	free_netdev (dev);
>  	pci_release_regions (pdev);
> +	pci_disable_device (pdev);
>  	pci_set_drvdata (pdev, NULL);
>  
>  	/* pci_power_off (pdev, -1); */
> 
> 
> 

This does fix this error:

porky kernel: tulip 0000:04:0a.0: Device was removed without properly 
calling pci_disable_device(). This may need fixing.

thanks,

kr

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

* [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-22 15:50                                 ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10 Ingo Molnar
  2004-10-22 16:47                                   ` Gene Heskett
@ 2004-10-22 17:56                                   ` Ingo Molnar
  2004-10-22 21:49                                     ` Gene Heskett
                                                       ` (6 more replies)
  2004-10-22 21:44                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10 Gene Heskett
  2 siblings, 7 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 17:56 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


i have released the -U10.2 Real-Time Preemption patch, which can be
downloaded from:

  http://redhat.com/~mingo/realtime-preempt/
 
this is a fixes-only release.

Changes since -U10:

 - fixed a big bug present ever since: the BKL got dropped when a
   spinlock-mutex was acquired and it scheduled away. This reduced the
   locking efficiency of the BKL. A number of outstanding problems could
   be affected, in particular this should fix the tty locking breakage
   reported by Alexander Batyrshin and Adam Heath. UP and SMP systems 
   are affected too, with SMP systems having a higher chance to trigger
   this condition.

 - tulip.c breakage fix from Thomas Gleixner

 - tg3 and 3c59x fixes.

 - made the hardirq threads SCHED_FIFO by default. They get priorities 
   between 25 and 50, depending on the irq #. (this is pretty random but 
   i found no better scheme.) Made the softirq thread SCHED_FIFO by 
   default as well, albeit this probably will have to change. These 
   changes should make it easier to debug a hung system.

to create a -U10.2 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/2.6.9-mm1.bz2
 + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-U10.2

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3
  2004-10-22 13:35                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3 Ingo Molnar
  2004-10-22 15:50                                 ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10 Ingo Molnar
@ 2004-10-22 18:41                                 ` Alexander Batyrshin
  2004-10-22 20:08                                   ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Alexander Batyrshin @ 2004-10-22 18:41 UTC (permalink / raw)
  To: Ingo Molnar, Ext-Rt-Dev@Mvista. Com, linux-kernel

   Hi Ingo,
U9.3 (defconfig) died with trace:

------------[ cut here ]------------
kernel BUG at kernel/sched.c:784!
invalid operand: 0000 [#1]
PREEMPT SMP
Modules linked in:
CPU:    0
EIP:    0060:[<c011873d>]    Not tainted VLI
EFLAGS: 00010002   (2.6.9-rc4-mm1-RT-U9.3)
EIP is at resched_task+0x80/0x8a
eax: 00000001   ebx: c1674000   ecx: dfb578f0   edx: 00000000
esi: c16712c0   edi: 00000000   ebp: c167bc48   esp: c167bc3c
ds: 007b   es: 007b   ss: 0068   preempt: 00000003
Process ksoftirqd/0 (pid: 3, threadinfo=c167a000 task=c1670660)
Stack: c1403820 c1403820 00000000 c167bc94 c0118b78 c16712c0 c1433820 
00000000
        00000000 00000000 00000001 00000100 c1433820 c1433820 00000001 
00000000
        00000000 00000001 00000082 00000001 de9d3e60 00000001 c167bcd8 
c0133c7b
Call Trace:
  [<c0118b78>] try_to_wake_up+0x1f3/0x26b (20)
  [<c0133c7b>] autoremove_wake_function+0x2f/0x57 (76)
  [<c011a766>] __wake_up_common+0x3f/0x5e (28)
  [<c011a7d0>] __wake_up+0x4b/0x62 (40)
  [<c034e08c>] sock_def_readable+0x8e/0x90 (52)
  [<c0388dbe>] tcp_child_process+0xe6/0xec (28)
  [<c0384df7>] tcp_v4_do_rcv+0x123/0x162 (36)
  [<c0134079>] _mutex_lock+0x2c/0x3b (16)
  [<c0385513>] tcp_v4_rcv+0x6dd/0x92c (16)
  [<c03c0e30>] svc_revisit+0x27/0x154 (48)
  [<c0368553>] ip_local_deliver_finish+0x0/0x1b2 (40)
  [<c0368609>] ip_local_deliver_finish+0xb6/0x1b2 (4)
  [<c0368553>] ip_local_deliver_finish+0x0/0x1b2 (12)
  [<c035f607>] nf_hook_slow+0xdc/0x12e (20)
  [<c0368553>] ip_local_deliver_finish+0x0/0x1b2 (28)
  [<c0368705>] ip_rcv_finish+0x0/0x2b3 (28)
  [<c0367fcb>] ip_local_deliver+0x208/0x226 (4)
  [<c0368553>] ip_local_deliver_finish+0x0/0x1b2 (24)
  [<c0368828>] ip_rcv_finish+0x123/0x2b3 (20)
  [<c0368705>] ip_rcv_finish+0x0/0x2b3 (32)
  [<c035f607>] nf_hook_slow+0xdc/0x12e (20)
  [<c0368705>] ip_rcv_finish+0x0/0x2b3 (28)
  [<c036846a>] ip_rcv+0x481/0x56a (32)
  [<c0368705>] ip_rcv_finish+0x0/0x2b3 (24)
  [<c0354e68>] netif_receive_skb+0x117/0x1dd (28)
  [<c0354ff7>] process_backlog+0xc9/0x1cb (36)
  [<c03551b2>] net_rx_action+0xb9/0x1ed (48)
  [<c01242d9>] ___do_softirq+0xe1/0x130 (36)
  [<c0124923>] ksoftirqd+0x0/0xda (40)
  [<c01243fb>] _do_softirq+0x4b/0x4d (4)
  [<c01249c5>] ksoftirqd+0xa2/0xda (16)
  [<c013376d>] kthread+0xb7/0xbd (24)
  [<c01336b6>] kthread+0x0/0xbd (28)
  [<c0103375>] kernel_thread_helper+0x5/0xb (16)
preempt count: 00000004
. 4-level deep critical section nesting:
.. entry 1: _spin_lock_irqsave+0x1d/0xa5 [<00000000>] / (0x0 [<00000000>])
.. entry 2: _spin_lock+0x19/0x6d [<00000000>] / (0x0 [<00000000>])
.. entry 3: _spin_lock_irqsave+0x1d/0xa5 [<00000000>] / (0x0 [<00000000>])
.. entry 4: print_traces+0x17/0x4e [<00000000>] / (0x0 [<00000000>])


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3
  2004-10-22 18:41                                 ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3 Alexander Batyrshin
@ 2004-10-22 20:08                                   ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-22 20:08 UTC (permalink / raw)
  To: Alexander Batyrshin; +Cc: Ext-Rt-Dev@Mvista. Com, linux-kernel


how about U10.3? That has the BKL fix too.

	Ingo

* Alexander Batyrshin <abatyrshin@ru.mvista.com> wrote:

>   Hi Ingo,
> U9.3 (defconfig) died with trace:
> 
> ------------[ cut here ]------------
> kernel BUG at kernel/sched.c:784!
> invalid operand: 0000 [#1]
> PREEMPT SMP
> Modules linked in:
> CPU:    0
> EIP:    0060:[<c011873d>]    Not tainted VLI
> EFLAGS: 00010002   (2.6.9-rc4-mm1-RT-U9.3)
> EIP is at resched_task+0x80/0x8a
> eax: 00000001   ebx: c1674000   ecx: dfb578f0   edx: 00000000
> esi: c16712c0   edi: 00000000   ebp: c167bc48   esp: c167bc3c
> ds: 007b   es: 007b   ss: 0068   preempt: 00000003
> Process ksoftirqd/0 (pid: 3, threadinfo=c167a000 task=c1670660)
> Stack: c1403820 c1403820 00000000 c167bc94 c0118b78 c16712c0 c1433820 
> 00000000
>        00000000 00000000 00000001 00000100 c1433820 c1433820 00000001 
> 00000000
>        00000000 00000001 00000082 00000001 de9d3e60 00000001 c167bcd8 
> c0133c7b
> Call Trace:
>  [<c0118b78>] try_to_wake_up+0x1f3/0x26b (20)
>  [<c0133c7b>] autoremove_wake_function+0x2f/0x57 (76)
>  [<c011a766>] __wake_up_common+0x3f/0x5e (28)
>  [<c011a7d0>] __wake_up+0x4b/0x62 (40)
>  [<c034e08c>] sock_def_readable+0x8e/0x90 (52)
>  [<c0388dbe>] tcp_child_process+0xe6/0xec (28)
>  [<c0384df7>] tcp_v4_do_rcv+0x123/0x162 (36)
>  [<c0134079>] _mutex_lock+0x2c/0x3b (16)
>  [<c0385513>] tcp_v4_rcv+0x6dd/0x92c (16)
>  [<c03c0e30>] svc_revisit+0x27/0x154 (48)
>  [<c0368553>] ip_local_deliver_finish+0x0/0x1b2 (40)
>  [<c0368609>] ip_local_deliver_finish+0xb6/0x1b2 (4)
>  [<c0368553>] ip_local_deliver_finish+0x0/0x1b2 (12)
>  [<c035f607>] nf_hook_slow+0xdc/0x12e (20)
>  [<c0368553>] ip_local_deliver_finish+0x0/0x1b2 (28)
>  [<c0368705>] ip_rcv_finish+0x0/0x2b3 (28)
>  [<c0367fcb>] ip_local_deliver+0x208/0x226 (4)
>  [<c0368553>] ip_local_deliver_finish+0x0/0x1b2 (24)
>  [<c0368828>] ip_rcv_finish+0x123/0x2b3 (20)
>  [<c0368705>] ip_rcv_finish+0x0/0x2b3 (32)
>  [<c035f607>] nf_hook_slow+0xdc/0x12e (20)
>  [<c0368705>] ip_rcv_finish+0x0/0x2b3 (28)
>  [<c036846a>] ip_rcv+0x481/0x56a (32)
>  [<c0368705>] ip_rcv_finish+0x0/0x2b3 (24)
>  [<c0354e68>] netif_receive_skb+0x117/0x1dd (28)
>  [<c0354ff7>] process_backlog+0xc9/0x1cb (36)
>  [<c03551b2>] net_rx_action+0xb9/0x1ed (48)
>  [<c01242d9>] ___do_softirq+0xe1/0x130 (36)
>  [<c0124923>] ksoftirqd+0x0/0xda (40)
>  [<c01243fb>] _do_softirq+0x4b/0x4d (4)
>  [<c01249c5>] ksoftirqd+0xa2/0xda (16)
>  [<c013376d>] kthread+0xb7/0xbd (24)
>  [<c01336b6>] kthread+0x0/0xbd (28)
>  [<c0103375>] kernel_thread_helper+0x5/0xb (16)
> preempt count: 00000004
> . 4-level deep critical section nesting:
> .. entry 1: _spin_lock_irqsave+0x1d/0xa5 [<00000000>] / (0x0 [<00000000>])
> .. entry 2: _spin_lock+0x19/0x6d [<00000000>] / (0x0 [<00000000>])
> .. entry 3: _spin_lock_irqsave+0x1d/0xa5 [<00000000>] / (0x0 [<00000000>])
> .. entry 4: print_traces+0x17/0x4e [<00000000>] / (0x0 [<00000000>])

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10
  2004-10-22 15:50                                 ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10 Ingo Molnar
  2004-10-22 16:47                                   ` Gene Heskett
  2004-10-22 17:56                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Ingo Molnar
@ 2004-10-22 21:44                                   ` Gene Heskett
  2 siblings, 0 replies; 951+ messages in thread
From: Gene Heskett @ 2004-10-22 21:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Ingo Molnar, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Friday 22 October 2004 11:50, Ingo Molnar wrote:
>i have released the -U10 Real-Time Preemption patch, which can be
>downloaded from:
>
>  http://redhat.com/~mingo/realtime-preempt/
>
>this is purely a rebasing of -U9.3 to 2.6.9-mm1.
>
>to create a -U10 tree from scratch, the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
> +
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.
>6.9-mm1/2.6.9-mm1.bz2 +
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm
>1-U10
>
> Ingo

I teased 2 gallons of latex primer out of the cans, making it jump up 
onto some outbuildings, so I'm a bit late with the report, which is 
that it spit out a whole flurry of scheduleing while atomic messages 
when I tried it just now, and finally hung, requiring I exersize the 
reset button long before it got to rc.sysinit.  The best I could do 
might be a screen snapshot, but I haven't figured out howto shut the 
flippin flash off and use the available light, or try and scribble it 
all down.  And that would lead to violent deaths if I was a doctor 
trying to write prescriptions. :-( 

As an experiment to see if I could lay bleeding edge, I bled. :)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10
  2004-10-22 16:19                                       ` Jeff V. Merkey
  2004-10-22 17:27                                         ` Russell Miller
@ 2004-10-22 21:47                                         ` Gene Heskett
  1 sibling, 0 replies; 951+ messages in thread
From: Gene Heskett @ 2004-10-22 21:47 UTC (permalink / raw)
  To: linux-kernel
  Cc: Jeff V. Merkey, Ingo Molnar, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano

On Friday 22 October 2004 12:19, Jeff V. Merkey wrote:
>Ingo Molnar wrote:
>>* Gene Heskett <gene.heskett@verizon.net> wrote:
>>>As sort of the ultimate dummy test, I'm building this right now. 
>>> The only oddments so far are a bunch of deprecated variable
>>> warnings, quite a few but many are dups.
>>
>>these warnings are present in -mm1 too.
>>
>> Ingo
>>-
>>To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in the body of a message to
>> majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at  http://www.tux.org/lkml/
>
>Hey Ingo,
>
>Bite Me.
>
>:-)
>
>Jeff

Frankly Jeff, we'd best be afraid of food poisoning if we got that 
hungry.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-22 17:56                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Ingo Molnar
@ 2004-10-22 21:49                                     ` Gene Heskett
  2004-10-22 22:06                                       ` Lee Revell
  2004-10-22 22:38                                     ` K.R. Foley
                                                       ` (5 subsequent siblings)
  6 siblings, 1 reply; 951+ messages in thread
From: Gene Heskett @ 2004-10-22 21:49 UTC (permalink / raw)
  To: linux-kernel
  Cc: Ingo Molnar, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Friday 22 October 2004 13:56, Ingo Molnar wrote:
>i have released the -U10.2 Real-Time Preemption patch, which can be
>downloaded from:
>
>  http://redhat.com/~mingo/realtime-preempt/
>
>this is a fixes-only release.
>
>Changes since -U10:
>
> - fixed a big bug present ever since: the BKL got dropped when a
>   spinlock-mutex was acquired and it scheduled away. This reduced
> the locking efficiency of the BKL. A number of outstanding problems
> could be affected, in particular this should fix the tty locking
> breakage reported by Alexander Batyrshin and Adam Heath. UP and SMP
> systems are affected too, with SMP systems having a higher chance
> to trigger this condition.
>
> - tulip.c breakage fix from Thomas Gleixner
>
> - tg3 and 3c59x fixes.
>
> - made the hardirq threads SCHED_FIFO by default. They get
> priorities between 25 and 50, depending on the irq #. (this is
> pretty random but i found no better scheme.) Made the softirq
> thread SCHED_FIFO by default as well, albeit this probably will
> have to change. These changes should make it easier to debug a hung
> system.
>
>to create a -U10.2 tree from scratch, the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
> +
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.
>6.9-mm1/2.6.9-mm1.bz2 +
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm
>1-U10.2

Mmm, I get a 404 page not found. when I click on  on thsi link.

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

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-22 21:49                                     ` Gene Heskett
@ 2004-10-22 22:06                                       ` Lee Revell
  2004-10-22 22:30                                         ` Lee Revell
  2004-10-23 10:36                                         ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-22 22:06 UTC (permalink / raw)
  To: gene.heskett
  Cc: linux-kernel, Ingo Molnar, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Fri, 2004-10-22 at 17:49 -0400, Gene Heskett wrote:
> Mmm, I get a 404 page not found. when I click on  on thsi link.

Same here.  The current version is 10.3:

http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-U10.3

I did not get an announcement, it looks like the listserv is backlogged,
or Ingo did not announce it yet.

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-22 22:06                                       ` Lee Revell
@ 2004-10-22 22:30                                         ` Lee Revell
  2004-10-23 10:36                                         ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-22 22:30 UTC (permalink / raw)
  To: gene.heskett
  Cc: linux-kernel, Ingo Molnar, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Fri, 2004-10-22 at 18:06 -0400, Lee Revell wrote:
> On Fri, 2004-10-22 at 17:49 -0400, Gene Heskett wrote:
> > Mmm, I get a 404 page not found. when I click on  on thsi link.
> 
> Same here.  The current version is 10.3:
> 
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-U10.3

OK, U10.3 is the first since T3 for me that boots flawlessly.  Latency
numbers forthcoming...

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-22 17:56                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Ingo Molnar
  2004-10-22 21:49                                     ` Gene Heskett
@ 2004-10-22 22:38                                     ` K.R. Foley
  2004-10-23 10:32                                       ` Ingo Molnar
  2004-10-23  0:27                                     ` Rui Nuno Capela
                                                       ` (4 subsequent siblings)
  6 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-22 22:38 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

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

Ingo Molnar wrote:
> i have released the -U10.2 Real-Time Preemption patch, which can be
> downloaded from:
> 
>   http://redhat.com/~mingo/realtime-preempt/
>  
> this is a fixes-only release.
> 

I got quite a few BUG traces this afternoon running this one on my 
workstation. I am just attaching the relevant chunk of the log because 
there are 7 or 8 of them.

kr

[-- Attachment #2: dump.txt --]
[-- Type: text/plain, Size: 15762 bytes --]

Oct 22 14:11:29 swdev14 kernel: NET: Registered protocol family 4
Oct 22 14:13:11 swdev14 ntpd[2865]: synchronized to 151.131.44.70, stratum=4
Oct 22 14:13:11 swdev14 ntpd[2865]: kernel time sync disabled 0041
Oct 22 14:26:00 swdev14 ntpd[2865]: kernel time sync enabled 0001
Oct 22 14:37:14 swdev14 kernel: BUG: sleeping function called from invalid context ksoftirqd/0(3) at kernel/mutex.c:37
Oct 22 14:37:14 swdev14 kernel: in_atomic():1 [00000001], irqs_disabled():0
Oct 22 14:37:14 swdev14 kernel:  [<c011ac3d>] __might_sleep+0xc4/0xd6 (12)
Oct 22 14:37:14 swdev14 kernel:  [<c0132ae8>] _mutex_lock+0x3e/0x63 (36)
Oct 22 14:37:14 swdev14 kernel:  [<e0a8b297>] ipxitf_find_using_phys+0x1e/0x4c [ipx] (28)
Oct 22 14:37:14 swdev14 kernel:  [<e0a8d5a6>] ipx_rcv+0xdc/0x1dd [ipx] (20)
Oct 22 14:37:14 swdev14 kernel:  [<c024050b>] snap_rcv+0x5f/0xe0 (32)
Oct 22 14:37:14 swdev14 kernel:  [<c023fadc>] llc_rcv+0x19b/0x2a3 (24)
Oct 22 14:37:14 swdev14 kernel:  [<c02325df>] netif_receive_skb+0x201/0x30c (32)
Oct 22 14:37:14 swdev14 kernel:  [<c0130400>] remove_from_abslist+0x6/0x64 (20)
Oct 22 14:37:14 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (8)
Oct 22 14:37:14 swdev14 kernel:  [<c0232780>] process_backlog+0x96/0x164 (28)
Oct 22 14:37:14 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (40)
Oct 22 14:37:14 swdev14 kernel:  [<c012299c>] ___do_softirq+0xb8/0x107 (40)
Oct 22 14:37:14 swdev14 kernel:  [<c013317c>] __mcount+0x1d/0x21 (12)
Oct 22 14:37:14 swdev14 kernel:  [<c0122a9b>] _do_softirq+0x20/0x22 (36)
Oct 22 14:37:14 swdev14 kernel:  [<c0122f85>] ksoftirqd+0xcd/0x105 (8)
Oct 22 14:37:14 swdev14 kernel:  [<c0132227>] kthread+0xbc/0xc1 (32)
Oct 22 14:37:14 swdev14 kernel:  [<c0122eb8>] ksoftirqd+0x0/0x105 (20)
Oct 22 14:37:14 swdev14 kernel:  [<c013216b>] kthread+0x0/0xc1 (12)
Oct 22 14:37:14 swdev14 kernel:  [<c01043b1>] kernel_thread_helper+0x5/0xb (16)
Oct 22 14:37:14 swdev14 kernel: preempt count: 00000002
Oct 22 14:37:14 swdev14 kernel: . 2-level deep critical section nesting:
Oct 22 14:37:14 swdev14 kernel: .. entry 1: snap_rcv+0x1b/0xe0 [<c023fadc>] / (llc_rcv+0x19b/0x2a3 [<c023fadc>])
Oct 22 14:37:14 swdev14 kernel: .. entry 2: print_traces+0x1d/0x59 [<c01070c3>] / (dump_stack+0x23/0x27 [<c01070c3>])
Oct 22 14:37:14 swdev14 kernel: 
Oct 22 14:37:16 swdev14 kernel: BUG: sleeping function called from invalid context ksoftirqd/0(3) at kernel/mutex.c:37
Oct 22 14:37:16 swdev14 kernel: in_atomic():1 [00000001], irqs_disabled():0
Oct 22 14:37:16 swdev14 kernel:  [<c011ac3d>] __might_sleep+0xc4/0xd6 (12)
Oct 22 14:37:16 swdev14 kernel:  [<c0132ae8>] _mutex_lock+0x3e/0x63 (36)
Oct 22 14:37:16 swdev14 kernel:  [<e0a8b297>] ipxitf_find_using_phys+0x1e/0x4c [ipx] (28)
Oct 22 14:37:16 swdev14 kernel:  [<e0a8d5a6>] ipx_rcv+0xdc/0x1dd [ipx] (20)
Oct 22 14:37:16 swdev14 kernel:  [<c024050b>] snap_rcv+0x5f/0xe0 (32)
Oct 22 14:37:16 swdev14 kernel:  [<c023fadc>] llc_rcv+0x19b/0x2a3 (24)
Oct 22 14:37:16 swdev14 kernel:  [<c02325df>] netif_receive_skb+0x201/0x30c (32)
Oct 22 14:37:16 swdev14 kernel:  [<c0130400>] remove_from_abslist+0x6/0x64 (20)
Oct 22 14:37:16 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (8)
Oct 22 14:37:16 swdev14 kernel:  [<c0232780>] process_backlog+0x96/0x164 (28)
Oct 22 14:37:16 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (40)
Oct 22 14:37:16 swdev14 kernel:  [<c012299c>] ___do_softirq+0xb8/0x107 (40)
Oct 22 14:37:16 swdev14 kernel:  [<c013317c>] __mcount+0x1d/0x21 (12)
Oct 22 14:37:16 swdev14 kernel:  [<c0122a9b>] _do_softirq+0x20/0x22 (36)
Oct 22 14:37:16 swdev14 kernel:  [<c0122f85>] ksoftirqd+0xcd/0x105 (8)
Oct 22 14:37:16 swdev14 kernel:  [<c0132227>] kthread+0xbc/0xc1 (32)
Oct 22 14:37:16 swdev14 kernel:  [<c0122eb8>] ksoftirqd+0x0/0x105 (20)
Oct 22 14:37:16 swdev14 kernel:  [<c013216b>] kthread+0x0/0xc1 (12)
Oct 22 14:37:16 swdev14 kernel:  [<c01043b1>] kernel_thread_helper+0x5/0xb (16)
Oct 22 14:37:16 swdev14 kernel: preempt count: 00000002
Oct 22 14:37:16 swdev14 kernel: . 2-level deep critical section nesting:
Oct 22 14:37:16 swdev14 kernel: .. entry 1: snap_rcv+0x1b/0xe0 [<c023fadc>] / (llc_rcv+0x19b/0x2a3 [<c023fadc>])
Oct 22 14:37:16 swdev14 kernel: .. entry 2: print_traces+0x1d/0x59 [<c01070c3>] / (dump_stack+0x23/0x27 [<c01070c3>])
Oct 22 14:37:16 swdev14 kernel: 
Oct 22 14:37:17 swdev14 kernel: BUG: sleeping function called from invalid context ksoftirqd/0(3) at kernel/mutex.c:37
Oct 22 14:37:17 swdev14 kernel: in_atomic():1 [00000001], irqs_disabled():0
Oct 22 14:37:17 swdev14 kernel:  [<c011ac3d>] __might_sleep+0xc4/0xd6 (12)
Oct 22 14:37:17 swdev14 kernel:  [<c0132ae8>] _mutex_lock+0x3e/0x63 (36)
Oct 22 14:37:17 swdev14 kernel:  [<e0a8b297>] ipxitf_find_using_phys+0x1e/0x4c [ipx] (28)
Oct 22 14:37:17 swdev14 kernel:  [<e0a8d5a6>] ipx_rcv+0xdc/0x1dd [ipx] (20)
Oct 22 14:37:17 swdev14 kernel:  [<c024050b>] snap_rcv+0x5f/0xe0 (32)
Oct 22 14:37:17 swdev14 kernel:  [<c023fadc>] llc_rcv+0x19b/0x2a3 (24)
Oct 22 14:37:17 swdev14 kernel:  [<c02325df>] netif_receive_skb+0x201/0x30c (32)
Oct 22 14:37:17 swdev14 kernel:  [<c0130400>] remove_from_abslist+0x6/0x64 (20)
Oct 22 14:37:17 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (8)
Oct 22 14:37:17 swdev14 kernel:  [<c0232780>] process_backlog+0x96/0x164 (28)
Oct 22 14:37:17 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (40)
Oct 22 14:37:17 swdev14 kernel:  [<c012299c>] ___do_softirq+0xb8/0x107 (40)
Oct 22 14:37:17 swdev14 kernel:  [<c013317c>] __mcount+0x1d/0x21 (12)
Oct 22 14:37:17 swdev14 kernel:  [<c0122a9b>] _do_softirq+0x20/0x22 (36)
Oct 22 14:37:17 swdev14 kernel:  [<c0122f85>] ksoftirqd+0xcd/0x105 (8)
Oct 22 14:37:17 swdev14 kernel:  [<c0132227>] kthread+0xbc/0xc1 (32)
Oct 22 14:37:17 swdev14 kernel:  [<c0122eb8>] ksoftirqd+0x0/0x105 (20)
Oct 22 14:37:17 swdev14 kernel:  [<c013216b>] kthread+0x0/0xc1 (12)
Oct 22 14:37:17 swdev14 kernel:  [<c01043b1>] kernel_thread_helper+0x5/0xb (16)
Oct 22 14:37:17 swdev14 kernel: preempt count: 00000002
Oct 22 14:37:17 swdev14 kernel: . 2-level deep critical section nesting:
Oct 22 14:37:17 swdev14 kernel: .. entry 1: snap_rcv+0x1b/0xe0 [<c023fadc>] / (llc_rcv+0x19b/0x2a3 [<c023fadc>])
Oct 22 14:37:17 swdev14 kernel: .. entry 2: print_traces+0x1d/0x59 [<c01070c3>] / (dump_stack+0x23/0x27 [<c01070c3>])
Oct 22 14:37:17 swdev14 kernel: 
Oct 22 14:37:17 swdev14 kernel: BUG: scheduling while atomic: ksoftirqd/0/0x10000001/3
Oct 22 14:37:17 swdev14 kernel: caller is cond_resched+0x64/0x78
Oct 22 14:37:17 swdev14 kernel:  [<c029dd88>] __sched_text_start+0xbdc/0xc2c (12)
Oct 22 14:37:17 swdev14 kernel:  [<c029e6da>] cond_resched+0x64/0x78 (8)
Oct 22 14:37:17 swdev14 kernel:  [<c01338ce>] check_preempt_timing+0x5d/0x289 (12)
Oct 22 14:37:17 swdev14 kernel:  [<c0133b40>] touch_preempt_timing+0x46/0x4a (4)
Oct 22 14:37:17 swdev14 kernel:  [<c029e69c>] cond_resched+0x26/0x78 (4)
Oct 22 14:37:17 swdev14 kernel:  [<c029deab>] preempt_schedule+0x11/0x6f (4)
Oct 22 14:37:17 swdev14 kernel:  [<c01070c3>] dump_stack+0x23/0x27 (4)
Oct 22 14:37:17 swdev14 kernel:  [<c0112038>] mcount+0x14/0x18 (8)
Oct 22 14:37:17 swdev14 kernel:  [<c0132aed>] _mutex_lock+0x43/0x63 (60)
Oct 22 14:37:17 swdev14 kernel:  [<c029e6da>] cond_resched+0x64/0x78 (20)
Oct 22 14:37:17 swdev14 kernel:  [<c0132aed>] _mutex_lock+0x43/0x63 (16)
Oct 22 14:37:17 swdev14 kernel:  [<e0a8b297>] ipxitf_find_using_phys+0x1e/0x4c [ipx] (28)
Oct 22 14:37:17 swdev14 kernel:  [<e0a8d5a6>] ipx_rcv+0xdc/0x1dd [ipx] (20)
Oct 22 14:37:17 swdev14 kernel:  [<c024050b>] snap_rcv+0x5f/0xe0 (32)
Oct 22 14:37:17 swdev14 kernel:  [<c023fadc>] llc_rcv+0x19b/0x2a3 (24)
Oct 22 14:37:17 swdev14 kernel:  [<c02325df>] netif_receive_skb+0x201/0x30c (32)
Oct 22 14:37:17 swdev14 kernel:  [<c0130400>] remove_from_abslist+0x6/0x64 (20)
Oct 22 14:37:17 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (8)
Oct 22 14:37:17 swdev14 kernel:  [<c0232780>] process_backlog+0x96/0x164 (28)
Oct 22 14:37:17 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (40)
Oct 22 14:37:17 swdev14 kernel:  [<c012299c>] ___do_softirq+0xb8/0x107 (40)
Oct 22 14:37:17 swdev14 kernel:  [<c013317c>] __mcount+0x1d/0x21 (12)
Oct 22 14:37:18 swdev14 kernel:  [<c0122a9b>] _do_softirq+0x20/0x22 (36)
Oct 22 14:37:18 swdev14 kernel:  [<c0122f85>] ksoftirqd+0xcd/0x105 (8)
Oct 22 14:37:18 swdev14 kernel:  [<c0132227>] kthread+0xbc/0xc1 (32)
Oct 22 14:37:18 swdev14 kernel:  [<c0122eb8>] ksoftirqd+0x0/0x105 (20)
Oct 22 14:37:18 swdev14 kernel:  [<c013216b>] kthread+0x0/0xc1 (12)
Oct 22 14:37:18 swdev14 kernel:  [<c01043b1>] kernel_thread_helper+0x5/0xb (16)
Oct 22 14:37:18 swdev14 kernel: preempt count: 10000002
Oct 22 14:37:18 swdev14 kernel: . 2-level deep critical section nesting:
Oct 22 14:37:18 swdev14 kernel: .. entry 1: snap_rcv+0x1b/0xe0 [<c023fadc>] / (llc_rcv+0x19b/0x2a3 [<c023fadc>])
Oct 22 14:37:18 swdev14 kernel: .. entry 2: print_traces+0x1d/0x59 [<c01070c3>] / (dump_stack+0x23/0x27 [<c01070c3>])
Oct 22 14:37:18 swdev14 kernel: 
Oct 22 15:22:47 swdev14 modprobe: FATAL: Error running install command for sound_slot_0 
Oct 22 15:22:47 swdev14 modprobe: FATAL: Error running install command for sound_slot_1 
Oct 22 15:22:47 swdev14 modprobe: FATAL: Error running install command for sound_slot_0 
Oct 22 15:22:47 swdev14 modprobe: FATAL: Error running install command for sound_slot_1 
Oct 22 15:22:47 swdev14 modprobe: FATAL: Error running install command for sound_slot_0 
Oct 22 15:22:47 swdev14 modprobe: FATAL: Error running install command for sound_slot_1 
Oct 22 15:22:47 swdev14 modprobe: FATAL: Error running install command for sound_slot_0 
Oct 22 15:22:47 swdev14 last message repeated 2 times
Oct 22 15:25:07 swdev14 su(pam_unix)[15830]: session opened for user root by aaektkf(uid=19990)
Oct 22 15:30:34 swdev14 kernel: BUG: sleeping function called from invalid context ksoftirqd/0(3) at kernel/mutex.c:37
Oct 22 15:30:34 swdev14 kernel: in_atomic():1 [00000001], irqs_disabled():0
Oct 22 15:30:34 swdev14 kernel:  [<c011ac3d>] __might_sleep+0xc4/0xd6 (12)
Oct 22 15:30:34 swdev14 kernel:  [<c0132ae8>] _mutex_lock+0x3e/0x63 (36)
Oct 22 15:30:34 swdev14 kernel:  [<e0a8b297>] ipxitf_find_using_phys+0x1e/0x4c [ipx] (28)
Oct 22 15:30:34 swdev14 kernel:  [<e0a8d5a6>] ipx_rcv+0xdc/0x1dd [ipx] (20)
Oct 22 15:30:34 swdev14 kernel:  [<c024050b>] snap_rcv+0x5f/0xe0 (32)
Oct 22 15:30:34 swdev14 kernel:  [<c023fadc>] llc_rcv+0x19b/0x2a3 (24)
Oct 22 15:30:34 swdev14 kernel:  [<c02325df>] netif_receive_skb+0x201/0x30c (32)
Oct 22 15:30:34 swdev14 kernel:  [<c0130400>] remove_from_abslist+0x6/0x64 (20)
Oct 22 15:30:34 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (8)
Oct 22 15:30:34 swdev14 kernel:  [<c0232780>] process_backlog+0x96/0x164 (28)
Oct 22 15:30:34 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (40)
Oct 22 15:30:34 swdev14 kernel:  [<c012299c>] ___do_softirq+0xb8/0x107 (40)
Oct 22 15:30:34 swdev14 kernel:  [<c013317c>] __mcount+0x1d/0x21 (12)
Oct 22 15:30:34 swdev14 kernel:  [<c0122a9b>] _do_softirq+0x20/0x22 (36)
Oct 22 15:30:34 swdev14 kernel:  [<c0122f85>] ksoftirqd+0xcd/0x105 (8)
Oct 22 15:30:34 swdev14 kernel:  [<c0132227>] kthread+0xbc/0xc1 (32)
Oct 22 15:30:34 swdev14 kernel:  [<c0122eb8>] ksoftirqd+0x0/0x105 (20)
Oct 22 15:30:34 swdev14 kernel:  [<c013216b>] kthread+0x0/0xc1 (12)
Oct 22 15:30:34 swdev14 kernel:  [<c01043b1>] kernel_thread_helper+0x5/0xb (16)
Oct 22 15:30:34 swdev14 kernel: preempt count: 00000002
Oct 22 15:30:34 swdev14 kernel: . 2-level deep critical section nesting:
Oct 22 15:30:34 swdev14 kernel: .. entry 1: snap_rcv+0x1b/0xe0 [<c023fadc>] / (llc_rcv+0x19b/0x2a3 [<c023fadc>])
Oct 22 15:30:34 swdev14 kernel: .. entry 2: print_traces+0x1d/0x59 [<c01070c3>] / (dump_stack+0x23/0x27 [<c01070c3>])
Oct 22 15:30:34 swdev14 kernel: 
Oct 22 15:30:35 swdev14 kernel: BUG: sleeping function called from invalid context ksoftirqd/0(3) at kernel/mutex.c:37
Oct 22 15:30:35 swdev14 kernel: in_atomic():1 [00000001], irqs_disabled():0
Oct 22 15:30:35 swdev14 kernel:  [<c011ac3d>] __might_sleep+0xc4/0xd6 (12)
Oct 22 15:30:35 swdev14 kernel:  [<c0132ae8>] _mutex_lock+0x3e/0x63 (36)
Oct 22 15:30:35 swdev14 kernel:  [<e0a8b297>] ipxitf_find_using_phys+0x1e/0x4c [ipx] (28)
Oct 22 15:30:35 swdev14 kernel:  [<e0a8d5a6>] ipx_rcv+0xdc/0x1dd [ipx] (20)
Oct 22 15:30:35 swdev14 kernel:  [<c024050b>] snap_rcv+0x5f/0xe0 (32)
Oct 22 15:30:35 swdev14 kernel:  [<c023fadc>] llc_rcv+0x19b/0x2a3 (24)
Oct 22 15:30:35 swdev14 kernel:  [<c02325df>] netif_receive_skb+0x201/0x30c (32)
Oct 22 15:30:35 swdev14 kernel:  [<c0130400>] remove_from_abslist+0x6/0x64 (20)
Oct 22 15:30:35 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (8)
Oct 22 15:30:35 swdev14 kernel:  [<c0232780>] process_backlog+0x96/0x164 (28)
Oct 22 15:30:35 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (40)
Oct 22 15:30:35 swdev14 kernel:  [<c012299c>] ___do_softirq+0xb8/0x107 (40)
Oct 22 15:30:35 swdev14 kernel:  [<c013317c>] __mcount+0x1d/0x21 (12)
Oct 22 15:30:35 swdev14 kernel:  [<c0122a9b>] _do_softirq+0x20/0x22 (36)
Oct 22 15:30:35 swdev14 kernel:  [<c0122f85>] ksoftirqd+0xcd/0x105 (8)
Oct 22 15:30:35 swdev14 kernel:  [<c0132227>] kthread+0xbc/0xc1 (32)
Oct 22 15:30:35 swdev14 kernel:  [<c0122eb8>] ksoftirqd+0x0/0x105 (20)
Oct 22 15:30:35 swdev14 kernel:  [<c013216b>] kthread+0x0/0xc1 (12)
Oct 22 15:30:35 swdev14 kernel:  [<c01043b1>] kernel_thread_helper+0x5/0xb (16)
Oct 22 15:30:35 swdev14 kernel: preempt count: 00000002
Oct 22 15:30:35 swdev14 kernel: . 2-level deep critical section nesting:
Oct 22 15:30:35 swdev14 kernel: .. entry 1: snap_rcv+0x1b/0xe0 [<c023fadc>] / (llc_rcv+0x19b/0x2a3 [<c023fadc>])
Oct 22 15:30:35 swdev14 kernel: .. entry 2: print_traces+0x1d/0x59 [<c01070c3>] / (dump_stack+0x23/0x27 [<c01070c3>])
Oct 22 15:30:35 swdev14 kernel: 
Oct 22 15:30:37 swdev14 kernel: BUG: sleeping function called from invalid context ksoftirqd/0(3) at kernel/mutex.c:37
Oct 22 15:30:37 swdev14 kernel: in_atomic():1 [00000001], irqs_disabled():0
Oct 22 15:30:37 swdev14 kernel:  [<c011ac3d>] __might_sleep+0xc4/0xd6 (12)
Oct 22 15:30:37 swdev14 kernel:  [<c0132ae8>] _mutex_lock+0x3e/0x63 (36)
Oct 22 15:30:37 swdev14 kernel:  [<e0a8b297>] ipxitf_find_using_phys+0x1e/0x4c [ipx] (28)
Oct 22 15:30:37 swdev14 kernel:  [<e0a8d5a6>] ipx_rcv+0xdc/0x1dd [ipx] (20)
Oct 22 15:30:37 swdev14 kernel:  [<c024050b>] snap_rcv+0x5f/0xe0 (32)
Oct 22 15:30:37 swdev14 kernel:  [<c023fadc>] llc_rcv+0x19b/0x2a3 (24)
Oct 22 15:30:37 swdev14 kernel:  [<c02325df>] netif_receive_skb+0x201/0x30c (32)
Oct 22 15:30:37 swdev14 kernel:  [<c0130400>] remove_from_abslist+0x6/0x64 (20)
Oct 22 15:30:37 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (8)
Oct 22 15:30:37 swdev14 kernel:  [<c0232780>] process_backlog+0x96/0x164 (28)
Oct 22 15:30:37 swdev14 kernel:  [<c02328ef>] net_rx_action+0xa1/0x178 (40)
Oct 22 15:30:37 swdev14 kernel:  [<c012299c>] ___do_softirq+0xb8/0x107 (40)
Oct 22 15:30:37 swdev14 kernel:  [<c013317c>] __mcount+0x1d/0x21 (12)
Oct 22 15:30:37 swdev14 kernel:  [<c0122a9b>] _do_softirq+0x20/0x22 (36)
Oct 22 15:30:37 swdev14 kernel:  [<c0122f85>] ksoftirqd+0xcd/0x105 (8)
Oct 22 15:30:37 swdev14 kernel:  [<c0132227>] kthread+0xbc/0xc1 (32)
Oct 22 15:30:37 swdev14 kernel:  [<c0122eb8>] ksoftirqd+0x0/0x105 (20)
Oct 22 15:30:37 swdev14 kernel:  [<c013216b>] kthread+0x0/0xc1 (12)
Oct 22 15:30:37 swdev14 kernel:  [<c01043b1>] kernel_thread_helper+0x5/0xb (16)
Oct 22 15:30:37 swdev14 kernel: preempt count: 00000002
Oct 22 15:30:37 swdev14 kernel: . 2-level deep critical section nesting:
Oct 22 15:30:37 swdev14 kernel: .. entry 1: snap_rcv+0x1b/0xe0 [<c023fadc>] / (llc_rcv+0x19b/0x2a3 [<c023fadc>])
Oct 22 15:30:37 swdev14 kernel: .. entry 2: print_traces+0x1d/0x59 [<c01070c3>] / (dump_stack+0x23/0x27 [<c01070c3>])
Oct 22 15:30:37 swdev14 kernel: 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7
  2004-10-19 19:57                           ` Bill Huey
@ 2004-10-23  0:05                             ` Lee Revell
  0 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-23  0:05 UTC (permalink / raw)
  To: Bill Huey
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano

On Tue, 2004-10-19 at 12:57 -0700, Bill Huey wrote:
> On Tue, Oct 19, 2004 at 08:00:59PM +0200, Ingo Molnar wrote:
> > 
> > i have released the -U7 Real-Time Preemption patch:
> > 
> >   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-rc4-mm1-U7
> 
> You should seriously think about using a kind of bitkeeper or CVS stle
> system so that multipule folks can dump stuff into it rapidly. This
> project is large enough that it needs some kind of facility like that.

We also might want to consider a separate mailing list, if the volume of
mail gets unwieldy, then just post release announcements to LKML.  The
volume is high enough and some of the terminology different enough that
we already had one inadvertent bout of flaming over some unfortunate
miscommunication.  As more people get involved this could get out of
hand.  The cc: lists are getting pretty long, and a lot of the testing
requires posting huge traces.  Think about how many copies of each mail
vger has to deliver...

Anyway, I am fine with continuing on LKML, it would really depend on how
Ingo and especially the people for whom this is all noise feel about it.

Lee 







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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-22 17:56                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Ingo Molnar
  2004-10-22 21:49                                     ` Gene Heskett
  2004-10-22 22:38                                     ` K.R. Foley
@ 2004-10-23  0:27                                     ` Rui Nuno Capela
  2004-10-23  0:41                                       ` Fernando Pablo Lopez-Lezcano
  2004-10-23 10:29                                       ` Ingo Molnar
  2004-10-23  1:15                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.3 Thomas Gleixner
                                                       ` (3 subsequent siblings)
  6 siblings, 2 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-23  0:27 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Alexander Batyrshin

Ingo Molnar wrote:
>
> i have released the -U10.2 Real-Time Preemption patch, which can be
> downloaded from:
>
>   http://redhat.com/~mingo/realtime-preempt/
>

Regarding the jackd -R issue, I was trying to capture some debug data via
netconsole on my laptop (P4/UP) running RT-U10.2, and when the system
freezes as reported before, I was able to kick the SysRq+T. But, instead
of a task trace list, I get the following:

SysRq : <3>BUG: sleeping function called from invalid context IRQ 1(776)
at kernel/mutex.c:37
in_atomic():1 [00000001], irqs_disabled():1
 [<c0104ee4>] dump_stack+0x1e/0x20 (20)
 [<c0114a23>] __might_sleep+0xb2/0xc7 (36)
 [<c012c0f2>] _mutex_lock+0x39/0x5e (28)
 [<c012c13a>] _mutex_lock_irqsave+0x11/0x15 (12)
 [<c027f927>] refill_skbs+0x13/0x6d (20)
 [<c027fa4c>] find_skb+0x5d/0x9d (24)
 [<c027fb74>] netpoll_send_udp+0x3b/0x298 (48)
 [<e00ef047>] write_msg+0x47/0x5c [netconsole] (36)
 [<c0117804>] __call_console_drivers+0x51/0x60 (32)
 [<c0117910>] call_console_drivers+0x6d/0x147 (40)
 [<c0117caf>] release_console_sem+0x48/0x100 (36)
 [<c0117bd5>] vprintk+0x127/0x174 (36)
 [<c0117aac>] printk+0x18/0x1a (16)
 [<c01f4849>] __handle_sysrq+0x38/0xed (40)
 [<c01ee426>] kbd_event+0xeb/0xfa (40)
 [<c025f6a8>] input_event+0x160/0x3d4 (44)
 [<c02620b6>] atkbd_report_key+0x3b/0x95 (32)
 [<c026236c>] atkbd_interrupt+0x25c/0x590 (60)
 [<c01f6fd2>] serio_interrupt+0x4f/0xa5 (44)
 [<c01f78cb>] i8042_interrupt+0xb8/0x1b8 (40)
 [<c0131dbc>] handle_IRQ_event+0x48/0x79 (32)
 [<c01325dd>] do_hardirq+0x86/0x123 (40)
 [<c0132712>] do_irqd+0x98/0xc9 (36)
 [<c012b7d7>] kthread+0x9c/0xc9 (48)
 [<c0102305>] kernel_thread_helper+0x5/0xb (548454420)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __sysrq_lock_table+0x12/0x14 [<c01f482b>] /
(__handle_sysrq+0x1a/0xed [<c01f482b>])
.. entry 2: print_traces+0x16/0x48 [<c0104ee4>] / (dump_stack+0x1e/0x20
[<c0104ee4>])

Other SysRq key combinations dumps similar.

Any suggestions?
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23  0:27                                     ` Rui Nuno Capela
@ 2004-10-23  0:41                                       ` Fernando Pablo Lopez-Lezcano
  2004-10-23 10:29                                       ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Fernando Pablo Lopez-Lezcano @ 2004-10-23  0:41 UTC (permalink / raw)
  To: Ingo Molnar, Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Alexander Batyrshin

On Fri, 2004-10-22 at 17:27, Rui Nuno Capela wrote:
> Ingo Molnar wrote:
> >> i have released the -U10.2 Real-Time Preemption patch, which can be
> > downloaded from:
> >
> >   http://redhat.com/~mingo/realtime-preempt/
>
> Regarding the jackd -R issue, I was trying to capture some debug data via
> netconsole on my laptop (P4/UP) running RT-U10.2

Just starting to test U10.3. So far no freezes but I do see problems
with Jack kicking out Hydrogen from the graph and some xruns. 

I see this on boot (athlon64 system):

ACPI: PCI interrupt 0000:00:0e.0[A] -> GSI 19 (level, low) -> IRQ 19
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] 
MMIO=[cfffe000-cfffe7ff]  Max Packet=[2048]
ohci1394 0000:00:0e.0: Device was removed without properly calling
pci_disable_device(). This may need fixing.
r8169 Gigabit Ethernet driver 1.6LK loaded
ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 16 (level, low) -> IRQ 16
divert: allocating divert_blk for eth0
eth0: Identified chip type is 'RTL8169s/8110s'.
eth0: RTL8169 at 0xf88c8f00, 00:0c:76:b3:c2:43, IRQ 16
BUG: atomic counter underflow at:
 [<c02b99a1>] qdisc_destroy+0x91/0xa0 (8)
 [<c02b9b6f>] dev_shutdown+0x2f/0x90 (12)
 [<c030dfc7>] cond_resched+0x17/0x70 (8)
 [<c02acea5>] unregister_netdevice+0x125/0x250 (16)
 [<c030e6b2>] down_write+0xa2/0x1e0 (12)
 [<c01cd87a>] __up_write+0x11a/0x200 (4)
 [<c02476cf>] unregister_netdev+0xf/0x20 (16)
 [<f8b0163d>] rtl8169_remove_one+0x1d/0x50 [r8169] (8)
 [<c01d6c08>] pci_device_remove+0x68/0x70 (16)
 [<c0235cb6>] device_release_driver+0x56/0x60 (20)
 [<c0235cd8>] driver_detach+0x18/0x30 (12)
 [<c02360d9>] bus_remove_driver+0x29/0x50 (12)
 [<c02364eb>] driver_unregister+0xb/0x20 (8)
 [<c01d6e3b>] pci_unregister_driver+0xb/0x20 (8)
 [<c0137795>] sys_delete_module+0x105/0x130 (8)
 [<c0106019>] sysenter_past_esp+0x52/0x71 (80)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0xd/0x40 [<00000000>] / (0x0 [<00000000>])

divert: freeing divert_blk for eth0
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack version 2.1 (8192 buckets, 65536 max) - 300 bytes per
conntrack
r8169 Gigabit Ethernet driver 1.6LK loaded
ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 16 (level, low) -> IRQ 16
divert: allocating divert_blk for eth0
eth0: Identified chip type is 'RTL8169s/8110s'.
eth0: RTL8169 at 0xf8af4f00, 00:0c:76:b3:c2:43, IRQ 16
IRQ#16 thread RT prio: 49.
r8169: eth0: link up

-- Fernando



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.3
  2004-10-22 17:56                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Ingo Molnar
                                                       ` (2 preceding siblings ...)
  2004-10-23  0:27                                     ` Rui Nuno Capela
@ 2004-10-23  1:15                                     ` Thomas Gleixner
  2004-10-23 18:51                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Paul E. McKenney
                                                       ` (2 subsequent siblings)
  6 siblings, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-23  1:15 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: LKML, Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Alexander Batyrshin

On Fri, 2004-10-22 at 19:56 +0200, Ingo Molnar wrote:
> i have released the -U10.2 Real-Time Preemption patch, which can be
> downloaded from:
> 
>   http://redhat.com/~mingo/realtime-preempt/

The current version is -U10.3

Find below a patch against -U10.3. It contains a couple of smaller fixes
including the network driver bootup BUG.

<Dislaimer>
I'm trying to start a serious discussion on that. It's not my intention
to start a flamewar. 
</Disclaimer>

The network driver load/unload problem, which was reported from a couple
of testers, is related to Ingo's check inside of atomic_dec_and_test().

        if (!atomic_read(v)) {
                printk("BUG: atomic counter underflow at:\n");
                dump_stack();
        }

The unmodified atomic_dec_and_test() returns 0 in all cases except for
the case when the counter is 0 after the decrement. This implementation
covers automatically the case, where atomic_dec_and_test() is called
with counter == 0.

The network code uses atomic_dec_and_test() in qdisk_destroy to check,
if the caller owns the last reference to the qdisc. This covers also the
case when no reference is there when this is called. I fixed this for
now with a check for 0 before calling qdisk_destroy().

Thats a fix, but not an answer to the following question.

The question is whether the atomic implementation is intended to allow
counter values less than 0 or not. Reviewing the usage it seems not to
be the case. The qdisc_destroy code is the only place I recognized so
far, which makes use of that implementation detail.

>From my point of view is allowing such usage covering a hidden problem. 

Assume count = 0, call atomic_dec_test() and you have count = -1. 
At a differemt places the check is if (!atomic_read(v)){...}
If count = -1 it signals, that data or whatever is available.  

I don't think there is code which is actually failing on that, but as a
design rule it might turn out that Ingo's check and the implied rule
"count must be >= 0" is appropriate.

tglx
---

diff --exclude='*~' -urN 2.6.9-mm1-U10.3/drivers/net/8139too.c
2.6.9-mm1-U10.work/drivers/net/8139too.c
--- 2.6.9-mm1-U10.3/drivers/net/8139too.c	2004-10-23 01:59:14.000000000
+0200
+++ 2.6.9-mm1-U10.work/drivers/net/8139too.c	2004-10-22
23:18:32.000000000 +0200
@@ -749,7 +749,7 @@
 	pci_release_regions (pdev);
 
 	free_netdev(dev);
-
+	pci_disable_device (pdev);
 	pci_set_drvdata (pdev, NULL);
 }
 
diff --exclude='*~' -urN
2.6.9-mm1-U10.3/drivers/pci/hotplug/cpci_hotplug_core.c
2.6.9-mm1-U10.work/drivers/pci/hotplug/cpci_hotplug_core.c
--- 2.6.9-mm1-U10.3/drivers/pci/hotplug/cpci_hotplug_core.c	2004-10-23
01:59:15.000000000 +0200
+++ 2.6.9-mm1-U10.work/drivers/pci/hotplug/cpci_hotplug_core.c
2004-10-22 19:06:47.000000000 +0200
@@ -598,7 +598,7 @@
 		msleep(100);
 	}
 	dbg("poll thread signals exit");
-	up(&thread_exit);
+	complete(&thread_exit);
 	return 0;
 }
 
diff --exclude='*~' -urN 2.6.9-mm1-U10.3/net/sched/sch_generic.c
2.6.9-mm1-U10.work/net/sched/sch_generic.c
--- 2.6.9-mm1-U10.3/net/sched/sch_generic.c	2004-10-23
01:59:12.000000000 +0200
+++ 2.6.9-mm1-U10.work/net/sched/sch_generic.c	2004-10-23
02:45:58.000000000 +0200
@@ -584,7 +584,9 @@
 	qdisc = dev->qdisc_sleeping;
 	dev->qdisc = &noop_qdisc;
 	dev->qdisc_sleeping = &noop_qdisc;
-	qdisc_destroy(qdisc);
+
+	if (atomic_read(&qdisc->refcnt))
+		qdisc_destroy(qdisc);
 #if defined(CONFIG_NET_SCH_INGRESS) ||
defined(CONFIG_NET_SCH_INGRESS_MODULE)
         if ((qdisc = dev->qdisc_ingress) != NULL) {
 		dev->qdisc_ingress = NULL;
diff --exclude='*~' -urN 2.6.9-mm1-U10.3/drivers/pcmcia/yenta_socket.c
2.6.9-mm1-U10.work/drivers/pcmcia/yenta_socket.c
--- 2.6.9-mm1-U10.3/drivers/pcmcia/yenta_socket.c	2004-10-22
16:52:26.000000000 +0200
+++ 2.6.9-mm1-U10.work/drivers/pcmcia/yenta_socket.c	2004-10-22
21:26:15.000000000 +0200
@@ -653,6 +653,7 @@
 	yenta_free_resources(sock);
 
 	pci_release_regions(dev);
+	pci_disable_device(dev);
 	pci_set_drvdata(dev, NULL);
 }
 


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23  0:27                                     ` Rui Nuno Capela
  2004-10-23  0:41                                       ` Fernando Pablo Lopez-Lezcano
@ 2004-10-23 10:29                                       ` Ingo Molnar
  2004-10-23 12:30                                         ` Rui Nuno Capela
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-23 10:29 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Alexander Batyrshin


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> Regarding the jackd -R issue, I was trying to capture some debug data
> via netconsole on my laptop (P4/UP) running RT-U10.2, and when the
> system freezes as reported before, I was able to kick the SysRq+T.
> But, instead of a task trace list, I get the following:
> 
> SysRq : <3>BUG: sleeping function called from invalid context IRQ 1(776)
> at kernel/mutex.c:37
> in_atomic():1 [00000001], irqs_disabled():1
>  [<c0104ee4>] dump_stack+0x1e/0x20 (20)
>  [<c0114a23>] __might_sleep+0xb2/0xc7 (36)
>  [<c012c0f2>] _mutex_lock+0x39/0x5e (28)

> preempt count: 00000002
> . 2-level deep critical section nesting:
> .. entry 1: __sysrq_lock_table+0x12/0x14 [<c01f482b>] /
> (__handle_sysrq+0x1a/0xed [<c01f482b>])
> .. entry 2: print_traces+0x16/0x48 [<c0104ee4>] / (dump_stack+0x1e/0x20

does the patch below help?

	Ingo

--- linux/drivers/char/sysrq.c.orig
+++ linux/drivers/char/sysrq.c
@@ -252,7 +252,7 @@ static struct sysrq_key_op sysrq_kill_op
 
 
 /* Key Operations table and lock */
-static DECLARE_RAW_SPINLOCK(sysrq_key_table_lock);
+static DECLARE_SPINLOCK(sysrq_key_table_lock);
 #define SYSRQ_KEY_TABLE_LENGTH 36
 static struct sysrq_key_op *sysrq_key_table[SYSRQ_KEY_TABLE_LENGTH] = {
 /* 0 */	&sysrq_loglevel_op,

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-22 22:38                                     ` K.R. Foley
@ 2004-10-23 10:32                                       ` Ingo Molnar
  2004-10-23 14:03                                         ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-23 10:32 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> Oct 22 14:37:14 swdev14 kernel: BUG: sleeping function called from invalid context ksoftirqd/0(3) at kernel/mutex.c:37
> Oct 22 14:37:14 swdev14 kernel: in_atomic():1 [00000001], irqs_disabled():0
> Oct 22 14:37:14 swdev14 kernel:  [<c011ac3d>] __might_sleep+0xc4/0xd6 (12)
> Oct 22 14:37:14 swdev14 kernel:  [<c0132ae8>] _mutex_lock+0x3e/0x63 (36)
> Oct 22 14:37:14 swdev14 kernel:  [<e0a8b297>] ipxitf_find_using_phys+0x1e/0x4c [ipx] (28)
> Oct 22 14:37:14 swdev14 kernel:  [<e0a8d5a6>] ipx_rcv+0xdc/0x1dd [ipx] (20)
> Oct 22 14:37:14 swdev14 kernel:  [<c024050b>] snap_rcv+0x5f/0xe0 (32)

does the patch below fix these?

	Ingo

--- linux/net/802/psnap.c.orig
+++ linux/net/802/psnap.c
@@ -55,7 +55,7 @@ static int snap_rcv(struct sk_buff *skb,
 		.type = __constant_htons(ETH_P_SNAP),
 	};
 
-	rcu_read_lock();
+	rcu_read_lock_spin(&snap_lock);
 	proto = find_snap_client(skb->h.raw);
 	if (proto) {
 		/* Pass the frame on. */
@@ -68,7 +68,7 @@ static int snap_rcv(struct sk_buff *skb,
 		rc = 1;
 	}
 
-	rcu_read_unlock();
+	rcu_read_unlock_spin(&snap_lock);
 	return rc;
 }
 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-22 22:06                                       ` Lee Revell
  2004-10-22 22:30                                         ` Lee Revell
@ 2004-10-23 10:36                                         ` Ingo Molnar
  2004-10-25  0:33                                           ` john cooper
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-23 10:36 UTC (permalink / raw)
  To: Lee Revell
  Cc: gene.heskett, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


* Lee Revell <rlrevell@joe-job.com> wrote:

> On Fri, 2004-10-22 at 17:49 -0400, Gene Heskett wrote:
> > Mmm, I get a 404 page not found. when I click on  on thsi link.
> 
> Same here.  The current version is 10.3:
> 
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-U10.3
> 
> I did not get an announcement, it looks like the listserv is
> backlogged, or Ingo did not announce it yet.

had to do it in the last minute and didnt have time to announce it. 
-RT-U10.3 fixes a UP compilation error reported by John Gilbert.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23 10:29                                       ` Ingo Molnar
@ 2004-10-23 12:30                                         ` Rui Nuno Capela
  2004-10-23 12:51                                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-23 12:30 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Alexander Batyrshin

Ingo Molnar wrote:
>
> Rui Nuno Capela wrote:
>
>> Regarding the jackd -R issue, I was trying to capture some debug data
>> via netconsole on my laptop (P4/UP) running RT-U10.2, and when the
>> system freezes as reported before, I was able to kick the SysRq+T.
>> But, instead of a task trace list, I get the following:
>>
>> SysRq : <3>BUG: sleeping function called from invalid context IRQ 1(776)
>> at kernel/mutex.c:37
>> in_atomic():1 [00000001], irqs_disabled():1
>>  [<c0104ee4>] dump_stack+0x1e/0x20 (20)
>>  [<c0114a23>] __might_sleep+0xb2/0xc7 (36)
>>  [<c012c0f2>] _mutex_lock+0x39/0x5e (28)
>
>> preempt count: 00000002
>> . 2-level deep critical section nesting:
>> .. entry 1: __sysrq_lock_table+0x12/0x14 [<c01f482b>] /
>> (__handle_sysrq+0x1a/0xed [<c01f482b>])
>> .. entry 2: print_traces+0x16/0x48 [<c0104ee4>] / (dump_stack+0x1e/0x20
>
> does the patch below help?
>
> 	Ingo
>
> --- linux/drivers/char/sysrq.c.orig
> +++ linux/drivers/char/sysrq.c
> @@ -252,7 +252,7 @@ static struct sysrq_key_op sysrq_kill_op
>
>
>  /* Key Operations table and lock */
> -static DECLARE_RAW_SPINLOCK(sysrq_key_table_lock);
> +static DECLARE_SPINLOCK(sysrq_key_table_lock);
>  #define SYSRQ_KEY_TABLE_LENGTH 36
>  static struct sysrq_key_op *sysrq_key_table[SYSRQ_KEY_TABLE_LENGTH] = {
>  /* 0 */	&sysrq_loglevel_op,
>

Nope. Same result:

SysRq : <3>BUG: sleeping function called from invalid context IRQ 1(776)
at kernel/mutex.c:37
in_atomic():0 [00000000], irqs_disabled():1
 [<c0104ee4>] dump_stack+0x1e/0x20 (20)
 [<c0114a23>] __might_sleep+0xb2/0xc7 (36)
 [<c012c0f2>] _mutex_lock+0x39/0x5e (28)
 [<c012c13a>] _mutex_lock_irqsave+0x11/0x15 (12)
 [<c027f913>] refill_skbs+0x13/0x6d (20)
 [<c027fa38>] find_skb+0x5d/0x9d (24)
 [<c027fb60>] netpoll_send_udp+0x3b/0x298 (48)
 [<e0136047>] write_msg+0x47/0x5c [netconsole] (36)
 [<c0117804>] __call_console_drivers+0x51/0x60 (32)
 [<c0117910>] call_console_drivers+0x6d/0x147 (40)
 [<c0117caf>] release_console_sem+0x48/0x100 (36)
 [<c0117bd5>] vprintk+0x127/0x174 (36)
 [<c0117aac>] printk+0x18/0x1a (16)
 [<c01f4835>] __handle_sysrq+0x38/0xed (40)
 [<c01ee426>] kbd_event+0xeb/0xfa (40)
 [<c025f694>] input_event+0x160/0x3d4 (44)
 [<c02620a2>] atkbd_report_key+0x3b/0x95 (32)
 [<c0262358>] atkbd_interrupt+0x25c/0x590 (60)
 [<c01f6fbe>] serio_interrupt+0x4f/0xa5 (44)
 [<c01f78b7>] i8042_interrupt+0xb8/0x1b8 (40)
 [<c0131dbc>] handle_IRQ_event+0x48/0x79 (32)
 [<c01325dd>] do_hardirq+0x86/0x123 (40)
 [<c0132712>] do_irqd+0x98/0xc9 (36)
 [<c012b7d7>] kthread+0x9c/0xc9 (48)
 [<c0102305>] kernel_thread_helper+0x5/0xb (548454420)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x16/0x48 [<c0104ee4>] / (dump_stack+0x1e/0x20
[<c0104ee4>])


Bye.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23 12:30                                         ` Rui Nuno Capela
@ 2004-10-23 12:51                                           ` Ingo Molnar
  2004-10-23 13:45                                             ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-23 12:51 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Alexander Batyrshin


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> > does the patch below help?

> Nope. Same result:

> SysRq : <3>BUG: sleeping function called from invalid context IRQ 1(776)
> at kernel/mutex.c:37
> in_atomic():0 [00000000], irqs_disabled():1

interrupts are disabled. You used a -RT-U10.2/3 kernel, and have 
CONFIG_REALTIME enabled, right? Do you have this in 
drivers/net/netconsole.c, line 77:

 #ifdef PREEMPT_REALTIME
         /*
          * A bit hairy. Netconsole uses mutexes (indirectly) and
          * thus must have interrupts enabled:
          */
         local_irq_enable();
 #endif

correct? Could you do this a few lines below:

                WARN_ON_RT(irqs_disabled());
                netpoll_send_udp(&np, msg, frag);
                WARN_ON_RT(irqs_disabled());

to figure out who disables interrupts. Also, could you add the same two
lines to net/core/netpoll.c, line 83:

        WARN_ON_RT(irqs_disabled());
        np->dev->poll_controller(np->dev);
        WARN_ON_RT(irqs_disabled());

and send me either the full bootlog, or the _first_ such BUG message
you'll be getting. Which network controller is this?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23 12:51                                           ` Ingo Molnar
@ 2004-10-23 13:45                                             ` Rui Nuno Capela
  2004-10-23 13:54                                               ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-23 13:45 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Alexander Batyrshin

Ingo Molnar wrote:
>
> Rui Nuno Capela wrote:
>
>> > does the patch below help?
>
>> Nope. Same result:
>
>> SysRq : <3>BUG: sleeping function called from invalid context IRQ 1(776)
>> at kernel/mutex.c:37
>> in_atomic():0 [00000000], irqs_disabled():1
>
> interrupts are disabled. You used a -RT-U10.2/3 kernel, and have
> CONFIG_REALTIME enabled, right? Do you have this in
> drivers/net/netconsole.c, line 77:
>
>  #ifdef PREEMPT_REALTIME
>          /*
>           * A bit hairy. Netconsole uses mutexes (indirectly) and
>           * thus must have interrupts enabled:
>           */
>          local_irq_enable();
>  #endif
>
> correct? Could you do this a few lines below:
>
>                 WARN_ON_RT(irqs_disabled());
>                 netpoll_send_udp(&np, msg, frag);
>                 WARN_ON_RT(irqs_disabled());
>
> to figure out who disables interrupts. Also, could you add the same two
> lines to net/core/netpoll.c, line 83:
>
>         WARN_ON_RT(irqs_disabled());
>         np->dev->poll_controller(np->dev);
>         WARN_ON_RT(irqs_disabled());
>
> and send me either the full bootlog, or the _first_ such BUG message
> you'll be getting. Which network controller is this?
>

OK. All affirmative. NIC is natsemi.

Here it is:

SysRq : IRQ 1/776: BUG in write_msg at drivers/net/netconsole.c:87
 [<c0104ee4>] dump_stack+0x1e/0x20 (20)
 [<e00ef0ab>] write_msg+0xab/0xf4 [netconsole] (52)
 [<c0117804>] __call_console_drivers+0x51/0x60 (32)
 [<c0117910>] call_console_drivers+0x6d/0x147 (40)
 [<c0117caf>] release_console_sem+0x48/0x100 (36)
 [<c0117bd5>] vprintk+0x127/0x174 (36)
 [<c0117aac>] printk+0x18/0x1a (16)
 [<c01f4835>] __handle_sysrq+0x38/0xed (40)
 [<c01ee426>] kbd_event+0xeb/0xfa (40)
 [<c025f694>] input_event+0x160/0x3d4 (44)
 [<c02620a2>] atkbd_report_key+0x3b/0x95 (32)
 [<c0262358>] atkbd_interrupt+0x25c/0x590 (60)
 [<c01f6fbe>] serio_interrupt+0x4f/0xa5 (44)
 [<c01f78b7>] i8042_interrupt+0xb8/0x1b8 (40)
 [<c0131dbc>] handle_IRQ_event+0x48/0x79 (32)
 [<c01325dd>] do_hardirq+0x86/0x123 (40)
 [<c0132712>] do_irqd+0x98/0xc9 (36)
 [<c012b7d7>] kthread+0x9c/0xc9 (48)
 [<c0102305>] kernel_thread_helper+0x5/0xb (548454420)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x16/0x48 [<c0104ee4>] / (dump_stack+0x1e/0x20
[<c0104ee4>])

BUG: sleeping function called from invalid context IRQ 1(776) at
kernel/mutex.c:37
in_atomic():0 [00000000], irqs_disabled():1
 [<c0104ee4>] dump_stack+0x1e/0x20 (20)
 [<c0114a23>] __might_sleep+0xb2/0xc7 (36)
 [<c012c0f2>] _mutex_lock+0x39/0x5e (28)
 [<c012c13a>] _mutex_lock_irqsave+0x11/0x15 (12)
 [<c027f9bc>] refill_skbs+0x13/0x6d (20)
 [<c027fae1>] find_skb+0x5d/0x9d (24)
 [<c027fc09>] netpoll_send_udp+0x3b/0x298 (48)
 [<e00ef050>] write_msg+0x50/0xf4 [netconsole] (52)
 [<c0117804>] __call_console_drivers+0x51/0x60 (32)
 [<c0117910>] call_console_drivers+0x6d/0x147 (40)
 [<c0117caf>] release_console_sem+0x48/0x100 (36)
 [<c0117bd5>] vprintk+0x127/0x174 (36)
 [<c0117aac>] printk+0x18/0x1a (16)
 [<c01f4835>] __handle_sysrq+0x38/0xed (40)
 [<c01ee426>] kbd_event+0xeb/0xfa (40)
 [<c025f694>] input_event+0x160/0x3d4 (44)
 [<c02620a2>] atkbd_report_key+0x3b/0x95 (32)
 [<c0262358>] atkbd_interrupt+0x25c/0x590 (60)
 [<c01f6fbe>] serio_interrupt+0x4f/0xa5 (44)
 [<c01f78b7>] i8042_interrupt+0xb8/0x1b8 (40)
 [<c0131dbc>] handle_IRQ_event+0x48/0x79 (32)
 [<c01325dd>] do_hardirq+0x86/0x123 (40)
 [<c0132712>] do_irqd+0x98/0xc9 (36)
 [<c012b7d7>] kthread+0x9c/0xc9 (48)
 [<c0102305>] kernel_thread_helper+0x5/0xb (548454420)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x16/0x48 [<c0104ee4>] / (dump_stack+0x1e/0x20
[<c0104ee4>])


Bye.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23 13:45                                             ` Rui Nuno Capela
@ 2004-10-23 13:54                                               ` Ingo Molnar
  2004-10-23 20:59                                                 ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-23 13:54 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Alexander Batyrshin


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> OK. All affirmative. NIC is natsemi.
> 
> Here it is:
> 
> SysRq : IRQ 1/776: BUG in write_msg at drivers/net/netconsole.c:87

doh! Go to line 77 and spot the bug. (yes, the PREEMPT_REALTIME needs to
become CONFIG_PREEMPT_REALTIME) With that fixed does it work for you?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23 10:32                                       ` Ingo Molnar
@ 2004-10-23 14:03                                         ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-23 14:03 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>Oct 22 14:37:14 swdev14 kernel: BUG: sleeping function called from invalid context ksoftirqd/0(3) at kernel/mutex.c:37
>>Oct 22 14:37:14 swdev14 kernel: in_atomic():1 [00000001], irqs_disabled():0
>>Oct 22 14:37:14 swdev14 kernel:  [<c011ac3d>] __might_sleep+0xc4/0xd6 (12)
>>Oct 22 14:37:14 swdev14 kernel:  [<c0132ae8>] _mutex_lock+0x3e/0x63 (36)
>>Oct 22 14:37:14 swdev14 kernel:  [<e0a8b297>] ipxitf_find_using_phys+0x1e/0x4c [ipx] (28)
>>Oct 22 14:37:14 swdev14 kernel:  [<e0a8d5a6>] ipx_rcv+0xdc/0x1dd [ipx] (20)
>>Oct 22 14:37:14 swdev14 kernel:  [<c024050b>] snap_rcv+0x5f/0xe0 (32)
> 
> 
> does the patch below fix these?
> 
> 	Ingo
> 

I will try reproducing it here (at home). Otherwise it'll have to wait 
till Monday.

> --- linux/net/802/psnap.c.orig
> +++ linux/net/802/psnap.c
> @@ -55,7 +55,7 @@ static int snap_rcv(struct sk_buff *skb,
>  		.type = __constant_htons(ETH_P_SNAP),
>  	};
>  
> -	rcu_read_lock();
> +	rcu_read_lock_spin(&snap_lock);
>  	proto = find_snap_client(skb->h.raw);
>  	if (proto) {
>  		/* Pass the frame on. */
> @@ -68,7 +68,7 @@ static int snap_rcv(struct sk_buff *skb,
>  		rc = 1;
>  	}
>  
> -	rcu_read_unlock();
> +	rcu_read_unlock_spin(&snap_lock);
>  	return rc;
>  }
>  
> 


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-22 17:56                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Ingo Molnar
                                                       ` (3 preceding siblings ...)
  2004-10-23  1:15                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.3 Thomas Gleixner
@ 2004-10-23 18:51                                     ` Paul E. McKenney
  2004-10-23 19:14                                       ` Lee Revell
  2004-10-23 20:24                                       ` Ingo Molnar
  2004-10-24 15:19                                     ` Gunther Persoons
  2004-10-25 10:40                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0 Ingo Molnar
  6 siblings, 2 replies; 951+ messages in thread
From: Paul E. McKenney @ 2004-10-23 18:51 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Fri, Oct 22, 2004 at 07:56:33PM +0200, Ingo Molnar wrote:
> 
> i have released the -U10.2 Real-Time Preemption patch, which can be
> downloaded from:
> 
>   http://redhat.com/~mingo/realtime-preempt/

On realtime-preempt-2.6.9-mm1-U10.3:

o	In rcupdate.h, I believe that the:

	+# define rcu_read_unlock_nort()                rcu_read_lock_nort()

	should instead be:

	+# define rcu_read_unlock_nort()                rcu_read_unlock()

	It looks to me like the current definition would cause
	preemption to be permanently disabled in a kernel with
	CONFIG_PREEMPT but without CONFIG_PREEMPT_REALTIME,
	at least if one used SysV IPC.

o	The rcu_read_lock_spin(), rcu_read_lock_read(),
	rcu_read_lock_bh_read(), rcu_read_lock_sem(), and
	rcu_read_lock_bh_spin() APIs cannot be called recursively.
	But you probably already knew that.  ;-)

	I don't understand why the rcu_read_lock_sem() API gets its
	own #ifdef.

o	Some recent RCU patches acquire the update-side lock
	under rcu_read_lock(), which I believe will deadlock here.
	Since the same CPU/task is acquiring the same lock twice, I don't
	believe that the mutex mods help, but could easily be mistaken.
	Then again, this may well be why there are all the emails on
	this thread advising that SELinux be disabled.

							Thanx, Paul

> this is a fixes-only release.
> 
> Changes since -U10:
> 
>  - fixed a big bug present ever since: the BKL got dropped when a
>    spinlock-mutex was acquired and it scheduled away. This reduced the
>    locking efficiency of the BKL. A number of outstanding problems could
>    be affected, in particular this should fix the tty locking breakage
>    reported by Alexander Batyrshin and Adam Heath. UP and SMP systems 
>    are affected too, with SMP systems having a higher chance to trigger
>    this condition.
> 
>  - tulip.c breakage fix from Thomas Gleixner
> 
>  - tg3 and 3c59x fixes.
> 
>  - made the hardirq threads SCHED_FIFO by default. They get priorities 
>    between 25 and 50, depending on the irq #. (this is pretty random but 
>    i found no better scheme.) Made the softirq thread SCHED_FIFO by 
>    default as well, albeit this probably will have to change. These 
>    changes should make it easier to debug a hung system.
> 
> to create a -U10.2 tree from scratch, the patching order is:
> 
>    http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
>  + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/2.6.9-mm1.bz2
>  + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-U10.2
> 
> 	Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23 18:51                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Paul E. McKenney
@ 2004-10-23 19:14                                       ` Lee Revell
  2004-10-23 19:31                                         ` Thomas Gleixner
  2004-10-23 20:24                                       ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-23 19:14 UTC (permalink / raw)
  To: paulmck
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Sat, 2004-10-23 at 11:51 -0700, Paul E. McKenney wrote:
> On Fri, Oct 22, 2004 at 07:56:33PM +0200, Ingo Molnar wrote:
> > 
> > i have released the -U10.2 Real-Time Preemption patch, which can be
> > downloaded from:
> > 
> >   http://redhat.com/~mingo/realtime-preempt/
> 
> On realtime-preempt-2.6.9-mm1-U10.3:
> 
> o	In rcupdate.h, I believe that the:
> 
> 	+# define rcu_read_unlock_nort()                rcu_read_lock_nort()
> 
> 	should instead be:
> 
> 	+# define rcu_read_unlock_nort()                rcu_read_unlock()
> 

Oh no!  That would explain a lot... the typical report is it works fine
until people go to use the network :-P

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23 19:14                                       ` Lee Revell
@ 2004-10-23 19:31                                         ` Thomas Gleixner
  0 siblings, 0 replies; 951+ messages in thread
From: Thomas Gleixner @ 2004-10-23 19:31 UTC (permalink / raw)
  To: Lee Revell
  Cc: paulmck, Ingo Molnar, LKML, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Sat, 2004-10-23 at 15:14 -0400, Lee Revell wrote:
> On Sat, 2004-10-23 at 11:51 -0700, Paul E. McKenney wrote:
> > On Fri, Oct 22, 2004 at 07:56:33PM +0200, Ingo Molnar wrote:
> > > 
> > > i have released the -U10.2 Real-Time Preemption patch, which can be
> > > downloaded from:
> > > 
> > >   http://redhat.com/~mingo/realtime-preempt/
> > 
> > On realtime-preempt-2.6.9-mm1-U10.3:
> > 
> > o	In rcupdate.h, I believe that the:
> > 
> > 	+# define rcu_read_unlock_nort()                rcu_read_lock_nort()
> > 
> > 	should instead be:
> > 
> > 	+# define rcu_read_unlock_nort()                rcu_read_unlock()
> > 
> 
> Oh no!  That would explain a lot... the typical report is it works fine
> until people go to use the network :-P

Yes and No !

The wrong define is in the #else path of CONFIG_PREEMPT_REALTIME, so it
affects the kernel only when it is built with PREEMPT_REALTIME
disabled. 

The network problem with PREEMPT_REALTIME enabled is a subtle race,
which I have nearly tracked down. I know the scenario, but I have not
yet identified the culprit. (:

tglx





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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23 18:51                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Paul E. McKenney
  2004-10-23 19:14                                       ` Lee Revell
@ 2004-10-23 20:24                                       ` Ingo Molnar
  2004-10-23 21:12                                         ` Paul E. McKenney
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-23 20:24 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


* Paul E. McKenney <paulmck@us.ibm.com> wrote:

> o	In rcupdate.h, I believe that the:
> 
> 	+# define rcu_read_unlock_nort()                rcu_read_lock_nort()
> 
> 	should instead be:
> 
> 	+# define rcu_read_unlock_nort()                rcu_read_unlock()

yeah, correct - fortunately this is a non-default path, but still a nice
fix.

> o	The rcu_read_lock_spin(), rcu_read_lock_read(),
> 	rcu_read_lock_bh_read(), rcu_read_lock_sem(), and
> 	rcu_read_lock_bh_spin() APIs cannot be called recursively.
> 	But you probably already knew that.  ;-)
> 
> 	I don't understand why the rcu_read_lock_sem() API gets its
> 	own #ifdef.

actually, rcu_read_lock_read() is the variant that _can_ be called
recursively and which i used in the networking code quite extensively.
The others are only useful if the locking is 'flat' in the original
code, or if the locking is extensively rewritten. (I havent tried to
convert the IPC code back from the 'flat' locking to the original
'nested' locking, but i've done it for the networking code.)

> o	Some recent RCU patches acquire the update-side lock
> 	under rcu_read_lock(), which I believe will deadlock here.

which codepaths do you mean? Things are looking pretty good in -U10.3 so
far.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23 13:54                                               ` Ingo Molnar
@ 2004-10-23 20:59                                                 ` Rui Nuno Capela
  0 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-23 20:59 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Alexander Batyrshin

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

> Ingo Molnar
>
> Rui Nuno Capela wrote:
>
>> OK. All affirmative. NIC is natsemi.
>>
>> Here it is:
>>
>> SysRq : IRQ 1/776: BUG in write_msg at drivers/net/netconsole.c:87
>
> doh! Go to line 77 and spot the bug. (yes, the PREEMPT_REALTIME needs to
> become CONFIG_PREEMPT_REALTIME) With that fixed does it work for you?
>

OK again. And found another place where PREEMPT_REALTIME is in place of
CONFIG_PREEMPT_REALTIME, on drivers/ide/ide-taskfile.c, lines 287 and 308
(see appended diffs).

Anyway, back to my jackd -R issue. I tell you that things are really
different now: hitting SysRq+T, just about when it all gets frozen, I see
nothing on netconsole capture end, only this single line:

SysRq : Show State

and nothing more.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: linux-2.6.9-mm1-RT-U10.3_netconsole-2.patch --]
[-- Type: text/x-diff; name="linux-2.6.9-mm1-RT-U10.3_netconsole-2.patch", Size: 401 bytes --]

--- linux-2.6.9-mm1-RT-U10.3/drivers/net/netconsole.c.orig	2004-10-23 16:24:45.178795840 +0100
+++ linux-2.6.9-mm1-RT-U10.3/drivers/net/netconsole.c	2004-10-23 16:25:12.869586200 +0100
@@ -74,7 +74,7 @@
 		return;
 
 	local_irq_save(flags);
-#ifdef PREEMPT_REALTIME
+#ifdef CONFIG_PREEMPT_REALTIME
 	/*
 	 * A bit hairy. Netconsole uses mutexes (indirectly) and
 	 * thus must have interrupts enabled:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: linux-2.6.9-mm1-RT-U10.3_ide-taskfile-2.patch --]
[-- Type: text/x-diff; name="linux-2.6.9-mm1-RT-U10.3_ide-taskfile-2.patch", Size: 729 bytes --]

--- linux-2.6.9-mm1-RT-U10.3/drivers/ide/ide-taskfile.c.orig	2004-10-23 14:13:38.000000000 +0100
+++ linux-2.6.9-mm1-RT-U10.3/drivers/ide/ide-taskfile.c	2004-10-23 16:34:10.142908240 +0100
@@ -284,7 +284,7 @@
 	u8 *buf;
 
 	page = sg[hwif->cursg].page;
-#if defined(CONFIG_HIGHMEM) && !defined(PREEMPT_REALTIME)
+#if defined(CONFIG_HIGHMEM) && !defined(CONFIG_PREEMPT_REALTIME)
 	local_irq_save(flags);
 #endif
 	buf = kmap_atomic(page, KM_BIO_SRC_IRQ) +
@@ -305,7 +305,7 @@
 		taskfile_input_data(drive, buf, SECTOR_WORDS);
 
 	kunmap_atomic(page, KM_BIO_SRC_IRQ);
-#if defined(CONFIG_HIGHMEM) && !defined(PREEMPT_REALTIME)
+#if defined(CONFIG_HIGHMEM) && !defined(CONFIG_PREEMPT_REALTIME)
 	local_irq_restore(flags);
 #endif
 }

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23 20:24                                       ` Ingo Molnar
@ 2004-10-23 21:12                                         ` Paul E. McKenney
  0 siblings, 0 replies; 951+ messages in thread
From: Paul E. McKenney @ 2004-10-23 21:12 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin, kaigai

On Sat, Oct 23, 2004 at 10:24:51PM +0200, Ingo Molnar wrote:
> * Paul E. McKenney <paulmck@us.ibm.com> wrote:
> > o	The rcu_read_lock_spin(), rcu_read_lock_read(),
> > 	rcu_read_lock_bh_read(), rcu_read_lock_sem(), and
> > 	rcu_read_lock_bh_spin() APIs cannot be called recursively.
> > 	But you probably already knew that.  ;-)
> > 
> > 	I don't understand why the rcu_read_lock_sem() API gets its
> > 	own #ifdef.
> 
> actually, rcu_read_lock_read() is the variant that _can_ be called
> recursively and which i used in the networking code quite extensively.
> The others are only useful if the locking is 'flat' in the original
> code, or if the locking is extensively rewritten. (I havent tried to
> convert the IPC code back from the 'flat' locking to the original
> 'nested' locking, but i've done it for the networking code.)

OK, sorry for my confusion.  I still don't see why rcu_read_lock_sem()
is segregated, but it will clearly work either way.

> > o	Some recent RCU patches acquire the update-side lock
> > 	under rcu_read_lock(), which I believe will deadlock here.
> 
> which codepaths do you mean? Things are looking pretty good in -U10.3 so
> far.

The one that I am aware of has not yet hit mainline -- Kaigai Kohei's
scalability changes to Linux.  See:

	http://marc.theaimsgroup.com/?l=linux-kernel&m=109628285418353&w=2

The function avc_update_cache() does an rcu_read_lock(), then
invokes avc_update_node(), which acquires the update-side lock.
No problem under conventional RCU, in the case where one might
realize that an update is needed during what is a read-only search
in the common case, but would be problematic given real-time preemption.

						Thanx, Paul

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-22 17:56                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Ingo Molnar
                                                       ` (4 preceding siblings ...)
  2004-10-23 18:51                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Paul E. McKenney
@ 2004-10-24 15:19                                     ` Gunther Persoons
  2004-10-25 10:40                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0 Ingo Molnar
  6 siblings, 0 replies; 951+ messages in thread
From: Gunther Persoons @ 2004-10-24 15:19 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Ingo Molnar wrote:

>i have released the -U10.2 Real-Time Preemption patch, which can be
>downloaded from:
>
>  http://redhat.com/~mingo/realtime-preempt/
> 
>this is a fixes-only release.
>
>Changes since -U10:
>
> - fixed a big bug present ever since: the BKL got dropped when a
>   spinlock-mutex was acquired and it scheduled away. This reduced the
>   locking efficiency of the BKL. A number of outstanding problems could
>   be affected, in particular this should fix the tty locking breakage
>   reported by Alexander Batyrshin and Adam Heath. UP and SMP systems 
>   are affected too, with SMP systems having a higher chance to trigger
>   this condition.
>
> - tulip.c breakage fix from Thomas Gleixner
>
> - tg3 and 3c59x fixes.
>
> - made the hardirq threads SCHED_FIFO by default. They get priorities 
>   between 25 and 50, depending on the irq #. (this is pretty random but 
>   i found no better scheme.) Made the softirq thread SCHED_FIFO by 
>   default as well, albeit this probably will have to change. These 
>   changes should make it easier to debug a hung system.
>
>to create a -U10.2 tree from scratch, the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
> + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/2.6.9-mm1.bz2
> + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-U10.2
>
>	Ingo
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
I get following error with 10.3 on kernel 2.6.9-mm1

Device 'i823650' does not have a release() function, it is broken and 
must be fixed.
swapper/1: BUG in device_release at drivers/base/core.c:85
 [<c0238aeb>] kobject_cleanup+0x9a/0x9c (8)
 [<c0238b15>] kobject_put+0x1e/0x22 (24)
 [<c0238aed>] kobject_release+0x0/0xa (8)
 [<c045cecf>] init_i82365+0x1f2/0x208 (4)
 [<c02487b6>] pci_register_driver+0x94/0xa6 (8)
 [<c044286c>] do_initcalls+0x54/0xb6 (32)
 [<c010040b>] init+0x0/0x10d (16)
 [<c010043f>] init+0x34/0x10d (12)
 [<c01042a8>] kernel_thread_helper+0x0/0xb (12)
 [<c01042ad>] kernel_thread_helper+0x5/0xb (4)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x14/0x45 [<00000000>] / (0x0 [<00000000>])


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-23 10:36                                         ` Ingo Molnar
@ 2004-10-25  0:33                                           ` john cooper
  2004-10-25 10:09                                             ` remi.colinet
  0 siblings, 1 reply; 951+ messages in thread
From: john cooper @ 2004-10-25  0:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, gene.heskett, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Alexander Batyrshin, john cooper

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

Ingo Molnar wrote:

>* Lee Revell <rlrevell@joe-job.com> wrote:
>
>
>>On Fri, 2004-10-22 at 17:49 -0400, Gene Heskett wrote:
>>
>>>Mmm, I get a 404 page not found. when I click on  on thsi link.
>>>
>>Same here.  The current version is 10.3:
>>
>>http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-U10.3
>>
I'm seeing an odd build error in the -U10.3 patch to 2.6.9-mm1:

    <snip>

  AS      arch/i386/boot/compressed/head.o
  CC      arch/i386/boot/compressed/misc.o
  OBJCOPY arch/i386/boot/compressed/vmlinux.bin
BFD: Warning: Writing section `.bss' to huge (ie negative) file offset 
0xc03ac000.
objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
make: *** [bzImage] Error 2

[root@otaku linux-2.6.9]# objdump -f vmlinux

vmlinux:     file format elf32-i386
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00100000

This appears a result of changes in:

   arch/i386/kernel/vmlinux.lds.S

apparently for support of CONFIG_KERN_PHYS_OFFSET.
This causes the kernel LMA start address to
change from 0xc0100000 to 0x100000 and objcopy to
gag.  I rolled back to a 2.6.9-mm1 version of the
above linker map file and did get the kernel to
build and boot.

Anyone else seeing this?  .config attached.

BTW, the -U10.2 patch seems to have disappeared
from:

    http://people.redhat.com/mingo/realtime-preempt/older/

-- 
john.cooper@timesys.com


[-- Attachment #2: config.bz2 --]
[-- Type: application/x-bzip, Size: 5943 bytes --]

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-25  0:33                                           ` john cooper
@ 2004-10-25 10:09                                             ` remi.colinet
  2004-10-25 13:35                                               ` john cooper
  0 siblings, 1 reply; 951+ messages in thread
From: remi.colinet @ 2004-10-25 10:09 UTC (permalink / raw)
  To: john cooper
  Cc: Ingo Molnar, Lee Revell, gene.heskett, linux-kernel,
	Rui Nuno Capela, Mark_H_Johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Alexander Batyrshin

Hi,

> I'm seeing an odd build error in the -U10.3 patch to 2.6.9-mm1:
>
>     <snip>
>
>   AS      arch/i386/boot/compressed/head.o
>   CC      arch/i386/boot/compressed/misc.o
>   OBJCOPY arch/i386/boot/compressed/vmlinux.bin
> BFD: Warning: Writing section `.bss' to huge (ie negative) file offset
> 0xc03ac000.
> objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
> make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
> make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
> make: *** [bzImage] Error 2
>
> [root@otaku linux-2.6.9]# objdump -f vmlinux
>
> vmlinux:     file format elf32-i386
> architecture: i386, flags 0x00000112:
> EXEC_P, HAS_SYMS, D_PAGED
> start address 0x00100000
>
> This appears a result of changes in:
>
>    arch/i386/kernel/vmlinux.lds.S
>
> apparently for support of CONFIG_KERN_PHYS_OFFSET.
> This causes the kernel LMA start address to
> change from 0xc0100000 to 0x100000 and objcopy to
> gag.  I rolled back to a 2.6.9-mm1 version of the
> above linker map file and did get the kernel to
> build and boot.
>
> Anyone else seeing this?  .config attached.

Yes.

You probably need to upgrade your binutil package. The .bss LMA start address
section is not dealt the way it should by ld.

An other (bad) way to work around this compile problem is to force the .bss LMA
start address with the following OBJCOPYFLAGS at objcopy time.

OBJCOPYFLAGS := -O binary --change-section-lma .bss-0xc0000000 -R .note -R
.comment -S

Hope this help,
Remi




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

* [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-22 17:56                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Ingo Molnar
                                                       ` (5 preceding siblings ...)
  2004-10-24 15:19                                     ` Gunther Persoons
@ 2004-10-25 10:40                                     ` Ingo Molnar
  2004-10-25 11:08                                       ` K.R. Foley
                                                         ` (4 more replies)
  6 siblings, 5 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-25 10:40 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


i have released the -V0 Real-Time Preemption patch, which can be
downloaded from:

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

NOTE: this is a highly experimental release, a more experimental one
than -U10.3.

the big change in the '-V' series of the patchset is that i have
converted the last couple of non-preemptible kernel subsystems to
fully-preemptible mutex-based locking. These subsystems are:

 - the SLAB allocator
 - the buddy page allocator
 - waitqueue handling
 - soft-timer subsystem
 - security/selinux
 - workqueues
 - the random driver

this is probably the last 'big leap forward' in terms of the scope of
the patch. (having reached the ultimate scope: it now encompasses
everything ;)

But as an inevitable result of this big leap it will likely break in a
couple of places. Unfortunately these subsystems were largely
interdependent so it's an all-or-nothing step with not much middle
ground between the locking done in -U10.3 and in -V0.

another result of these changes is that the number of critical sections
in -V0 is roughly 30% of that in -U10.3. Now we only have the scheduler
and very lowlevel IRQ-hardware locks as raw spinlocks. (plus the lone
holdout vga_lock - which i will probably make a mutex too in the near
future)

[ NOTE: there's one known bug in this release: selinux on one of my
testsystems broke, it hangs during bootup. With CONFIG_SECURITY disabled
it works fine. I'm working on the fix. So please keep CONFIG_SECURITY
disabled for the time being. ]

other changes in -V0:

 - build fixes: more driver fixes from Thomas Gleixner

 - crash fix: fixed a bug found by Thomas Gleixner: rwsem runtime
   initialization was racy.

 - deadlock fix: fixed lockup bug caused by __schedule clearing
   PREEMPT_ACTIVE. The need_resched loop is now outside of __schedule(). 
   This might solve lockups/slowdowns reported by some people.

 - latency fix: made keventd SCHED_FIFO - this could fix the mouse
   related delays reported by a number of people.

 - latency fix: fixed SMP lock-break mechanism of mutexes.

 - usability feature: hard-interrupts get decreasing SCHED_FIFO priority
   starting at prio 49 and stopping at prio 25. This should give a good
   default.

 - debug feature: implemented SysRq-D to show the list of tasks with
   locks blocked on, if RW_SEM_DEADLOCK_DETECTION is enabled.

to create a -V0 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/2.6.9-mm1.bz2
 + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-V0

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 10:40                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0 Ingo Molnar
@ 2004-10-25 11:08                                       ` K.R. Foley
  2004-10-25 11:10                                         ` Ingo Molnar
  2004-10-25 18:52                                       ` K.R. Foley
                                                         ` (3 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-25 11:08 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:

> [ NOTE: there's one known bug in this release: selinux on one of my
> testsystems broke, it hangs during bootup. With CONFIG_SECURITY disabled
> it works fine. I'm working on the fix. So please keep CONFIG_SECURITY
> disabled for the time being. ]
>
Does this include all models of security or just the selinux stuff?


> other changes in -V0:
> 
>  - build fixes: more driver fixes from Thomas Gleixner
> 
>  - crash fix: fixed a bug found by Thomas Gleixner: rwsem runtime
>    initialization was racy.
> 
>  - deadlock fix: fixed lockup bug caused by __schedule clearing
>    PREEMPT_ACTIVE. The need_resched loop is now outside of __schedule(). 
>    This might solve lockups/slowdowns reported by some people.
> 
>  - latency fix: made keventd SCHED_FIFO - this could fix the mouse
>    related delays reported by a number of people.
> 
>  - latency fix: fixed SMP lock-break mechanism of mutexes.
> 
>  - usability feature: hard-interrupts get decreasing SCHED_FIFO priority
>    starting at prio 49 and stopping at prio 25. This should give a good
>    default.
> 
>  - debug feature: implemented SysRq-D to show the list of tasks with
>    locks blocked on, if RW_SEM_DEADLOCK_DETECTION is enabled.
> 
> to create a -V0 tree from scratch, the patching order is:
> 
>    http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
>  + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/2.6.9-mm1.bz2
>  + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-V0
> 
> 	Ingo
> 



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 11:08                                       ` K.R. Foley
@ 2004-10-25 11:10                                         ` Ingo Molnar
  2004-10-25 11:13                                           ` K.R. Foley
  2004-10-25 12:12                                           ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-25 11:10 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> >[ NOTE: there's one known bug in this release: selinux on one of my
> >testsystems broke, it hangs during bootup. With CONFIG_SECURITY disabled
> >it works fine. I'm working on the fix. So please keep CONFIG_SECURITY
> >disabled for the time being. ]
> >
> Does this include all models of security or just the selinux stuff?

i have only tried selinux. (which is installed/enabled by default on FC3
so it's easy for me to test on an out of box distro.)

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 11:10                                         ` Ingo Molnar
@ 2004-10-25 11:13                                           ` K.R. Foley
  2004-10-25 12:12                                           ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-25 11:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>>[ NOTE: there's one known bug in this release: selinux on one of my
>>>testsystems broke, it hangs during bootup. With CONFIG_SECURITY disabled
>>>it works fine. I'm working on the fix. So please keep CONFIG_SECURITY
>>>disabled for the time being. ]
>>>
>>
>>Does this include all models of security or just the selinux stuff?
> 
> 
> i have only tried selinux. (which is installed/enabled by default on FC3
> so it's easy for me to test on an out of box distro.)
> 
> 	Ingo
> 

Well I will know when it boots, or doesn't. :) I will report back when I 
know.

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 11:10                                         ` Ingo Molnar
  2004-10-25 11:13                                           ` K.R. Foley
@ 2004-10-25 12:12                                           ` Ingo Molnar
  2004-10-25 13:24                                             ` Florian Schmidt
  2004-10-25 13:39                                             ` Florian Schmidt
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-25 12:12 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> > >[ NOTE: there's one known bug in this release: selinux on one of my
> > >testsystems broke, it hangs during bootup. With CONFIG_SECURITY disabled
> > >it works fine. I'm working on the fix. So please keep CONFIG_SECURITY
> > >disabled for the time being. ]
> > >
> > Does this include all models of security or just the selinux stuff?
> 
> i have only tried selinux. (which is installed/enabled by default on
> FC3 so it's easy for me to test on an out of box distro.)

i think i found the bug - now selinux boots fine. I've uploaded -V0.1
with the fix included. This fix could solve a number of other complaints
as well.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 12:12                                           ` Ingo Molnar
@ 2004-10-25 13:24                                             ` Florian Schmidt
  2004-10-25 13:26                                               ` Ingo Molnar
  2004-10-25 13:39                                             ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-25 13:24 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

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

On Mon, 25 Oct 2004 14:12:10 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> i think i found the bug - now selinux boots fine. I've uploaded -V0.1
> with the fix included. This fix could solve a number of other complaints
> as well.



hi, i saw these during boot (config and complete dmesg attached):

Freeing unused kernel memory: 348k freed
Adding 289160k swap on /dev/hda3.  Priority:-1 extents:1
EXT3 FS on hdc1, internal journal
IRQ#8 thread RT prio: 45.
BUG: sleeping function called from invalid context modprobe(116) at kernel/mutex.c:28
in_atomic():1 [00000001], irqs_disabled():1
 [<c0117182>] __might_sleep+0xc2/0xe0 (12)
 [<c0134989>] resolve_symbol+0xb9/0xc0 (24)
 [<c01309f8>] _mutex_lock+0x38/0x50 (12)
 [<c0144995>] kmem_cache_alloc+0x45/0x100 (24)
 [<c0134989>] resolve_symbol+0xb9/0xc0 (8)
 [<c0133cfc>] use_module+0x4c/0x160 (4)
 [<c0133d50>] use_module+0xa0/0x160 (20)
 [<f08414f0>] unregister_sound_special+0x0/0x40 [soundcore] (12)
 [<c0134989>] resolve_symbol+0xb9/0xc0 (16)
 [<c0134fe2>] simplify_symbols+0xb2/0x120 (48)
 [<c0135cc3>] load_module+0x573/0xa90 (44)
 [<c013100d>] __mcount+0x1d/0x20 (48)
 [<c0136236>] sys_init_module+0x56/0x260 (112)
 [<c010617b>] syscall_call+0x7/0xb (28)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: resolve_symbol+0x21/0xc0 [<c01348f1>] / (simplify_symbols+0xb2/0x120 [<c0134fe2>])
.. entry 2: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

PCI: Found IRQ 3 for device 0000:00:0f.0
sis900.c: v1.08.07 11/02/2003

[...]

EXT3-fs: mounted filesystem with ordered data mode.
eth0: Media Link On 100mbps full-duplex 
IRQ#5 thread RT prio: 44.
ip_tables: (C) 2000-2002 Netfilter core team
BUG: sleeping function called from invalid context modprobe(591) at kernel/mutex.c:28
in_atomic():1 [00000001], irqs_disabled():1
 [<c0117182>] __might_sleep+0xc2/0xe0 (12)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (24)
 [<c01309f8>] _mutex_lock+0x38/0x50 (12)
 [<c0144995>] kmem_cache_alloc+0x45/0x100 (24)
 [<c0134989>] resolve_symbol+0xb9/0xc0 (8)
 [<c0133cfc>] use_module+0x4c/0x160 (4)
 [<c0133d50>] use_module+0xa0/0x160 (20)
 [<f0914030>] ipt_do_table+0x0/0x320 [ip_tables] (12)
 [<c0134989>] resolve_symbol+0xb9/0xc0 (16)
 [<c0134fe2>] simplify_symbols+0xb2/0x120 (48)
 [<c0135cc3>] load_module+0x573/0xa90 (44)
 [<c01ef27b>] __up_write+0x13b/0x320 (48)
 [<c0136236>] sys_init_module+0x56/0x260 (112)
 [<c010617b>] syscall_call+0x7/0xb (28)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: resolve_symbol+0x21/0xc0 [<c01348f1>] / (simplify_symbols+0xb2/0x120 [<c0134fe2>])
.. entry 2: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

ip_conntrack version 2.1 (6144 buckets, 49152 max) - 452 bytes per conntrack

Module                  Size  Used by
ipt_addrtype            2112  1 
ipt_state               1920  1 
ip_conntrack           51096  1 ipt_state
iptable_filter          3136  1 
ip_tables              19584  3 ipt_addrtype,ipt_state,iptable_filter
bsd_comp                5952  0 
ppp_deflate             6272  0 
zlib_deflate           22360  1 ppp_deflate
ppp_async              13784  1 
ppp_generic            34276  7 bsd_comp,ppp_deflate,ppp_async
slhc                    8320  1 ppp_generic
crc_ccitt               2112  1 ppp_async
sis900                 20036  0 
crc32                   4352  1 sis900
snd_cs46xx             84168  1 
snd_rawmidi            26592  1 snd_cs46xx
snd_seq_device          8972  1 snd_rawmidi
snd_ac97_codec         77472  1 snd_cs46xx
snd_pcm               100600  2 snd_cs46xx,snd_ac97_codec
snd_timer              27612  1 snd_pcm
snd                    57668  8 snd_cs46xx,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm,snd_timer
soundcore              10688  1 snd
snd_page_alloc         10244  2 snd_cs46xx,snd_pcm
gameport                4992  1 snd_cs46xx


flo

[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 26191 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-mm1-RT-V0.1
# Mon Oct 25 14:57:54 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=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

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

#
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# 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_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_GENERIC=y
CONFIG_GENERIC_SEMAPHORES=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_X86_USE_3DNOW=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
CONFIG_PREEMPT_BKL=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_KERN_PHYS_OFFSET=1
# 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 is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

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

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

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

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD 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=m
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_TASKFILE_IO is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 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 is not set
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 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=y
# 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

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

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

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

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_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_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_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

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT 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_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM 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_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

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

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set

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

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
# CONFIG_SENSORS_LM87 is not set
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

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

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

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

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

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

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY 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_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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=m
CONFIG_RXRPC=m

#
# 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=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_PREEMPT_TIMING=y
CONFIG_PREEMPT_TRACE=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_RWSEM_DEADLOCK_DETECT=y
CONFIG_RWSEM_MAX_OWNERS=32
# CONFIG_DEBUG_INFO is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set

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

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

[-- Attachment #3: log --]
[-- Type: application/octet-stream, Size: 1107 bytes --]

Module                  Size  Used by
ipt_addrtype            2112  1 
ipt_state               1920  1 
ip_conntrack           51096  1 ipt_state
iptable_filter          3136  1 
ip_tables              19584  3 ipt_addrtype,ipt_state,iptable_filter
bsd_comp                5952  0 
ppp_deflate             6272  0 
zlib_deflate           22360  1 ppp_deflate
ppp_async              13784  1 
ppp_generic            34276  7 bsd_comp,ppp_deflate,ppp_async
slhc                    8320  1 ppp_generic
crc_ccitt               2112  1 ppp_async
sis900                 20036  0 
crc32                   4352  1 sis900
snd_cs46xx             84168  1 
snd_rawmidi            26592  1 snd_cs46xx
snd_seq_device          8972  1 snd_rawmidi
snd_ac97_codec         77472  1 snd_cs46xx
snd_pcm               100600  2 snd_cs46xx,snd_ac97_codec
snd_timer              27612  1 snd_pcm
snd                    57668  8 snd_cs46xx,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm,snd_timer
soundcore              10688  1 snd
snd_page_alloc         10244  2 snd_cs46xx,snd_pcm
gameport                4992  1 snd_cs46xx

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 13:24                                             ` Florian Schmidt
@ 2004-10-25 13:26                                               ` Ingo Molnar
  2004-10-25 14:03                                                 ` Florian Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-25 13:26 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> hi, i saw these during boot (config and complete dmesg attached):
> 
> Freeing unused kernel memory: 348k freed
> Adding 289160k swap on /dev/hda3.  Priority:-1 extents:1
> EXT3 FS on hdc1, internal journal
> IRQ#8 thread RT prio: 45.
> BUG: sleeping function called from invalid context modprobe(116) at kernel/mutex.c:28
> in_atomic():1 [00000001], irqs_disabled():1
>  [<c0117182>] __might_sleep+0xc2/0xe0 (12)
>  [<c0134989>] resolve_symbol+0xb9/0xc0 (24)
>  [<c01309f8>] _mutex_lock+0x38/0x50 (12)
>  [<c0144995>] kmem_cache_alloc+0x45/0x100 (24)
>  [<c0134989>] resolve_symbol+0xb9/0xc0 (8)

does the patch below fix this?

	Ingo

--- linux/kernel/module.c.orig
+++ linux/kernel/module.c
@@ -53,7 +53,7 @@
 #define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))
 
 /* Protects module list */
-static DECLARE_RAW_SPINLOCK(modlist_lock);
+static DECLARE_SPINLOCK(modlist_lock);
 
 /* List of modules, protected by module_mutex AND modlist_lock */
 static DECLARE_MUTEX(module_mutex);

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 13:48                                               ` Florian Schmidt
@ 2004-10-25 13:35                                                 ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-25 13:35 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> [snip]
> 
> i forgot to mention these were from the same session as the previous
> one. also i think i missed the first ones, so the reports in this mail
> are probably useless(?).

i think the futex assert is a separate problem not triggered by the
module.c warnings.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2
  2004-10-25 10:09                                             ` remi.colinet
@ 2004-10-25 13:35                                               ` john cooper
  0 siblings, 0 replies; 951+ messages in thread
From: john cooper @ 2004-10-25 13:35 UTC (permalink / raw)
  To: remi.colinet
  Cc: Ingo Molnar, Lee Revell, gene.heskett, linux-kernel,
	Rui Nuno Capela, Mark_H_Johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Alexander Batyrshin, john.cooper

remi.colinet@free.fr wrote:

>Hi,
>
>
>>I'm seeing an odd build error in the -U10.3 patch to 2.6.9-mm1:
>>
>>    <snip>
>>
>>  AS      arch/i386/boot/compressed/head.o
>>  CC      arch/i386/boot/compressed/misc.o
>>  OBJCOPY arch/i386/boot/compressed/vmlinux.bin
>>BFD: Warning: Writing section `.bss' to huge (ie negative) file offset
>>0xc03ac000.
>>objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
>>make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
>>make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
>>make: *** [bzImage] Error 2
>>
>>[root@otaku linux-2.6.9]# objdump -f vmlinux
>>
>>vmlinux:     file format elf32-i386
>>architecture: i386, flags 0x00000112:
>>EXEC_P, HAS_SYMS, D_PAGED
>>start address 0x00100000
>>
>>This appears a result of changes in:
>>
>>   arch/i386/kernel/vmlinux.lds.S
>>
>>apparently for support of CONFIG_KERN_PHYS_OFFSET.
>>This causes the kernel LMA start address to
>>change from 0xc0100000 to 0x100000 and objcopy to
>>gag.  I rolled back to a 2.6.9-mm1 version of the
>>above linker map file and did get the kernel to
>>build and boot.
>>
>>Anyone else seeing this?  .config attached.
>>
>
>Yes.
>
>You probably need to upgrade your binutil package. The .bss LMA start address
>section is not dealt the way it should by ld.
>
>An other (bad) way to work around this compile problem is to force the .bss LMA
>start address with the following OBJCOPYFLAGS at objcopy time.
>
>OBJCOPYFLAGS := -O binary --change-section-lma .bss-0xc0000000 -R .note -R
>.comment -S
>
>Hope this help,
>Remi
>
Already tried a recent (2.15) version of objcopy
with the same results.  But LD was the issue.
BTW the offending version of binutils was 2.13.

Thanks!

-- 
john.cooper@timesys.com


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 12:12                                           ` Ingo Molnar
  2004-10-25 13:24                                             ` Florian Schmidt
@ 2004-10-25 13:39                                             ` Florian Schmidt
  2004-10-25 13:48                                               ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-25 13:39 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Mon, 25 Oct 2004 14:12:10 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> i think i found the bug - now selinux boots fine. I've uploaded -V0.1
> with the fix included. This fix could solve a number of other complaints
> as well.

some more:

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

mozilla-bin/753: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c01ef27b>] __up_write+0x13b/0x320 (84)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (16)
 [<c02b9880>] down_write+0xd0/0x2b0 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c02b9880>] down_write+0xd0/0x2b0 (4)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (8)
 [<c01ef27b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef27b>] __up_write+0x13b/0x320 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (72)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 13:39                                             ` Florian Schmidt
@ 2004-10-25 13:48                                               ` Florian Schmidt
  2004-10-25 13:35                                                 ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-25 13:48 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, K.R. Foley, linux-kernel, Lee Revell,
	Rui Nuno Capela, Mark_H_Johnson, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Mon, 25 Oct 2004 15:39:40 +0200
Florian Schmidt <mista.tapas@gmx.net> wrote:

> On Mon, 25 Oct 2004 14:12:10 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > i think i found the bug - now selinux boots fine. I've uploaded -V0.1
> > with the fix included. This fix could solve a number of other complaints
> > as well.
> 
> some more:

[snip]

i forgot to mention these were from the same session as the previous one.
also i think i missed the first ones, so the reports in this mail are
probably useless(?).

flo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 13:26                                               ` Ingo Molnar
@ 2004-10-25 14:03                                                 ` Florian Schmidt
  2004-10-25 14:10                                                   ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-25 14:03 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Mon, 25 Oct 2004 15:26:05 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> does the patch below fix this?

looks like it. they didn't show on first boot of the new kernel with patch
applied. 

Btw: i still experience some "pauses". They are different now though. It
seems i can trigger them by reloading a page in mozilla (not always). This
BUG definetly looks related. Dunno, when exactly it happened (related to
what i did at that moment), but it's the only one in dmesg output on this
bootup. Each of the pauses is accompanied by a high cpu usage of ksoftirqd.
I cannot retrigger the BUG though.

mozilla-bin/763: BUG in futex_wait at kernel/futex.c:542
 [<c0132962>] futex_wait+0x192/0x1a0 (12)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (64)
 [<c01ef17b>] __up_write+0x13b/0x320 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01ef17b>] __up_write+0x13b/0x320 (4)
 [<c02b94d3>] down_read+0xd3/0x2b0 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01eef11>] up_read+0x111/0x240 (8)
 [<c0131788>] check_preempt_timing+0x58/0x290 (8)
 [<c0131c55>] sub_preempt_count+0x65/0xd0 (4)
 [<c01eef11>] up_read+0x111/0x240 (4)
 [<c0115f60>] default_wake_function+0x0/0x20 (104)
 [<c0115f60>] default_wake_function+0x0/0x20 (32)
 [<c0132c17>] do_futex+0x47/0xa0 (40)
 [<c0132d60>] sys_futex+0xf0/0x100 (40)
 [<c010617b>] syscall_call+0x7/0xb (68)
preempt count: 00000001
. 1-level deep critical section nesting:
.. entry 1: print_traces+0x17/0x90 [<c0131fc7>] / (dump_stack+0x23/0x30 [<c0106733>])

Here's the syslog entry:

Oct 25 15:56:31 mango kernel: mozilla-bin/763: BUG in futex_wait at kernel/futex.c:542
Oct 25 15:56:31 mango kernel:  [futex_requeue+162/608] futex_wait+0x192/0x1a0 (12)
Oct 25 15:56:31 mango kernel:  [print_name_offset+149/160] sub_preempt_count+0x65/0xd0 (64)
Oct 25 15:56:31 mango kernel:  [zlib_inflateReset+43/128] __up_write+0x13b/0x320 (8)
Oct 25 15:56:31 mango kernel:  [kfifo_alloc+216/240] check_preempt_timing+0x58/0x290 (8)
Oct 25 15:56:31 mango kernel:  [print_name_offset+149/160] sub_preempt_count+0x65/0xd0 (4)
Oct 25 15:56:31 mango kernel:  [zlib_inflateReset+43/128] __up_write+0x13b/0x320 (4)
Oct 25 15:56:31 mango kernel:  [__func__.0+318/987] down_read+0xd3/0x2b0 (8)
Oct 25 15:56:31 mango kernel:  [print_name_offset+149/160] sub_preempt_count+0x65/0xd0 (4)
Oct 25 15:56:31 mango kernel:  [zlib_inflate_fast+465/1024] up_read+0x111/0x240 (8)
Oct 25 15:56:31 mango kernel:  [kfifo_alloc+216/240] check_preempt_timing+0x58/0x290 (8)
Oct 25 15:56:31 mango kernel:  [print_name_offset+149/160] sub_preempt_count+0x65/0xd0 (4)
Oct 25 15:56:31 mango kernel:  [zlib_inflate_fast+465/1024] up_read+0x111/0x240 (4)
Oct 25 15:56:31 mango kernel:  [wake_up_process+32/48] default_wake_function+0x0/0x20 (104)
Oct 25 15:56:31 mango kernel:  [wake_up_process+32/48] default_wake_function+0x0/0x20 (32)
Oct 25 15:56:31 mango kernel:  [unqueue_me+103/256] do_futex+0x47/0xa0 (40)
Oct 25 15:56:31 mango kernel:  [futex_wait+176/400] sys_futex+0xf0/0x100 (40)
Oct 25 15:56:31 mango kernel:  [irq_entries_start+107/128] syscall_call+0x7/0xb (68)
Oct 25 15:56:31 mango kernel: preempt count: 00000001
Oct 25 15:56:31 mango kernel: . 1-level deep critical section nesting:
Oct 25 15:56:31 mango kernel: .. entry 1: print_traces+0x17/0x90 [update_max_trace+23/160] / (dump_stack+0x23/0x30 [show_registers+131/464])

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 14:03                                                 ` Florian Schmidt
@ 2004-10-25 14:10                                                   ` Ingo Molnar
  2004-10-25 14:16                                                     ` Ingo Molnar
  2004-10-25 15:06                                                     ` Florian Schmidt
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-25 14:10 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> > does the patch below fix this?
> 
> looks like it. they didn't show on first boot of the new kernel with
> patch applied. 

ok, i've added it and uploaded -V0.2 together with another fix: there
was a scheduler recursion possible via the delayed-put mechanism using
workqueues - now it's using its own separate lists and per-CPU threads.

> Btw: i still experience some "pauses". They are different now though.
> It seems i can trigger them by reloading a page in mozilla (not
> always). This BUG definetly looks related. Dunno, when exactly it
> happened (related to what i did at that moment), but it's the only one
> in dmesg output on this bootup. Each of the pauses is accompanied by a
> high cpu usage of ksoftirqd. I cannot retrigger the BUG though.

please try -V0.2 - maybe the delayed-put fix is somehow related. (but
only maybe...)

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 14:10                                                   ` Ingo Molnar
@ 2004-10-25 14:16                                                     ` Ingo Molnar
  2004-10-25 19:40                                                       ` Rui Nuno Capela
  2004-10-25 15:06                                                     ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-25 14:16 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> ok, i've added it and uploaded -V0.2 together with another fix: there
> was a scheduler recursion possible via the delayed-put mechanism using
> workqueues - now it's using its own separate lists and per-CPU
> threads.

-V0.2 seems to behave quite well on my testboxes - i'm unable to
reproduce the selinux boot hang anymore.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 14:10                                                   ` Ingo Molnar
  2004-10-25 14:16                                                     ` Ingo Molnar
@ 2004-10-25 15:06                                                     ` Florian Schmidt
  2004-10-25 16:45                                                       ` K.R. Foley
  1 sibling, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-25 15:06 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Mon, 25 Oct 2004 16:10:08 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> > Btw: i still experience some "pauses". They are different now though.
> > It seems i can trigger them by reloading a page in mozilla (not
> > always). This BUG definetly looks related. Dunno, when exactly it
> > happened (related to what i did at that moment), but it's the only one
> > in dmesg output on this bootup. Each of the pauses is accompanied by a
> > high cpu usage of ksoftirqd. I cannot retrigger the BUG though.
> 
> please try -V0.2 - maybe the delayed-put fix is somehow related. (but
> only maybe...)
> 

doesn't seem so. V0.2 doesn't fix this for me. This time i got a BUG storm
again in syslog (it kinda seems related to starting playback in xmms plus
loading pages in mozilla. will boot again to verify):

Oct 25 16:53:42 mango kernel: IRQ#3 thread RT prio: 43.
Oct 25 16:53:52 mango kernel: mozilla-bin/741: BUG in futex_wait at kernel/futex.c:542
Oct 25 16:53:52 mango kernel:  [add_preempt_count+130/224] futex_wait+0x192/0x1a0 (12)
Oct 25 16:53:52 mango kernel:  [zlib_inflate_blocks+1352/3088] __up_write+0x148/0x320 (100)
Oct 25 16:53:52 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (16)
Oct 25 16:53:52 mango kernel:  [__func__.13+351/922] down_write+0xd5/0x250 (8)
Oct 25 16:53:52 mango kernel:  [kthread_create+120/208] check_preempt_timing+0x58/0x290 (8)
Oct 25 16:53:52 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:52 mango kernel:  [__func__.13+351/922] down_write+0xd5/0x250 (4)
Oct 25 16:53:52 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (8)
Oct 25 16:53:52 mango kernel:  [zlib_inflate_blocks+1352/3088] __up_write+0x148/0x320 (8)
Oct 25 16:53:52 mango kernel:  [kthread_create+120/208] check_preempt_timing+0x58/0x290 (8)
Oct 25 16:53:52 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:56 mango kernel:  [zlib_inflate_blocks+1352/3088] __up_write+0x148/0x320 (4)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (72)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (32)
Oct 25 16:53:56 mango kernel:  [print_last_trace+247/256] do_futex+0x47/0xa0 (40)
Oct 25 16:53:56 mango kernel:  [get_futex_key+128/448] sys_futex+0xf0/0x100 (40)
Oct 25 16:53:56 mango kernel:  [syscall_fault+35/40] syscall_call+0x7/0xb (68)
Oct 25 16:53:56 mango kernel: preempt count: 00000001
Oct 25 16:53:56 mango kernel: . 1-level deep critical section nesting:
Oct 25 16:53:56 mango kernel: .. entry 1: print_traces+0x1d/0x70 [__kfifo_put+157/208] / (dump_stack+0x23/0x30 [show_registers+3/464])
Oct 25 16:53:56 mango kernel:
Oct 25 16:53:56 mango kernel: kernel/futex.c:542
Oct 25 16:53:56 mango kernel:  [add_preempt_count+130/224] futex_wait+0x192/0x1a0 (12)
Oct 25 16:53:56 mango kernel:  [dequeue_task+24/64] effective_prio+0x8/0x60 (80)
Oct 25 16:53:56 mango kernel:  [decay_avgs_and_calculate_rates+136/624] recalc_task_prio+0x98/0x190 (8)
Oct 25 16:53:56 mango kernel:  [task_rq_lock+98/112] enqueue_task+0x12/0x50 (24)
Oct 25 16:53:56 mango kernel:  [decay_avgs_and_calculate_rates+487/624] activate_task+0x67/0x80 (16)
Oct 25 16:53:56 mango kernel:  [__mon_yday+161/268] preempt_schedule+0x11/0x80 (12)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (16)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (8)
Oct 25 16:53:56 mango kernel:  [kthread_create+120/208] check_preempt_timing+0x58/0x290 (8)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (4)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (60)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (12)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (20)
Oct 25 16:53:56 mango kernel:  [print_last_trace+247/256] do_futex+0x47/0xa0 (40)
Oct 25 16:53:56 mango kernel:  [get_futex_key+128/448] sys_futex+0xf0/0x100 (40)
Oct 25 16:53:56 mango kernel:  [syscall_fault+35/40] syscall_call+0x7/0xb (68)
Oct 25 16:53:56 mango kernel: preempt count: 00000001
Oct 25 16:53:56 mango kernel: . 1-level deep critical section nesting:
Oct 25 16:53:56 mango kernel: .. entry 1: print_traces+0x1d/0x70 [__kfifo_put+157/208] / (dump_stack+0x23/0x30 [show_registers+3/464])
Oct 25 16:53:56 mango kernel:
Oct 25 16:53:56 mango kernel: mozilla-bin/741: BUG in futex_wait at kernel/futex.c:542
Oct 25 16:53:56 mango kernel:  [add_preempt_count+130/224] futex_wait+0x192/0x1a0 (12)
Oct 25 16:53:56 mango kernel:  [dequeue_task+24/64] effective_prio+0x8/0x60 (80)
Oct 25 16:53:56 mango kernel:  [decay_avgs_and_calculate_rates+136/624] recalc_task_prio+0x98/0x190 (8)
Oct 25 16:53:56 mango kernel:  [task_rq_lock+98/112] enqueue_task+0x12/0x50 (24)
Oct 25 16:53:56 mango kernel:  [decay_avgs_and_calculate_rates+487/624] activate_task+0x67/0x80 (16)
Oct 25 16:53:56 mango kernel:  [__mon_yday+161/268] preempt_schedule+0x11/0x80 (12)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (16)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (8)
Oct 25 16:53:56 mango kernel:  [kthread_create+120/208] check_preempt_timing+0x58/0x290 (8)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (4)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (60)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (12)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (20)
Oct 25 16:53:56 mango kernel:  [print_last_trace+247/256] do_futex+0x47/0xa0 (40)
Oct 25 16:53:56 mango kernel:  [get_futex_key+128/448] sys_futex+0xf0/0x100 (40)
Oct 25 16:53:56 mango kernel:  [syscall_fault+35/40] syscall_call+0x7/0xb (68)
Oct 25 16:53:56 mango kernel: preempt count: 00000001
Oct 25 16:53:56 mango kernel: . 1-level deep critical section nesting:
Oct 25 16:53:56 mango kernel: .. entry 1: print_traces+0x1d/0x70 [__kfifo_put+157/208] / (dump_stack+0x23/0x30 [show_registers+3/464])
Oct 25 16:53:56 mango kernel:
Oct 25 16:53:56 mango kernel: mozilla-bin/741: BUG in futex_wait at kernel/futex.c:542
Oct 25 16:53:56 mango kernel:  [add_preempt_count+130/224] futex_wait+0x192/0x1a0 (12)
Oct 25 16:53:56 mango kernel:  [dequeue_task+24/64] effective_prio+0x8/0x60 (80)
Oct 25 16:53:56 mango kernel:  [decay_avgs_and_calculate_rates+136/624] recalc_task_prio+0x98/0x190 (8)
Oct 25 16:53:56 mango kernel:  [task_rq_lock+98/112] enqueue_task+0x12/0x50 (24)
Oct 25 16:53:56 mango kernel:  [decay_avgs_and_calculate_rates+487/624] activate_task+0x67/0x80 (16)
Oct 25 16:53:56 mango kernel:  [__mon_yday+161/268] preempt_schedule+0x11/0x80 (12)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (16)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (8)
Oct 25 16:53:56 mango kernel:  [kthread_create+120/208] check_preempt_timing+0x58/0x290 (8)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (4)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (60)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (12)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (20)
Oct 25 16:53:56 mango kernel:  [print_last_trace+247/256] do_futex+0x47/0xa0 (40)
Oct 25 16:53:56 mango kernel:  [get_futex_key+128/448] sys_futex+0xf0/0x100 (40)
Oct 25 16:53:56 mango kernel:  [syscall_fault+35/40] syscall_call+0x7/0xb (68)
Oct 25 16:53:56 mango kernel: preempt count: 00000001
Oct 25 16:53:56 mango kernel: . 1-level deep critical section nesting:
Oct 25 16:53:56 mango kernel: .. entry 1: print_traces+0x1d/0x70 [__kfifo_put+157/208] / (dump_stack+0x23/0x30 [show_registers+3/464])
Oct 25 16:53:56 mango kernel:
Oct 25 16:53:56 mango kernel: mozilla-bin/741: BUG in futex_wait at kernel/futex.c:542
Oct 25 16:53:56 mango kernel:  [add_preempt_count+130/224] futex_wait+0x192/0x1a0 (12)
Oct 25 16:53:56 mango kernel:  [dequeue_task+24/64] effective_prio+0x8/0x60 (80)
Oct 25 16:53:56 mango kernel:  [decay_avgs_and_calculate_rates+136/624] recalc_task_prio+0x98/0x190 (8)
Oct 25 16:53:56 mango kernel:  [task_rq_lock+98/112] enqueue_task+0x12/0x50 (24)
Oct 25 16:53:56 mango kernel:  [decay_avgs_and_calculate_rates+487/624] activate_task+0x67/0x80 (16)
Oct 25 16:53:56 mango kernel:  [__mon_yday+161/268] preempt_schedule+0x11/0x80 (12)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (16)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (8)
Oct 25 16:53:56 mango kernel:  [kthread_create+120/208] check_preempt_timing+0x58/0x290 (8)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (4)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (60)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (12)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (20)
Oct 25 16:53:56 mango kernel:  [print_last_trace+247/256] do_futex+0x47/0xa0 (40)
Oct 25 16:53:56 mango kernel:  [get_futex_key+128/448] sys_futex+0xf0/0x100 (40)
Oct 25 16:53:56 mango kernel:  [syscall_fault+35/40] syscall_call+0x7/0xb (68)
Oct 25 16:53:56 mango kernel: preempt count: 00000001
Oct 25 16:53:56 mango kernel: . 1-level deep critical section nesting:
Oct 25 16:53:56 mango kernel: .. entry 1: print_traces+0x1d/0x70 [__kfifo_put+157/208] / (dump_stack+0x23/0x30 [show_registers+3/464])
Oct 25 16:53:56 mango kernel:
Oct 25 16:53:56 mango kernel: mozilla-bin/741: BUG in futex_wait at kernel/futex.c:542
Oct 25 16:53:56 mango kernel:  [add_preempt_count+130/224] futex_wait+0x192/0x1a0 (12)
Oct 25 16:53:56 mango kernel:  [dequeue_task+24/64] effective_prio+0x8/0x60 (80)
Oct 25 16:53:56 mango kernel:  [decay_avgs_and_calculate_rates+136/624] recalc_task_prio+0x98/0x190 (8)
Oct 25 16:53:56 mango kernel:  [task_rq_lock+98/112] enqueue_task+0x12/0x50 (24)
Oct 25 16:53:56 mango kernel:  [decay_avgs_and_calculate_rates+487/624] activate_task+0x67/0x80 (16)
Oct 25 16:53:56 mango kernel:  [__mon_yday+161/268] preempt_schedule+0x11/0x80 (12)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (16)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (8)
Oct 25 16:53:56 mango kernel:  [kthread_create+120/208] check_preempt_timing+0x58/0x290 (8)
Oct 25 16:53:56 mango kernel:  [wake_bit_function+5/96] sub_preempt_count+0x65/0xd0 (4)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (4)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (60)
Oct 25 16:53:56 mango kernel:  [__func__.5+7/19] preempt_schedule_irq+0x6f/0xa0 (12)
Oct 25 16:53:56 mango kernel:  [deactivate_task+0/64] default_wake_function+0x0/0x20 (20)
Oct 25 16:53:56 mango kernel:  [print_last_trace+247/256] do_futex+0x47/0xa0 (40)
Oct 25 16:53:56 mango kernel:  [get_futex_key+128/448] sys_futex+0xf0/0x100 (40)
Oct 25 16:53:56 mango kernel:  [syscall_fault+35/40] syscall_call+0x7/0xb (68)
Oct 25 16:53:56 mango kernel: preempt count: 00000001
Oct 25 16:53:56 mango kernel: . 1-level deep critical section nesting:
Oct 25 16:53:56 mango kernel: .. entry 1: print_traces+0x1d/0x70 [__kfifo_put+157/208] / (dump_stack+0x23/0x30 [show_registers+3/464])
Oct 25 16:53:56 mango kernel:

[gazillions more]

flo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 15:06                                                     ` Florian Schmidt
@ 2004-10-25 16:45                                                       ` K.R. Foley
  2004-10-26  8:29                                                         ` Eran Mann
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-25 16:45 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Florian Schmidt wrote:
> On Mon, 25 Oct 2004 16:10:08 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> 
>>>Btw: i still experience some "pauses". They are different now though.
>>>It seems i can trigger them by reloading a page in mozilla (not
>>>always). This BUG definetly looks related. Dunno, when exactly it
>>>happened (related to what i did at that moment), but it's the only one
>>>in dmesg output on this bootup. Each of the pauses is accompanied by a
>>>high cpu usage of ksoftirqd. I cannot retrigger the BUG though.
>>
>>please try -V0.2 - maybe the delayed-put fix is somehow related. (but
>>only maybe...)
>>
> 
> 
> doesn't seem so. V0.2 doesn't fix this for me. This time i got a BUG storm
> again in syslog (it kinda seems related to starting playback in xmms plus
> loading pages in mozilla. will boot again to verify):
> 

Well I have now gotten a couple of these now too (with V0.2). They all 
seem to be generated by firefox or thunderbird and the traces are all 
identical except for the offending process.


Oct 25 11:22:11 swdev14 kernel:
Oct 25 11:22:20 swdev14 kernel: thunderbird-bin/3946: BUG in futex_wait 
at kernel/futex.c:542
Oct 25 11:22:20 swdev14 kernel:  [<c0136389>] futex_wait+0x192/0x19c (12)
Oct 25 11:22:20 swdev14 kernel:  [<c0135646>] 
sub_preempt_count+0x75/0xd8 (72)
Oct 25 11:22:20 swdev14 kernel:  [<c02aa9f2>] _spin_unlock+0x1a/0x34 (4)
Oct 25 11:22:20 swdev14 kernel:  [<c02aa9f2>] _spin_unlock+0x1a/0x34 (84)
Oct 25 11:22:20 swdev14 kernel:  [<c01120ac>] mcount+0x14/0x18 (4)
Oct 25 11:22:20 swdev14 kernel:  [<c02aa9f2>] _spin_unlock+0x1a/0x34 (20)
Oct 25 11:22:20 swdev14 kernel:  [<c0118e15>] 
default_wake_function+0x0/0x1c (60)
Oct 25 11:22:20 swdev14 kernel:  [<c0118e15>] 
default_wake_function+0x0/0x1c (32)
Oct 25 11:22:20 swdev14 kernel:  [<c0136777>] sys_futex+0xf0/0xfc (12)
Oct 25 11:22:20 swdev14 kernel:  [<c01120ac>] mcount+0x14/0x18 (8)
Oct 25 11:22:20 swdev14 kernel:  [<c0136637>] do_futex+0x47/0x97 (20)
Oct 25 11:22:20 swdev14 kernel:  [<c0136777>] sys_futex+0xf0/0xfc (40)
Oct 25 11:22:20 swdev14 kernel:  [<c010623d>] 
sysenter_past_esp+0x52/0x71 (68)
Oct 25 11:22:20 swdev14 kernel: preempt count: 00000001
Oct 25 11:22:20 swdev14 kernel: . 1-level deep critical section nesting:
Oct 25 11:22:20 swdev14 kernel: .. entry 1: print_traces+0x1d/0x59 
[<c0135a28>] / (dump_stack+0x23/0x27 [<c01070db>])
Oct 25 11:22:20 swdev14 kernel:


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 10:40                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0 Ingo Molnar
  2004-10-25 11:08                                       ` K.R. Foley
@ 2004-10-25 18:52                                       ` K.R. Foley
  2004-10-25 20:38                                         ` Ingo Molnar
  2004-10-25 21:41                                         ` Esben Nielsen
  2004-10-25 21:47                                       ` Michal Schmidt
                                                         ` (2 subsequent siblings)
  4 siblings, 2 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-25 18:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:
> i have released the -V0 Real-Time Preemption patch, which can be
> downloaded from:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 

Actually pertaining to V0.2. I just got my UP system booted up on V0.2 
and got this in the log. I did notice that this is not new to this 
release. It has been here at least since U10.3. Sorry I didn't catch it 
sooner.

Oct 25 13:31:56 daffy kernel: IRQ#11 thread RT prio: 43.
Oct 25 13:31:56 daffy kernel: ip/2432: BUG in enable_irq at 
kernel/irq/manage.c:112
Oct 25 13:31:56 daffy kernel:  [<c01396ab>] enable_irq+0xfb/0x100 (12)
Oct 25 13:31:56 daffy kernel:  [<d0975614>] e100_up+0x114/0x200 [e100] (48)
Oct 25 13:31:56 daffy kernel:  [<d0976a20>] e100_open+0x30/0x80 [e100] (48)
Oct 25 13:31:56 daffy kernel:  [<c0113154>] mcount+0x14/0x18 (12)
Oct 25 13:31:56 daffy kernel:  [<c0265d98>] dev_open+0x88/0xa0 (20)
Oct 25 13:31:56 daffy kernel:  [<c02677cd>] dev_change_flags+0x5d/0x140 (28)
Oct 25 13:31:56 daffy kernel:  [<c02653ee>] __dev_get_by_name+0xe/0xd0 (8)
Oct 25 13:31:56 daffy kernel:  [<c02af3d7>] devinet_ioctl+0x277/0x6c0 (28)
Oct 25 13:31:56 daffy kernel:  [<c02b1894>] inet_ioctl+0x64/0xb0 (108)
Oct 25 13:31:56 daffy kernel:  [<c025c048>] sock_ioctl+0xc8/0x250 (28)
Oct 25 13:31:56 daffy kernel:  [<c0171cf7>] sys_ioctl+0xf7/0x260 (32)
Oct 25 13:31:56 daffy kernel:  [<c01064ed>] sysenter_past_esp+0x52/0x71 (48)
Oct 25 13:31:56 daffy kernel: preempt count: 00000002
Oct 25 13:31:56 daffy kernel: . 2-level deep critical section nesting:
Oct 25 13:31:56 daffy kernel: .. entry 1: enable_irq+0x33/0x100 
[<c01395e3>] / (e100_up+0x114/0x200 [e100] [<d0975614>])
Oct 25 13:31:56 daffy kernel: .. entry 2: print_traces+0x1d/0x60 
[<c0132ecd>] / (dump_stack+0x23/0x30 [<c0106b23>])
Oct 25 13:31:56 daffy kernel:

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 14:16                                                     ` Ingo Molnar
@ 2004-10-25 19:40                                                       ` Rui Nuno Capela
  2004-10-26  3:01                                                         ` Lee Revell
  2004-10-26  5:28                                                         ` Denis Vlasenko
  0 siblings, 2 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-25 19:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Florian Schmidt, K.R. Foley, linux-kernel, Lee Revell,
	mark_h_johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:
>> ok, i've added it and uploaded -V0.2 together with another fix: there
>> was a scheduler recursion possible via the delayed-put mechanism using
>> workqueues - now it's using its own separate lists and per-CPU
>> threads.
>
> -V0.2 seems to behave quite well on my testboxes - i'm unable to
> reproduce the selinux boot hang anymore.
>

OK. RT-V0.2 boots on my laptop (P4/UP), sometimes ;)

I know that my early impressions are illusive, rather subjective, but I do
feel overall behavior is getting worst, when regarding low-latency audio
work with jackd -R.

To put things straight with RT-V0.2, I get trouble with much less load
than even before.

I noticed that something is, now and then, topping the cpu to 99%, leaving
the system to a crawl, eventually returning back to normal. Can't figure
out who or what, just because ps or top are stalling to silence, only
returning results after when the crawl ends, which are of no useful
evidence. When I'm lucky enough to let top (and gkrellm) telling me
something, it does look like that most of the time is spent on kernel mode
(sys time) and none of the running processes are at stake. Puzzled. It's
just like you're about to loose confidence on the procps tools.

OTOH, jackd -R xruns are awfully back, even thought I (re)prioritize the
relevant IRQ thread handlers to be always higher than jackd's. This just
doesn't seem like an improvement, not at all :( IMO, given the xrun rate
I'm experiencing with RT-V0.2, it all seems that I'm running on vanilla
2.6.9, with pretty much instability added to the picture.

About that jackd -R issue, which has been hosing the complete system
occasionally, is still an annoyance on RT-V0.2. On this same laptop
(P4/UP), it does happen only if PREEMPT_REALTIME is set. However, I think
I've narrowed it's reproducibility: loading more than two fluidsynth
instances was the easiest way to get the box frozen in less than one
minute, at least on RT-U10.3. With RT-V0.2 is even easier, with just two
fluidsynth instances, or even one.

Sorry for this kind of rant, but I had to distress myself, somehow ;)

Nevertheless, I'll keep on going with my user level trials... and let you
informed, of course.

Cheers,
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 18:52                                       ` K.R. Foley
@ 2004-10-25 20:38                                         ` Ingo Molnar
  2004-10-26 10:53                                           ` K.R. Foley
  2004-10-25 21:41                                         ` Esben Nielsen
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-25 20:38 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> Actually pertaining to V0.2. I just got my UP system booted up on V0.2
> and got this in the log. I did notice that this is not new to this
> release. It has been here at least since U10.3. Sorry I didn't catch
> it sooner.
> 
> Oct 25 13:31:56 daffy kernel: IRQ#11 thread RT prio: 43.
> Oct 25 13:31:56 daffy kernel: ip/2432: BUG in enable_irq at 
> kernel/irq/manage.c:112

this is pretty harmless and has been happening in -mm for some time. The
e100 device will work fine afterwards.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 18:52                                       ` K.R. Foley
  2004-10-25 20:38                                         ` Ingo Molnar
@ 2004-10-25 21:41                                         ` Esben Nielsen
  1 sibling, 0 replies; 951+ messages in thread
From: Esben Nielsen @ 2004-10-25 21:41 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

I see the same problem. It courses no problems. I _think_ the enable_irq()
call have to be removed. I mailed the list about but nobody answered. I am
rather new to Linux kernel programming so I am not sure...

Esben


On Mon, 25 Oct 2004, K.R. Foley wrote:

> Ingo Molnar wrote:
> > i have released the -V0 Real-Time Preemption patch, which can be
> > downloaded from:
> > 
> >   http://redhat.com/~mingo/realtime-preempt/
> > 
> 
> Actually pertaining to V0.2. I just got my UP system booted up on V0.2 
> and got this in the log. I did notice that this is not new to this 
> release. It has been here at least since U10.3. Sorry I didn't catch it 
> sooner.
> 
> Oct 25 13:31:56 daffy kernel: IRQ#11 thread RT prio: 43.
> Oct 25 13:31:56 daffy kernel: ip/2432: BUG in enable_irq at 
> kernel/irq/manage.c:112
> Oct 25 13:31:56 daffy kernel:  [<c01396ab>] enable_irq+0xfb/0x100 (12)
> Oct 25 13:31:56 daffy kernel:  [<d0975614>] e100_up+0x114/0x200 [e100] (48)
> Oct 25 13:31:56 daffy kernel:  [<d0976a20>] e100_open+0x30/0x80 [e100] (48)
> Oct 25 13:31:56 daffy kernel:  [<c0113154>] mcount+0x14/0x18 (12)
> Oct 25 13:31:56 daffy kernel:  [<c0265d98>] dev_open+0x88/0xa0 (20)
> Oct 25 13:31:56 daffy kernel:  [<c02677cd>] dev_change_flags+0x5d/0x140 (28)
> Oct 25 13:31:56 daffy kernel:  [<c02653ee>] __dev_get_by_name+0xe/0xd0 (8)
> Oct 25 13:31:56 daffy kernel:  [<c02af3d7>] devinet_ioctl+0x277/0x6c0 (28)
> Oct 25 13:31:56 daffy kernel:  [<c02b1894>] inet_ioctl+0x64/0xb0 (108)
> Oct 25 13:31:56 daffy kernel:  [<c025c048>] sock_ioctl+0xc8/0x250 (28)
> Oct 25 13:31:56 daffy kernel:  [<c0171cf7>] sys_ioctl+0xf7/0x260 (32)
> Oct 25 13:31:56 daffy kernel:  [<c01064ed>] sysenter_past_esp+0x52/0x71 (48)
> Oct 25 13:31:56 daffy kernel: preempt count: 00000002
> Oct 25 13:31:56 daffy kernel: . 2-level deep critical section nesting:
> Oct 25 13:31:56 daffy kernel: .. entry 1: enable_irq+0x33/0x100 
> [<c01395e3>] / (e100_up+0x114/0x200 [e100] [<d0975614>])
> Oct 25 13:31:56 daffy kernel: .. entry 2: print_traces+0x1d/0x60 
> [<c0132ecd>] / (dump_stack+0x23/0x30 [<c0106b23>])
> Oct 25 13:31:56 daffy kernel:
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 10:40                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0 Ingo Molnar
  2004-10-25 11:08                                       ` K.R. Foley
  2004-10-25 18:52                                       ` K.R. Foley
@ 2004-10-25 21:47                                       ` Michal Schmidt
  2004-10-25 23:04                                       ` Remi Colinet
  2004-10-27  0:15                                       ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Ingo Molnar
  4 siblings, 0 replies; 951+ messages in thread
From: Michal Schmidt @ 2004-10-25 21:47 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:
> i have released the -V0 Real-Time Preemption patch, which can be
> downloaded from:
> 
>   http://redhat.com/~mingo/realtime-preempt/

I'm testing -V0.2. I'm getting reproducible deadlocks very soon after I 
start anything talking to network (firefox, links, licq).
Example with links:

BUG: semaphore recursion deadlock detected!
.. current task links/4724 is already holding c0430840.
  [<c01c7546>] __rwsem_deadlock+0x176/0x190 (12)
  [<c02cb966>] down_write+0x116/0x250 (20)
  [<c01c743c>] __rwsem_deadlock+0x6c/0x190 (28)
  [<c02cb839>] down_read+0x39/0x50 (20)
  [<c02cb8b2>] down_write+0x62/0x250 (4)
  [<c02cb966>] down_write+0x116/0x250 (24)
  [<c02cb839>] down_read+0x39/0x50 (48)
  [<c0114310>] mcount+0x14/0x18 (12)
  [<c0271c91>] dev_queue_xmit_nit+0x41/0x130 (28)
  [<c01c7bf6>] up_write+0x26/0x60 (12)
  [<c0281443>] qdisc_restart+0x223/0x250 (24)
  [<c027221d>] dev_queue_xmit+0x1ad/0x260 (12)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c027222f>] dev_queue_xmit+0x1bf/0x260 (36)
  [<c027856e>] neigh_resolve_output+0xfe/0x240 (32)
  [<c029327e>] ip_finish_output2+0xbe/0x240 (56)
  [<c027dc45>] nf_hook_slow+0xd5/0x130 (36)
  [<c02931c0>] ip_finish_output2+0x0/0x240 (28)
  [<c0290a8b>] ip_finish_output+0x26b/0x270 (32)
  [<c02931c0>] ip_finish_output2+0x0/0x240 (24)
  [<c02931aa>] dst_output+0x1a/0x30 (32)
  [<c027dc45>] nf_hook_slow+0xd5/0x130 (12)
  [<c0293190>] dst_output+0x0/0x30 (28)
  [<c029114a>] ip_queue_xmit+0x45a/0x570 (32)
  [<c0293190>] dst_output+0x0/0x30 (24)
  [<c0135c75>] sub_preempt_count+0x65/0xd0 (24)
  [<c01c79f8>] __up_write+0x148/0x320 (8)
  [<c0135708>] check_preempt_timing+0x58/0x2e0 (8)
  [<c0135c75>] sub_preempt_count+0x65/0xd0 (4)
  [<c01c79f8>] __up_write+0x148/0x320 (4)
  [<c0134f9d>] __mcount+0x1d/0x20 (28)
  [<c01c727e>] rwsem_owner_del+0xe/0x120 (4)
  [<c0134f9d>] __mcount+0x1d/0x20 (52)
  [<c02a875e>] tcp_v4_send_check+0xe/0xf0 (4)
  [<c02a2259>] tcp_transmit_skb+0x439/0x880 (4)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c02a879f>] tcp_v4_send_check+0x4f/0xf0 (20)
  [<c02a2302>] tcp_transmit_skb+0x4e2/0x880 (32)
  [<c0114310>] mcount+0x14/0x18 (28)
  [<c02a4f96>] tcp_send_ack+0xa6/0xf0 (52)
  [<c0297ccc>] tcp_recvmsg+0x2ec/0x750 (36)
  [<c0134f9d>] __mcount+0x1d/0x20 (20)
  [<c0114310>] mcount+0x14/0x18 (44)
  [<c026bb59>] sock_common_recvmsg+0x59/0x70 (20)
  [<c0267f78>] sock_aio_read+0xf8/0x110 (48)
  [<c0114310>] mcount+0x14/0x18 (100)
  [<c015e7fa>] do_sync_read+0xaa/0xe0 (20)
  [<c01344a0>] autoremove_wake_function+0x0/0x60 (116)
  [<c01c11b8>] dummy_file_permission+0x8/0x10 (12)
  [<c015e8d6>] vfs_read+0xa6/0x140 (4)
  [<c015e933>] vfs_read+0x103/0x140 (36)
  [<c0114310>] mcount+0x14/0x18 (24)
  [<c015ebe0>] sys_read+0x50/0x80 (20)
  [<c010527b>] syscall_call+0x7/0xb (44)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: down_write+0x249/0x250 [<c02cba99>] / (down_read+0x39/0x50 
[<c02cb839>])
.. entry 2: print_traces+0x1d/0x90 [<c0135fcd>] / (dump_stack+0x23/0x30 
[<c01060b3>])

BUG: circular semaphore deadlock: ksoftirqd/0/2 is blocked on c0430840, 
deadlocking links/4724
f7c2be00 00000046 f7c24020 c03bfd60 00000202 00001db4 f7c2a000 f7c24020
        f7c24020 f7c2bdec 00000227 e443e1ce 0000001d f7c24020 f7c242b4 
f7c2a000
        f7c24020 f7c24020 f7c2be24 c02ca79f f7c2be24 00000086 c03e3b00 
c02cb9d0
Call Trace:
  [<c02ca79f>] schedule+0x2f/0xe0 (80)
  [<c02cb9d0>] down_write+0x180/0x250 (16)
  [<c02cb9b1>] down_write+0x161/0x250 (20)
  [<c02cb839>] down_read+0x39/0x50 (48)
  [<c0114310>] mcount+0x14/0x18 (12)
  [<c027db97>] nf_hook_slow+0x27/0x130 (28)
  [<c0134f9d>] __mcount+0x1d/0x20 (24)
  [<c028d4ee>] ip_rcv+0xe/0x540 (4)
  [<c027274d>] netif_receive_skb+0x12d/0x240 (4)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c028d940>] ip_rcv+0x460/0x540 (20)
  [<c028dbc0>] ip_rcv_finish+0x0/0x300 (24)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c027274d>] netif_receive_skb+0x12d/0x240 (28)
  [<c0270008>] gnet_stats_start_copy+0x18/0x40 (20)
  [<c0272a7f>] net_rx_action+0x7f/0x1a0 (4)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c02728e8>] process_backlog+0x88/0x1a0 (20)
  [<c0272a7f>] net_rx_action+0x7f/0x1a0 (40)
  [<c01237c7>] ___do_softirq+0x87/0xd0 (36)
  [<c0123898>] _do_softirq+0x8/0x30 (8)
  [<c0123c84>] ksoftirqd+0xb4/0x100 (4)
  [<c01238b0>] _do_softirq+0x20/0x30 (28)
  [<c0123c84>] ksoftirqd+0xb4/0x100 (8)
  [<c0133eea>] kthread+0xaa/0xb0 (24)
  [<c0123bd0>] ksoftirqd+0x0/0x100 (20)
  [<c0133e40>] kthread+0x0/0xb0 (12)
  [<c0103319>] kernel_thread_helper+0x5/0xc (16)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __schedule+0x4e/0x5f0 [<c02ca1ce>] / (schedule+0x2f/0xe0 
[<c02ca79f>])
.. entry 2: __schedule+0xdd/0x5f0 [<c02ca25d>] / (schedule+0x2f/0xe0 
[<c02ca79f>])


Michal

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 10:40                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0 Ingo Molnar
                                                         ` (2 preceding siblings ...)
  2004-10-25 21:47                                       ` Michal Schmidt
@ 2004-10-25 23:04                                       ` Remi Colinet
  2004-10-27  0:15                                       ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Ingo Molnar
  4 siblings, 0 replies; 951+ messages in thread
From: Remi Colinet @ 2004-10-25 23:04 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:

>i have released the -V0 Real-Time Preemption patch, which can be
>downloaded from:
>
>  http://redhat.com/~mingo/realtime-preempt/
>  
>

I'am facing three different BUG messages :


Oct 26 01:32:46 tigre02 kernel: BUG: sleeping function called from 
invalid context kpnpbiosd(229) at kernel/mutex.c:28
Oct 26 01:32:46 tigre02 kernel: in_atomic():1 [00000001], irqs_disabled():0
Oct 26 01:32:46 tigre02 kernel:  [<c0121c4a>] __might_sleep+0xca/0xe0 (12)
Oct 26 01:32:46 tigre02 kernel:  [<c013e268>] _mutex_lock+0x38/0x50 (36)
Oct 26 01:32:46 tigre02 kernel:  [<c013e2d6>] 
_mutex_lock_irqsave+0x16/0x20 (24)
Oct 26 01:32:46 tigre02 kernel:  [<c02e5237>] 
pnp_bios_dock_station_info+0x97/0x1f0 (12)
Oct 26 01:32:46 tigre02 kernel:  [<c02e4371>] pnp_dock_thread+0x81/0x100 
(48)
Oct 26 01:32:46 tigre02 kernel:  [<c02e42f0>] pnp_dock_thread+0x0/0x100 (16)
Oct 26 01:32:46 tigre02 kernel:  [<c01033f9>] 
kernel_thread_helper+0x5/0xc (16)
Oct 26 01:32:46 tigre02 kernel: preempt count: 00000002
Oct 26 01:32:46 tigre02 kernel: . 2-level deep critical section nesting:
Oct 26 01:32:46 tigre02 kernel: .. entry 1: 
pnp_bios_dock_station_info+0x4f/0x1f0 [<c02e51ef>] / 
(pnp_dock_thread+0x81/0x100 [<c02e4371>])
Oct 26 01:32:46 tigre02 kernel: .. entry 2: print_traces+0x1d/0x60 
[<c013fa7d>] / (dump_stack+0x23/0x30 [<c01064d3>])
Oct 26 01:32:46 tigre02 kernel:


Oct 26 01:32:45 tigre02 kernel: BUG: using smp_processor_id() in 
preemptible [00000001] code: usb.agent/1479
Oct 26 01:32:45 tigre02 kernel: caller is store_stackinfo+0x5d/0xb0
Oct 26 01:32:45 tigre02 kernel:  [<c011f0d7>] smp_processor_id+0xb7/0xc0 
(12)
Oct 26 01:32:45 tigre02 kernel:  [<c0158fcd>] store_stackinfo+0x5d/0xb0 (8)
Oct 26 01:32:45 tigre02 kernel:  [<c0158fcd>] store_stackinfo+0x5d/0xb0 (24)
Oct 26 01:32:45 tigre02 kernel:  [<c015ac1a>] 
cache_free_debugcheck+0x1aa/0x390 (28)
Oct 26 01:32:45 tigre02 kernel:  [<c018446e>] __user_walk+0x5e/0x80 (12)
Oct 26 01:32:45 tigre02 kernel:  [<c015bba3>] kmem_cache_free+0x33/0xf0 (4)
Oct 26 01:32:45 tigre02 kernel:  [<c0116454>] mcount+0x14/0x18 (8)
Oct 26 01:32:45 tigre02 kernel:  [<c015bbb6>] kmem_cache_free+0x46/0xf0 (28)
Oct 26 01:32:45 tigre02 kernel:  [<c018446e>] __user_walk+0x5e/0x80 (12)
Oct 26 01:32:45 tigre02 kernel:  [<c018446e>] __user_walk+0x5e/0x80 (20)
Oct 26 01:32:45 tigre02 kernel:  [<c017e323>] vfs_stat+0x23/0x60 (32)
Oct 26 01:32:45 tigre02 kernel:  [<c013e8cd>] __mcount+0x1d/0x30 (56)
Oct 26 01:32:45 tigre02 kernel:  [<c017eaae>] sys_stat64+0xe/0x50 (4)
Oct 26 01:32:45 tigre02 kernel:  [<c0105541>] 
sysenter_past_esp+0x52/0x71 (4)
Oct 26 01:32:45 tigre02 kernel:  [<c0116454>] mcount+0x14/0x18 (8)
Oct 26 01:32:45 tigre02 kernel:  [<c017eac0>] sys_stat64+0x20/0x50 (20)
Oct 26 01:32:45 tigre02 kernel:  [<c0291659>] copy_to_user+0x69/0x80 (24)
Oct 26 01:32:45 tigre02 kernel:  [<c01339eb>] 
sys_rt_sigprocmask+0x9b/0xf0 (28)
Oct 26 01:32:45 tigre02 kernel:  [<c0105541>] 
sysenter_past_esp+0x52/0x71 (48)
Oct 26 01:32:45 tigre02 kernel: preempt count: 00000002
Oct 26 01:32:45 tigre02 kernel: . 2-level deep critical section nesting:
Oct 26 01:32:45 tigre02 kernel: .. entry 1: smp_processor_id+0x5f/0xc0 
[<c011f07f>] / (store_stackinfo+0x5d/0xb0 [<c0158fcd>])
Oct 26 01:32:46 tigre02 kernel: .. entry 2: print_traces+0x1d/0x60 
[<c013fa7d>] / (dump_stack+0x23/0x30 [<c01064d3>])
Oct 26 01:32:46 tigre02 kernel:


Oct 26 01:32:46 tigre02 kernel: BUG: using smp_processor_id() in 
preemptible [00000001] code: rc.sysinit/1628
Oct 26 01:32:46 tigre02 kernel: caller is store_stackinfo+0x5d/0xb0
Oct 26 01:32:46 tigre02 kernel:  [<c011f0d7>] smp_processor_id+0xb7/0xc0 
(12)
Oct 26 01:32:46 tigre02 kernel:  [<c0158fcd>] store_stackinfo+0x5d/0xb0 (8)
Oct 26 01:32:46 tigre02 kernel:  [<c0158fcd>] store_stackinfo+0x5d/0xb0 (24)
Oct 26 01:32:46 tigre02 kernel:  [<c015ac1a>] 
cache_free_debugcheck+0x1aa/0x390 (28)
Oct 26 01:32:46 tigre02 kernel:  [<c0121d4c>] free_task+0x1c/0x40 (12)
Oct 26 01:32:46 tigre02 kernel:  [<c015bd2e>] kfree+0x5e/0x120 (4)
Oct 26 01:32:46 tigre02 kernel:  [<c0116454>] mcount+0x14/0x18 (8)
Oct 26 01:32:46 tigre02 kernel:  [<c015bd41>] kfree+0x71/0x120 (28)
Oct 26 01:32:46 tigre02 kernel:  [<c0121d4c>] free_task+0x1c/0x40 (12)
Oct 26 01:32:46 tigre02 kernel:  [<c0121d4c>] free_task+0x1c/0x40 (28)
Oct 26 01:32:46 tigre02 kernel:  [<c0126f9c>] release_task+0xec/0x1a0 (20)
Oct 26 01:32:46 tigre02 kernel:  [<c0129617>] 
wait_task_zombie+0x4b7/0x5d0 (40)
Oct 26 01:32:46 tigre02 kernel:  [<c013e8cd>] __mcount+0x1d/0x30 (28)
Oct 26 01:32:46 tigre02 kernel:  [<c0271ed8>] dummy_task_wait+0x8/0x10 (4)
Oct 26 01:32:46 tigre02 kernel:  [<c0128ed1>] eligible_child+0x71/0xf0 (4)
Oct 26 01:32:46 tigre02 kernel:  [<c0116454>] mcount+0x14/0x18 (8)
Oct 26 01:32:46 tigre02 kernel:  [<c0271ed8>] dummy_task_wait+0x8/0x10 (20)
Oct 26 01:32:46 tigre02 kernel:  [<c012a1ce>] do_wait+0x4ae/0x590 (24)
Oct 26 01:32:46 tigre02 kernel:  [<c0291501>] 
__copy_to_user_ll+0x11/0x80 (40)
Oct 26 01:32:46 tigre02 kernel:  [<c011f1b0>] 
default_wake_function+0x0/0x20 (28)
Oct 26 01:32:46 tigre02 kernel:  [<c011f1b0>] 
default_wake_function+0x0/0x20 (32)
Oct 26 01:32:46 tigre02 kernel:  [<c012a3bc>] sys_waitpid+0x2c/0x30 (12)
Oct 26 01:32:46 tigre02 kernel:  [<c0116454>] mcount+0x14/0x18 (8)
Oct 26 01:32:46 tigre02 kernel:  [<c012a388>] sys_wait4+0x48/0x50 (20)
Oct 26 01:32:46 tigre02 kernel:  [<c012a3bc>] sys_waitpid+0x2c/0x30 (28)
Oct 26 01:32:46 tigre02 kernel:  [<c0105541>] 
sysenter_past_esp+0x52/0x71 (24)
Oct 26 01:32:46 tigre02 kernel: preempt count: 00000002
Oct 26 01:32:46 tigre02 kernel: . 2-level deep critical section nesting:
Oct 26 01:32:47 tigre02 kernel: .. entry 1: smp_processor_id+0x5f/0xc0 
[<c011f07f>] / (store_stackinfo+0x5d/0xb0 [<c0158fcd>])
Oct 26 01:32:47 tigre02 kernel: .. entry 2: print_traces+0x1d/0x60 
[<c013fa7d>] / (dump_stack+0x23/0x30 [<c01064d3>])
Oct 26 01:32:47 tigre02 kernel:

The kernel is stable (X started).

Remi

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 19:40                                                       ` Rui Nuno Capela
@ 2004-10-26  3:01                                                         ` Lee Revell
  2004-10-26  3:11                                                           ` K.R. Foley
  2004-10-26  5:11                                                           ` Fernando Pablo Lopez-Lezcano
  2004-10-26  5:28                                                         ` Denis Vlasenko
  1 sibling, 2 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-26  3:01 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, Florian Schmidt, K.R. Foley, linux-kernel,
	mark_h_johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Mon, 2004-10-25 at 20:40 +0100, Rui Nuno Capela wrote:
> OTOH, jackd -R xruns are awfully back, even thought I (re)prioritize the
> relevant IRQ thread handlers to be always higher than jackd's.

Actually they should be lower, except the soundcard.  I was only able to
get the xrun free behavior of T3 by setting all IRQ threads except the
soundcard to SCHED_OTHER.  Especially important was setting ksoftirqd to
SCHED_OTHER, this actually may have been the only one necessary.

The relative priorities of jackd and the soundcard irq do not matter as
these two should never contend (aka they are never both runnable at the
same time).

Lee 


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26  3:01                                                         ` Lee Revell
@ 2004-10-26  3:11                                                           ` K.R. Foley
  2004-10-26  3:58                                                             ` Lee Revell
  2004-10-26  5:11                                                           ` Fernando Pablo Lopez-Lezcano
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-26  3:11 UTC (permalink / raw)
  To: Lee Revell
  Cc: Rui Nuno Capela, Ingo Molnar, Florian Schmidt, linux-kernel,
	mark_h_johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Lee Revell wrote:
> On Mon, 2004-10-25 at 20:40 +0100, Rui Nuno Capela wrote:
> 
>>OTOH, jackd -R xruns are awfully back, even thought I (re)prioritize the
>>relevant IRQ thread handlers to be always higher than jackd's.
> 
> 
> Actually they should be lower, except the soundcard.  I was only able to
> get the xrun free behavior of T3 by setting all IRQ threads except the
> soundcard to SCHED_OTHER.  Especially important was setting ksoftirqd to
> SCHED_OTHER, this actually may have been the only one necessary.
> 
> The relative priorities of jackd and the soundcard irq do not matter as
> these two should never contend (aka they are never both runnable at the
> same time).
> 
> Lee 
> 
> 
Not being familiar with jack, does it use rtc?

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26  3:11                                                           ` K.R. Foley
@ 2004-10-26  3:58                                                             ` Lee Revell
  2004-10-26  4:15                                                               ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-26  3:58 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Rui Nuno Capela, Ingo Molnar, Florian Schmidt, linux-kernel,
	mark_h_johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Mon, 2004-10-25 at 22:11 -0500, K.R. Foley wrote:
>  
> Not being familiar with jack, does it use rtc?
> 

No it normally uses the soundcard for timing.  For testing there is a
dummy backend that just usleep()s.  This makes a pretty useful latency
tester.

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26  3:58                                                             ` Lee Revell
@ 2004-10-26  4:15                                                               ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-26  4:15 UTC (permalink / raw)
  To: Lee Revell
  Cc: Rui Nuno Capela, Ingo Molnar, Florian Schmidt, linux-kernel,
	mark_h_johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Lee Revell wrote:
> On Mon, 2004-10-25 at 22:11 -0500, K.R. Foley wrote:
> 
>> 
>>Not being familiar with jack, does it use rtc?
>>
> 
> 
> No it normally uses the soundcard for timing.  For testing there is a
> dummy backend that just usleep()s.  This makes a pretty useful latency
> tester.
> 
> Lee
> 
> 
Just wondered. I am writing an email right now about my results with
V0.2, one of which happens to be that amlat will kill any of my systems
running it.

kr


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26  3:01                                                         ` Lee Revell
  2004-10-26  3:11                                                           ` K.R. Foley
@ 2004-10-26  5:11                                                           ` Fernando Pablo Lopez-Lezcano
  2004-10-26 17:25                                                             ` Lee Revell
  1 sibling, 1 reply; 951+ messages in thread
From: Fernando Pablo Lopez-Lezcano @ 2004-10-26  5:11 UTC (permalink / raw)
  To: Lee Revell
  Cc: Rui Nuno Capela, Ingo Molnar, Florian Schmidt, K.R. Foley,
	linux-kernel, mark_h_johnson, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Alexander Batyrshin,
	Fernando Pablo Lopez-Lezcano

On Mon, 2004-10-25 at 20:01, Lee Revell wrote: 
> On Mon, 2004-10-25 at 20:40 +0100, Rui Nuno Capela wrote:
> > OTOH, jackd -R xruns are awfully back, even thought I (re)prioritize the
> > relevant IRQ thread handlers to be always higher than jackd's.
> 
> Actually they should be lower, except the soundcard.  I was only able to
> get the xrun free behavior of T3 by setting all IRQ threads except the
> soundcard to SCHED_OTHER.  Especially important was setting ksoftirqd to
> SCHED_OTHER, this actually may have been the only one necessary.
> 
> The relative priorities of jackd and the soundcard irq do not matter as
> these two should never contend (aka they are never both runnable at the
> same time).

What happens when one is blessed with a laptop where everything is
sharing an interrupt?

$ cat /proc/interrupts
           CPU0
  0:    2372239          XT-PIC  timer  0/72239
  1:       5362          XT-PIC  i8042  0/5362
  2:          0          XT-PIC  cascade  0/0
  8:          1          XT-PIC  rtc  0/1
  9:     616176          XT-PIC  acpi, uhci_hcd, uhci_hcd, uhci_hcd,
eth0, yenta, yenta, Intel 82801CA-ICH3, radeon@PCI:1:0:0  0/16176
11:         37          XT-PIC  sonypi  0/35
12:      28392          XT-PIC  i8042  0/28392
14:      21078          XT-PIC  ide0  0/21078
15:        472          XT-PIC  ide1  0/472
NMI:          0
LOC:          0
ERR:          0
MIS:          0

I'm running U10.3 and I'm consistently seeing xruns when Jack clients
start and stop, something I would not see before (I have not tried the
latest V series yet). I have tried changing the priority of IRQ9 and the
scheduler but I still see the xruns. Yesterday I tried enabling
preempt_thresh to a low value but did not see hits when the xruns
occurred. Maybe I'm missing something I need to do...

-- Fernando



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 19:40                                                       ` Rui Nuno Capela
  2004-10-26  3:01                                                         ` Lee Revell
@ 2004-10-26  5:28                                                         ` Denis Vlasenko
  2004-10-26 10:40                                                           ` Rui Nuno Capela
  1 sibling, 1 reply; 951+ messages in thread
From: Denis Vlasenko @ 2004-10-26  5:28 UTC (permalink / raw)
  To: Rui Nuno Capela; +Cc: linux-kernel

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

On Monday 25 October 2004 22:40, Rui Nuno Capela wrote:
> Ingo Molnar wrote:
> >> ok, i've added it and uploaded -V0.2 together with another fix: there
> >> was a scheduler recursion possible via the delayed-put mechanism using
> >> workqueues - now it's using its own separate lists and per-CPU
> >> threads.
> >
> > -V0.2 seems to behave quite well on my testboxes - i'm unable to
> > reproduce the selinux boot hang anymore.
> >
> 
> OK. RT-V0.2 boots on my laptop (P4/UP), sometimes ;)
> 
> I know that my early impressions are illusive, rather subjective, but I do
> feel overall behavior is getting worst, when regarding low-latency audio
> work with jackd -R.
> 
> To put things straight with RT-V0.2, I get trouble with much less load
> than even before.
> 
> I noticed that something is, now and then, topping the cpu to 99%, leaving
> the system to a crawl, eventually returning back to normal. Can't figure
> out who or what, just because ps or top are stalling to silence, only
> returning results after when the crawl ends, which are of no useful
> evidence. When I'm lucky enough to let top (and gkrellm) telling me
> something, it does look like that most of the time is spent on kernel mode
> (sys time) and none of the running processes are at stake. Puzzled. It's
> just like you're about to loose confidence on the procps tools.

<shameless plug>
Maybe this program will be useful. It is designed to give you
overall system statistics without the need to scan entire /proc/NNN
forest. Together with nice -20, it will hopefully not stall.

Compiled with dietlibc. If you will have trouble compiling it, binary is
attached too.

Latest version is 0.9 but it seems I forgot it in my home box :(
</shameless plug>
--
vda



[-- Attachment #2: nmeter --]
[-- Type: application/x-executable, Size: 9960 bytes --]

[-- Attachment #3: nmeter.c --]
[-- Type: text/x-csrc, Size: 22121 bytes --]

// Based on nanotop.c from floppyfw project
// Released under GPL
// Contact me: vda@port.imtp.ilyichevsk.odessa.ua

//TODO: 
// simplify code
// /proc/locks
// /proc/stat:
// disk_io: (3,0):(22272,17897,410702,4375,54750)
// btime 1059401962

//#include <ctype.h>
#include <sys/time.h>	// gettimeofday
#include <string.h>	// strstr etc
#include <stdarg.h>	// f(...)
#include <fcntl.h>	// O_RDONLY

#define VERSION_STR "0.7"
#define DELIM_CHAR ' '

//==============
#define NL "\n"
typedef unsigned long long ullong;
typedef unsigned long ulong;

typedef ulong sample_t;

//==============
#define proc_file_size 4096

typedef struct proc_file {
    char *name;
    int gen;
    char *file;
} proc_file;

proc_file proc_stat = { "/proc/stat", -1 };
proc_file proc_net_dev = { "/proc/net/dev", -1 };
proc_file proc_meminfo = { "/proc/meminfo", -1 };
proc_file proc_diskstats = { "/proc/diskstats", -1 };
struct timeval tv;
int gen=-1;
int is26=0;

//==============
#if 0
#include <stdio.h>
void dprintf(const char *fmt, ...) {
    va_list ap;
    va_start(ap, fmt);
    vprintf(fmt, ap);
    va_end(ap);
}
#else
extern void dprintf(const char *fmt, ...) {}
#endif

//==============
char outbuf[4096];
char *cur_outbuf = outbuf;

extern inline void reset_outbuf() {
    cur_outbuf = outbuf;
}

extern inline int outbuf_count() {
    return cur_outbuf-outbuf;
}

extern inline void print_outbuf() {
    if(cur_outbuf>outbuf) {
	write(1, outbuf, cur_outbuf-outbuf);
	cur_outbuf = outbuf;
    }
}

void put(const char *s) {
    int sz = strlen(s);
    if(sz > (outbuf+sizeof(outbuf))-cur_outbuf)
	sz = (outbuf+sizeof(outbuf))-cur_outbuf;
    memcpy(cur_outbuf, s, sz);
    cur_outbuf += sz;
}

void put_c(char c) {
    if(cur_outbuf < outbuf+sizeof(outbuf))
	*cur_outbuf++ = c;
}

//==============
char* simple_itoa(char *s, int sz, unsigned long v, int pad) {
//==============
    s += sz;
    *--s = '\0';
    while (--sz > 0) {
        *--s = "0123456789"[v%10];
        pad--;
        v /= 10;
        if(!v && pad<=0) break;
    }
    return s;
}

//==============
int readfile_z(char *buf, int sz, const char* fname) {
//==============
    int fd;
    fd=open(fname,O_RDONLY);
    if(fd<0) return 1;
    sz = read(fd,buf,sz-1);
    close(fd);
    if(sz<0) {
	buf[0]='\0';
	return 1;
    }
    buf[sz]='\0';
    return 0;
}

//==============
int rdval(const char* p, const char* key, sample_t *vec, ...) {
//==============
    va_list arg_ptr;
    int indexline;
    int indexnext;

    p = strstr(p,key);
    if(!p) return 1;
	
    p += strlen(key);
    va_start(arg_ptr, vec);
    indexline = 1;
    indexnext = va_arg(arg_ptr, int);
    while(1) {
    	while(*p==' ' || *p=='\t') p++;
	if(*p=='\n' || *p=='\0') break;

        if(indexline == indexnext) { // read this value
            *vec++ = strtoul(p, NULL, 10);
            indexnext = va_arg(arg_ptr, int);
        }
    	while(*p > ' ') p++; // skip over value
        indexline++;
    }
    va_end(arg_ptr);
    return 0;
}

//==============
int rdval_diskstats(const char* p, sample_t *vec) {
//   1    2 3   4     5     6(rd)  7      8     9     10(wr) 11      12 13    14
//   3    0 hda 51292 14441 841783 926052 25717 79650 843256 3029804 0 148459 3956933
//   3    1 hda1 0 0 0 0 <- ignore if only 4 fields
//==============
    sample_t rd;
    int indexline = 0;
    vec[0] = 0;
    vec[1] = 0;
    while(1) {
        indexline++;
        while(*p==' ' || *p=='\t') p++;
        if(*p=='\0') break;
        if(*p=='\n') {
            indexline = 0;
	    p++;
            continue;
        }
        if(indexline == 6) {
            rd = strtoul(p, NULL, 10);
        } else
        if(indexline == 10) {
            vec[0] += rd;  // TODO: *sectorsize (don't know how to find out sectorsize)
            vec[1] += strtoul(p, NULL, 10);
    	    while(*p!='\n' && *p!='\0') p++;
	    continue;
        }
        while(*p > ' ') p++; // skip over value
    }
    return 0;
}

//==============
void scale(sample_t ul) {
//==============
    char buf[5];
    int index = 0;
    ul *= 10;
    if(ul>9999*10) { // do not scale if 9999 or less
	while(ul >= 10000) {
	    ul /= 1024;
	    index++;
	}
    }

    if(!index) {/* use 1234 format */
	buf[0] = " 123456789"[ul/10000];
	if(buf[0]== ' ') buf[1] = " 123456789"[ul/1000%10];
	            else buf[1] = "0123456789"[ul/1000%10];
	if(buf[1]== ' ') buf[2] = " 123456789"[ul/100%10];
                    else buf[2] = "0123456789"[ul/100%10];
	buf[3] = "0123456789"[ul/10%10];
    } else if(ul>=100) { /* use 123k format */
	if( (buf[0]= " 123456789"[ul/1000]) == ' ')
	    buf[1] = " 123456789"[ul/100%10];
	else
	    buf[1] = "0123456789"[ul/100%10];
	buf[2] = "0123456789"[ul/10%10];
	buf[3] = " kMGTEP"[index];
    } else { /* use 1.2M format */
	buf[0] = "0123456789"[ul/10];
	buf[1] = '.';
	buf[2] = "0123456789"[ul%10];
	buf[3] = " kMGTEP"[index];
    }
    buf[4] = 0;
    put(buf);
}

//==============
const char* prepare(proc_file *pf) {
    if(!pf->file) pf->file = (char*)malloc(proc_file_size);
    if(pf->gen != gen) {
	pf->gen = gen;
	readfile_z(pf->file, proc_file_size, pf->name);
    }
    return pf->file;
}

//==============
#define S_STAT(a) \
typedef struct a { \
    struct s_stat *next; \
    int (*collect)(struct a *s); \
    const char *label; \
    int width;

S_STAT(s_stat)
} s_stat;

#define MALLOC_STAT(type,var) type *var = (type*)malloc(sizeof(type))

//==============
S_STAT(cpu_stat)
    sample_t old[4];
    int bar_sz;
    char *bar;
} cpu_stat;

//==============
int collect_cpu(cpu_stat *s) {
//==============
    sample_t data[4];
    sample_t frac[4];
    sample_t all = 0;
    int norm_all = 0;
    int bar_sz = s->bar_sz;
    char *bar = s->bar;
    int i;

    if(rdval(prepare(&proc_stat), "cpu ", data, 1, 2, 3, 4))
	return 1;
    
    put_c('[');

//dprintf("data1:");
    for(i=0; i<4; i++) {
	sample_t old = s->old[i];
	if(data[i] < old) old = data[i];	//sanitize
        s->old[i] = data[i];
        all += (data[i] -= old);
//dprintf(" %lu",data[i]);
    }
//dprintf(" all %lu\n",all);

    if(all) {
//dprintf("data2:");
	for(i=0; i<4; i++) {
	    ullong t = bar_sz*(ullong)data[i];
	    norm_all += data[i] = t / all;
	    frac[i] = t % all;
//dprintf(" %lu/%lu",data[i],frac[i]);
	}
//dprintf(" norm_all %lu\n",norm_all);
    
	while(norm_all<bar_sz) {
	    sample_t max=frac[0]; int pos=0;
	    //for(i=1; i<4; i++) if(frac[i]>=max) max=frac[i], pos=i;
	    if(frac[1]>=max) max=frac[1], pos=1;
	    if(frac[2]>=max) max=frac[2], pos=2;
	    if(frac[3]>=max) max=frac[3], pos=3;
	    frac[pos]=0;	//avoid bumping same value twice
	    data[pos]++;
//dprintf("bumped %i\n",pos);
	    norm_all++;
        }
    
//dprintf("bar_sz %i\n",bar_sz);
//dprintf("sys %i\n",data[2]);
//dprintf("usr %i\n",data[0]);
//dprintf("nice %i\n",data[1]);
	memset(bar,'.',bar_sz);
	memset(bar,'S',data[2]); bar+=data[2]; //sys
	memset(bar,'U',data[0]); bar+=data[0]; //usr
	memset(bar,'N',data[1]); bar+=data[1]; //nice
    } else {
	memset(bar,'?',bar_sz);
    }
    put(s->bar);
    put_c(']');
    return 0;
}

//==============
s_stat* init_cpu(const char *param) {
//==============
    int sz;
    MALLOC_STAT(cpu_stat,s);
    s->collect = collect_cpu;
    s->label = "cpu ";
    s->width = 4;

    sz = strtol(param, NULL, 0);
    if(sz<10) sz=10;
    if(sz>1000) sz=1000;

    s->bar = (char*)malloc(sz+1);
    s->bar[sz]=0;
    s->bar_sz = sz;
    s->width = sz+2;
    return (s_stat*)s;
}

//==============
S_STAT(int_stat)
    sample_t old;
    int no;
    char numlabel[6];
} int_stat;

//==============
int collect_int(int_stat *s) {
//==============
    sample_t data[1];

    if(rdval(prepare(&proc_stat), "intr", data, s->no))
	return 1;

    sample_t old = s->old;
    if(data[0] < old) old = data[0];	//sanitize
    s->old = data[0];
    scale(data[0] - old);
    return 0;
}

//==============
s_stat* init_int(const char *param) {
//==============
    MALLOC_STAT(int_stat,s);
    s->collect = collect_int;
    s->width = 4;
    if(param[0]=='\0') {
	s->no = 1;
	s->label = "int ";
    } else {
	int n = strtoul(param, NULL, 0);
	s->no = n+2;
	s->label = s->numlabel;
	s->numlabel[0]='i';
	s->numlabel[1]='n';
	s->numlabel[2]='t';
	s->numlabel[3]=(n<=9 ? '0'+n : n+('A'-10));
	s->numlabel[4]=' ';
	s->numlabel[5]='\0';
    }
    return (s_stat*)s;
}

//==============
S_STAT(ctx_stat)
    sample_t old;
} ctx_stat;

//==============
int collect_ctx(ctx_stat *s) {
//==============
    sample_t data[1];

    if(rdval(prepare(&proc_stat), "ctxt", data, 1))
	return 1;

    sample_t old = s->old;
    if(data[0] < old) old = data[0];	//sanitize
    s->old = data[0];
    scale(data[0] - old);
    return 0;
}

//==============
s_stat* init_ctx(const char *param) {
//==============
    MALLOC_STAT(ctx_stat,s);
    s->collect = collect_ctx;
    s->label = "ctx ";
    s->width = 4;
    return (s_stat*)s;
}

//==============
S_STAT(blk_stat)
    const char* lookfor;
    sample_t old[2];
} blk_stat;

//==============
int collect_blk24(blk_stat *s) {
//==============
    sample_t data[2];
    int i;
    if(rdval(prepare(&proc_stat), s->lookfor, data, 1, 2))
    	return 1;

    for(i=0; i<2; i++) {
	sample_t old = s->old[i];
	if(data[i] < old) old = data[i];	//sanitize
	s->old[i] = data[i];
	data[i] -= old;
    }
    scale(data[0]*1024);
    put_c(' ');
    scale(data[1]*1024);
    return 0;
}

//==============
int collect_blk26(blk_stat *s) {
//==============
    sample_t data[2];
    int i;
    if(rdval_diskstats(prepare(&proc_diskstats), data))
	return 1;

    for(i=0; i<2; i++) {
	sample_t old = s->old[i];
	if(data[i] < old) old = data[i];	//sanitize
	s->old[i] = data[i];
	data[i] -= old;
    }
    scale(data[0]*512);
    put_c(' ');
    scale(data[1]*512);
    return 0;
}

//==============
int collect_blk(blk_stat *s) {
//==============
    if(is26) return collect_blk26(s);
    return collect_blk24(s);
}

//==============
s_stat* init_blk(const char *param) {
//==============
    MALLOC_STAT(blk_stat,s);
    s->collect = collect_blk;
    if(param[0]=='s') {
	s->label = "sio ";
	s->lookfor = "swap";
    } else {
	s->label = "bio ";
	s->lookfor = "page";
    }
    s->width = 9;
    return (s_stat*)s;
}

//==============
S_STAT(fork_stat)
    sample_t old;
} fork_stat;

//==============
int collect_fork(fork_stat *s) {
//==============
    sample_t data[1];

    if(rdval(prepare(&proc_stat), "processes", data, 1))
	return 1;

    sample_t old = s->old;
    if(data[0] < old) old = data[0];	//sanitize
    s->old = data[0];
    scale(data[0] - old);
    return 0;
}

//==============
s_stat* init_fork(const char *param) {
//==============
    MALLOC_STAT(fork_stat,s);
    s->collect = collect_fork;
    s->label = "fork";  // no trailing space: there usually <1000 forks,
    s->width = 4;       // we trade usual "fork    3" for rare "fork1234"
    return (s_stat*)s;
}

//==============
S_STAT(if_stat)
    sample_t old[4];
    const char *device;
    char *device_colon;
} if_stat;

//==============
int collect_if(if_stat *s) {
//==============
    sample_t data[4];
    int i;

    if(rdval(prepare(&proc_net_dev), s->device_colon, data, 1, 3, 9, 11))
	return 1;

    //dprintf("data1:");
    for(i=0; i<4; i++) {
	sample_t old = s->old[i];
	if(data[i] < old) old = data[i];	//sanitize
        s->old[i] = data[i];
        data[i] -= old;
	//dprintf(" %lu",data[i]);
    }
    //dprintf("\n");
    
    put_c(data[1] ? '*' : ' ');
    scale(data[0]);
    put_c(data[3] ? '*' : ' ');
    scale(data[2]);
    return 0;
}

//==============
s_stat* init_if(const char *device) {
//==============
    MALLOC_STAT(if_stat,s);
    s->collect = collect_if;
    s->label = device;
    s->width = 10;
    
    s->device = device;
    s->device_colon = (char*)malloc(strlen(device)+2);
    strcpy(s->device_colon,device);
    strcat(s->device_colon,":");
    return (s_stat*)s;
}

//==============
S_STAT(mem_stat)
    char opt;
} mem_stat;

//==============
int collect_mem(mem_stat *s) {
//==============
//        total:    used:    free:  shared: buffers:  cached:
//Mem:  29306880 21946368  7360512        0  2101248 11956224
//Swap: 100655104 10207232 90447872
//MemTotal:        28620 kB
//MemFree:          7188 kB
//MemShared:           0 kB  <-- ?
//Buffers:          2052 kB
//Cached:           9080 kB
//SwapCached:       2596 kB  <-- ?

    // Not available in 2.6:
    //if(rdval(prepare(&proc_meminfo), "Mem:", data, 1, 2, 5, 6))
    //    return 1;
    sample_t m_total;
    sample_t m_free;
    sample_t m_bufs;
    sample_t m_cached;
    if(rdval(prepare(&proc_meminfo), "MemTotal:", &m_total , 1)) return 1;
    if(rdval(prepare(&proc_meminfo), "MemFree:",  &m_free  , 1)) return 1;
    if(rdval(prepare(&proc_meminfo), "Buffers:",  &m_bufs  , 1)) return 1;
    if(rdval(prepare(&proc_meminfo), "Cached:",   &m_cached, 1)) return 1;
    switch(s->opt) {
    case 'f':
        scale((m_free + m_bufs + m_cached)<<10); break;
    case 't':
        scale(m_total<<10); break;
    default:
        scale((m_total - m_free - m_bufs - m_cached)<<10); break;
    }
    return 0;
}

//==============
s_stat* init_mem(const char *param) {
//==============
    MALLOC_STAT(mem_stat,s);
    s->collect = collect_mem;
    s->width = 4;
    s->opt=param[0];
    switch(param[0]) {
    case 'f':
	s->label = "free "; break;
    case 't':
	s->label = "tot "; break;
    default:
	s->label = "mem "; break;
    }
    return (s_stat*)s;
}

//==============
S_STAT(swp_stat)
} swp_stat;

//==============
int collect_swp(swp_stat *s) {
//==============
    sample_t data[1];
    if(rdval(prepare(&proc_meminfo), "Swap:", data, 2))
	return 1;
	
    scale(data[0]);
    return 0;
}

//==============
s_stat* init_swp(const char *param) {
//==============
    MALLOC_STAT(swp_stat,s);
    s->collect = collect_swp;
    s->label = "swp ";
    s->width = 4;
    return (s_stat*)s;
}

//==============
S_STAT(fd_stat)
} fd_stat;

//==============
int collect_fd(fd_stat *s) {
//==============
    char file[4096];
    sample_t data[2];

    readfile_z(file, sizeof(file), "/proc/sys/fs/file-nr");
    if(rdval(file, "", data, 1, 2))
	return 1;

    scale(data[0]-data[1]);
    return 0;
}

//==============
s_stat* init_fd(const char *param) {
//==============
    MALLOC_STAT(fd_stat,s);
    s->collect = collect_fd;
    s->label = "fd ";
    s->width = 4;
    return (s_stat*)s;
}

//==============
S_STAT(time_stat)
    int prec;
    int scale;
} time_stat;

//==============
int collect_time(time_stat *s) {
//==============
    char buf[16];	// 12:34:56.123456<eol>
			// 1234567890123456
    simple_itoa(buf, 3, tv.tv_sec/(60*60)%24, 2);
    buf[2] = ':';
    simple_itoa(buf+3, 3, tv.tv_sec/60%60, 2);
    buf[5] = ':';
    simple_itoa(buf+6, 3, tv.tv_sec%60, 2);
    
    if(s->prec) {
	buf[8] = '.';
	//simple_itoa(buf+9, s->prec+1, (tv.tv_usec + s->scale/2) / s->scale, s->prec);
	// (fixme: round up seconds too!)
	// so... rounding omitted! just use more prec if you need it! ;)
	simple_itoa(buf+9, s->prec+1, tv.tv_usec / s->scale, s->prec);
    }
    put(buf);
    return 0;
}

//==============
s_stat* init_time(const char *param) {
//==============
    int prec;
    MALLOC_STAT(time_stat,s);
    s->collect = collect_time;
    s->label = "";
    prec = param[0]-'0';
    if(prec<0) prec = 0;
    else if(prec>6) prec = 6;
    s->width = 8+prec + (prec!=0);
    s->prec = prec;
    s->scale = 1;
    while(prec++ < 6)
	s->scale *= 10;
    return (s_stat*)s;
}

//==============
S_STAT(extern_stat)
    int ifd,ofd;
    char *buf;
    char *cur;
} extern_stat;

#define WIDTH

//==============
int collect_extern(extern_stat *s) {
//==============
    int sz;
    char *p;
    int buffered = s->cur - s->buf;
    
    s->buf[40] = 0;
    p = strchr(s->buf,'\n');
    if(!p || p > s->cur) {
	do {
	    sz = read(s->ofd,s->cur,40 - buffered);
	    if(sz<0) exit(1);
	    buffered += sz;
	    p = strchr(s->cur,'\n');
	    s->cur = s->buf+buffered;
	    if(p > s->cur) p=0;
	} while(!p && buffered<40);
	if(!p) p=s->buf+40;
    }
    
    *p++ = 0;
    put(s->buf);
    s->cur = s->buf;
    while(p < s->buf+buffered) {
	put_c('=');
	*s->cur++ = *p++;
    }
    while(p <= s->buf+40) {
	put_c('='); p++;
    }
    return 0;
}

//#include <stdio.h>

void myexec(void *param) {
    char **argv = (char **)param;
    execv(argv[0], argv);
}

int start_child(int *i,int *o,void (*f)(void*),void *param) {
    int pid;
//printf("execv(%s, argv);\n",((char**)param)[0]);
    {
	int in[2];
	int out[2];
	pipe(in);
	pipe(out);
	pid = fork();
	switch(pid) {
	case -1: /* error */
	    return -1;
	case 0: /* child */
	    dup2(in[0],0); close(in[0]); close(in[1]);
	    dup2(out[1],1); close(out[0]); close(out[1]);
	    f(param);
	    exit(1);
	default: /* parent */
	    close(in[0]);
	    if(i) *i=in[1]; else close(in[1]);
	    if(o) *o=out[0]; else close(out[0]);
	    close(out[1]); 
	    return pid;
	}
    }
}

//==============
s_stat* init_extern(const char *param) {
//==============
    int pid;
    char *argv[] = { (char*)param, 0 };
    MALLOC_STAT(extern_stat,s);
    s->collect = collect_extern;
    s->label = "extern ";
    s->width = 40;
    s->buf = (char*)malloc(41);
    s->cur = s->buf;
    pid = start_child(&s->ifd, &s->ofd, myexec, argv);
    if(pid<0) exit(1);
//printf("pid,i,o=%d %d %d\n",pid,s->ifd,s->ofd);
    return (s_stat*)s;
}

//==============
char *header;
//==============
void build_n_put_hdr(s_stat *s) {
//==============
    while(s) {
	int l = 0;
        if(s->label[0]!=' ') {
    	    put(s->label);
	    l = strlen(s->label);
	}
	while(l <= s->width) {
	    put_c(' ');	
	    l++;
	}
        s = s->next;
    }
    put_c('\n');

    header = (char*)malloc(outbuf_count()+1);
    memcpy(header, outbuf, outbuf_count());
    header[outbuf_count()] = '\0';
    //print_outbuf();
}

//==============
void put_hdr(s_stat *s) {
//==============
    if(!header) build_n_put_hdr(s);
    else {
	put(header);
	//print_outbuf();
    }
}

//==============
void run_once(s_stat *s, int without_headers) {
//==============
    gen++;
    int first = 1;
    while(s) {
	if(s->label[0]!=' ') {		// "[prev ][LABEL]data
	    if(!first) put_c(DELIM_CHAR);
    	    if(!without_headers) put(s->label);
	} else {			// "prevLABELdata
	    put(s->label+1);
	}
        if(s->collect(s)) {
	    int w = s->width;
	    while(w-- > 0)
		put_c('?');
	}
        s = s->next;
	first = 0;
    }
}

//==============
typedef s_stat* init_func(const char *param);

const char options[] = "ncmsfixptbe";
init_func* init_functions[] = {
    init_if,  
    init_cpu, 
    init_mem, 
    init_swp, 
    init_fd,  
    init_int, 
    init_ctx, 
    init_fork,
    init_time,
    init_blk,
    init_extern,
};

//==============
int main(int argc, char* argv[]) {
//==============
    struct timezone tz;
    s_stat *first = 0;
    s_stat *last = 0;
    s_stat *s;
    int delta = 1000000;
    int deltanz = 1000000;
    int print_headers = 0;
    char *final_str = "\n";
    char *p;
    int fd;
    int i;
    
    if(argc==1) {
	put(
	"nmeter " VERSION_STR " allows you to monitor your system in real time" NL
	NL
	"Options:" NL
	"c[N]	monitor CPU. N - bar size, default 10" NL
	"nIFACE	monitor network interface IFACE" NL
	"m[f/t]	monitor allocated/free/total memory" NL
	"s	monitor allocated swap" NL
	"f	monitor number of used filedescriptors" NL
	"i[NN]	monitor total/specific IRQ rate" NL
	"x	monitor context switch rate" NL
	"p	monitor process creation rate" NL
	"b[s]	monitor block io (swap io)" NL
	"t[N]	show time (with N decimal points)" NL
	"d[N]	milliseconds between updates. Default 1000" NL
	"h[N]	print headers above numbers (each N lines, default once)" NL
	"lLABEL	specify label for previous item" NL
	"LLABEL	same + label will be printed without surrounding blanks" NL
	"r	print <cr> instead of <lf> at EOL. Try it ;)" NL
	);
	print_outbuf();
	return 0;
    }

    fd = open("/proc/version",O_RDONLY);
    if(fd>=0) {
	char buf[32];
	if(0<read(fd,buf,sizeof(buf)))
	    is26 = (strstr(buf,"Linux version 2.6.")!=NULL);
	close(fd);
    }
    for(i=1; i<argc; i++) {
	p = strchr(options,argv[i][0]);
	if(p) {
	    s = init_functions[p-options](argv[i]+1);
	    if(s) {
		s->next = 0;
		if(!first)
		    first = s;
		else
		    last->next = s;
		last = s;
	    }
	}

// You have to see it... gcc 3.2 coded switch() as 40 element jump table
// OH NO! >>>:^O
/*
#define SW(a) switch(a) {
#define ENDSW }
#define CASE(a,b) case (b): {
#define ENDCASE }
*/
#define SW(a) do {
#define ENDSW } while(0);
#define CASE(a,b) if((a)==(b)) {
#define ENDCASE }
	SW(argv[i][0])
	CASE(argv[i][0],'r')
	    final_str = "\r";
	    break;
	ENDCASE
	CASE(argv[i][0],'d')
	    delta = strtol(argv[i]+1, NULL, 0)*1000;
	    deltanz = delta>0? delta : 1;
	    break;
	ENDCASE
	CASE(argv[i][0],'h')
	    if(argv[i][1]=='\0')
		print_headers = -1;
	    else
		print_headers = strtol(argv[i]+1, NULL, 0);
	    break;
	ENDCASE
	CASE(argv[i][0],'l')
	    if(last)
		last->label=argv[i]+1;
	    break;
	ENDCASE
	CASE(argv[i][0],'L')
	    if(last) {
		argv[i][0]=' ';
		last->label=argv[i];
	    }
	    break;
	ENDCASE
	ENDSW
    }
	
    if(print_headers == -1) {
	build_n_put_hdr(first);
	print_outbuf();
    }
    run_once(first, print_headers);
    reset_outbuf();
    if(delta>=0) {
	//gettimeofday(&tv,0);
	gettimeofday(&tv,&tz); //
	usleep(delta>1000000 ? 1000000 : delta-tv.tv_usec%deltanz);
    }
    while(1) {
	gettimeofday(&tv,&tz);
        tv.tv_sec -= tz.tz_minuteswest*60;

	if(print_headers > 0 && gen%print_headers == 0)
	    put_hdr(first);
	run_once(first, print_headers);
	put(final_str);
	print_outbuf();

	// Negative delta -> no usleep at all
	// This will hog the CPU but you can have REALLY GOOD
	// time resolution ;)
	// TODO: detect and avoid useless updates
	// (like: nothing happens except time)
        if(delta>=0) {
	    int rem = delta - ((ullong)tv.tv_sec*1000000+tv.tv_usec)%deltanz;
	    // Sometimes kernel wakes us up just a tiny bit earlier than asked
	    // Do not go to very short sleep in this case
	    if(rem < delta/128) {
		rem += delta;
	    }
	    usleep(rem);
	}
    }

    return 0;
}

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 16:45                                                       ` K.R. Foley
@ 2004-10-26  8:29                                                         ` Eran Mann
  0 siblings, 0 replies; 951+ messages in thread
From: Eran Mann @ 2004-10-26  8:29 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Florian Schmidt, Ingo Molnar, linux-kernel, Lee Revell,
	Rui Nuno Capela, Mark_H_Johnson, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

K.R. Foley wrote:
> Florian Schmidt wrote:
> 
>> doesn't seem so. V0.2 doesn't fix this for me. This time i got a BUG 
>> storm
>> again in syslog (it kinda seems related to starting playback in xmms plus
>> loading pages in mozilla. will boot again to verify):
>>
> 
> Well I have now gotten a couple of these now too (with V0.2). They all 
> seem to be generated by firefox or thunderbird and the traces are all 
> identical except for the offending process.
> 
> 
> Oct 25 11:22:11 swdev14 kernel:
> Oct 25 11:22:20 swdev14 kernel: thunderbird-bin/3946: BUG in futex_wait 
> at kernel/futex.c:542
> Oct 25 11:22:20 swdev14 kernel:  [<c0136389>] futex_wait+0x192/0x19c (12)
> Oct 25 11:22:20 swdev14 kernel:  [<c0135646>] 
> sub_preempt_count+0x75/0xd8 (72)
> Oct 25 11:22:20 swdev14 kernel:  [<c02aa9f2>] _spin_unlock+0x1a/0x34 (4)
> Oct 25 11:22:20 swdev14 kernel:  [<c02aa9f2>] _spin_unlock+0x1a/0x34 (84)
> Oct 25 11:22:20 swdev14 kernel:  [<c01120ac>] mcount+0x14/0x18 (4)
> Oct 25 11:22:20 swdev14 kernel:  [<c02aa9f2>] _spin_unlock+0x1a/0x34 (20)
> Oct 25 11:22:20 swdev14 kernel:  [<c0118e15>] 
> default_wake_function+0x0/0x1c (60)
> Oct 25 11:22:20 swdev14 kernel:  [<c0118e15>] 
> default_wake_function+0x0/0x1c (32)
> Oct 25 11:22:20 swdev14 kernel:  [<c0136777>] sys_futex+0xf0/0xfc (12)
> Oct 25 11:22:20 swdev14 kernel:  [<c01120ac>] mcount+0x14/0x18 (8)
> Oct 25 11:22:20 swdev14 kernel:  [<c0136637>] do_futex+0x47/0x97 (20)
> Oct 25 11:22:20 swdev14 kernel:  [<c0136777>] sys_futex+0xf0/0xfc (40)
> Oct 25 11:22:20 swdev14 kernel:  [<c010623d>] 
> sysenter_past_esp+0x52/0x71 (68)
> Oct 25 11:22:20 swdev14 kernel: preempt count: 00000001
> Oct 25 11:22:20 swdev14 kernel: . 1-level deep critical section nesting:
> Oct 25 11:22:20 swdev14 kernel: .. entry 1: print_traces+0x1d/0x59 
> [<c0135a28>] / (dump_stack+0x23/0x27 [<c01070db>])
> Oct 25 11:22:20 swdev14 kernel:
I see a lot of similar traces too on V0.2 (also either from firefox or 
thunderbird):
Oct 26 10:20:57 eran kernel: thunderbird-bin/4285: BUG in futex_wait at 
kernel/futex.c:542
Oct 26 10:20:57 eran kernel:  [<c01338d9>] futex_wait+0x1b9/0x1c0 (8)
Oct 26 10:20:57 eran kernel:  [<c0132b84>] 
check_preempt_timing+0x64/0x190 (80)
Oct 26 10:20:57 eran kernel:  [<c0132b84>] 
check_preempt_timing+0x64/0x190 (4)
Oct 26 10:20:57 eran kernel:  [<c01191f7>] recalc_task_prio+0xa7/0x1a0 (12)
Oct 26 10:20:57 eran kernel:  [<c0119785>] finish_task_switch+0x35/0xb0 (8)
Oct 26 10:20:57 eran kernel:  [<c011941a>] try_to_wake_up+0x8a/0xc0 (8)
Oct 26 10:20:57 eran kernel:  [<c01191f7>] recalc_task_prio+0xa7/0x1a0 (12)
Oct 26 10:20:57 eran kernel:  [<c01191f7>] recalc_task_prio+0xa7/0x1a0 (12)
Oct 26 10:20:57 eran kernel:  [<c01191f7>] recalc_task_prio+0xa7/0x1a0 (8)
Oct 26 10:20:57 eran kernel:  [<c0119785>] finish_task_switch+0x35/0xb0 (12)
Oct 26 10:20:57 eran kernel:  [<c01191f7>] recalc_task_prio+0xa7/0x1a0 (20)
Oct 26 10:20:57 eran kernel:  [<c0119785>] finish_task_switch+0x35/0xb0 (12)
Oct 26 10:20:57 eran kernel:  [<c0119e20>] 
default_wake_function+0x0/0x10 (64)
Oct 26 10:20:57 eran kernel:  [<c0119e20>] 
default_wake_function+0x0/0x10 (32)
Oct 26 10:20:57 eran kernel:  [<c0108609>] do_IRQ+0x39/0x60 (20)
Oct 26 10:20:57 eran kernel:  [<c0133b55>] do_futex+0x35/0x90 (20)
Oct 26 10:20:57 eran kernel:  [<c022cf3c>] copy_from_user+0x5c/0x90 (8)
Oct 26 10:20:57 eran kernel:  [<c0133c9a>] sys_futex+0xea/0x100 (16)
Oct 26 10:20:57 eran kernel:  [<c01060f9>] sysenter_past_esp+0x52/0x71 (56)
Oct 26 10:20:57 eran kernel: preempt count: 00000001
Oct 26 10:20:57 eran kernel: . 1-level deep critical section nesting:
Oct 26 10:20:57 eran kernel: .. entry 1: print_traces+0xd/0x40 
[<c0132f8d>] / (0x0 [<00000000>])

I also get these errors from 'tail -f /var/log/messages':
tail: cannot read realtime clock: Unknown error 516
(it seems to happen at the same time as the above traces, though less 
often).

-- 
Eran Mann
MRV International
Tel: 972-4-9936297
Fax: 972-4-9890430
www.mrv.com

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26  5:28                                                         ` Denis Vlasenko
@ 2004-10-26 10:40                                                           ` Rui Nuno Capela
  2004-10-26 19:09                                                             ` Denis Vlasenko
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-26 10:40 UTC (permalink / raw)
  To: Denis Vlasenko; +Cc: linux-kernel

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

Denis Vlasenko wrote:
>
> <shameless plug>
> Maybe this program will be useful. It is designed to give you
> overall system statistics without the need to scan entire /proc/NNN
> forest. Together with nice -20, it will hopefully not stall.
>
> Compiled with dietlibc. If you will have trouble compiling it,
> binary is attached too.
>
> Latest version is 0.9 but it seems I forgot it in my home box :(
</shameless plug>

Thanks for nmeter. I have changed a couple of little bits to build with
gcc-3.4 here (see diff attached).

Indeed, it says 0.7 as its version string. What's up on 0.9?
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


[-- Attachment #2: nmeter-1.diff --]
[-- Type: text/plain, Size: 529 bytes --]

--- nmeter.c.orig	2004-10-26 10:01:00.579922368 +0100
+++ nmeter.c	2004-10-26 09:59:48.525876248 +0100
@@ -59,15 +59,15 @@
 char outbuf[4096];
 char *cur_outbuf = outbuf;
 
-extern inline void reset_outbuf() {
+inline void reset_outbuf() {
     cur_outbuf = outbuf;
 }
 
-extern inline int outbuf_count() {
+inline int outbuf_count() {
     return cur_outbuf-outbuf;
 }
 
-extern inline void print_outbuf() {
+inline void print_outbuf() {
     if(cur_outbuf>outbuf) {
 	write(1, outbuf, cur_outbuf-outbuf);
 	cur_outbuf = outbuf;

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-25 20:38                                         ` Ingo Molnar
@ 2004-10-26 10:53                                           ` K.R. Foley
  2004-10-26 10:57                                             ` Ingo Molnar
  2004-10-27  0:24                                             ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-26 10:53 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>Actually pertaining to V0.2. I just got my UP system booted up on V0.2
>>and got this in the log. I did notice that this is not new to this
>>release. It has been here at least since U10.3. Sorry I didn't catch
>>it sooner.
>>
>>Oct 25 13:31:56 daffy kernel: IRQ#11 thread RT prio: 43.
>>Oct 25 13:31:56 daffy kernel: ip/2432: BUG in enable_irq at 
>>kernel/irq/manage.c:112
> 
> 
> this is pretty harmless and has been happening in -mm for some time. The
> e100 device will work fine afterwards.
> 
> 	Ingo
> 

Several things in regard to V0.2:

1) Interactive responsiveness seems to be noticably sluggish at times on
all three of the systems I have tested this on.
2) My 450MHz UP system is definitely the worst by far. Scrolling through
the syslog in a telnet session produces pauses every few seconds for
about a second, that is while it's still responding. These problems seem
to be network related, but there are no indications of what the problem
is. This system also at times will just stop responding to network requests.
3) Both of the SMP systems are lacking the snappy responsiveness in X
that I have become accustomed to with previous patches, but the 2.6GHz
Xeon (w/HT) is worse than the 933MHz Xeon. Again no indications of
problems in the logs.
4) Using amlat to run the RTC at 1kHz will kill any of these systems
very quickly.

kr



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26 10:53                                           ` K.R. Foley
@ 2004-10-26 10:57                                             ` Ingo Molnar
  2004-10-27  0:24                                             ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-26 10:57 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> 1) Interactive responsiveness seems to be noticably sluggish at times on
> all three of the systems I have tested this on.

yeah, something's seriously buggered in V0.2 - dont bother testing its
latencies, the bug hides all the benefits.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26  5:11                                                           ` Fernando Pablo Lopez-Lezcano
@ 2004-10-26 17:25                                                             ` Lee Revell
  2004-10-26 17:45                                                               ` Fernando Pablo Lopez-Lezcano
  0 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-26 17:25 UTC (permalink / raw)
  To: Fernando Pablo Lopez-Lezcano
  Cc: Rui Nuno Capela, Ingo Molnar, Florian Schmidt, K.R. Foley,
	linux-kernel, mark_h_johnson, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Alexander Batyrshin

On Mon, 2004-10-25 at 22:11 -0700, Fernando Pablo Lopez-Lezcano wrote:
> On Mon, 2004-10-25 at 20:01, Lee Revell wrote: 
> > On Mon, 2004-10-25 at 20:40 +0100, Rui Nuno Capela wrote:
> > > OTOH, jackd -R xruns are awfully back, even thought I (re)prioritize the
> > > relevant IRQ thread handlers to be always higher than jackd's.
> > 
> > Actually they should be lower, except the soundcard.  I was only able to
> > get the xrun free behavior of T3 by setting all IRQ threads except the
> > soundcard to SCHED_OTHER.  Especially important was setting ksoftirqd to
> > SCHED_OTHER, this actually may have been the only one necessary.
> > 
> > The relative priorities of jackd and the soundcard irq do not matter as
> > these two should never contend (aka they are never both runnable at the
> > same time).
> 
> What happens when one is blessed with a laptop where everything is
> sharing an interrupt?
> 
> $ cat /proc/interrupts
>            CPU0
>   0:    2372239          XT-PIC  timer  0/72239
>   1:       5362          XT-PIC  i8042  0/5362
>   2:          0          XT-PIC  cascade  0/0
>   8:          1          XT-PIC  rtc  0/1
>   9:     616176          XT-PIC  acpi, uhci_hcd, uhci_hcd, uhci_hcd,
> eth0, yenta, yenta, Intel 82801CA-ICH3, radeon@PCI:1:0:0  0/16176
> 11:         37          XT-PIC  sonypi  0/35
> 12:      28392          XT-PIC  i8042  0/28392
> 14:      21078          XT-PIC  ide0  0/21078
> 15:        472          XT-PIC  ide1  0/472

Ugh, why would _anyone_ design a laptop like that?  You have 4
perfectly good interrupts that you are not using at all.  Is it really
cheaper to put everything on the same irq?  Does this work better under
Windows or something?

AFAIK there is nothing you can do - any other irq that fires on 9 will
mask out all the others until it completes.

I am increasingly convinced that the vast majority of laptops are
horribly broken and completely unsuitable for low latency audio work.

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26 17:25                                                             ` Lee Revell
@ 2004-10-26 17:45                                                               ` Fernando Pablo Lopez-Lezcano
  2004-10-26 17:55                                                                 ` Lee Revell
  0 siblings, 1 reply; 951+ messages in thread
From: Fernando Pablo Lopez-Lezcano @ 2004-10-26 17:45 UTC (permalink / raw)
  To: Lee Revell
  Cc: Rui Nuno Capela, Ingo Molnar, Florian Schmidt, K.R. Foley,
	linux-kernel, mark_h_johnson, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Alexander Batyrshin,
	Fernando Pablo Lopez-Lezcano

On Tue, 2004-10-26 at 10:25, Lee Revell wrote:
> On Mon, 2004-10-25 at 22:11 -0700, Fernando Pablo Lopez-Lezcano wrote:
> > On Mon, 2004-10-25 at 20:01, Lee Revell wrote: 
> > > On Mon, 2004-10-25 at 20:40 +0100, Rui Nuno Capela wrote:
> > > > OTOH, jackd -R xruns are awfully back, even thought I (re)prioritize the
> > > > relevant IRQ thread handlers to be always higher than jackd's.
> > > 
> > > Actually they should be lower, except the soundcard.  I was only able to
> > > get the xrun free behavior of T3 by setting all IRQ threads except the
> > > soundcard to SCHED_OTHER.  Especially important was setting ksoftirqd to
> > > SCHED_OTHER, this actually may have been the only one necessary.
> > > 
> > > The relative priorities of jackd and the soundcard irq do not matter as
> > > these two should never contend (aka they are never both runnable at the
> > > same time).
> > 
> > What happens when one is blessed with a laptop where everything is
> > sharing an interrupt?
> > 
> > $ cat /proc/interrupts
> >            CPU0
> >   0:    2372239          XT-PIC  timer  0/72239
> >   1:       5362          XT-PIC  i8042  0/5362
> >   2:          0          XT-PIC  cascade  0/0
> >   8:          1          XT-PIC  rtc  0/1
> >   9:     616176          XT-PIC  acpi, uhci_hcd, uhci_hcd, uhci_hcd,
> > eth0, yenta, yenta, Intel 82801CA-ICH3, radeon@PCI:1:0:0  0/16176
> > 11:         37          XT-PIC  sonypi  0/35
> > 12:      28392          XT-PIC  i8042  0/28392
> > 14:      21078          XT-PIC  ide0  0/21078
> > 15:        472          XT-PIC  ide1  0/472
> 
> Ugh, why would _anyone_ design a laptop like that?  You have 4
> perfectly good interrupts that you are not using at all.  Is it really
> cheaper to put everything on the same irq?  Does this work better under
> Windows or something?
> 
> AFAIK there is nothing you can do - any other irq that fires on 9 will
> mask out all the others until it completes.

Yes, except I did not see all these xruns running 2.4.26 + lowlat +
preempt (same machine). Things got better with 2.6.x up to, perhaps, S7,
although I would have to retest to make sure. Now they seem to be worse
than before. 

-- Fernando



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26 17:45                                                               ` Fernando Pablo Lopez-Lezcano
@ 2004-10-26 17:55                                                                 ` Lee Revell
  0 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-26 17:55 UTC (permalink / raw)
  To: Fernando Pablo Lopez-Lezcano
  Cc: Rui Nuno Capela, Ingo Molnar, Florian Schmidt, K.R. Foley,
	linux-kernel, mark_h_johnson, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Alexander Batyrshin

On Tue, 2004-10-26 at 10:45 -0700, Fernando Pablo Lopez-Lezcano wrote:
> > AFAIK there is nothing you can do - any other irq that fires on 9 will
> > mask out all the others until it completes.
> 
> Yes, except I did not see all these xruns running 2.4.26 + lowlat +
> preempt (same machine). Things got better with 2.6.x up to, perhaps, S7,
> although I would have to retest to make sure. Now they seem to be worse
> than before. 

Hmm, interesting.  Anyway T3 is the last version that was stable for me,
this is the xrun-free standard that I compare the later ones to.

Lee





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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26 10:40                                                           ` Rui Nuno Capela
@ 2004-10-26 19:09                                                             ` Denis Vlasenko
  2004-10-27  8:23                                                               ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Denis Vlasenko @ 2004-10-26 19:09 UTC (permalink / raw)
  To: Rui Nuno Capela; +Cc: linux-kernel

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

On Tuesday 26 October 2004 13:40, Rui Nuno Capela wrote:
> Denis Vlasenko wrote:
> >
> > <shameless plug>
> > Maybe this program will be useful. It is designed to give you
> > overall system statistics without the need to scan entire /proc/NNN
> > forest. Together with nice -20, it will hopefully not stall.
> >
> > Compiled with dietlibc. If you will have trouble compiling it,
> > binary is attached too.
> >
> > Latest version is 0.9 but it seems I forgot it in my home box :(
> </shameless plug>
> 
> Thanks for nmeter. I have changed a couple of little bits to build with
> gcc-3.4 here (see diff attached).

Hmm will it compile on 3.4 with "static inline"?

> Indeed, it says 0.7 as its version string. What's up on 0.9?

Here it is.
--
vda

[-- Attachment #2: nmeter.c --]
[-- Type: text/x-csrc, Size: 20783 bytes --]

// Based on nanotop.c from floppyfw project
// Released under GPL
// Contact me: vda@port.imtp.ilyichevsk.odessa.ua

//TODO: 
// simplify code
// /proc/locks
// /proc/stat:
// disk_io: (3,0):(22272,17897,410702,4375,54750)
// btime 1059401962

#include <time.h>	// timezone (global var)
#include <sys/time.h>	// gettimeofday
#include <string.h>	// strstr etc
#include <stdarg.h>	// f(...)
#include <fcntl.h>	// O_RDONLY

#define VERSION_STR "0.9"
#define DELIM_CHAR ' '

//==============
#define NL "\n"
typedef unsigned long long ullong;
typedef unsigned long ulong;

typedef ulong sample_t;

//==============
#define proc_file_size 4096

typedef struct proc_file {
    char *name;
    int gen;
    char *file;
} proc_file;

proc_file proc_stat = { "/proc/stat", -1 };
proc_file proc_net_dev = { "/proc/net/dev", -1 };
proc_file proc_meminfo = { "/proc/meminfo", -1 };
proc_file proc_diskstats = { "/proc/diskstats", -1 };
struct timeval tv;
int gen=-1;
int is26=0;

//==============
#if 0
#include <stdio.h>
void dprintf(const char *fmt, ...) {
    va_list ap;
    va_start(ap, fmt);
    vprintf(fmt, ap);
    va_end(ap);
}
#else
extern void dprintf(const char *fmt, ...) {}
#endif

//==============
char outbuf[4096];
char *cur_outbuf = outbuf;
int delta = 1000000;
int deltanz = 1000000;

static inline void reset_outbuf() {
    cur_outbuf = outbuf;
}

static inline int outbuf_count() {
    return cur_outbuf-outbuf;
}

static inline void print_outbuf() {
    if(cur_outbuf>outbuf) {
	write(1, outbuf, cur_outbuf-outbuf);
	cur_outbuf = outbuf;
    }
}

void put(const char *s) {
    int sz = strlen(s);
    if(sz > (outbuf+sizeof(outbuf))-cur_outbuf)
	sz = (outbuf+sizeof(outbuf))-cur_outbuf;
    memcpy(cur_outbuf, s, sz);
    cur_outbuf += sz;
}

void put_c(char c) {
    if(cur_outbuf < outbuf+sizeof(outbuf))
	*cur_outbuf++ = c;
}

//==============
char* simple_itoa(char *s, int sz, unsigned long v, int pad) {
//==============
    s += sz;
    *--s = '\0';
    while (--sz > 0) {
        *--s = "0123456789"[v%10];
        pad--;
        v /= 10;
        if(!v && pad<=0) break;
    }
    return s;
}

//==============
int readfile_z(char *buf, int sz, const char* fname) {
//==============
    int fd;
    fd=open(fname,O_RDONLY);
    if(fd<0) return 1;
    sz = read(fd,buf,sz-1);
    close(fd);
    if(sz<0) {
	buf[0]='\0';
	return 1;
    }
    buf[sz]='\0';
    return 0;
}

//==============
int rdval(const char* p, const char* key, sample_t *vec, ...) {
//==============
    va_list arg_ptr;
    int indexline;
    int indexnext;

    p = strstr(p,key);
    if(!p) return 1;
	
    p += strlen(key);
    va_start(arg_ptr, vec);
    indexline = 1;
    indexnext = va_arg(arg_ptr, int);
    while(1) {
    	while(*p==' ' || *p=='\t') p++;
	if(*p=='\n' || *p=='\0') break;

        if(indexline == indexnext) { // read this value
            *vec++ = strtoul(p, NULL, 10);
            indexnext = va_arg(arg_ptr, int);
        }
    	while(*p > ' ') p++; // skip over value
        indexline++;
    }
    va_end(arg_ptr);
    return 0;
}

//==============
int rdval_diskstats(const char* p, sample_t *vec) {
//   1    2 3   4     5     6(rd)  7      8     9     10(wr) 11      12 13    14
//   3    0 hda 51292 14441 841783 926052 25717 79650 843256 3029804 0 148459 3956933
//   3    1 hda1 0 0 0 0 <- ignore if only 4 fields
//==============
    sample_t rd;
    int indexline = 0;
    vec[0] = 0;
    vec[1] = 0;
    while(1) {
        indexline++;
        while(*p==' ' || *p=='\t') p++;
        if(*p=='\0') break;
        if(*p=='\n') {
            indexline = 0;
	    p++;
            continue;
        }
        if(indexline == 6) {
            rd = strtoul(p, NULL, 10);
        } else
        if(indexline == 10) {
            vec[0] += rd;  // TODO: *sectorsize (don't know how to find out sectorsize)
            vec[1] += strtoul(p, NULL, 10);
    	    while(*p!='\n' && *p!='\0') p++;
	    continue;
        }
        while(*p > ' ') p++; // skip over value
    }
    return 0;
}

//==============
void scale(sample_t ul) {
//==============
    char buf[5];
    int index = 0;
    ul *= 10;
    if(ul>9999*10) { // do not scale if 9999 or less
	while(ul >= 10000) {
	    ul /= 1024;
	    index++;
	}
    }

    if(!index) {/* use 1234 format */
	buf[0] = " 123456789"[ul/10000];
	if(buf[0]== ' ') buf[1] = " 123456789"[ul/1000%10];
	            else buf[1] = "0123456789"[ul/1000%10];
	if(buf[1]== ' ') buf[2] = " 123456789"[ul/100%10];
                    else buf[2] = "0123456789"[ul/100%10];
	buf[3] = "0123456789"[ul/10%10];
    } else if(ul>=100) { /* use 123k format */
	if( (buf[0]= " 123456789"[ul/1000]) == ' ')
	    buf[1] = " 123456789"[ul/100%10];
	else
	    buf[1] = "0123456789"[ul/100%10];
	buf[2] = "0123456789"[ul/10%10];
	buf[3] = " kMGTEP"[index];
    } else { /* use 1.2M format */
	buf[0] = "0123456789"[ul/10];
	buf[1] = '.';
	buf[2] = "0123456789"[ul%10];
	buf[3] = " kMGTEP"[index];
    }
    buf[4] = 0;
    put(buf);
}

//==============
const char* prepare(proc_file *pf) {
    if(!pf->file) pf->file = (char*)malloc(proc_file_size);
    if(pf->gen != gen) {
	pf->gen = gen;
	readfile_z(pf->file, proc_file_size, pf->name);
    }
    return pf->file;
}

//==============
#define S_STAT(a) \
typedef struct a { \
    struct s_stat *next; \
    int (*collect)(struct a *s); \
    const char *label; \
    int width;

S_STAT(s_stat)
} s_stat;

#define MALLOC_STAT(type,var) type *var = (type*)malloc(sizeof(type))

//==============
//     user nice system idle  iowait irq  softirq (last 3 only in 2.6)
//cpu  649369 0 341297 4336769 11640 7122 1183
//cpuN 649369 0 341297 4336769 11640 7122 1183
#define N 7
S_STAT(cpu_stat)
    sample_t old[N];
    int bar_sz;
    char *bar;
} cpu_stat;

//==============
int collect_cpu(cpu_stat *s) {
//==============
    sample_t data[N] = {0,0,0,0,0,0,0};
    sample_t frac[N] = {0,0,0,0,0,0,0};
    sample_t all = 0;
    int norm_all = 0;
    int bar_sz = s->bar_sz;
    char *bar = s->bar;
    int i;

    if(rdval(prepare(&proc_stat), "cpu ", data, 1, 2, 3, 4, 5, 6 ,7))
	return 1;
    
    put_c('[');

    for(i=0; i<N; i++) {
	sample_t old = s->old[i];
	if(data[i] < old) old = data[i];	//sanitize
        s->old[i] = data[i];
        all += (data[i] -= old);
    }

    if(all) {
//dprintf("data2:");
	for(i=0; i<N; i++) {
	    ullong t = bar_sz*(ullong)data[i];
	    norm_all += data[i] = t / all;
	    frac[i] = t % all;
//dprintf(" %lu/%lu",data[i],frac[i]);
	}
//dprintf(" norm_all %lu\n",norm_all);
    
	while(norm_all<bar_sz) {
	    sample_t max=frac[0]; int pos=0;
	    //for(i=1; i<4; i++) if(frac[i]>=max) max=frac[i], pos=i;
	    for(i=1; i<N; i++) {
		if(frac[i]>=max) max=frac[i], pos=i;
	    }
	    frac[pos]=0;	//avoid bumping same value twice
	    data[pos]++;
//dprintf("bumped %i\n",pos);
	    norm_all++;
        }
    
//dprintf("bar_sz %i\n",bar_sz);
//dprintf("sys %i\n",data[2]);
//dprintf("usr %i\n",data[0]);
//dprintf("nice %i\n",data[1]);
	memset(bar,'.',bar_sz);
	memset(bar,'S',data[2]); bar+=data[2]; //sys
	memset(bar,'U',data[0]); bar+=data[0]; //usr
	memset(bar,'N',data[1]); bar+=data[1]; //nice
	memset(bar,'D',data[4]); bar+=data[4]; //iowait
	memset(bar,'I',data[5]); bar+=data[5]; //irq
	memset(bar,'i',data[6]); bar+=data[6]; //softirq
    } else {
	memset(bar,'?',bar_sz);
    }
    put(s->bar);
    put_c(']');
    return 0;
}

//==============
s_stat* init_cpu(const char *param) {
//==============
    int sz;
    MALLOC_STAT(cpu_stat,s);
    s->collect = collect_cpu;
    s->label = "cpu ";
    s->width = 4;

    sz = strtol(param, NULL, 0);
    if(sz<10) sz=10;
    if(sz>1000) sz=1000;

    s->bar = (char*)malloc(sz+1);
    s->bar[sz]=0;
    s->bar_sz = sz;
    s->width = sz+2;
    return (s_stat*)s;
}

//==============
S_STAT(int_stat)
    sample_t old;
    int no;
    char numlabel[6];
} int_stat;

//==============
int collect_int(int_stat *s) {
//==============
    sample_t data[1];

    if(rdval(prepare(&proc_stat), "intr", data, s->no))
	return 1;

    sample_t old = s->old;
    if(data[0] < old) old = data[0];	//sanitize
    s->old = data[0];
    scale(data[0] - old);
    return 0;
}

//==============
s_stat* init_int(const char *param) {
//==============
    MALLOC_STAT(int_stat,s);
    s->collect = collect_int;
    s->width = 4;
    if(param[0]=='\0') {
	s->no = 1;
	s->label = "int ";
    } else {
	int n = strtoul(param, NULL, 0);
	s->no = n+2;
	s->label = s->numlabel;
	s->numlabel[0]='i';
	s->numlabel[1]='n';
	s->numlabel[2]='t';
	s->numlabel[3]=(n<=9 ? '0'+n : n+('A'-10));
	s->numlabel[4]=' ';
	s->numlabel[5]='\0';
    }
    return (s_stat*)s;
}

//==============
S_STAT(ctx_stat)
    sample_t old;
} ctx_stat;

//==============
int collect_ctx(ctx_stat *s) {
//==============
    sample_t data[1];

    if(rdval(prepare(&proc_stat), "ctxt", data, 1))
	return 1;

    sample_t old = s->old;
    if(data[0] < old) old = data[0];	//sanitize
    s->old = data[0];
    scale(data[0] - old);
    return 0;
}

//==============
s_stat* init_ctx(const char *param) {
//==============
    MALLOC_STAT(ctx_stat,s);
    s->collect = collect_ctx;
    s->label = "ctx ";
    s->width = 4;
    return (s_stat*)s;
}

//==============
S_STAT(blk_stat)
    const char* lookfor;
    sample_t old[2];
} blk_stat;

//==============
int collect_blk24(blk_stat *s) {
//==============
    sample_t data[2];
    int i;
    if(rdval(prepare(&proc_stat), s->lookfor, data, 1, 2))
    	return 1;

    for(i=0; i<2; i++) {
	sample_t old = s->old[i];
	if(data[i] < old) old = data[i];	//sanitize
	s->old[i] = data[i];
	data[i] -= old;
    }
    scale(data[0]*1024);
    put_c(' ');
    scale(data[1]*1024);
    return 0;
}

//==============
int collect_blk26(blk_stat *s) {
//==============
    sample_t data[2];
    int i;
    if(rdval_diskstats(prepare(&proc_diskstats), data))
	return 1;

    for(i=0; i<2; i++) {
	sample_t old = s->old[i];
	if(data[i] < old) old = data[i];	//sanitize
	s->old[i] = data[i];
	data[i] -= old;
    }
    scale(data[0]*512);
    put_c(' ');
    scale(data[1]*512);
    return 0;
}

//==============
int collect_blk(blk_stat *s) {
//==============
    if(is26) return collect_blk26(s);
    return collect_blk24(s);
}

//==============
s_stat* init_blk(const char *param) {
//==============
    MALLOC_STAT(blk_stat,s);
    s->collect = collect_blk;
//    if(param[0]=='s') {
//	s->label = "sio ";
//	s->lookfor = "swap";
//    } else {
	s->label = "bio ";
	s->lookfor = "page";
//    }
    s->width = 9;
    return (s_stat*)s;
}

//==============
S_STAT(fork_stat)
    sample_t old;
} fork_stat;

//==============
int collect_fork(fork_stat *s) {
//==============
    sample_t data[1];

    if(rdval(prepare(&proc_stat), "processes", data, 1))
	return 1;

    sample_t old = s->old;
    if(data[0] < old) old = data[0];	//sanitize
    s->old = data[0];
    scale(data[0] - old);
    return 0;
}

//==============
s_stat* init_fork(const char *param) {
//==============
    MALLOC_STAT(fork_stat,s);
    s->collect = collect_fork;
    s->label = "fork";  // no trailing space: there usually <1000 forks,
    s->width = 4;       // we trade usual "fork    3" for rare "fork1234"
    return (s_stat*)s;
}

//==============
S_STAT(if_stat)
    sample_t old[4];
    const char *device;
    char *device_colon;
} if_stat;

//==============
int collect_if(if_stat *s) {
//==============
    sample_t data[4];
    int i;

    if(rdval(prepare(&proc_net_dev), s->device_colon, data, 1, 3, 9, 11))
	return 1;

    for(i=0; i<4; i++) {
	sample_t old = s->old[i];
	if(data[i] < old) old = data[i];	//sanitize
        s->old[i] = data[i];
        data[i] -= old;
    }
    put_c(data[1] ? '*' : ' ');
    scale(data[0]);
    put_c(data[3] ? '*' : ' ');
    scale(data[2]);
    return 0;
}

//==============
s_stat* init_if(const char *device) {
//==============
    MALLOC_STAT(if_stat,s);
    s->collect = collect_if;
    s->label = device;
    s->width = 10;
    
    s->device = device;
    s->device_colon = (char*)malloc(strlen(device)+2);
    strcpy(s->device_colon,device);
    strcat(s->device_colon,":");
    return (s_stat*)s;
}

//==============
S_STAT(mem_stat)
    char opt;
} mem_stat;

//==============
int collect_mem(mem_stat *s) {
//==============
//        total:    used:    free:  shared: buffers:  cached:
//Mem:  29306880 21946368  7360512        0  2101248 11956224
//Swap: 100655104 10207232 90447872
//MemTotal:        28620 kB
//MemFree:          7188 kB
//MemShared:           0 kB  <-- ?
//Buffers:          2052 kB
//Cached:           9080 kB
//SwapCached:       2596 kB  <-- ?

    // Not available in 2.6:
    //if(rdval(prepare(&proc_meminfo), "Mem:", data, 1, 2, 5, 6))
    //    return 1;
    sample_t m_total;
    sample_t m_free;
    sample_t m_bufs;
    sample_t m_cached;
    if(rdval(prepare(&proc_meminfo), "MemTotal:", &m_total , 1)) return 1;
    if(rdval(prepare(&proc_meminfo), "MemFree:",  &m_free  , 1)) return 1;
    if(rdval(prepare(&proc_meminfo), "Buffers:",  &m_bufs  , 1)) return 1;
    if(rdval(prepare(&proc_meminfo), "Cached:",   &m_cached, 1)) return 1;
    switch(s->opt) {
    case 'f':
        scale((m_free + m_bufs + m_cached)<<10); break;
    case 't':
        scale(m_total<<10); break;
    default:
        scale((m_total - m_free - m_bufs - m_cached)<<10); break;
    }
    return 0;
}

//==============
s_stat* init_mem(const char *param) {
//==============
    MALLOC_STAT(mem_stat,s);
    s->collect = collect_mem;
    s->width = 4;
    s->opt=param[0];
    switch(param[0]) {
    case 'f':
	s->label = "free "; break;
    case 't':
	s->label = "tot "; break;
    default:
	s->label = "mem "; break;
    }
    return (s_stat*)s;
}

//==============
S_STAT(swp_stat)
} swp_stat;

//==============
int collect_swp(swp_stat *s) {
//==============
    sample_t data[1];
    if(rdval(prepare(&proc_meminfo), "Swap:", data, 2))
	return 1;
	
    scale(data[0]);
    return 0;
}

//==============
s_stat* init_swp(const char *param) {
//==============
    MALLOC_STAT(swp_stat,s);
    s->collect = collect_swp;
    s->label = "swp ";
    s->width = 4;
    return (s_stat*)s;
}

//==============
S_STAT(fd_stat)
} fd_stat;

//==============
int collect_fd(fd_stat *s) {
//==============
    char file[4096];
    sample_t data[2];

    readfile_z(file, sizeof(file), "/proc/sys/fs/file-nr");
    if(rdval(file, "", data, 1, 2))
	return 1;

    scale(data[0]-data[1]);
    return 0;
}

//==============
s_stat* init_fd(const char *param) {
//==============
    MALLOC_STAT(fd_stat,s);
    s->collect = collect_fd;
    s->label = "fd ";
    s->width = 4;
    return (s_stat*)s;
}

//==============
S_STAT(time_stat)
    int prec;
    int scale;
} time_stat;

//==============
int collect_time(time_stat *s) {
//==============
    char buf[16];	// 12:34:56.123456<eol>
			// 1234567890123456
    simple_itoa(buf, 3, tv.tv_sec/(60*60)%24, 2);
    buf[2] = ':';
    simple_itoa(buf+3, 3, tv.tv_sec/60%60, 2);
    buf[5] = ':';
    simple_itoa(buf+6, 3, tv.tv_sec%60, 2);
    
    if(s->prec) {
	buf[8] = '.';
	//simple_itoa(buf+9, s->prec+1, (tv.tv_usec + s->scale/2) / s->scale, s->prec);
	// (fixme: round up seconds too!)
	// so... rounding omitted! just use more prec if you need it! ;)
	simple_itoa(buf+9, s->prec+1, tv.tv_usec / s->scale, s->prec);
    }
    put(buf);
    return 0;
}

//==============
s_stat* init_time(const char *param) {
//==============
    int prec;
    MALLOC_STAT(time_stat,s);
    s->collect = collect_time;
    s->label = "";
    prec = param[0]-'0';
    if(prec<0) prec = 0;
    else if(prec>6) prec = 6;
    s->width = 8+prec + (prec!=0);
    s->prec = prec;
    s->scale = 1;
    while(prec++ < 6)
	s->scale *= 10;
    return (s_stat*)s;
}

//==============
char *header;
//==============
void build_n_put_hdr(s_stat *s) {
//==============
    while(s) {
	int l = 0;
        if(s->label[0]!=' ') {
    	    put(s->label);
	    l = strlen(s->label);
	}
	while(l <= s->width) {
	    put_c(' ');	
	    l++;
	}
        s = s->next;
    }
    put_c('\n');

    header = (char*)malloc(outbuf_count()+1);
    memcpy(header, outbuf, outbuf_count());
    header[outbuf_count()] = '\0';
    //print_outbuf();
}

//==============
void put_hdr(s_stat *s) {
//==============
    if(!header) build_n_put_hdr(s);
    else {
	put(header);
	//print_outbuf();
    }
}

//==============
void run_once(s_stat *s, int without_headers) {
//==============
    gen++;
    int first = 1;
    while(s) {
	if(s->label[0]!=' ') {		// "[prev ][LABEL]data
	    if(!first) put_c(DELIM_CHAR);
    	    if(!without_headers) put(s->label);
	} else {			// "prevLABELdata
	    put(s->label+1);
	}
        if(s->collect(s)) {
	    int w = s->width;
	    while(w-- > 0)
		put_c('?');
	}
        s = s->next;
	first = 0;
    }
}

//==============
typedef s_stat* init_func(const char *param);

const char options[] = "ncmsfixptb";
init_func* init_functions[] = {
    init_if,  
    init_cpu, 
    init_mem, 
    init_swp, 
    init_fd,  
    init_int, 
    init_ctx, 
    init_fork,
    init_time,
    init_blk,
};

//#include <signal.h>
//static void setup_signals() {
//    sigset_t ss;
//
//    sigemptyset(&ss);
//    sigaddset(&ss, SIGPIPE);	
//    sigprocmask(SIG_BLOCK, &ss, NULL);
//}

//==============
int main(int argc, char* argv[]) {
//==============
    s_stat *first = 0;
    s_stat *last = 0;
    s_stat *s;
    int print_headers = 0;
    char *final_str = "\n";
    char *p;
    int fd;
    int i;

    //setup_signals();

    { // this incredibly ugly code is used only for timezone brain damage
	time_t tmp=0;
	// used only for a side effect of setting global timezone var:
	localtime(&tmp); 
    }
    
    if(argc==1) {
	put(
	"Nmeter " VERSION_STR " allows you to monitor your system in real time" NL
	NL
	"Options:" NL
	"c[N]	monitor CPU. N - bar size, default 10" NL
	"	(legend: S:system U:user N:niced D:iowait I:irq i:softirq)" NL
	"nIFACE	monitor network interface IFACE" NL
	"m[f/t]	monitor allocated/free/total memory" NL
	"s	monitor allocated swap" NL
	"f	monitor number of used filedescriptors" NL
	"i[NN]	monitor total/specific IRQ rate" NL
	"x	monitor context switch rate" NL
	"p	monitor process creation rate" NL
	"b	monitor block io" NL
	//"b[s]	monitor block io (swap io)" NL
	"t[N]	show time (with N decimal points)" NL
	"d[N]	milliseconds between updates. Default 1000" NL
	"h[N]	print headers above numbers (each N lines, default once)" NL
	"lLABEL	specify label for previous item" NL
	"LLABEL	same + label will be printed without surrounding blanks" NL
	"r	print <cr> instead of <lf> at EOL" NL
	);
	print_outbuf();
	return 0;
    }

    fd = open("/proc/version",O_RDONLY);
    if(fd>=0) {
	char buf[32];
	if(0<read(fd,buf,sizeof(buf)))
	    is26 = (strstr(buf,"Linux version 2.6.")!=NULL);
	close(fd);
    }
    for(i=1; i<argc; i++) {
	p = strchr(options,argv[i][0]);
	if(p) {
	    s = init_functions[p-options](argv[i]+1);
	    if(s) {
		s->next = 0;
		if(!first)
		    first = s;
		else
		    last->next = s;
		last = s;
	    }
	}

// You have to see it... gcc 3.2 coded switch() as 40 element jump table
// OH NO! >>>:^O
/*
#define SW(a) switch(a) {
#define ENDSW }
#define CASE(a,b) case (b): {
#define ENDCASE }
*/
#define SW(a) do {
#define ENDSW } while(0);
#define CASE(a,b) if((a)==(b)) {
#define ENDCASE }
	SW(argv[i][0])
	CASE(argv[i][0],'r')
	    final_str = "\r";
	    break;
	ENDCASE
	CASE(argv[i][0],'d')
	    delta = strtol(argv[i]+1, NULL, 0)*1000;
	    deltanz = delta>0? delta : 1;
	    break;
	ENDCASE
	CASE(argv[i][0],'h')
	    if(argv[i][1]=='\0')
		print_headers = -1;
	    else
		print_headers = strtol(argv[i]+1, NULL, 0);
	    break;
	ENDCASE
	CASE(argv[i][0],'l')
	    if(last)
		last->label=argv[i]+1;
	    break;
	ENDCASE
	CASE(argv[i][0],'L')
	    if(last) {
		argv[i][0]=' ';
		last->label=argv[i];
	    }
	    break;
	ENDCASE
	ENDSW
    }
	
    if(print_headers == -1) {
	build_n_put_hdr(first);
	print_outbuf();
    }
    run_once(first, print_headers);
    reset_outbuf();
    if(delta>=0) {
	gettimeofday(&tv,0);
	usleep(delta>1000000 ? 1000000 : delta-tv.tv_usec%deltanz);
    }
    while(1) {
	gettimeofday(&tv,0);
	tv.tv_sec -= timezone;

	if(print_headers > 0 && gen%print_headers == 0)
	    put_hdr(first);
	run_once(first, print_headers);
	put(final_str);
	print_outbuf();

	// Negative delta -> no usleep at all
	// This will hog the CPU but you can have REALLY GOOD
	// time resolution ;)
	// TODO: detect and avoid useless updates
	// (like: nothing happens except time)
        if(delta>=0) {
	    int rem = delta - ((ullong)tv.tv_sec*1000000+tv.tv_usec)%deltanz;
	    // Sometimes kernel wakes us up just a tiny bit earlier than asked
	    // Do not go to very short sleep in this case
	    if(rem < delta/128) {
		rem += delta;
	    }
	    usleep(rem);
	}
    }

    return 0;
}

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

* [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-25 10:40                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0 Ingo Molnar
                                                         ` (3 preceding siblings ...)
  2004-10-25 23:04                                       ` Remi Colinet
@ 2004-10-27  0:15                                       ` Ingo Molnar
  2004-10-27  0:44                                         ` Ingo Molnar
                                                           ` (5 more replies)
  4 siblings, 6 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27  0:15 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese


i have released the -V0.3 Real-Time Preemption patch, which can be
downloaded from:

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

this is a fixes-only release, but still experimental.

this release should fix a number of bugs that were reported for the V0
series: the futex.c assert, the lockups and the 'slowdown problem'.

The slowdown problem was an architectural issue that surfaced sometime
around U10 and increased in prominence as the the number of mutexes
increased and the number of spinlocks decreased. The futex.c assert was
related to this architectural issue as well, and most of the lockups
reported were i believe livelocks caused by the same issue. Also, the
scheduler path had an easy-to-trigger deadlock that often just silently
locked up.

some of the networking lockups might be related to this issue too, but i
think PREEMPT_REALTIME still has separate lock odering issues within the
networking code. Please re-report any deadlock-tracer asserts that you
might encounter.

Changes since -V0.2:

 - HEAP_SIZE fix from Karsten Wiese

 - fix hdparm-triggered debugging message reported by Mark H Johnson

 - fixed mutex related preemption to not impact the task state, just 
   like a normal spinlock does. This necessiated the introduction of
   TASK_RUNNING_MUTEX handling and related kernel infrastructure. This 
   framework avoids spurious wakeups done by mutex handling by isolating
   the state changes done by normal wakeups vs. the state changes caused
   by the mutex code.

 - added per-CPU deschedule threads. This fixes a deadlock scenario and
   it is also much faster than keventd.

 - fix debugging message upon console unblanking

to create a -V0.3 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/2.6.9-mm1.bz2
 + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-V0.3

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26 10:53                                           ` K.R. Foley
  2004-10-26 10:57                                             ` Ingo Molnar
@ 2004-10-27  0:24                                             ` Ingo Molnar
  2004-10-27  0:53                                               ` K.R. Foley
                                                                 ` (2 more replies)
  1 sibling, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27  0:24 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> Several things in regard to V0.2:
> 
> 1) Interactive responsiveness seems to be noticably sluggish at times on
> all three of the systems I have tested this on.
> 2) My 450MHz UP system is definitely the worst by far. Scrolling through
> the syslog in a telnet session produces pauses every few seconds for
> about a second, that is while it's still responding. These problems seem
> to be network related, but there are no indications of what the problem
> is. This system also at times will just stop responding to network requests.
> 3) Both of the SMP systems are lacking the snappy responsiveness in X
> that I have become accustomed to with previous patches, but the 2.6GHz
> Xeon (w/HT) is worse than the 933MHz Xeon. Again no indications of
> problems in the logs.
> 4) Using amlat to run the RTC at 1kHz will kill any of these systems
> very quickly.

could you try this with -V0.3 too? I believe most of these problems
should be solved.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-27  0:15                                       ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Ingo Molnar
@ 2004-10-27  0:44                                         ` Ingo Molnar
  2004-10-27  1:43                                         ` Bill Huey
                                                           ` (4 subsequent siblings)
  5 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27  0:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese


> i have released the -V0.3 Real-Time Preemption patch, which can be
> downloaded from:
> 
> 	http://redhat.com/~mingo/realtime-preempt/
> 
> this is a fixes-only release, but still experimental.

i've uploaded -V0.3.1, it fixes a trivial procfs oversight (related to
the new TASK_RUNNING_MUTEX state) that just triggered a crash in one of
my stresstests.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  0:24                                             ` Ingo Molnar
@ 2004-10-27  0:53                                               ` K.R. Foley
  2004-10-27  3:32                                               ` K.R. Foley
  2004-10-27  3:48                                               ` K.R. Foley
  2 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-27  0:53 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>Several things in regard to V0.2:
>>
>>1) Interactive responsiveness seems to be noticably sluggish at times on
>>all three of the systems I have tested this on.
>>2) My 450MHz UP system is definitely the worst by far. Scrolling through
>>the syslog in a telnet session produces pauses every few seconds for
>>about a second, that is while it's still responding. These problems seem
>>to be network related, but there are no indications of what the problem
>>is. This system also at times will just stop responding to network requests.
>>3) Both of the SMP systems are lacking the snappy responsiveness in X
>>that I have become accustomed to with previous patches, but the 2.6GHz
>>Xeon (w/HT) is worse than the 933MHz Xeon. Again no indications of
>>problems in the logs.
>>4) Using amlat to run the RTC at 1kHz will kill any of these systems
>>very quickly.
> 
> 
> could you try this with -V0.3 too? I believe most of these problems
> should be solved.
> 
> 	Ingo
> 

Sure will. It's building on two of the systems now (V0.3.1).

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-27  0:15                                       ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Ingo Molnar
  2004-10-27  0:44                                         ` Ingo Molnar
@ 2004-10-27  1:43                                         ` Bill Huey
  2004-10-27  2:04                                           ` K.R. Foley
  2004-10-27 10:50                                         ` Michal Schmidt
                                                           ` (3 subsequent siblings)
  5 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-27  1:43 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese

On Wed, Oct 27, 2004 at 02:15:42AM +0200, Ingo Molnar wrote:
> 
> i have released the -V0.3 Real-Time Preemption patch, which can be
> downloaded from:
> 
> 	http://redhat.com/~mingo/realtime-preempt/

>  + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-V0.3

Bad link.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-27  1:43                                         ` Bill Huey
@ 2004-10-27  2:04                                           ` K.R. Foley
  2004-10-27  3:29                                             ` Bill Huey
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-27  2:04 UTC (permalink / raw)
  To: Bill Huey (hui)
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese

Bill Huey (hui) wrote:
> On Wed, Oct 27, 2004 at 02:15:42AM +0200, Ingo Molnar wrote:
> 
>>i have released the -V0.3 Real-Time Preemption patch, which can be
>>downloaded from:
>>
>>	http://redhat.com/~mingo/realtime-preempt/
> 
> 
>> + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-V0.3
> 
> 
> Bad link.
> 
> bill
> 
> 
That's because he uploaded V0.3.1.

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-27  2:04                                           ` K.R. Foley
@ 2004-10-27  3:29                                             ` Bill Huey
  2004-10-27  3:35                                               ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-27  3:29 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Bill Huey (hui),
	Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese

On Tue, Oct 26, 2004 at 09:04:18PM -0500, K.R. Foley wrote:
> Bill Huey (hui) wrote:
> >On Wed, Oct 27, 2004 at 02:15:42AM +0200, Ingo Molnar wrote:
> >>i have released the -V0.3 Real-Time Preemption patch, which can be
> >>downloaded from:
> >>
> >>	http://redhat.com/~mingo/realtime-preempt/

> That's because he uploaded V0.3.1.

Even that top level link/directory doesn't work.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  0:24                                             ` Ingo Molnar
  2004-10-27  0:53                                               ` K.R. Foley
@ 2004-10-27  3:32                                               ` K.R. Foley
  2004-10-27  8:28                                                 ` Ingo Molnar
                                                                   ` (2 more replies)
  2004-10-27  3:48                                               ` K.R. Foley
  2 siblings, 3 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-27  3:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>Several things in regard to V0.2:
>>
>>1) Interactive responsiveness seems to be noticably sluggish at times on
>>all three of the systems I have tested this on.
>>2) My 450MHz UP system is definitely the worst by far. Scrolling through
>>the syslog in a telnet session produces pauses every few seconds for
>>about a second, that is while it's still responding. These problems seem
>>to be network related, but there are no indications of what the problem
>>is. This system also at times will just stop responding to network requests.
>>3) Both of the SMP systems are lacking the snappy responsiveness in X
>>that I have become accustomed to with previous patches, but the 2.6GHz
>>Xeon (w/HT) is worse than the 933MHz Xeon. Again no indications of
>>problems in the logs.
>>4) Using amlat to run the RTC at 1kHz will kill any of these systems
>>very quickly.
> 
> 
> could you try this with -V0.3 too? I believe most of these problems
> should be solved.
> 
> 	Ingo
> 

I've repeated the above on the dual 933 Xeon:

Still problems with interactive behavior. Running KDE, with top running 
in xterm, scrolling through the menus I get some pauses. When the pauses 
occur I see kdeinit hit the top of the list and sometimes consuming 90% 
or more of a CPU and idle usage drops to 30-40%. I do see some latency 
traces (not really high ones) in the log that were generated by kdeinit 
but I think they were generated prior to when these pauses occurred, 
most likely when logging in.

Running amlat still hard locks the system. The last time this happened I 
got this in the log:

  Oct 26 21:43:56 porky kernel: BUG: sleeping function called from 
invalid context amlat(3963) at kernel/mutex.c:28
Oct 26 21:43:56 porky kernel: in_atomic():1 [00000001], irqs_disabled():1
Oct 26 21:43:56 porky kernel:  [<c011c7da>] __might_sleep+0xca/0xe0 (12)
Oct 26 21:43:56 porky kernel:  [<c0137d89>] _mutex_lock+0x39/0x50 (36)
Oct 26 21:43:56 porky kernel:  [<c0137df6>] 
_mutex_lock_irqsave+0x16/0x20 (24)
Oct 26 21:43:56 porky kernel:  [<c012977d>] __mod_timer+0x4d/0x1f0 (12)
Oct 26 21:43:56 porky kernel:  [<c01f6535>] rtc_do_ioctl+0x185/0x970 (44)
Oct 26 21:43:56 porky kernel:  [<c013838d>] __mcount+0x1d/0x30 (136)
Oct 26 21:43:56 porky kernel:  [<c01f6d2b>] rtc_ioctl+0xb/0x30 (4)
Oct 26 21:43:56 porky kernel:  [<c0179367>] sys_ioctl+0xe7/0x250 (4)
Oct 26 21:43:56 porky kernel:  [<c01131f8>] mcount+0x14/0x18 (8)
Oct 26 21:43:56 porky kernel:  [<c01f6d2b>] rtc_ioctl+0xb/0x30 (20)
Oct 26 21:43:56 porky kernel:  [<c0179367>] sys_ioctl+0xe7/0x250 (20)
Oct 26 21:43:56 porky kernel:  [<c0106739>] sysenter_past_esp+0x52/0x71 (48)
Oct 26 21:43:56 porky kernel: preempt count: 00000002
Oct 26 21:43:56 porky kernel: . 2-level deep critical section nesting:
Oct 26 21:43:56 porky kernel: .. entry 1: _spin_lock_irqsave+0x22/0x80 
[<c02c71c2>] / (rtc_do_ioctl+0x158/0x970 [<c01f6508>])
Oct 26 21:43:56 porky kernel: .. entry 2: print_traces+0x1d/0x60 
[<c01394bd>] / (dump_stack+0x23/0x30 [<c0107613>])
Oct 26 21:43:56 porky kernel:
Oct 26 21:43:56 porky kernel: BUG: scheduling while atomic: IRQ 
8/0x00000001/672
Oct 26 21:43:56 porky kernel: caller is schedule+0x30/0xe0
Oct 26 21:43:57 porky kernel:  [<c02c58c1>] __schedule+0x771/0x7d0 (12)
Oct 26 21:43:57 porky kernel:  [<c02c5950>] schedule+0x30/0xe0 (8)
Oct 26 21:43:57 porky kernel:  [<c013838d>] __mcount+0x1d/0x30 (60)
Oct 26 21:43:57 porky kernel:  [<c02c592e>] schedule+0xe/0xe0 (4)
Oct 26 21:43:57 porky kernel:  [<c02c6c4d>] down_write_mutex+0x12d/0x1e0 (4)
Oct 26 21:43:57 porky kernel:  [<c01131f8>] mcount+0x14/0x18 (8)
Oct 26 21:43:57 porky kernel:  [<c02c5950>] schedule+0x30/0xe0 (20)
Oct 26 21:43:57 porky kernel:  [<c01131f8>] mcount+0x14/0x18 (4)
Oct 26 21:43:57 porky kernel:  [<c02c74ea>] _spin_unlock+0x1a/0x40 (20)
Oct 26 21:43:57 porky kernel:  [<c02c6c4d>] down_write_mutex+0x12d/0x1e0 
(12)

Working on booting the 450 right now.

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-27  3:29                                             ` Bill Huey
@ 2004-10-27  3:35                                               ` K.R. Foley
  2004-10-27  3:40                                                 ` Bill Huey
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-27  3:35 UTC (permalink / raw)
  To: Bill Huey (hui)
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese

Bill Huey (hui) wrote:
> On Tue, Oct 26, 2004 at 09:04:18PM -0500, K.R. Foley wrote:
> 
>>Bill Huey (hui) wrote:
>>
>>>On Wed, Oct 27, 2004 at 02:15:42AM +0200, Ingo Molnar wrote:
>>>
>>>>i have released the -V0.3 Real-Time Preemption patch, which can be
>>>>downloaded from:
>>>>
>>>>	http://redhat.com/~mingo/realtime-preempt/
> 
> 
>>That's because he uploaded V0.3.1.
> 
> 
> Even that top level link/directory doesn't work.
> 
> bill
> 
> 
For me it redirects to http://people.redhat.com/mingo/realtime-preempt/ 
Try that directly.

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-27  3:35                                               ` K.R. Foley
@ 2004-10-27  3:40                                                 ` Bill Huey
  0 siblings, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-27  3:40 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Bill Huey (hui),
	Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese

On Tue, Oct 26, 2004 at 10:35:01PM -0500, K.R. Foley wrote:
> Bill Huey (hui) wrote:
> For me it redirects to http://people.redhat.com/mingo/realtime-preempt/ 
> Try that directly.

They both work now, same for redirection.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  0:24                                             ` Ingo Molnar
  2004-10-27  0:53                                               ` K.R. Foley
  2004-10-27  3:32                                               ` K.R. Foley
@ 2004-10-27  3:48                                               ` K.R. Foley
  2 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-27  3:48 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>Several things in regard to V0.2:
>>
>>1) Interactive responsiveness seems to be noticably sluggish at times on
>>all three of the systems I have tested this on.
>>2) My 450MHz UP system is definitely the worst by far. Scrolling through
>>the syslog in a telnet session produces pauses every few seconds for
>>about a second, that is while it's still responding. These problems seem
>>to be network related, but there are no indications of what the problem
>>is. This system also at times will just stop responding to network requests.
>>3) Both of the SMP systems are lacking the snappy responsiveness in X
>>that I have become accustomed to with previous patches, but the 2.6GHz
>>Xeon (w/HT) is worse than the 933MHz Xeon. Again no indications of
>>problems in the logs.
>>4) Using amlat to run the RTC at 1kHz will kill any of these systems
>>very quickly.
> 
> 
> could you try this with -V0.3 too? I believe most of these problems
> should be solved.
> 
> 	Ingo
> 

OK the 450 (UP) dies before it gets out of the gate. From the tail end 
of the Oops on the screen it looks to be related to the rtc also. Will 
investigate further after I rest my eyes a bit.

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-26 19:09                                                             ` Denis Vlasenko
@ 2004-10-27  8:23                                                               ` Rui Nuno Capela
  0 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-27  8:23 UTC (permalink / raw)
  To: Denis Vlasenko; +Cc: linux-kernel

>> Denis Vlasenko wrote:
>> >
>> > <shameless plug>
>> > Maybe this program will be useful. It is designed to give you
>> > overall system statistics without the need to scan entire /proc/NNN
>> > forest. Together with nice -20, it will hopefully not stall.
>> >
>> > Compiled with dietlibc. If you will have trouble compiling it,
>> > binary is attached too.
>> >
>> > Latest version is 0.9 but it seems I forgot it in my home box :(
>> </shameless plug>
>>
>> Thanks for nmeter. I have changed a couple of little bits to build with
>> gcc-3.4 here (see diff attached).
>
> Hmm will it compile on 3.4 with "static inline"?
>

Yes, it now compiles on gcc-3.4.1 out of the box.

Thanks for this nice little utility.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  3:32                                               ` K.R. Foley
@ 2004-10-27  8:28                                                 ` Ingo Molnar
  2004-10-27  8:44                                                   ` Ingo Molnar
  2004-10-27  9:24                                                 ` Ingo Molnar
  2004-10-27 13:29                                                 ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27  8:28 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> Running amlat still hard locks the system. The last time this happened
> I got this in the log:
> 
>  Oct 26 21:43:56 porky kernel: BUG: sleeping function called from 
> invalid context amlat(3963) at kernel/mutex.c:28
> Oct 26 21:43:56 porky kernel: in_atomic():1 [00000001], irqs_disabled():1
> Oct 26 21:43:56 porky kernel:  [<c011c7da>] __might_sleep+0xca/0xe0 (12)
> Oct 26 21:43:56 porky kernel:  [<c0137d89>] _mutex_lock+0x39/0x50 (36)
> Oct 26 21:43:56 porky kernel:  [<c0137df6>]  _mutex_lock_irqsave+0x16/0x20 (24)
> Oct 26 21:43:56 porky kernel:  [<c012977d>] __mod_timer+0x4d/0x1f0 (12)
> Oct 26 21:43:56 porky kernel:  [<c01f6535>] rtc_do_ioctl+0x185/0x970 (44)

does the quick hack below help?

	Ingo

--- linux/drivers/char/rtc.c.orig
+++ linux/drivers/char/rtc.c
@@ -238,11 +238,11 @@ irqreturn_t rtc_interrupt(int irq, void 
 		rtc_irq_data |= (CMOS_READ(RTC_INTR_FLAGS) & 0xF0);
 	}
 
+	spin_unlock (&rtc_lock);
+
 	if (rtc_status & RTC_TIMER_ON)
 		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
 
-	spin_unlock (&rtc_lock);
-
 	/* Now do the rest of the actions */
 	spin_lock(&rtc_task_lock);
 	if (rtc_callback)
@@ -1094,10 +1094,6 @@ static void rtc_dropped_irq(unsigned lon
 		return;
 	}
 
-	/* Just in case someone disabled the timer from behind our back... */
-	if (rtc_status & RTC_TIMER_ON)
-		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
-
 	rtc_irq_data += ((rtc_freq/HZ)<<8);
 	rtc_irq_data &= ~0xff;
 	rtc_irq_data |= (CMOS_READ(RTC_INTR_FLAGS) & 0xF0);	/* restart */
@@ -1106,6 +1102,10 @@ static void rtc_dropped_irq(unsigned lon
 
 	spin_unlock_irq(&rtc_lock);
 
+	/* Just in case someone disabled the timer from behind our back... */
+	if (rtc_status & RTC_TIMER_ON)
+		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
+
 	printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
 
 	/* Now we have new data */

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  8:28                                                 ` Ingo Molnar
@ 2004-10-27  8:44                                                   ` Ingo Molnar
  2004-10-27  8:52                                                     ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27  8:44 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> >  Oct 26 21:43:56 porky kernel: BUG: sleeping function called from 
> > invalid context amlat(3963) at kernel/mutex.c:28
> > Oct 26 21:43:56 porky kernel: in_atomic():1 [00000001], irqs_disabled():1
> > Oct 26 21:43:56 porky kernel:  [<c011c7da>] __might_sleep+0xca/0xe0 (12)
> > Oct 26 21:43:56 porky kernel:  [<c0137d89>] _mutex_lock+0x39/0x50 (36)
> > Oct 26 21:43:56 porky kernel:  [<c0137df6>]  _mutex_lock_irqsave+0x16/0x20 (24)
> > Oct 26 21:43:56 porky kernel:  [<c012977d>] __mod_timer+0x4d/0x1f0 (12)
> > Oct 26 21:43:56 porky kernel:  [<c01f6535>] rtc_do_ioctl+0x185/0x970 (44)
> 
> does the quick hack below help?

here's a more complete fix.

	Ingo

--- linux/drivers/char/rtc.c.orig
+++ linux/drivers/char/rtc.c
@@ -177,7 +177,7 @@ static unsigned long rtc_max_user_freq =
 /*
  * rtc_task_lock nests inside rtc_lock.
  */
-static DECLARE_SPINLOCK(rtc_task_lock);
+static DECLARE_RAW_SPINLOCK(rtc_task_lock);
 static rtc_task_t *rtc_callback = NULL;
 #endif
 
@@ -238,10 +238,17 @@ irqreturn_t rtc_interrupt(int irq, void 
 		rtc_irq_data |= (CMOS_READ(RTC_INTR_FLAGS) & 0xF0);
 	}
 
-	if (rtc_status & RTC_TIMER_ON)
+	if (rtc_status & RTC_TIMER_ON) {
+		spin_unlock (&rtc_lock);
+		/*
+		 * We do the mod_timer outside of the lock because
+		 * it may reschedule under PREEMPT_REALTIME. As long
+		 * as we read the flag race-free it is not a problem
+		 * if two mod_timer()s race:
+		 */
 		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
-
-	spin_unlock (&rtc_lock);
+	} else
+		spin_unlock (&rtc_lock);
 
 	/* Now do the rest of the actions */
 	spin_lock(&rtc_task_lock);
@@ -1094,17 +1101,19 @@ static void rtc_dropped_irq(unsigned lon
 		return;
 	}
 
-	/* Just in case someone disabled the timer from behind our back... */
-	if (rtc_status & RTC_TIMER_ON)
-		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
-
 	rtc_irq_data += ((rtc_freq/HZ)<<8);
 	rtc_irq_data &= ~0xff;
 	rtc_irq_data |= (CMOS_READ(RTC_INTR_FLAGS) & 0xF0);	/* restart */
 
 	freq = rtc_freq;
 
-	spin_unlock_irq(&rtc_lock);
+	/* Just in case someone disabled the timer from behind our back... */
+	if (rtc_status & RTC_TIMER_ON) {
+		spin_unlock_irq(&rtc_lock);
+		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
+	} else
+		spin_unlock_irq(&rtc_lock);
+
 
 	printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  8:44                                                   ` Ingo Molnar
@ 2004-10-27  8:52                                                     ` Ingo Molnar
  2004-10-27  9:06                                                       ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27  8:52 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> > does the quick hack below help?
> 
> here's a more complete fix.

third time lucky?

	Ingo

--- linux/drivers/char/rtc.c.orig
+++ linux/drivers/char/rtc.c
@@ -177,7 +177,7 @@ static unsigned long rtc_max_user_freq =
 /*
  * rtc_task_lock nests inside rtc_lock.
  */
-static DECLARE_SPINLOCK(rtc_task_lock);
+static DECLARE_RAW_SPINLOCK(rtc_task_lock);
 static rtc_task_t *rtc_callback = NULL;
 #endif
 
@@ -238,10 +238,17 @@ irqreturn_t rtc_interrupt(int irq, void 
 		rtc_irq_data |= (CMOS_READ(RTC_INTR_FLAGS) & 0xF0);
 	}
 
-	if (rtc_status & RTC_TIMER_ON)
+	if (rtc_status & RTC_TIMER_ON) {
+		spin_unlock (&rtc_lock);
+		/*
+		 * We do the mod_timer outside of the lock because
+		 * it may reschedule under PREEMPT_REALTIME. As long
+		 * as we read the flag race-free it is not a problem
+		 * if two mod_timer()s race:
+		 */
 		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
-
-	spin_unlock (&rtc_lock);
+	} else
+		spin_unlock (&rtc_lock);
 
 	/* Now do the rest of the actions */
 	spin_lock(&rtc_task_lock);
@@ -404,8 +411,8 @@ static int rtc_do_ioctl(unsigned int cmd
 		if (rtc_status & RTC_TIMER_ON) {
 			spin_lock_irq (&rtc_lock);
 			rtc_status &= ~RTC_TIMER_ON;
-			del_timer(&rtc_irq_timer);
 			spin_unlock_irq (&rtc_lock);
+			del_timer(&rtc_irq_timer); // FIXME
 		}
 		return 0;
 	}
@@ -730,9 +737,10 @@ static int rtc_release(struct inode *ino
 	}
 	if (rtc_status & RTC_TIMER_ON) {
 		rtc_status &= ~RTC_TIMER_ON;
-		del_timer(&rtc_irq_timer);
-	}
-	spin_unlock_irq(&rtc_lock);
+		spin_unlock_irq(&rtc_lock);
+		del_timer(&rtc_irq_timer); // FIXME
+	} else
+		spin_unlock_irq(&rtc_lock);
 
 	if (file->f_flags & FASYNC) {
 		rtc_fasync (-1, file, 0);
@@ -808,6 +816,7 @@ int rtc_unregister(rtc_task_t *task)
 	return -EIO;
 #else
 	unsigned char tmp;
+	int rm_timer;
 
 	spin_lock_irq(&rtc_lock);
 	spin_lock(&rtc_task_lock);
@@ -827,13 +836,16 @@ int rtc_unregister(rtc_task_t *task)
 		CMOS_WRITE(tmp, RTC_CONTROL);
 		CMOS_READ(RTC_INTR_FLAGS);
 	}
+	rm_timer = 0;
 	if (rtc_status & RTC_TIMER_ON) {
 		rtc_status &= ~RTC_TIMER_ON;
-		del_timer(&rtc_irq_timer);
+		rm_timer = 1;
 	}
 	rtc_status &= ~RTC_IS_OPEN;
 	spin_unlock(&rtc_task_lock);
 	spin_unlock_irq(&rtc_lock);
+	if (rm_timer)
+		del_timer(&rtc_irq_timer);
 	return 0;
 #endif
 }
@@ -1094,17 +1106,19 @@ static void rtc_dropped_irq(unsigned lon
 		return;
 	}
 
-	/* Just in case someone disabled the timer from behind our back... */
-	if (rtc_status & RTC_TIMER_ON)
-		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
-
 	rtc_irq_data += ((rtc_freq/HZ)<<8);
 	rtc_irq_data &= ~0xff;
 	rtc_irq_data |= (CMOS_READ(RTC_INTR_FLAGS) & 0xF0);	/* restart */
 
 	freq = rtc_freq;
 
-	spin_unlock_irq(&rtc_lock);
+	/* Just in case someone disabled the timer from behind our back... */
+	if (rtc_status & RTC_TIMER_ON) {
+		spin_unlock_irq(&rtc_lock);
+		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
+	} else
+		spin_unlock_irq(&rtc_lock);
+
 
 	printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  8:52                                                     ` Ingo Molnar
@ 2004-10-27  9:06                                                       ` Ingo Molnar
  2004-10-27 10:03                                                         ` Ingo Molnar
  2004-10-27 10:33                                                         ` Florian Schmidt
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27  9:06 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> third time lucky?

there was one more piece missing...

i've also uploaded -RT-V0.3.2 with this fix included.

	Ingo

--- linux/drivers/char/rtc.c.orig
+++ linux/drivers/char/rtc.c
@@ -177,7 +177,7 @@ static unsigned long rtc_max_user_freq =
 /*
  * rtc_task_lock nests inside rtc_lock.
  */
-static DECLARE_SPINLOCK(rtc_task_lock);
+static DECLARE_RAW_SPINLOCK(rtc_task_lock);
 static rtc_task_t *rtc_callback = NULL;
 #endif
 
@@ -217,6 +217,8 @@ static inline unsigned char rtc_is_updat
 
 irqreturn_t rtc_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
+	unsigned long flags;
+
 	/*
 	 *	Can be an alarm interrupt, update complete interrupt,
 	 *	or a periodic interrupt. We store the status in the
@@ -224,7 +226,7 @@ irqreturn_t rtc_interrupt(int irq, void 
 	 *	the last read in the remainder of rtc_irq_data.
 	 */
 
-	spin_lock (&rtc_lock);
+	spin_lock_irqsave(&rtc_lock, flags);
 	rtc_irq_data += 0x100;
 	rtc_irq_data &= ~0xff;
 	if (is_hpet_enabled()) {
@@ -238,16 +240,23 @@ irqreturn_t rtc_interrupt(int irq, void 
 		rtc_irq_data |= (CMOS_READ(RTC_INTR_FLAGS) & 0xF0);
 	}
 
-	if (rtc_status & RTC_TIMER_ON)
+	if (rtc_status & RTC_TIMER_ON) {
+		spin_unlock_irqrestore(&rtc_lock, flags);
+		/*
+		 * We do the mod_timer outside of the lock because
+		 * it may reschedule under PREEMPT_REALTIME. As long
+		 * as we read the flag race-free it is not a problem
+		 * if two mod_timer()s race:
+		 */
 		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
-
-	spin_unlock (&rtc_lock);
+	} else
+		spin_unlock_irqrestore(&rtc_lock, flags);
 
 	/* Now do the rest of the actions */
-	spin_lock(&rtc_task_lock);
+	spin_lock_irqsave(&rtc_task_lock, flags);
 	if (rtc_callback)
 		rtc_callback->func(rtc_callback->private_data);
-	spin_unlock(&rtc_task_lock);
+	spin_unlock_irqrestore(&rtc_task_lock, flags);
 	wake_up_interruptible(&rtc_wait);	
 
 	kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
@@ -404,8 +413,8 @@ static int rtc_do_ioctl(unsigned int cmd
 		if (rtc_status & RTC_TIMER_ON) {
 			spin_lock_irq (&rtc_lock);
 			rtc_status &= ~RTC_TIMER_ON;
-			del_timer(&rtc_irq_timer);
 			spin_unlock_irq (&rtc_lock);
+			del_timer(&rtc_irq_timer); // FIXME
 		}
 		return 0;
 	}
@@ -422,10 +431,9 @@ static int rtc_do_ioctl(unsigned int cmd
 
 		if (!(rtc_status & RTC_TIMER_ON)) {
 			spin_lock_irq (&rtc_lock);
-			rtc_irq_timer.expires = jiffies + HZ/rtc_freq + 2*HZ/100;
-			add_timer(&rtc_irq_timer);
 			rtc_status |= RTC_TIMER_ON;
 			spin_unlock_irq (&rtc_lock);
+			mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
 		}
 		set_rtc_irq_bit(RTC_PIE);
 		return 0;
@@ -730,9 +738,10 @@ static int rtc_release(struct inode *ino
 	}
 	if (rtc_status & RTC_TIMER_ON) {
 		rtc_status &= ~RTC_TIMER_ON;
-		del_timer(&rtc_irq_timer);
-	}
-	spin_unlock_irq(&rtc_lock);
+		spin_unlock_irq(&rtc_lock);
+		del_timer(&rtc_irq_timer); // FIXME
+	} else
+		spin_unlock_irq(&rtc_lock);
 
 	if (file->f_flags & FASYNC) {
 		rtc_fasync (-1, file, 0);
@@ -808,6 +817,7 @@ int rtc_unregister(rtc_task_t *task)
 	return -EIO;
 #else
 	unsigned char tmp;
+	int rm_timer;
 
 	spin_lock_irq(&rtc_lock);
 	spin_lock(&rtc_task_lock);
@@ -827,13 +837,16 @@ int rtc_unregister(rtc_task_t *task)
 		CMOS_WRITE(tmp, RTC_CONTROL);
 		CMOS_READ(RTC_INTR_FLAGS);
 	}
+	rm_timer = 0;
 	if (rtc_status & RTC_TIMER_ON) {
 		rtc_status &= ~RTC_TIMER_ON;
-		del_timer(&rtc_irq_timer);
+		rm_timer = 1;
 	}
 	rtc_status &= ~RTC_IS_OPEN;
 	spin_unlock(&rtc_task_lock);
 	spin_unlock_irq(&rtc_lock);
+	if (rm_timer)
+		del_timer(&rtc_irq_timer);
 	return 0;
 #endif
 }
@@ -1094,17 +1107,19 @@ static void rtc_dropped_irq(unsigned lon
 		return;
 	}
 
-	/* Just in case someone disabled the timer from behind our back... */
-	if (rtc_status & RTC_TIMER_ON)
-		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
-
 	rtc_irq_data += ((rtc_freq/HZ)<<8);
 	rtc_irq_data &= ~0xff;
 	rtc_irq_data |= (CMOS_READ(RTC_INTR_FLAGS) & 0xF0);	/* restart */
 
 	freq = rtc_freq;
 
-	spin_unlock_irq(&rtc_lock);
+	/* Just in case someone disabled the timer from behind our back... */
+	if (rtc_status & RTC_TIMER_ON) {
+		spin_unlock_irq(&rtc_lock);
+		mod_timer(&rtc_irq_timer, jiffies + HZ/rtc_freq + 2*HZ/100);
+	} else
+		spin_unlock_irq(&rtc_lock);
+
 
 	printk(KERN_WARNING "rtc: lost some interrupts at %ldHz.\n", freq);
 

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  3:32                                               ` K.R. Foley
  2004-10-27  8:28                                                 ` Ingo Molnar
@ 2004-10-27  9:24                                                 ` Ingo Molnar
  2004-10-27  9:32                                                   ` Ingo Molnar
  2004-10-27 13:29                                                 ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27  9:24 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> I've repeated the above on the dual 933 Xeon:
> 
> Still problems with interactive behavior. Running KDE, with top
> running in xterm, scrolling through the menus I get some pauses. When
> the pauses occur I see kdeinit hit the top of the list and sometimes
> consuming 90% or more of a CPU and idle usage drops to 30-40%. I do
> see some latency traces (not really high ones) in the log that were
> generated by kdeinit but I think they were generated prior to when
> these pauses occurred, most likely when logging in.

is this 90% or more CPU time system (kernel) overhead or userspace
overhead?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  9:24                                                 ` Ingo Molnar
@ 2004-10-27  9:32                                                   ` Ingo Molnar
  2004-10-27 12:19                                                     ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27  9:32 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


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

> > Still problems with interactive behavior. Running KDE, with top
> > running in xterm, scrolling through the menus I get some pauses. When
> > the pauses occur I see kdeinit hit the top of the list and sometimes
> > consuming 90% or more of a CPU and idle usage drops to 30-40%. I do
> > see some latency traces (not really high ones) in the log that were
> > generated by kdeinit but I think they were generated prior to when
> > these pauses occurred, most likely when logging in.
> 
> is this 90% or more CPU time system (kernel) overhead or userspace
> overhead?

another thing to watch for is the context-switch rate in vmstat. -V0.3
patches include a hack that include involuntary context-switches (mutex
context switches) in the context-switch stat as well. (previously those
were reported in a separate field which vmstat didnt pick up.)

So if the context-switch rate shots up to above say 100K/sec that is a
sure sign of some mutex badness. The livelock scenarios i solved in
-V0.3 occasionally generated a more than 500K/sec context-switch rate on
a 2GHz box. Having just a couple of thousand per sec isnt by itself a
sign of anything unusual.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  9:06                                                       ` Ingo Molnar
@ 2004-10-27 10:03                                                         ` Ingo Molnar
  2004-10-27 10:33                                                         ` Florian Schmidt
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 10:03 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


> i've also uploaded -RT-V0.3.2 with this fix included.

note that if you are running amlat/realfeel then you should do something
like this after starting realfeel:

  chrt -f 99 -p `pidof 'IRQ 8'`
  chrt -f 98 -p `pidof realfeel`

because by default IRQ 8 has a lower RT priority than realfeel.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 10:33                                                         ` Florian Schmidt
@ 2004-10-27 10:29                                                           ` Ingo Molnar
  2004-10-27 10:58                                                             ` Florian Schmidt
  2004-10-27 10:45                                                           ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 10:29 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> jackd runs with a period size of 128 frames (48000hz samplerate) and with
> SCHED_FIFO with prios from 60 to 70 (ps output is somewhat broken):
> 
> mango:~# ps -cmL `pidof jackd`
>   PID   LWP CLS PRI TTY      STAT   TIME COMMAND
>  1286     - -     - ?        -      0:28 /usr/bin/jackd -R -P60 -t20000 -dalsa -
>     -  1286 TS   20 -        SLsl   0:00 -
>     -  1287 TS   23 -        SLsl   0:00 -
>     -  1288 FF  110 -        SLsl   0:00 -
>     -  1289 FF  100 -        SLsl   0:27 -
> 
> ~$ chrt -p 1286
> pid 1286's current scheduling policy: SCHED_OTHER
> pid 1286's current scheduling priority: 0
> ~$ chrt -p 1287
> pid 1287's current scheduling policy: SCHED_OTHER
> pid 1287's current scheduling priority: 0

just curious, are these two important to the latency path of jackd, or
are they lowprio things and are thus at SCHED_OTHER intentionally?

> ~$ chrt -p 1288
> pid 1288's current scheduling policy: SCHED_FIFO
> pid 1288's current scheduling priority: 70
> ~$ chrt -p 1289
> pid 1289's current scheduling policy: SCHED_FIFO
> pid 1289's current scheduling priority: 60
> 
> Anyways i get xruns like crazy under load (like 200 in 10 minutes). It
> seems the scheduling class and high priority don't matter really as
> wiggling windows around on the screen or doing a "find /" can easily
> provoke xruns.

yeah, i'm hunting a quite similar bug: i can see 'realfeel' latencies
generated by simple window scrolling. It is most likely a logic bug
somewhere - a missing reschedule check, irqs left disabled accidentally,
or something like that. Since some other workloads dont trigger it i
dont think i broke RT scheduling by itself - it is most likely some
non-core code somewhere missing a resched. Which doesnt make it less of
a problem, but it makes it harder to find :-|

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  9:06                                                       ` Ingo Molnar
  2004-10-27 10:03                                                         ` Ingo Molnar
@ 2004-10-27 10:33                                                         ` Florian Schmidt
  2004-10-27 10:29                                                           ` Ingo Molnar
  2004-10-27 10:45                                                           ` Florian Schmidt
  1 sibling, 2 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-27 10:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

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

On Wed, 27 Oct 2004 11:06:20 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > third time lucky?
> 
> there was one more piece missing...
> 
> i've also uploaded -RT-V0.3.2 with this fix included.

Hi,

V0.3.2 builds and boots fine here. It seems to run ok, too. Uptime 25
minutes and no BUG's [yay! 25 minutes already! ;)]. Well anyways,
preempt_max_thresh is at 38us after running several concurrent find's plus
jackd.

There's a problem though with jackd performance. Read on below if it is of
any interest at this point. 

Soundcard IRQ is 3:

mango:~# cat /proc/interrupts 
           CPU0       
  0:    1331024          XT-PIC  timer  0/31024
  1:       3494          XT-PIC  i8042  0/3494
  2:          0          XT-PIC  cascade  0/0
  3:     781428          XT-PIC  CS46XX  0/81428
  5:       1811          XT-PIC  eth0  0/1811
  8:          4          XT-PIC  rtc  0/4
 12:      71236          XT-PIC  i8042  1/71236
 14:       5163          XT-PIC  ide0  0/5163
 15:      50392          XT-PIC  ide1  0/50392
NMI:          0 
ERR:          0

I set the irq handler thread to prio 99:

mango:~# chrt -p `pidof "IRQ 3"`
pid 118's current scheduling policy: SCHED_FIFO
pid 118's current scheduling priority: 99

jackd runs with a period size of 128 frames (48000hz samplerate) and with
SCHED_FIFO with prios from 60 to 70 (ps output is somewhat broken):

mango:~# ps -cmL `pidof jackd`
  PID   LWP CLS PRI TTY      STAT   TIME COMMAND
 1286     - -     - ?        -      0:28 /usr/bin/jackd -R -P60 -t20000 -dalsa -
    -  1286 TS   20 -        SLsl   0:00 -
    -  1287 TS   23 -        SLsl   0:00 -
    -  1288 FF  110 -        SLsl   0:00 -
    -  1289 FF  100 -        SLsl   0:27 -

~$ chrt -p 1286
pid 1286's current scheduling policy: SCHED_OTHER
pid 1286's current scheduling priority: 0
~$ chrt -p 1287
pid 1287's current scheduling policy: SCHED_OTHER
pid 1287's current scheduling priority: 0
~$ chrt -p 1288
pid 1288's current scheduling policy: SCHED_FIFO
pid 1288's current scheduling priority: 70
~$ chrt -p 1289
pid 1289's current scheduling policy: SCHED_FIFO
pid 1289's current scheduling priority: 60

Anyways i get xruns like crazy under load (like 200 in 10 minutes). It seems
the scheduling class and high priority don't matter really as wiggling
windows around on the screen or doing a "find /" can easily provoke xruns.

flo

[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 26196 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-mm1-RT-V0.3.2
# Wed Oct 27 11:36:41 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION="-rt"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=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

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

#
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# 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_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_GENERIC=y
CONFIG_GENERIC_SEMAPHORES=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_X86_USE_3DNOW=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
CONFIG_PREEMPT_BKL=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_KERN_PHYS_OFFSET=1
# 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 is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

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

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

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

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD 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=m
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_TASKFILE_IO is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 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 is not set
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 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=y
# 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

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

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

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

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_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_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

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

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_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

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT 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_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM 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_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

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

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set

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

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
# CONFIG_SENSORS_LM87 is not set
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

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

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

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

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

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

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

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

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY 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_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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=m
CONFIG_RXRPC=m

#
# 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=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_PREEMPT_TIMING=y
CONFIG_PREEMPT_TRACE=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_RWSEM_DEADLOCK_DETECT=y
CONFIG_RWSEM_MAX_OWNERS=32
# CONFIG_DEBUG_INFO is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set

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

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 10:33                                                         ` Florian Schmidt
  2004-10-27 10:29                                                           ` Ingo Molnar
@ 2004-10-27 10:45                                                           ` Florian Schmidt
  2004-10-27 11:09                                                             ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-10-27 10:45 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, K.R. Foley, linux-kernel, Lee Revell,
	Rui Nuno Capela, Mark_H_Johnson, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Wed, 27 Oct 2004 12:33:29 +0200
Florian Schmidt <mista.tapas@gmx.net> wrote:

> V0.3.2 builds and boots fine here. It seems to run ok, too. Uptime 25
> minutes and no BUG's [yay! 25 minutes already! ;)]. Well anyways,
> preempt_max_thresh is at 38us after running several concurrent find's plus
> jackd.
> 
> There's a problem though with jackd performance. Read on below if it is of
> any interest at this point. 
[snip]

anyways, i still see the mysterious pauses which do not show up in the
preempt_max_thresh.

ah, and btw: what does the /proc/sys/kernel/kernel_preemption tunable do
with PREEMPT_REALTIME enabled?

mango:~# cat /proc/sys/kernel/kernel_preemption 
1

[all the other VP tunables are not available anymore]

mango:~# cat /proc/sys/kernel/voluntary_preemption
cat: /proc/sys/kernel/voluntary_preemption: No such file or directory
mango:~# cat /proc/sys/kernel/hardirq_preemption
cat: /proc/sys/kernel/hardirq_preemption: No such file or directory
mango:~# cat /proc/sys/kernel/softirq_preemption
cat: /proc/sys/kernel/softirq_preemption: No such file or directory

flo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-27  0:15                                       ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Ingo Molnar
  2004-10-27  0:44                                         ` Ingo Molnar
  2004-10-27  1:43                                         ` Bill Huey
@ 2004-10-27 10:50                                         ` Michal Schmidt
  2004-10-27 13:48                                           ` Ingo Molnar
  2004-10-27 12:43                                         ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Rui Nuno Capela
                                                           ` (2 subsequent siblings)
  5 siblings, 1 reply; 951+ messages in thread
From: Michal Schmidt @ 2004-10-27 10:50 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Karsten Wiese

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

Ingo Molnar wrote:
> i have released the -V0.3 Real-Time Preemption patch, which can be
> downloaded from:
> 
> 	http://redhat.com/~mingo/realtime-preempt/
> 
> [...]
> some of the networking lockups might be related to this issue too, but i
> think PREEMPT_REALTIME still has separate lock odering issues within the
> networking code. Please re-report any deadlock-tracer asserts that you
> might encounter.
> 

OK, re-reporting a network deadlock. It happens a few seconds after 
starting Firefox. This is with -V0.3.2:

Linux version 2.6.9-mm1-RT-V0.3.2 (michich@k4-912b) (gcc version 3.3.4 
(Debian 1:3.3.4-6sarge1)) #5 Wed Oct 27 12:26:13 CEST 2004
BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
  BIOS-e820: 0000000000100000 - 000000003ffb0000 (usable)
  BIOS-e820: 000000003ffb0000 - 000000003ffc0000 (ACPI data)
  BIOS-e820: 000000003ffc0000 - 000000003fff0000 (ACPI NVS)
  BIOS-e820: 000000003fff0000 - 0000000040000000 (reserved)
  BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
896MB LOWMEM available.
found SMP MP-table at 000ff780
On node 0 totalpages: 229376
   DMA zone: 4096 pages, LIFO batch:1
   Normal zone: 225280 pages, LIFO batch:16
   HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v002 ACPIAM                                ) @ 0x000fa840
ACPI: XSDT (v001 A M I  OEMXSDT  0x06000417 MSFT 0x00000097) @ 0x3ffb0100
ACPI: FADT (v003 A M I  OEMFACP  0x06000417 MSFT 0x00000097) @ 0x3ffb0290
ACPI: MADT (v001 A M I  OEMAPIC  0x06000417 MSFT 0x00000097) @ 0x3ffb0390
ACPI: OEMB (v001 A M I  OEMBIOS  0x06000417 MSFT 0x00000097) @ 0x3ffc0040
ACPI: DSDT (v001  A0036 A0036001 0x00000001 MSFT 0x0100000d) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:7 APIC version 16
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
Initializing CPU#0
Kernel command line: BOOT_IMAGE=Deb-32-RT ro root=308 
netconsole=4444@147.229.222.29/eth0,4444@147.229.222.28/00:0C:6E:2F:30:75
netconsole: local port 4444
netconsole: local IP 147.229.222.29
netconsole: interface eth0
netconsole: remote port 4444
netconsole: remote IP 147.229.222.28
netconsole: remote ethernet address 00:0c:6e:2f:30:75
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 2403.782 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x30
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 905628k/917504k available (1843k kernel code, 11488k reserved, 
786k data, 148k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 4702.20 BogoMIPS (lpj=2351104)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 078bfbff e1d3fbff 00000000 00000000
CPU: After vendor identify, caps:  078bfbff e1d3fbff 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: After all inits, caps:        078bfbff e1d3fbff 00000000 00000010
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(tm) 64 FX-53 Processor stepping 0a
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
softirq RT prio: 24.
desched cpu_callback 2/00000000
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
desched thread 0 started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040816
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *10 11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 7 10 11 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of "lspci" to bjorn.helgaas@hp.com
** so I can fix the driver.
Initializing Cryptographic API
Real Time Clock Driver v1.12
ACPI: PS/2 Keyboard Controller [PS2K] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [PS2M] at irq 12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 17 (level, low) -> IRQ 17
eth0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
       PrefPort:A  RlmtMode:Check Link State
netconsole: device eth0 not up yet, forcing it
netconsole: carrier detect appears flaky, waiting 10 seconds
IRQ#17 thread RT prio: 49.
eth0: network connection up using port A
     speed:           100
     autonegotiation: yes
     duplex mode:     full
     flowctrl:        none
     irq moderation:  disabled
     scatter-gather:  enabled
netconsole: network logging started
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:0f.1
ACPI: PCI interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 20
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
     ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:DMA
     ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:DMA
Probing IDE interface ide0...
hda: ST3120026A, ATA DISK drive
hdb: ST320011A, ATA DISK drive
elevator: using anticipatory as default io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdd: TEAC CD-W552E, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
Probing IDE interface ide4...
ide4: Wait for ready failed before probe !
Probing IDE interface ide5...
ide5: Wait for ready failed before probe !
hda: max request size: 1024KiB
IRQ#14 thread RT prio: 48.
hda: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=16383/255/63, 
UDMA(100)
hda: cache flushes supported
  hda: hda1 hda2 < hda5 hda6 hda7 hda8 > hda3
hdb: max request size: 128KiB
hdb: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100)
hdb: cache flushes not supported
  hdb: hdb1
mice: PS/2 mouse device common for all mice
IRQ#12 thread RT prio: 47.
IRQ#1 thread RT prio: 46.
input: AT Translated Set 2 keyboard on isa0060/serio0
input: ImExPS/2 Generic Explorer Mouse on isa0060/serio1
input: PC Speaker
NET: Registered protocol family 2
IP: routing cache hash table of 256 buckets, 40Kbytes
TCP: Hash tables configured (established 8192 bind 13107)
arp_tables: (C) 2002 David S. Miller
NET: Registered protocol family 1
ACPI: (supports S0 S1 S3 S4 S5)
ACPI wakeup devices:
PCI0 PS2K PS2M UAR2 UAR1 AC97 USB1 USB2 USB3 USB4 EHCI PWRB SLPB
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 148k freed
Adding 995988k swap on /dev/hda6.  Priority:2 extents:1
EXT3 FS on hda8, internal journal
IRQ#8 thread RT prio: 45.
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack version 2.1 (7168 buckets, 57344 max) - 456 bytes per conntrack
Capability LSM initialized
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected AGP bridge 0
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: AGP aperture is 64M @ 0xe4000000
ACPI: PCI interrupt 0000:00:09.0[A] -> GSI 16 (level, low) -> IRQ 16
SCSI subsystem initialized
libata version 1.02 loaded.
sata_via version 0.20
ACPI: PCI interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 20
sata_via(0000:00:0f.0): routed to hard irq line 10
ata1: SATA max UDMA/133 cmd 0xC400 ctl 0xC002 bmdma 0xB000 irq 20
ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xB402 bmdma 0xB008 irq 20
ata1: no device found (phy stat 00000000)
scsi0 : sata_via
ata2: no device found (phy stat 00000000)
scsi1 : sata_via
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 21
PCI: Via IRQ fixup for 0000:00:10.0, from 11 to 5
uhci_hcd 0000:00:10.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller
uhci_hcd 0000:00:10.0: irq 21, io base 0xc800
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 21
PCI: Via IRQ fixup for 0000:00:10.1, from 11 to 5
uhci_hcd 0000:00:10.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (#2)
uhci_hcd 0000:00:10.1: irq 21, io base 0xd000
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.2[B] -> GSI 21 (level, low) -> IRQ 21
PCI: Via IRQ fixup for 0000:00:10.2, from 10 to 5
uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (#3)
uhci_hcd 0000:00:10.2: irq 21, io base 0xd400
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.3[B] -> GSI 21 (level, low) -> IRQ 21
PCI: Via IRQ fixup for 0000:00:10.3, from 10 to 5
uhci_hcd 0000:00:10.3: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (#4)
uhci_hcd 0000:00:10.3: irq 21, io base 0xd800
uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 21
ehci_hcd 0000:00:10.4: VIA Technologies, Inc. USB 2.0
ehci_hcd 0000:00:10.4: irq 21, pci mem 0xfbc00000
ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 5
ehci_hcd 0000:00:10.4: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 8 ports detected
NET: Registered protocol family 17
IRQ#4 thread RT prio: 44.
IRQ#3 thread RT prio: 43.
ACPI: Processor [CPU1] (supports C1)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
BUG: semaphore recursion deadlock detected!
.. current task firefox-bin/4761 [f21a3020] is already holding c04306c0 
[w:f21a3020, d:1].
  [<c01c7408>] __rwsem_deadlock+0x188/0x1a0 (12)
  [<c01c72ec>] __rwsem_deadlock+0x6c/0x1a0 (52)
  [<c0271c51>] dev_queue_xmit_nit+0x41/0x130 (24)
  [<c02cb9ee>] down_write_mutex+0x5e/0x210 (4)
  [<c02cba8e>] down_write_mutex+0xfe/0x210 (24)
  [<c02cbba8>] down_read_mutex+0x8/0x30 (12)
  [<c0271c51>] dev_queue_xmit_nit+0x41/0x130 (40)
  [<c01c7abe>] up_write_mutex+0x2e/0x60 (12)
  [<c0281403>] qdisc_restart+0x223/0x250 (24)
  [<c02721dd>] dev_queue_xmit+0x1ad/0x260 (12)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c02721ef>] dev_queue_xmit+0x1bf/0x260 (36)
  [<c027852e>] neigh_resolve_output+0xfe/0x240 (32)
  [<c029323e>] ip_finish_output2+0xbe/0x240 (56)
  [<c027dc05>] nf_hook_slow+0xd5/0x130 (36)
  [<c0293180>] ip_finish_output2+0x0/0x240 (28)
  [<c0290a4b>] ip_finish_output+0x26b/0x270 (32)
  [<c0293180>] ip_finish_output2+0x0/0x240 (24)
  [<c029316a>] dst_output+0x1a/0x30 (32)
  [<c027dc05>] nf_hook_slow+0xd5/0x130 (12)
  [<c0293150>] dst_output+0x0/0x30 (28)
  [<c029110a>] ip_queue_xmit+0x45a/0x570 (32)
  [<c0293150>] dst_output+0x0/0x30 (24)
  [<c0135cb5>] sub_preempt_count+0x65/0xd0 (36)
  [<c01c791e>] __up_write+0x10e/0x220 (8)
  [<c0135748>] check_preempt_timing+0x58/0x2e0 (8)
  [<c0135cb5>] sub_preempt_count+0x65/0xd0 (4)
  [<c01c791e>] __up_write+0x10e/0x220 (4)
  [<c0134fdd>] __mcount+0x1d/0x20 (28)
  [<c01c715e>] rwsem_owner_del+0xe/0xf0 (4)
  [<c0134fdd>] __mcount+0x1d/0x20 (40)
  [<c02a871e>] tcp_v4_send_check+0xe/0xf0 (4)
  [<c02a2219>] tcp_transmit_skb+0x439/0x880 (4)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c02a875f>] tcp_v4_send_check+0x4f/0xf0 (20)
  [<c02a22c2>] tcp_transmit_skb+0x4e2/0x880 (32)
  [<c0114310>] mcount+0x14/0x18 (28)
  [<c02a4f56>] tcp_send_ack+0xa6/0xf0 (52)
  [<c029feb4>] __tcp_ack_snd_check+0x14/0xa0 (12)
  [<c02a0965>] tcp_rcv_established+0x6e5/0x920 (24)
  [<c02a9c0e>] tcp_v4_do_rcv+0x13e/0x150 (56)
  [<c026b065>] __release_sock+0x55/0x80 (32)
  [<c026b98e>] release_sock+0x7e/0x80 (32)
  [<c0297c94>] tcp_recvmsg+0x2f4/0x750 (24)
  [<c0114310>] mcount+0x14/0x18 (64)
  [<c026bb19>] sock_common_recvmsg+0x59/0x70 (20)
  [<c0267da1>] sock_recvmsg+0xd1/0xf0 (48)
  [<c01c791e>] __up_write+0x10e/0x220 (24)
  [<c0134fdd>] __mcount+0x1d/0x20 (44)
  [<c01c715e>] rwsem_owner_del+0xe/0xf0 (4)
  [<c015f959>] fget+0x59/0x70 (72)
  [<c01c7abe>] up_write_mutex+0x2e/0x60 (28)
  [<c01344e0>] autoremove_wake_function+0x0/0x60 (24)
  [<c026798f>] sockfd_lookup+0x1f/0x80 (28)
  [<c0114310>] mcount+0x14/0x18 (4)
  [<c0269409>] sys_recvfrom+0x99/0x100 (20)
  [<c01426f2>] free_pages_bulk+0x1d2/0x2e0 (48)
  [<c01c7abe>] up_write_mutex+0x2e/0x60 (28)
  [<c0114310>] mcount+0x14/0x18 (112)
  [<c02694ab>] sys_recv+0x3b/0x40 (20)
  [<c0269be2>] sys_socketcall+0x152/0x240 (32)
  [<c010527b>] syscall_call+0x7/0xb (68)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: down_write_mutex+0x201/0x210 [<c02cbb91>] / 
(dev_queue_xmit_nit+0x41/0x130 [<c0271c51>])
.. entry 2: print_traces+0x1d/0x90 [<c013600d>] / (dump_stack+0x23/0x30 
[<c01060b3>])

BUG: circular semaphore deadlock: ksoftirqd/0/2 is blocked on c04306c0, 
deadlocking firefox-bin/4761
f7c2be24 00000046 f7c24020 c03bfca0 00000202 00001dd8 f7c2a000 f7c24020
        00000000 f7c2be10 000002c5 03c4f81b 00000029 f7c24020 f7c242b4 
f7c2a000
        f7c24020 00000000 f7c2be48 c02ca7af f7c2be48 00000082 c03e3a40 
c02cbb1e
Call Trace:
  [<c02ca7af>] schedule+0x2f/0xe0 (80)
  [<c02cbb1e>] down_write_mutex+0x18e/0x210 (16)
  [<c02cbadd>] down_write_mutex+0x14d/0x210 (20)
  [<c02cbba8>] down_read_mutex+0x8/0x30 (12)
  [<c027db57>] nf_hook_slow+0x27/0x130 (40)
  [<c0134fdd>] __mcount+0x1d/0x20 (24)
  [<c028d4ae>] ip_rcv+0xe/0x540 (4)
  [<c027270d>] netif_receive_skb+0x12d/0x240 (4)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c028d900>] ip_rcv+0x460/0x540 (20)
  [<c028db80>] ip_rcv_finish+0x0/0x300 (24)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c027270d>] netif_receive_skb+0x12d/0x240 (28)
  [<c0270008>] gnet_stats_copy_basic+0x18/0x80 (20)
  [<c0272a3f>] net_rx_action+0x7f/0x1a0 (4)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c02728a8>] process_backlog+0x88/0x1a0 (20)
  [<c0272a3f>] net_rx_action+0x7f/0x1a0 (40)
  [<c0123807>] ___do_softirq+0x87/0xd0 (36)
  [<c01238d8>] _do_softirq+0x8/0x30 (8)
  [<c0123cc4>] ksoftirqd+0xb4/0x100 (4)
  [<c01238f0>] _do_softirq+0x20/0x30 (28)
  [<c0123cc4>] ksoftirqd+0xb4/0x100 (8)
  [<c0133f2a>] kthread+0xaa/0xb0 (24)
  [<c0123c10>] ksoftirqd+0x0/0x100 (20)
  [<c0133e80>] kthread+0x0/0xb0 (12)
  [<c0103319>] kernel_thread_helper+0x5/0xc (16)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __schedule+0x4e/0x640 [<c02ca18e>] / (schedule+0x2f/0xe0 
[<c02ca7af>])
.. entry 2: __schedule+0xdd/0x640 [<c02ca21d>] / (schedule+0x2f/0xe0 
[<c02ca7af>])


Michal

[-- Attachment #2: V0.3.2-deadlock --]
[-- Type: text/plain, Size: 16657 bytes --]

Linux version 2.6.9-mm1-RT-V0.3.2 (michich@k4-912b) (gcc version 3.3.4 (Debian 1:3.3.4-6sarge1)) #5 Wed Oct 27 12:26:13 CEST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ffb0000 (usable)
 BIOS-e820: 000000003ffb0000 - 000000003ffc0000 (ACPI data)
 BIOS-e820: 000000003ffc0000 - 000000003fff0000 (ACPI NVS)
 BIOS-e820: 000000003fff0000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
896MB LOWMEM available.
found SMP MP-table at 000ff780
On node 0 totalpages: 229376
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 225280 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v002 ACPIAM                                ) @ 0x000fa840
ACPI: XSDT (v001 A M I  OEMXSDT  0x06000417 MSFT 0x00000097) @ 0x3ffb0100
ACPI: FADT (v003 A M I  OEMFACP  0x06000417 MSFT 0x00000097) @ 0x3ffb0290
ACPI: MADT (v001 A M I  OEMAPIC  0x06000417 MSFT 0x00000097) @ 0x3ffb0390
ACPI: OEMB (v001 A M I  OEMBIOS  0x06000417 MSFT 0x00000097) @ 0x3ffc0040
ACPI: DSDT (v001  A0036 A0036001 0x00000001 MSFT 0x0100000d) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:7 APIC version 16
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
Initializing CPU#0
Kernel command line: BOOT_IMAGE=Deb-32-RT ro root=308 netconsole=4444@147.229.222.29/eth0,4444@147.229.222.28/00:0C:6E:2F:30:75
netconsole: local port 4444
netconsole: local IP 147.229.222.29
netconsole: interface eth0
netconsole: remote port 4444
netconsole: remote IP 147.229.222.28
netconsole: remote ethernet address 00:0c:6e:2f:30:75
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 2403.782 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x30
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 905628k/917504k available (1843k kernel code, 11488k reserved, 786k data, 148k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 4702.20 BogoMIPS (lpj=2351104)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 078bfbff e1d3fbff 00000000 00000000
CPU: After vendor identify, caps:  078bfbff e1d3fbff 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: After all inits, caps:        078bfbff e1d3fbff 00000000 00000010
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(tm) 64 FX-53 Processor stepping 0a
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
softirq RT prio: 24.
desched cpu_callback 2/00000000
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
desched thread 0 started up.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040816
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *10 11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 7 10 11 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of "lspci" to bjorn.helgaas@hp.com
** so I can fix the driver.
Initializing Cryptographic API
Real Time Clock Driver v1.12
ACPI: PS/2 Keyboard Controller [PS2K] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [PS2M] at irq 12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 17 (level, low) -> IRQ 17
eth0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
      PrefPort:A  RlmtMode:Check Link State
netconsole: device eth0 not up yet, forcing it
netconsole: carrier detect appears flaky, waiting 10 seconds
IRQ#17 thread RT prio: 49.
eth0: network connection up using port A
    speed:           100
    autonegotiation: yes
    duplex mode:     full
    flowctrl:        none
    irq moderation:  disabled
    scatter-gather:  enabled
netconsole: network logging started
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:0f.1
ACPI: PCI interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 20
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
    ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:DMA
Probing IDE interface ide0...
hda: ST3120026A, ATA DISK drive
hdb: ST320011A, ATA DISK drive
elevator: using anticipatory as default io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdd: TEAC CD-W552E, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
Probing IDE interface ide4...
ide4: Wait for ready failed before probe !
Probing IDE interface ide5...
ide5: Wait for ready failed before probe !
hda: max request size: 1024KiB
IRQ#14 thread RT prio: 48.
hda: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 < hda5 hda6 hda7 hda8 > hda3
hdb: max request size: 128KiB
hdb: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100)
hdb: cache flushes not supported
 hdb: hdb1
mice: PS/2 mouse device common for all mice
IRQ#12 thread RT prio: 47.
IRQ#1 thread RT prio: 46.
input: AT Translated Set 2 keyboard on isa0060/serio0
input: ImExPS/2 Generic Explorer Mouse on isa0060/serio1
input: PC Speaker
NET: Registered protocol family 2
IP: routing cache hash table of 256 buckets, 40Kbytes
TCP: Hash tables configured (established 8192 bind 13107)
arp_tables: (C) 2002 David S. Miller
NET: Registered protocol family 1
ACPI: (supports S0 S1 S3 S4 S5)
ACPI wakeup devices: 
PCI0 PS2K PS2M UAR2 UAR1 AC97 USB1 USB2 USB3 USB4 EHCI PWRB SLPB 
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 148k freed
Adding 995988k swap on /dev/hda6.  Priority:2 extents:1
EXT3 FS on hda8, internal journal
IRQ#8 thread RT prio: 45.
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack version 2.1 (7168 buckets, 57344 max) - 456 bytes per conntrack
Capability LSM initialized
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected AGP bridge 0
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: AGP aperture is 64M @ 0xe4000000
ACPI: PCI interrupt 0000:00:09.0[A] -> GSI 16 (level, low) -> IRQ 16
SCSI subsystem initialized
libata version 1.02 loaded.
sata_via version 0.20
ACPI: PCI interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 20
sata_via(0000:00:0f.0): routed to hard irq line 10
ata1: SATA max UDMA/133 cmd 0xC400 ctl 0xC002 bmdma 0xB000 irq 20
ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xB402 bmdma 0xB008 irq 20
ata1: no device found (phy stat 00000000)
scsi0 : sata_via
ata2: no device found (phy stat 00000000)
scsi1 : sata_via
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 21
PCI: Via IRQ fixup for 0000:00:10.0, from 11 to 5
uhci_hcd 0000:00:10.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
uhci_hcd 0000:00:10.0: irq 21, io base 0xc800
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 21
PCI: Via IRQ fixup for 0000:00:10.1, from 11 to 5
uhci_hcd 0000:00:10.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2)
uhci_hcd 0000:00:10.1: irq 21, io base 0xd000
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.2[B] -> GSI 21 (level, low) -> IRQ 21
PCI: Via IRQ fixup for 0000:00:10.2, from 10 to 5
uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#3)
uhci_hcd 0000:00:10.2: irq 21, io base 0xd400
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.3[B] -> GSI 21 (level, low) -> IRQ 21
PCI: Via IRQ fixup for 0000:00:10.3, from 10 to 5
uhci_hcd 0000:00:10.3: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#4)
uhci_hcd 0000:00:10.3: irq 21, io base 0xd800
uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 21
ehci_hcd 0000:00:10.4: VIA Technologies, Inc. USB 2.0
ehci_hcd 0000:00:10.4: irq 21, pci mem 0xfbc00000
ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 5
ehci_hcd 0000:00:10.4: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 8 ports detected
NET: Registered protocol family 17
IRQ#4 thread RT prio: 44.
IRQ#3 thread RT prio: 43.
ACPI: Processor [CPU1] (supports C1)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
BUG: semaphore recursion deadlock detected!
.. current task firefox-bin/4761 [f21a3020] is already holding c04306c0 [w:f21a3020, d:1].
 [<c01c7408>] __rwsem_deadlock+0x188/0x1a0 (12)
 [<c01c72ec>] __rwsem_deadlock+0x6c/0x1a0 (52)
 [<c0271c51>] dev_queue_xmit_nit+0x41/0x130 (24)
 [<c02cb9ee>] down_write_mutex+0x5e/0x210 (4)
 [<c02cba8e>] down_write_mutex+0xfe/0x210 (24)
 [<c02cbba8>] down_read_mutex+0x8/0x30 (12)
 [<c0271c51>] dev_queue_xmit_nit+0x41/0x130 (40)
 [<c01c7abe>] up_write_mutex+0x2e/0x60 (12)
 [<c0281403>] qdisc_restart+0x223/0x250 (24)
 [<c02721dd>] dev_queue_xmit+0x1ad/0x260 (12)
 [<c0114310>] mcount+0x14/0x18 (8)
 [<c02721ef>] dev_queue_xmit+0x1bf/0x260 (36)
 [<c027852e>] neigh_resolve_output+0xfe/0x240 (32)
 [<c029323e>] ip_finish_output2+0xbe/0x240 (56)
 [<c027dc05>] nf_hook_slow+0xd5/0x130 (36)
 [<c0293180>] ip_finish_output2+0x0/0x240 (28)
 [<c0290a4b>] ip_finish_output+0x26b/0x270 (32)
 [<c0293180>] ip_finish_output2+0x0/0x240 (24)
 [<c029316a>] dst_output+0x1a/0x30 (32)
 [<c027dc05>] nf_hook_slow+0xd5/0x130 (12)
 [<c0293150>] dst_output+0x0/0x30 (28)
 [<c029110a>] ip_queue_xmit+0x45a/0x570 (32)
 [<c0293150>] dst_output+0x0/0x30 (24)
 [<c0135cb5>] sub_preempt_count+0x65/0xd0 (36)
 [<c01c791e>] __up_write+0x10e/0x220 (8)
 [<c0135748>] check_preempt_timing+0x58/0x2e0 (8)
 [<c0135cb5>] sub_preempt_count+0x65/0xd0 (4)
 [<c01c791e>] __up_write+0x10e/0x220 (4)
 [<c0134fdd>] __mcount+0x1d/0x20 (28)
 [<c01c715e>] rwsem_owner_del+0xe/0xf0 (4)
 [<c0134fdd>] __mcount+0x1d/0x20 (40)
 [<c02a871e>] tcp_v4_send_check+0xe/0xf0 (4)
 [<c02a2219>] tcp_transmit_skb+0x439/0x880 (4)
 [<c0114310>] mcount+0x14/0x18 (8)
 [<c02a875f>] tcp_v4_send_check+0x4f/0xf0 (20)
 [<c02a22c2>] tcp_transmit_skb+0x4e2/0x880 (32)
 [<c0114310>] mcount+0x14/0x18 (28)
 [<c02a4f56>] tcp_send_ack+0xa6/0xf0 (52)
 [<c029feb4>] __tcp_ack_snd_check+0x14/0xa0 (12)
 [<c02a0965>] tcp_rcv_established+0x6e5/0x920 (24)
 [<c02a9c0e>] tcp_v4_do_rcv+0x13e/0x150 (56)
 [<c026b065>] __release_sock+0x55/0x80 (32)
 [<c026b98e>] release_sock+0x7e/0x80 (32)
 [<c0297c94>] tcp_recvmsg+0x2f4/0x750 (24)
 [<c0114310>] mcount+0x14/0x18 (64)
 [<c026bb19>] sock_common_recvmsg+0x59/0x70 (20)
 [<c0267da1>] sock_recvmsg+0xd1/0xf0 (48)
 [<c01c791e>] __up_write+0x10e/0x220 (24)
 [<c0134fdd>] __mcount+0x1d/0x20 (44)
 [<c01c715e>] rwsem_owner_del+0xe/0xf0 (4)
 [<c015f959>] fget+0x59/0x70 (72)
 [<c01c7abe>] up_write_mutex+0x2e/0x60 (28)
 [<c01344e0>] autoremove_wake_function+0x0/0x60 (24)
 [<c026798f>] sockfd_lookup+0x1f/0x80 (28)
 [<c0114310>] mcount+0x14/0x18 (4)
 [<c0269409>] sys_recvfrom+0x99/0x100 (20)
 [<c01426f2>] free_pages_bulk+0x1d2/0x2e0 (48)
 [<c01c7abe>] up_write_mutex+0x2e/0x60 (28)
 [<c0114310>] mcount+0x14/0x18 (112)
 [<c02694ab>] sys_recv+0x3b/0x40 (20)
 [<c0269be2>] sys_socketcall+0x152/0x240 (32)
 [<c010527b>] syscall_call+0x7/0xb (68)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: down_write_mutex+0x201/0x210 [<c02cbb91>] / (dev_queue_xmit_nit+0x41/0x130 [<c0271c51>])
.. entry 2: print_traces+0x1d/0x90 [<c013600d>] / (dump_stack+0x23/0x30 [<c01060b3>])

BUG: circular semaphore deadlock: ksoftirqd/0/2 is blocked on c04306c0, deadlocking firefox-bin/4761
f7c2be24 00000046 f7c24020 c03bfca0 00000202 00001dd8 f7c2a000 f7c24020 
       00000000 f7c2be10 000002c5 03c4f81b 00000029 f7c24020 f7c242b4 f7c2a000 
       f7c24020 00000000 f7c2be48 c02ca7af f7c2be48 00000082 c03e3a40 c02cbb1e 
Call Trace:
 [<c02ca7af>] schedule+0x2f/0xe0 (80)
 [<c02cbb1e>] down_write_mutex+0x18e/0x210 (16)
 [<c02cbadd>] down_write_mutex+0x14d/0x210 (20)
 [<c02cbba8>] down_read_mutex+0x8/0x30 (12)
 [<c027db57>] nf_hook_slow+0x27/0x130 (40)
 [<c0134fdd>] __mcount+0x1d/0x20 (24)
 [<c028d4ae>] ip_rcv+0xe/0x540 (4)
 [<c027270d>] netif_receive_skb+0x12d/0x240 (4)
 [<c0114310>] mcount+0x14/0x18 (8)
 [<c028d900>] ip_rcv+0x460/0x540 (20)
 [<c028db80>] ip_rcv_finish+0x0/0x300 (24)
 [<c0114310>] mcount+0x14/0x18 (8)
 [<c027270d>] netif_receive_skb+0x12d/0x240 (28)
 [<c0270008>] gnet_stats_copy_basic+0x18/0x80 (20)
 [<c0272a3f>] net_rx_action+0x7f/0x1a0 (4)
 [<c0114310>] mcount+0x14/0x18 (8)
 [<c02728a8>] process_backlog+0x88/0x1a0 (20)
 [<c0272a3f>] net_rx_action+0x7f/0x1a0 (40)
 [<c0123807>] ___do_softirq+0x87/0xd0 (36)
 [<c01238d8>] _do_softirq+0x8/0x30 (8)
 [<c0123cc4>] ksoftirqd+0xb4/0x100 (4)
 [<c01238f0>] _do_softirq+0x20/0x30 (28)
 [<c0123cc4>] ksoftirqd+0xb4/0x100 (8)
 [<c0133f2a>] kthread+0xaa/0xb0 (24)
 [<c0123c10>] ksoftirqd+0x0/0x100 (20)
 [<c0133e80>] kthread+0x0/0xb0 (12)
 [<c0103319>] kernel_thread_helper+0x5/0xc (16)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __schedule+0x4e/0x640 [<c02ca18e>] / (schedule+0x2f/0xe0 [<c02ca7af>])
.. entry 2: __schedule+0xdd/0x640 [<c02ca21d>] / (schedule+0x2f/0xe0 [<c02ca7af>])


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 10:29                                                           ` Ingo Molnar
@ 2004-10-27 10:58                                                             ` Florian Schmidt
  0 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-27 10:58 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

On Wed, 27 Oct 2004 12:29:21 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> > pid 1286's current scheduling policy: SCHED_OTHER
> > pid 1286's current scheduling priority: 0
> > ~$ chrt -p 1287
> > pid 1287's current scheduling policy: SCHED_OTHER
> > pid 1287's current scheduling priority: 0
> 
> just curious, are these two important to the latency path of jackd, or
> are they lowprio things and are thus at SCHED_OTHER intentionally?

the latter. jackd has one RT thread for doing the grunt work and one which
acts as a watchdog. The other two are SCHED_OTHER by design.

> > Anyways i get xruns like crazy under load (like 200 in 10 minutes). It
> > seems the scheduling class and high priority don't matter really as
> > wiggling windows around on the screen or doing a "find /" can easily
> > provoke xruns.
> 
> yeah, i'm hunting a quite similar bug: i can see 'realfeel' latencies
> generated by simple window scrolling. It is most likely a logic bug
> somewhere - a missing reschedule check, irqs left disabled accidentally,
> or something like that. Since some other workloads dont trigger it i
> dont think i broke RT scheduling by itself - it is most likely some
> non-core code somewhere missing a resched. Which doesnt make it less of
> a problem, but it makes it harder to find :-|

Hmm, you're right. It seems that diskload alone doesn't trigger the problem.
it rather looks like graphics output/activity is the problem.

Anyways i'm back in U3 w/o PREEMPT_REALTIME as V0.3.2 just hardlocked on me
when i pressed ctrl-d in a root shell (in an xterm) to exit. Nothing has
made it to the log. I haven't found out yet whether it's possible to use my
old zx81 as serial console, so i can't help with OOPS/BUG output.

flo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 10:45                                                           ` Florian Schmidt
@ 2004-10-27 11:09                                                             ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 11:09 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> ah, and btw: what does the /proc/sys/kernel/kernel_preemption tunable
> do with PREEMPT_REALTIME enabled?

it's pretty pointless to offer this tunable, agreed. In theory one could
try to turn off involuntary preemption but what's the point?

> mango:~# cat /proc/sys/kernel/kernel_preemption 
> 1
> 
> [all the other VP tunables are not available anymore]
> 
> mango:~# cat /proc/sys/kernel/voluntary_preemption
> cat: /proc/sys/kernel/voluntary_preemption: No such file or directory
> mango:~# cat /proc/sys/kernel/hardirq_preemption
> cat: /proc/sys/kernel/hardirq_preemption: No such file or directory
> mango:~# cat /proc/sys/kernel/softirq_preemption
> cat: /proc/sys/kernel/softirq_preemption: No such file or directory

right - the PREEMPT_REALTIME kernel is only correct if all asynchronous
processing is done in a process context, so i removed those tunables.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  9:32                                                   ` Ingo Molnar
@ 2004-10-27 12:19                                                     ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-27 12:19 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Alexander Batyrshin

Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> 
>>>Still problems with interactive behavior. Running KDE, with top
>>>running in xterm, scrolling through the menus I get some pauses. When
>>>the pauses occur I see kdeinit hit the top of the list and sometimes
>>>consuming 90% or more of a CPU and idle usage drops to 30-40%. I do
>>>see some latency traces (not really high ones) in the log that were
>>>generated by kdeinit but I think they were generated prior to when
>>>these pauses occurred, most likely when logging in.
>>
>>is this 90% or more CPU time system (kernel) overhead or userspace
>>overhead?
> 

It appears that most of the time is being consumed in system (~50% vs. 
~6%).
> 
> another thing to watch for is the context-switch rate in vmstat. -V0.3
> patches include a hack that include involuntary context-switches (mutex
> context switches) in the context-switch stat as well. (previously those
> were reported in a separate field which vmstat didnt pick up.)
> 
> So if the context-switch rate shots up to above say 100K/sec that is a
> sure sign of some mutex badness. The livelock scenarios i solved in
> -V0.3 occasionally generated a more than 500K/sec context-switch rate on
> a 2GHz box. Having just a couple of thousand per sec isnt by itself a
> sign of anything unusual.

As for the context-switch, I do see this jump up to ~10-11K/sec from 
~4-5K/sec and I see this only when I trigger the pauses.

> 
> 	Ingo
> 

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-27  0:15                                       ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Ingo Molnar
                                                           ` (2 preceding siblings ...)
  2004-10-27 10:50                                         ` Michal Schmidt
@ 2004-10-27 12:43                                         ` Rui Nuno Capela
  2004-10-27 13:53                                           ` Ingo Molnar
  2004-10-27 13:03                                         ` Ingo Molnar
  2004-11-03 10:58                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 Ingo Molnar
  5 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-27 12:43 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
>
> i have released the -V0.3 Real-Time Preemption patch, which can be
> downloaded from:
>
> 	http://redhat.com/~mingo/realtime-preempt/
>
> this is a fixes-only release, but still experimental.

OK. Currently with RT-V0.3.2.

So it seems that the jackd -R is no more an issue here.

I've tested several times now, and can even start more than 7 (yes,
seven!) fluidsynth instances, with respective soundfonts loaded, all
running without problems, besides the cpu cost topping to 80% (user) and
memory is near the swappiness edge, which is usually a normal behavior, or
so I believe.

Remember that having just 2 (two) fluidsynth instances was quite enough
for hosing the system in no time, on RT-V0.2.

However (oh no!:) those jackd -R xruns are still frequent, much frequent
than RT-U3, which is my stable RT kernel atm.

OK. I'll take this time for some questions:

What's the rationale that you guys are using on tunning the IRQ threading
policies and priorities?

What's the best approach to take, regarding the jackd, soundcard, usb,
keyboard, mouse, whatever IRQ handlers?

I've heard somewhat contraditory opinions elsewhere, but would like to
know what's in the road ahead ;)

As a side note, while I was testing this snd-usb-usx2y ALSA development
module for my Tascam US-224 USB audio/midi control interface, I've found
that the best and stable results are achieved by leveraging the ohci_hcd
IRQ handler (normally IRQ 10) to a higher priority than jackd's.

I've been doing just that with e.g. chrt -p -f 60 `pidof "IRQ 10"`.
Failing to do so just makes jackd (or it's alsa backend) missing some
deadline and drop out very easily. This has been my conclusion while
testing with RT-U3. Don't know what is reserved by RT-V0.3.2, yet. I'll do
that later.

Take care.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



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

* [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27  0:15                                       ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Ingo Molnar
                                                           ` (3 preceding siblings ...)
  2004-10-27 12:43                                         ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Rui Nuno Capela
@ 2004-10-27 13:03                                         ` Ingo Molnar
  2004-10-27 21:41                                           ` Magnus Naeslund(t)
  2004-10-28 14:14                                           ` K.R. Foley
  2004-11-03 10:58                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 Ingo Molnar
  5 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 13:03 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese


i have released the -V0.4 Real-Time Preemption patch, which can be
downloaded from:

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

this is a fixes-only release, but still experimental.

this release should fix more bugs of the 'slowdown' and 'interactivity
problems' variety.

To debug the wakeup anomalies reported i've implemented a new variant of
the latency tracer, which now traces 'wakeup latencies' too - i.e. it
measures and traces maximum delays observed from the point of wakeup to
the point of the really starting to execute. Only the highest-priority
runnable task in the system is traced at a time, but this should be more
than enough to find the high latency scheduling paths.

This new tracing mode can be enabled by compiling a LATENCY_TRACE kernel
as usual and doing:

	echo 4 > /proc/sys/kernel/trace_enabled

then to start tracing, reset the current max latency value via e.g.:

	echo 10 > /proc/sys/kernel/preempt_max_latency

then the kernel should signal wakeup latency events in the syslog:

  (sshd/3093/CPU#0): new 18 us maximum-latency wakeup.
  (sshd/3093/CPU#0): new 19 us maximum-latency wakeup.
  (hackbench/3818/CPU#0): new 20 us maximum-latency wakeup.
  (hackbench/3762/CPU#0): new 21 us maximum-latency wakeup.
  (hackbench/3814/CPU#0): new 22 us maximum-latency wakeup.
  (ksoftirqd/0/3/CPU#0): new 35 us maximum-latency wakeup.

the latency trace of the last (and highest) event can always be found in
/proc/latency_trace, as usual. Note that the trace output is a bit
different in the wakeup-tracing case.

NOTE: the tracer works on SMP too, but since on SMP tasks can switch
from one CPU to another a given trace can be less useful if the delay
happened on another CPU.

using this wakeup tracer i found and fixed a couple of 'missed
preemption check' bugs - all introduced by PREEMPT_REALTIME in the -U/-V
timeframe. So if you had latency/interactivity problems please re-check
-V0.4.

the wakeup tracer is nice in the sense of that it traces actual, realy.

Changes since -V0.3.2:

 - fixed the rtc_lock related crash reported by K.R. Foley and Robert 
   Crocombe.

 - fixed missing preemption checks in rwsem-generic.c

 - fixed missing preemption check in schedule_tail() [==new task wakeup]

 - implemented wakeup-latency tracer

to create a -V0.4 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/2.6.9-mm1.bz2
 + http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.9-mm1-V0.4

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27  3:32                                               ` K.R. Foley
  2004-10-27  8:28                                                 ` Ingo Molnar
  2004-10-27  9:24                                                 ` Ingo Molnar
@ 2004-10-27 13:29                                                 ` Ingo Molnar
  2004-10-27 15:00                                                   ` K.R. Foley
  2 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 13:29 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

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


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

> Running amlat [...]

btw., to get good 'realfeel' results i had to apply the attached patch. 
Especially when running realfeel over the network it can easily happen
that it's delayed for some time and gets out of sync with the RTC. So
after a new maximum latency has triggered the code now waits 10 periods
to wait for the timings to recover.

this does not hurt the latency measurements in any way - latencies that
occur after these 10 ticks (~5 msecs) are over are still fully measured
and reported.

amlat produces weird output for me, continuously increasing latency
values:

 latency = 2967939 milliseconds
 latency = 2967950 milliseconds
 sigint
 max jitter = 0 microseconds

maybe some /dev/rtc API detail changed? Or is this the normal output?

	Ingo

[-- Attachment #2: realfeel.diff --]
[-- Type: text/plain, Size: 1010 bytes --]

--- realfeel.c.orig	2004-10-27 15:04:46.237707040 +0200
+++ realfeel.c	2004-10-27 15:04:50.204104056 +0200
@@ -91,7 +91,7 @@ int set_realtime_priority(void)
 	 * set the process to realtime privs
 	 */
 	memset(&schp, 0, sizeof(schp));
-	schp.sched_priority = sched_get_priority_max(SCHED_FIFO);
+	schp.sched_priority = sched_get_priority_max(SCHED_FIFO) - 1;
 	
 	if (sched_setscheduler(0, SCHED_FIFO, &schp) != 0) {
 		perror("sched_setscheduler");
@@ -191,8 +191,19 @@ int main(int argc, char *argv[])
 		now = rdtsc();
 		delay = secondsPerTick * (now - last);
 		if (delay > max_delay) {
+			int i;
+
 			max_delay = delay;
 			printf("%.3f msec\n", 1e3 * (ideal - delay));
+			/*
+			 * To make sure that the delay due to the printf
+			 * is not counted we skip the next period:
+			 */
+			for (i = 0; i < 10; i++)
+				if (read(fd, &data, sizeof(data)) == -1)
+					fatal("blocking read failed");
+			last = rdtsc();
+			continue;
 		}
 		ms = (-(ideal - delay) + 1.0/20000.0) * 10000;
 		if (ms < 0)

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-27 10:50                                         ` Michal Schmidt
@ 2004-10-27 13:48                                           ` Ingo Molnar
  2004-10-27 17:25                                             ` Michal Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 13:48 UTC (permalink / raw)
  To: Michal Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:

> OK, re-reporting a network deadlock. It happens a few seconds after 
> starting Firefox. This is with -V0.3.2:

i've uploaded -V0.4.1 with a fix that could fix this networking
deadlock. Does it work any better?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-27 12:43                                         ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Rui Nuno Capela
@ 2004-10-27 13:53                                           ` Ingo Molnar
  2004-10-27 15:26                                             ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4 Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 13:53 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> OK. Currently with RT-V0.3.2.
> 
> So it seems that the jackd -R is no more an issue here.

great.

> However (oh no!:) those jackd -R xruns are still frequent, much
> frequent than RT-U3, which is my stable RT kernel atm.

-V0.4.1 could help with this problem. There were a number of places
where the PREEMPT_REALTIME kernel missed reschedules so it could easily
happen that jackd would sit in the runqueue waiting to be executed and
the kernel got quickly out of a critical section but then the kernel
'forgot' to reschedule for many milliseconds!

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 13:29                                                 ` Ingo Molnar
@ 2004-10-27 15:00                                                   ` K.R. Foley
  2004-10-27 15:05                                                     ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-27 15:00 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>Running amlat [...]
> 
> 
> btw., to get good 'realfeel' results i had to apply the attached patch. 
> Especially when running realfeel over the network it can easily happen
> that it's delayed for some time and gets out of sync with the RTC. So
> after a new maximum latency has triggered the code now waits 10 periods
> to wait for the timings to recover.
> 
> this does not hurt the latency measurements in any way - latencies that
> occur after these 10 ticks (~5 msecs) are over are still fully measured
> and reported.
> 
> amlat produces weird output for me, continuously increasing latency
> values:
> 
>  latency = 2967939 milliseconds
>  latency = 2967950 milliseconds
>  sigint
>  max jitter = 0 microseconds
> 
> maybe some /dev/rtc API detail changed? Or is this the normal output?
> 
> 	Ingo
> 
Well to produce useful results, amlat requires Andrew's rtc-debug patch 
that modifies the rtc driver as well as traps so that timings are kept 
when the isr gets run and when the rtc device is read to track 
scheduling latencies. Also if this patch was applied the value being 
read by amlat from the rtc device would be the last interrupt time 
instead of the interrupt info that rtc normally produces. So the latency 
values being spit out are bogus, but it's good enough to exercise the rtc.

I use the rtc-debug and amlat to generate histograms of latencies which 
is what I was trying to do when I found the rtc problem the first time. 
I believe that rtc-debug/amlat is much more accurate for generating 
histograms of latencies than realfeel is because the instrumentation is 
in the kernel rather than a userspace program.

kr


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 15:00                                                   ` K.R. Foley
@ 2004-10-27 15:05                                                     ` Ingo Molnar
  2004-10-27 15:13                                                       ` Lee Revell
                                                                         ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 15:05 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton


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

> I use the rtc-debug and amlat to generate histograms of latencies
> which is what I was trying to do when I found the rtc problem the
> first time.  I believe that rtc-debug/amlat is much more accurate for
> generating histograms of latencies than realfeel is because the
> instrumentation is in the kernel rather than a userspace program.

ah, ok - nice. So rtc-debug+amlat is the only known-reliable way to
produce latency histograms?

Btw., rtc-debug's latency results could now be cross-validated with
-V0.4's wakeup tracer (and vice versa), because the two are totally
independent mechanisms.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 15:05                                                     ` Ingo Molnar
@ 2004-10-27 15:13                                                       ` Lee Revell
  2004-10-27 15:17                                                         ` Ingo Molnar
  2004-10-27 15:16                                                       ` K.R. Foley
  2004-10-27 20:49                                                       ` Bill Huey
  2 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-27 15:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: K.R. Foley, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

On Wed, 2004-10-27 at 17:05 +0200, Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> > I use the rtc-debug and amlat to generate histograms of latencies
> > which is what I was trying to do when I found the rtc problem the
> > first time.  I believe that rtc-debug/amlat is much more accurate for
> > generating histograms of latencies than realfeel is because the
> > instrumentation is in the kernel rather than a userspace program.
> 
> ah, ok - nice. So rtc-debug+amlat is the only known-reliable way to
> produce latency histograms?
> 

Yes, I think it is the most reliable way because the measurement is done
in the kernel.  At least, this is what AM's notes say.  There are any
number of ways to generate these with userspace programs (jackd,
realfeel, etc).

Here is a more up to date version of the rtc-debug patch:

http://lkml.org/lkml/2004/9/9/307

There is still a bit of 2.4 cruft in there but it works well.  Maybe
this could be included in future patches.

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 15:05                                                     ` Ingo Molnar
  2004-10-27 15:13                                                       ` Lee Revell
@ 2004-10-27 15:16                                                       ` K.R. Foley
  2004-10-27 20:49                                                       ` Bill Huey
  2 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-27 15:16 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>I use the rtc-debug and amlat to generate histograms of latencies
>>which is what I was trying to do when I found the rtc problem the
>>first time.  I believe that rtc-debug/amlat is much more accurate for
>>generating histograms of latencies than realfeel is because the
>>instrumentation is in the kernel rather than a userspace program.
> 
> 
> ah, ok - nice. So rtc-debug+amlat is the only known-reliable way to
> produce latency histograms?

Don't know that for sure, but it is the most reliable way that I am 
aware of.

> 
> Btw., rtc-debug's latency results could now be cross-validated with
> -V0.4's wakeup tracer (and vice versa), because the two are totally
> independent mechanisms.

Agreed. :)

> 
> 	Ingo
> 

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 15:13                                                       ` Lee Revell
@ 2004-10-27 15:17                                                         ` Ingo Molnar
  2004-10-27 17:14                                                           ` Lee Revell
  2004-10-27 20:09                                                           ` Andrew Morton
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 15:17 UTC (permalink / raw)
  To: Lee Revell
  Cc: K.R. Foley, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton


* Lee Revell <rlrevell@joe-job.com> wrote:

> > ah, ok - nice. So rtc-debug+amlat is the only known-reliable way to
> > produce latency histograms?
> > 
> 
> Yes, I think it is the most reliable way because the measurement is
> done in the kernel.  At least, this is what AM's notes say.  There are
> any number of ways to generate these with userspace programs (jackd,
> realfeel, etc).
> 
> Here is a more up to date version of the rtc-debug patch:
> 
> http://lkml.org/lkml/2004/9/9/307
> 
> There is still a bit of 2.4 cruft in there but it works well.  Maybe
> this could be included in future patches.

the most natural point of inclusion would be Andrew's -mm tree i think
:-)

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 13:53                                           ` Ingo Molnar
@ 2004-10-27 15:26                                             ` Rui Nuno Capela
  2004-10-27 15:30                                               ` Lee Revell
                                                                 ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-27 15:26 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
>
> Rui Nuno Capela wrote:
>
>> OK. Currently with RT-V0.3.2.
>>
>> So it seems that the jackd -R is no more an issue here.
>
> great.
>
>> However (oh no!:) those jackd -R xruns are still frequent, much
>> frequent than RT-U3, which is my stable RT kernel atm.
>
> -V0.4.1 could help with this problem. There were a number of places
> where the PREEMPT_REALTIME kernel missed reschedules so it could easily
> happen that jackd would sit in the runqueue waiting to be executed and
> the kernel got quickly out of a critical section but then the kernel
> 'forgot' to reschedule for many milliseconds!
>

On RT-V0.4.1, xruns seems slighly reduced, but plenty enough for my taste.

Running jackd -R with 6 fluidsynth instances gives me 0 (zero) xruns on
RT-U3, but more than 20 (twenty) on RT-V0.4.1, under a 5 minute time
frame. It was 30 (thirty something) on RT-V0.4, but overall "feel" is
about the same.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 15:26                                             ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4 Rui Nuno Capela
@ 2004-10-27 15:30                                               ` Lee Revell
  2004-10-27 17:39                                                 ` Rui Nuno Capela
  2004-10-27 20:01                                               ` Ingo Molnar
  2004-10-27 20:51                                               ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-27 15:30 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, linux-kernel, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

On Wed, 2004-10-27 at 16:26 +0100, Rui Nuno Capela wrote:
> On RT-V0.4.1, xruns seems slighly reduced, but plenty enough for my taste.
> 

Have you tried making ksoftirqd SCHED_OTHER?  This drastically reduced
xruns on my system with an earlier version.

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 15:17                                                         ` Ingo Molnar
@ 2004-10-27 17:14                                                           ` Lee Revell
  2004-10-27 17:21                                                             ` K.R. Foley
  2004-10-27 20:09                                                           ` Andrew Morton
  1 sibling, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-27 17:14 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: K.R. Foley, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

On Wed, 2004-10-27 at 17:17 +0200, Ingo Molnar wrote:
> > Here is a more up to date version of the rtc-debug patch:
> > 
> > http://lkml.org/lkml/2004/9/9/307
> > 
> > There is still a bit of 2.4 cruft in there but it works well.  Maybe
> > this could be included in future patches.
> 
> the most natural point of inclusion would be Andrew's -mm tree i think
> :-)
> 

Well I suspect from looking at the comments :-) that he would not
include it in its current form due to the way it just checks whether the
process opening the RTC is called "amlat" and updates the RTC histogram
if so.  I am not sure what a clean way to do this would be, maybe an
ioctl()?

Anyway I am generating a cleaned up version of the patch agaqinst
2.6.9-mm1.

Lee




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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 17:14                                                           ` Lee Revell
@ 2004-10-27 17:21                                                             ` K.R. Foley
  2004-10-27 17:26                                                               ` Lee Revell
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-27 17:21 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

Lee Revell wrote:
> On Wed, 2004-10-27 at 17:17 +0200, Ingo Molnar wrote:
> 
>>>Here is a more up to date version of the rtc-debug patch:
>>>
>>>http://lkml.org/lkml/2004/9/9/307
>>>
>>>There is still a bit of 2.4 cruft in there but it works well.  Maybe
>>>this could be included in future patches.
>>
>>the most natural point of inclusion would be Andrew's -mm tree i think
>>:-)
>>
> 
> 
> Well I suspect from looking at the comments :-) that he would not
> include it in its current form due to the way it just checks whether the
> process opening the RTC is called "amlat" and updates the RTC histogram
> if so.  I am not sure what a clean way to do this would be, maybe an
> ioctl()?
> 
> Anyway I am generating a cleaned up version of the patch agaqinst
> 2.6.9-mm1.
> 
> Lee
> 

Actually if you are cleaning it up anyway, could you fix it to work with 
Ingo's changes to rtc.c? If not I will be glad to do it. Up until one of 
the last couple of versions of RT PREEMPT it applied cleanly, but I just 
tried it and it failed.

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3
  2004-10-27 13:48                                           ` Ingo Molnar
@ 2004-10-27 17:25                                             ` Michal Schmidt
  2004-10-28 11:57                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Michal Schmidt @ 2004-10-27 17:25 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
> * Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:
> 
>>OK, re-reporting a network deadlock. It happens a few seconds after 
>>starting Firefox. This is with -V0.3.2:
> 
> i've uploaded -V0.4.1 with a fix that could fix this networking
> deadlock. Does it work any better?
> 
> 	Ingo

Unfortunately, no. It's only slightly different:

BUG: semaphore recursion deadlock detected!
.. current task ksoftirqd/0/2 [f7c24020] is already holding c0438ec0 
[w:f7c24020, d:0].
  [<c01c7a08>] __rwsem_deadlock+0x188/0x1a0 (12)
  [<c01c78ec>] __rwsem_deadlock+0x6c/0x1a0 (52)
  [<c0134ac0>] _mutex_lock+0x40/0x50 (28)
  [<c02cc153>] down_write_mutex+0x113/0x220 (24)
  [<c01c8228>] down_mutex+0x8/0x10 (12)
  [<c0134ac0>] _mutex_lock+0x40/0x50 (40)
  [<c0281a16>] qdisc_restart+0x236/0x250 (24)
  [<c0281d2e>] pfifo_fast_enqueue+0xe/0xc0 (8)
  [<c02727dd>] dev_queue_xmit+0x1ad/0x260 (4)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c02727ef>] dev_queue_xmit+0x1bf/0x260 (36)
  [<c0278b2e>] neigh_resolve_output+0xfe/0x240 (32)
  [<c029383e>] ip_finish_output2+0xbe/0x240 (56)
  [<c01c80be>] up_write_mutex+0x2e/0x60 (12)
  [<c027e211>] nf_hook_slow+0xe1/0x130 (24)
  [<c0293780>] ip_finish_output2+0x0/0x240 (28)
  [<c029104b>] ip_finish_output+0x26b/0x270 (32)
  [<c0293780>] ip_finish_output2+0x0/0x240 (24)
  [<c029376a>] dst_output+0x1a/0x30 (32)
  [<c027e211>] nf_hook_slow+0xe1/0x130 (12)
  [<c0293750>] dst_output+0x0/0x30 (28)
  [<c029170a>] ip_queue_xmit+0x45a/0x570 (32)
  [<c0293750>] dst_output+0x0/0x30 (24)
  [<c0135ef0>] sub_preempt_count+0x60/0xd0 (24)
  [<c01c7f1e>] __up_write+0x10e/0x220 (12)
  [<c0135ef0>] sub_preempt_count+0x60/0xd0 (4)
  [<c0135958>] check_preempt_timing+0x58/0x2f0 (8)
  [<c0135ef0>] sub_preempt_count+0x60/0xd0 (4)
  [<c01c7f1e>] __up_write+0x10e/0x220 (4)
  [<c013514d>] __mcount+0x1d/0x20 (32)
  [<c01c775e>] rwsem_owner_del+0xe/0xf0 (4)
  [<c013514d>] __mcount+0x1d/0x20 (40)
  [<c02a8d1e>] tcp_v4_send_check+0xe/0xf0 (4)
  [<c02a2819>] tcp_transmit_skb+0x439/0x880 (4)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c02a8d5f>] tcp_v4_send_check+0x4f/0xf0 (20)
  [<c02a28c2>] tcp_transmit_skb+0x4e2/0x880 (32)
  [<c0114310>] mcount+0x14/0x18 (28)
  [<c02a5556>] tcp_send_ack+0xa6/0xf0 (52)
  [<c02a0527>] __tcp_ack_snd_check+0x87/0xa0 (12)
  [<c02a0f65>] tcp_rcv_established+0x6e5/0x920 (24)
  [<c02aa20e>] tcp_v4_do_rcv+0x13e/0x150 (56)
  [<c02aa8e0>] tcp_v4_rcv+0x6c0/0x8d0 (32)
  [<c02cc11f>] down_write_mutex+0xdf/0x220 (28)
  [<c028e09d>] ip_local_deliver_finish+0xbd/0x1a0 (52)
  [<c01c80be>] up_write_mutex+0x2e/0x60 (12)
  [<c027e211>] nf_hook_slow+0xe1/0x130 (24)
  [<c028dfe0>] ip_local_deliver_finish+0x0/0x1a0 (28)
  [<c028da76>] ip_local_deliver+0x1f6/0x220 (32)
  [<c028dfe0>] ip_local_deliver_finish+0x0/0x1a0 (24)
  [<c028e2c9>] ip_rcv_finish+0x149/0x300 (24)
  [<c01c80be>] up_write_mutex+0x2e/0x60 (36)
  [<c027e211>] nf_hook_slow+0xe1/0x130 (24)
  [<c028e180>] ip_rcv_finish+0x0/0x300 (28)
  [<c028df00>] ip_rcv+0x460/0x540 (32)
  [<c028e180>] ip_rcv_finish+0x0/0x300 (24)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c0272d0d>] netif_receive_skb+0x12d/0x240 (28)
  [<c0270008>] __scm_send+0x78/0x1e0 (20)
  [<c027303f>] net_rx_action+0x7f/0x1a0 (4)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c0272ea8>] process_backlog+0x88/0x1a0 (20)
  [<c027303f>] net_rx_action+0x7f/0x1a0 (40)
  [<c0123887>] ___do_softirq+0x87/0xd0 (36)
  [<c0123958>] _do_softirq+0x8/0x30 (8)
  [<c0123d44>] ksoftirqd+0xb4/0x100 (4)
  [<c0123970>] _do_softirq+0x20/0x30 (28)
  [<c0123d44>] ksoftirqd+0xb4/0x100 (8)
  [<c013406a>] kthread+0xaa/0xb0 (24)
  [<c0123c90>] ksoftirqd+0x0/0x100 (20)
  [<c0133fc0>] kthread+0x0/0xb0 (12)
  [<c0103319>] kernel_thread_helper+0x5/0xc (16)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: down_write_mutex+0x214/0x220 [<c02cc254>] / 
(_mutex_lock+0x40/0x50 [<c0134ac0>])
.. entry 2: print_traces+0x1d/0x60 [<c013663d>] / (dump_stack+0x23/0x30 
[<c01060b3>])

BUG: circular semaphore deadlock: firefox-bin/4792 is blocked on 
c0438ec0, deadlocking ksoftirqd/0/2
f18119bc 00200086 f1fbe810 c03c1ca0 f1810000 0000196c f1810000 f1fbe810
        00000000 f18119a8 00000167 4344b736 00000023 f1fbe810 f1fbeaa4 
f1810000
        f1fbe810 00000000 f18119e0 c02cae1f 00000054 00000008 f18119e0 
00200046
Call Trace:
  [<c02cae1f>] schedule+0x2f/0xe0 (80)
  [<c02cc1a0>] down_write_mutex+0x160/0x220 (36)
  [<c02cc268>] down_read_mutex+0x8/0x30 (12)
  [<c0272251>] dev_queue_xmit_nit+0x41/0x130 (40)
  [<c01c80be>] up_write_mutex+0x2e/0x60 (12)
  [<c0281a03>] qdisc_restart+0x223/0x250 (24)
  [<c02727dd>] dev_queue_xmit+0x1ad/0x260 (12)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c02727ef>] dev_queue_xmit+0x1bf/0x260 (36)
  [<c0278b2e>] neigh_resolve_output+0xfe/0x240 (32)
  [<c029383e>] ip_finish_output2+0xbe/0x240 (56)
  [<c01c80be>] up_write_mutex+0x2e/0x60 (12)
  [<c027e211>] nf_hook_slow+0xe1/0x130 (24)
  [<c0293780>] ip_finish_output2+0x0/0x240 (28)
  [<c029104b>] ip_finish_output+0x26b/0x270 (32)
  [<c0293780>] ip_finish_output2+0x0/0x240 (24)
  [<c029376a>] dst_output+0x1a/0x30 (32)
  [<c027e211>] nf_hook_slow+0xe1/0x130 (12)
  [<c0293750>] dst_output+0x0/0x30 (28)
  [<c029170a>] ip_queue_xmit+0x45a/0x570 (32)
  [<c0293750>] dst_output+0x0/0x30 (24)
  [<c02cc11f>] down_write_mutex+0xdf/0x220 (24)
  [<c0135ef0>] sub_preempt_count+0x60/0xd0 (4)
  [<c01c7f1e>] __up_write+0x10e/0x220 (12)
  [<c0135ef0>] sub_preempt_count+0x60/0xd0 (4)
  [<c0135958>] check_preempt_timing+0x58/0x2f0 (8)
  [<c0135ef0>] sub_preempt_count+0x60/0xd0 (4)
  [<c01c7f1e>] __up_write+0x10e/0x220 (4)
  [<c013514d>] __mcount+0x1d/0x20 (32)
  [<c01c775e>] rwsem_owner_del+0xe/0xf0 (4)
  [<c013514d>] __mcount+0x1d/0x20 (36)
  [<c02a8d1e>] tcp_v4_send_check+0xe/0xf0 (4)
  [<c02a2819>] tcp_transmit_skb+0x439/0x880 (4)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c02a8d5f>] tcp_v4_send_check+0x4f/0xf0 (20)
  [<c02a28c2>] tcp_transmit_skb+0x4e2/0x880 (32)
  [<c01c9f52>] memcpy+0x12/0x40 (36)
  [<c02a37f4>] tcp_write_xmit+0x154/0x2d0 (44)
  [<c0296eea>] tcp_sendmsg+0x50a/0x1130 (12)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c0296ebe>] tcp_sendmsg+0x4de/0x1130 (32)
  [<c0268254>] sock_sendmsg+0xc4/0xe0 (84)
  [<c02b9af0>] inet_sendmsg+0x50/0x60 (28)
  [<c0268254>] sock_sendmsg+0xc4/0xe0 (28)
  [<c0135958>] check_preempt_timing+0x58/0x2f0 (24)
  [<c0135ef0>] sub_preempt_count+0x60/0xd0 (4)
  [<c013514d>] __mcount+0x1d/0x20 (36)
  [<c01c775e>] rwsem_owner_del+0xe/0xf0 (4)
  [<c015ff59>] fget+0x59/0x70 (72)
  [<c01c80be>] up_write_mutex+0x2e/0x60 (28)
  [<c0134620>] autoremove_wake_function+0x0/0x60 (24)
  [<c0267f8f>] sockfd_lookup+0x1f/0x80 (28)
  [<c0114310>] mcount+0x14/0x18 (4)
  [<c026990d>] sys_sendto+0xed/0x110 (20)
  [<c01c80be>] up_write_mutex+0x2e/0x60 (72)
  [<c0142cf2>] free_pages_bulk+0x1d2/0x2e0 (24)
  [<c013514d>] __mcount+0x1d/0x20 (72)
  [<c026993b>] sys_send+0xb/0x40 (4)
  [<c026a1c3>] sys_socketcall+0x133/0x240 (4)
  [<c0114310>] mcount+0x14/0x18 (8)
  [<c026996b>] sys_send+0x3b/0x40 (20)
  [<c026a1c3>] sys_socketcall+0x133/0x240 (32)
  [<c010527b>] syscall_call+0x7/0xb (68)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __schedule+0x4e/0x6b0 [<c02ca78e>] / (schedule+0x2f/0xe0 
[<c02cae1f>])
.. entry 2: __schedule+0xdd/0x6b0 [<c02ca81d>] / (schedule+0x2f/0xe0 
[<c02cae1f>])


Michal

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 17:21                                                             ` K.R. Foley
@ 2004-10-27 17:26                                                               ` Lee Revell
  2004-10-27 17:40                                                                 ` K.R. Foley
  2004-10-27 17:43                                                                 ` K.R. Foley
  0 siblings, 2 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-27 17:26 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

On Wed, 2004-10-27 at 12:21 -0500, K.R. Foley wrote:
> > 
> > Anyway I am generating a cleaned up version of the patch agaqinst
> > 2.6.9-mm1.
> > 
> > Lee
> > 
> 
> Actually if you are cleaning it up anyway, could you fix it to work with 
> Ingo's changes to rtc.c? If not I will be glad to do it. Up until one of 
> the last couple of versions of RT PREEMPT it applied cleanly, but I just 
> tried it and it failed.

Yup, here it is against 2.6.9-mm1-V0.4.1.  Not yet tested (building now)
but should work.  I took out the show_trace_smp part because that never
worked, I always get "Stack pointer is garbage".  So now the patch is
smaller and only touches rtc.c.

--- linux-2.6.9-mm1/drivers/char/rtc.c	2004-10-27 13:19:04.000000000 -0400
+++ linux-2.6.9-mm1-V0.4.1/drivers/char/rtc.c	2004-10-27 12:55:23.000000000 -0400
@@ -86,6 +86,18 @@
 #include <asm/hpet.h>
 #endif
 
+static unsigned long long last_interrupt_time;
+
+#include <asm/timex.h>
+
+
+#define CPU_MHZ	(cpu_khz / 1000)
+#define HISTSIZE	10000
+static int histogram[HISTSIZE];
+
+int rtc_debug;
+int rtc_running;
+
 #ifdef __sparc__
 #include <linux/pci.h>
 #include <asm/ebus.h>
@@ -191,6 +203,14 @@
 static const unsigned char days_in_mo[] = 
 {0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
 
+static int rtc_state;
+
+enum rtc_states {
+	S_IDLE,			/* Waiting for an interrupt */
+	S_WAITING_FOR_READ,	/* Signal delivered. waiting for rtc_read() */
+	S_READ_MISSED,		/* Signal delivered, read() deadline missed */
+};
+
 /*
  * Returns true if a clock update is in progress
  */
@@ -259,7 +279,36 @@
 	spin_unlock_irqrestore(&rtc_task_lock, flags);
 	wake_up_interruptible(&rtc_wait);	
 
-	kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+	if (!(rtc_status & RTC_IS_OPEN))
+		goto tata;
+
+	switch (rtc_state) {
+	case S_IDLE:			/* Waiting for an interrupt */
+		rdtscll(last_interrupt_time);
+		kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+		rtc_state = S_WAITING_FOR_READ;
+		break;
+	case S_WAITING_FOR_READ:	/* Signal has been delivered. waiting for rtc_read() */
+		/*
+		 * Well foo.  The usermode application didn't schedule and read in time.
+		 */
+		rtc_state = S_READ_MISSED;
+		if (strcmp(current->comm, "amlat") != 0) {
+			printk("`%s'[%d] is being piggy.  "
+					"need_resched=%d, cpu=%d\n",
+				current->comm, current->pid,
+				need_resched(), smp_processor_id());
+			/* show_trace_smp(); */
+		}
+		break;
+	case S_READ_MISSED:		/* Signal has been delivered, read() deadline was missed */
+		/*
+		 * Not much we can do here.  We're waiting for the usermode
+		 * application to read the rtc
+		 */
+		break;
+	}
+tata:
 
 	return IRQ_HANDLED;
 }
@@ -319,8 +368,74 @@
  *	Now all the various file operations that we export.
  */
 
-static ssize_t rtc_read(struct file *file, char __user *buf,
-			size_t count, loff_t *ppos)
+static ssize_t ll_rtc_read(struct file *file, char *buf,
+				size_t count, loff_t *ppos)
+{
+	ssize_t retval;
+	unsigned long long now;
+
+	rdtscll(now);
+
+	switch (rtc_state) {
+	case S_IDLE:			/* Waiting for an interrupt */
+		/*
+		 * err...  This can't be happening
+		 */
+		printk("ll_rtc_read(): called in state S_IDLE!\n");
+		break;
+	case S_WAITING_FOR_READ:	/*
+					 * Signal has been delivered.
+					 * waiting for rtc_read()
+					 */
+		/*
+		 * Well done
+		 */
+	case S_READ_MISSED:		/*
+					 * Signal has been delivered, read()
+					 * deadline was missed
+					 */
+		/*
+		 * So, you finally got here.
+		 */
+		if (last_interrupt_time == 0)
+			printk("ll_rtc_read(): we screwed up.  "
+					"last_interrupt_time = 0\n");
+		rtc_state = S_IDLE;
+		{
+			unsigned long long latency = now - last_interrupt_time;
+			unsigned long delta;	/* Nocroseconds */
+
+			delta = latency;
+			delta /= CPU_MHZ;
+			if (delta > 1000 * 1000) {
+				printk("rtc: eek\n");
+			} else {
+				unsigned long slot = delta;
+				if (slot >= HISTSIZE)
+					slot = HISTSIZE - 1;
+				histogram[slot]++;
+				if (delta > 2000)
+					printk("wow!  That was a "
+							"%ld millisec bump\n",
+						delta / 1000);
+			}
+		}
+		rtc_state = S_IDLE;
+		break;
+	}
+
+	if (count < sizeof(last_interrupt_time))
+		return -EINVAL;
+
+	retval = -EIO;
+	if (copy_to_user(buf, &last_interrupt_time,
+				sizeof(last_interrupt_time)) == 0)
+		retval = sizeof(last_interrupt_time);
+	return retval;
+}
+
+static ssize_t orig_rtc_read(struct file *file, char *buf,
+  			size_t count, loff_t *ppos)
 {
 #ifndef RTC_IRQ
 	return -EIO;
@@ -375,6 +490,19 @@
 #endif
 }
 
+/*
+ * If anyone reads this, please send me an email describing
+ * the superlative elegance of this conception
+ */
+static ssize_t rtc_read(struct file *file, char *buf,
+			size_t count, loff_t *ppos)
+{
+	if (strcmp(current->comm, "amlat") == 0)
+		return ll_rtc_read(file, buf, count, ppos);
+	else
+		return orig_rtc_read(file, buf, count, ppos);
+}
+
 static int rtc_do_ioctl(unsigned int cmd, unsigned long arg, int kernel)
 {
 	struct rtc_time wtime; 
@@ -692,6 +820,8 @@
  * needed here. Or anywhere else in this driver. */
 static int rtc_open(struct inode *inode, struct file *file)
 {
+	int i;
+
 	spin_lock_irq (&rtc_lock);
 
 	if(rtc_status & RTC_IS_OPEN)
@@ -699,7 +829,16 @@
 
 	rtc_status |= RTC_IS_OPEN;
 
-	rtc_irq_data = 0;
+	if (strcmp(current->comm, "amlat") == 0) {
+		last_interrupt_time = 0;
+		rtc_state = S_IDLE;
+		rtc_irq_data = 0;
+	}
+
+	rtc_running = 1;
+	for (i = 0; i < HISTSIZE; i++)
+		histogram[i] = 0;
+
 	spin_unlock_irq (&rtc_lock);
 	return 0;
 
@@ -753,6 +892,19 @@
 	rtc_irq_data = 0;
 	rtc_status &= ~RTC_IS_OPEN;
 	spin_unlock_irq (&rtc_lock);
+	{
+		int i = 0;
+		unsigned long total = 0;
+		printk("rtc histogram:\n");
+		for (i = 0; i < HISTSIZE; i++) {
+			if (histogram[i]) {
+				total += histogram[i];
+				printk("%d %d\n", i, histogram[i]);
+			}
+		}
+		printk("\nTotal samples: %lu\n", total);
+		rtc_running = 0;
+	}
 	return 0;
 }
 
@@ -1127,6 +1279,7 @@
 	wake_up_interruptible(&rtc_wait);
 
 	kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+	return;
 }
 #endif
 





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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 15:30                                               ` Lee Revell
@ 2004-10-27 17:39                                                 ` Rui Nuno Capela
  2004-10-27 18:57                                                   ` karsten wiese
  2004-10-27 18:59                                                   ` karsten wiese
  0 siblings, 2 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-27 17:39 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, linux-kernel, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese


> Lee Revell
> On Wed, 2004-10-27 at 16:26 +0100, Rui Nuno Capela wrote:
>> On RT-V0.4.1, xruns seems slighly reduced, but plenty enough for my
>> taste.
>>
>
> Have you tried making ksoftirqd SCHED_OTHER?  This drastically reduced
> xruns on my system with an earlier version.
>
> Lee
>

Hmm... ksoftirqd/0 (or also ksoftirqd/1 on 2cpu SMP) are already
SCHED_OTHER by default, at least on both of my boxes that are running
RT-V0.4.1 now.

Should I try the other way around? Lets see... 'chrt -p -f 90 `pidof
ksoftirwd/0`',... yes, apparentely the xrun rate seems to decrease into
half, but IMHO not conclusive enough, thought.

CU
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 17:26                                                               ` Lee Revell
@ 2004-10-27 17:40                                                                 ` K.R. Foley
  2004-10-27 17:44                                                                   ` Lee Revell
  2004-10-27 17:43                                                                 ` K.R. Foley
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-27 17:40 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

Lee Revell wrote:
> On Wed, 2004-10-27 at 12:21 -0500, K.R. Foley wrote:
> 
>>>Anyway I am generating a cleaned up version of the patch agaqinst
>>>2.6.9-mm1.
>>>
>>>Lee
>>>
>>
>>Actually if you are cleaning it up anyway, could you fix it to work with 
>>Ingo's changes to rtc.c? If not I will be glad to do it. Up until one of 
>>the last couple of versions of RT PREEMPT it applied cleanly, but I just 
>>tried it and it failed.
> 
> 
> Yup, here it is against 2.6.9-mm1-V0.4.1.  Not yet tested (building now)
> but should work.  I took out the show_trace_smp part because that never
> worked, I always get "Stack pointer is garbage".  So now the patch is
> smaller and only touches rtc.c.
> 

You've also eliminated the stack trace altogether then, right? Not that 
I really need it. :-)

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 17:26                                                               ` Lee Revell
  2004-10-27 17:40                                                                 ` K.R. Foley
@ 2004-10-27 17:43                                                                 ` K.R. Foley
  2004-10-27 19:47                                                                   ` Lee Revell
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-27 17:43 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

Lee Revell wrote:
> On Wed, 2004-10-27 at 12:21 -0500, K.R. Foley wrote:
> 
>>>Anyway I am generating a cleaned up version of the patch agaqinst
>>>2.6.9-mm1.
>>>
>>>Lee
>>>
>>
>>Actually if you are cleaning it up anyway, could you fix it to work with 
>>Ingo's changes to rtc.c? If not I will be glad to do it. Up until one of 
>>the last couple of versions of RT PREEMPT it applied cleanly, but I just 
>>tried it and it failed.
> 
> 
> Yup, here it is against 2.6.9-mm1-V0.4.1.  Not yet tested (building now)
> but should work.  I took out the show_trace_smp part because that never
> worked, I always get "Stack pointer is garbage".  So now the patch is
> smaller and only touches rtc.c.
> 

OH! And thanks. :)

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 17:40                                                                 ` K.R. Foley
@ 2004-10-27 17:44                                                                   ` Lee Revell
  0 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-27 17:44 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

On Wed, 2004-10-27 at 12:40 -0500, K.R. Foley wrote:
> Lee Revell wrote:
> > On Wed, 2004-10-27 at 12:21 -0500, K.R. Foley wrote:
> > 
> >>>Anyway I am generating a cleaned up version of the patch agaqinst
> >>>2.6.9-mm1.
> >>>
> >>>Lee
> >>>
> >>
> >>Actually if you are cleaning it up anyway, could you fix it to work with 
> >>Ingo's changes to rtc.c? If not I will be glad to do it. Up until one of 
> >>the last couple of versions of RT PREEMPT it applied cleanly, but I just 
> >>tried it and it failed.
> > 
> > 
> > Yup, here it is against 2.6.9-mm1-V0.4.1.  Not yet tested (building now)
> > but should work.  I took out the show_trace_smp part because that never
> > worked, I always get "Stack pointer is garbage".  So now the patch is
> > smaller and only touches rtc.c.
> > 
> 
> You've also eliminated the stack trace altogether then, right? Not that 
> I really need it. :-)

Yes, it's commented out.  I figured that a better way would be to have
it trigger Ingo's latency tracer.

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 17:39                                                 ` Rui Nuno Capela
@ 2004-10-27 18:57                                                   ` karsten wiese
  2004-10-27 20:28                                                     ` Rui Nuno Capela
  2004-10-27 18:59                                                   ` karsten wiese
  1 sibling, 1 reply; 951+ messages in thread
From: karsten wiese @ 2004-10-27 18:57 UTC (permalink / raw)
  To: Rui Nuno Capela, Lee Revell
  Cc: Ingo Molnar, linux-kernel, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

 --- Rui Nuno Capela <rncbc@rncbc.org> schrieb: 
> Should I try the other way around? Lets see... 'chrt -p
> -f 90 `pidof
> ksoftirwd/0`',... yes, apparentely the xrun rate seems to
> decrease into
> half, but IMHO not conclusive enough, thought.
> 
'into half' makes me wonder:
did you also 'chrt -p -f 90 `pidof ksoftirwd/1`'?
I guess you meant that with '...'. Just in case :-)

Best,
Karsten


	

	
		
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 17:39                                                 ` Rui Nuno Capela
  2004-10-27 18:57                                                   ` karsten wiese
@ 2004-10-27 18:59                                                   ` karsten wiese
  1 sibling, 0 replies; 951+ messages in thread
From: karsten wiese @ 2004-10-27 18:59 UTC (permalink / raw)
  To: Rui Nuno Capela, Lee Revell
  Cc: Ingo Molnar, linux-kernel, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

 --- Rui Nuno Capela <rncbc@rncbc.org> schrieb: 
> Should I try the other way around? Lets see... 'chrt -p
> -f 90 `pidof
> ksoftirwd/0`',... yes, apparentely the xrun rate seems to
> decrease into
> half, but IMHO not conclusive enough, thought.
> 
'into half' makes me wonder:
did you also 'chrt -p -f 90 `pidof ksoftirwd/1`'?
(I guess you meant that with '...') And isn't it
'ksoftirqd'? Just in case :-)

Best,
Karsten


	

	
		
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 17:43                                                                 ` K.R. Foley
@ 2004-10-27 19:47                                                                   ` Lee Revell
  2004-10-27 21:40                                                                     ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-27 19:47 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

On Wed, 2004-10-27 at 12:43 -0500, K.R. Foley wrote:
> OH! And thanks. :)
> 

Well I tried it and it does not seem to work exactly right.  This might
be because I enabled the HPET so the RTC is not getting used.  When I
run amlat for a few minutes I get a histogram with only 38 samples.
Does this work for you?

Lee


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 15:26                                             ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4 Rui Nuno Capela
  2004-10-27 15:30                                               ` Lee Revell
@ 2004-10-27 20:01                                               ` Ingo Molnar
  2004-10-27 20:51                                               ` Ingo Molnar
  2 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 20:01 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> On RT-V0.4.1, xruns seems slighly reduced, but plenty enough for my
> taste.
> 
> Running jackd -R with 6 fluidsynth instances gives me 0 (zero) xruns
> on RT-U3, but more than 20 (twenty) on RT-V0.4.1, under a 5 minute
> time frame. It was 30 (thirty something) on RT-V0.4, but overall
> "feel" is about the same.

does the wakeup tracer show any high latency?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 15:17                                                         ` Ingo Molnar
  2004-10-27 17:14                                                           ` Lee Revell
@ 2004-10-27 20:09                                                           ` Andrew Morton
  2004-10-27 21:43                                                             ` K.R. Foley
  1 sibling, 1 reply; 951+ messages in thread
From: Andrew Morton @ 2004-10-27 20:09 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: rlrevell, kr, linux-kernel, rncbc, Mark_H_Johnson, bhuey, doogie,
	mista.tapas, tglx, xschmi00, nando

Ingo Molnar <mingo@elte.hu> wrote:
>
> > Here is a more up to date version of the rtc-debug patch:
>  > 
>  > http://lkml.org/lkml/2004/9/9/307
>  > 
>  > There is still a bit of 2.4 cruft in there but it works well.  Maybe
>  > this could be included in future patches.
> 
>  the most natural point of inclusion would be Andrew's -mm tree i think
>  :-)

It's 'orrid.  And iirc it breaks normal use of the RTC.

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 18:57                                                   ` karsten wiese
@ 2004-10-27 20:28                                                     ` Rui Nuno Capela
  0 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-27 20:28 UTC (permalink / raw)
  To: karsten wiese
  Cc: Lee Revell, Ingo Molnar, linux-kernel, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese

karsten wiese wrote:
> Rui Nuno Capela wrote:
>> Should I try the other way around? Lets see... 'chrt -p
>> -f 90 `pidof ksoftirwd/0`',... yes, apparentely the xrun
>> rate seems to decrease into half, but IMHO not conclusive
>> enough, thought.
>>
> 'into half' makes me wonder:
> did you also 'chrt -p -f 90 `pidof ksoftirwd/1`'?
> I guess you meant that with '...'. Just in case :-)
>

Wonder no more. All my statistical-wise tests were carried on a UP box (my
laptop), so there's no "ksoftirqd/1" in there, just a single
"ksoftirqd/0".

Speaking of which, I was not taking tests very seriously on my other
SMP/HT box, just because I don't want to rant about it anymore :) Only
recently VP and RT kernels were barely able to boot there, where even
plain vanilla 2.6.9 seems to be snappier and with far fewer xruns than
V0.4.1 or even U3 (either RT or not).

OTOH, on my laptop (P4/UP) I can testify as truth that, at least for
RT-U3, the improvement is real: I don't have a record of such a top
performer, when regarding the zero-xrun, low-latency audio setup
potential. When even compared, it just outperforms by far that old
2.4+preempt+low-latency myth ;)

Unfortunately, this is not what I see on my P4/SMP/HT desktop box. I
cannot tell a lie ;)

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

P.S. Karsten, my US-224 is working real nice on my laptop now (provided
I'm with RT-U3 :) I'm real thankful for all of your work on snd-usb-usx2y.
Cheers.



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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 15:05                                                     ` Ingo Molnar
  2004-10-27 15:13                                                       ` Lee Revell
  2004-10-27 15:16                                                       ` K.R. Foley
@ 2004-10-27 20:49                                                       ` Bill Huey
  2004-10-27 20:54                                                         ` Bill Huey
  2 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-27 20:49 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Andrew Morton

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

On Wed, Oct 27, 2004 at 05:05:48PM +0200, Ingo Molnar wrote:
> 
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> > I use the rtc-debug and amlat to generate histograms of latencies
> > which is what I was trying to do when I found the rtc problem the
> > first time.  I believe that rtc-debug/amlat is much more accurate for
> > generating histograms of latencies than realfeel is because the
> > instrumentation is in the kernel rather than a userspace program.
> 
> ah, ok - nice. So rtc-debug+amlat is the only known-reliable way to
> produce latency histograms?
> 
> Btw., rtc-debug's latency results could now be cross-validated with
> -V0.4's wakeup tracer (and vice versa), because the two are totally
> independent mechanisms.

I've got a latency/histogram patch here, but I've been having problems
trying to integrate it into Ingo's irq-threads and getting that simple
subtraction returning something sensible. The basic logic works otherwise.

Maybe another pair of eyes can figure this out, since I could have missed
something pretty simple...

bill


[-- Attachment #2: s.diff --]
[-- Type: text/plain, Size: 14363 bytes --]

diff -rwu linux.voluntary.virgin/arch/i386/Kconfig linux.voluntary/arch/i386/Kconfig
--- linux.voluntary.virgin/arch/i386/Kconfig	2004-10-21 21:52:33.000000000 -0700
+++ linux.voluntary/arch/i386/Kconfig	2004-10-21 22:35:53.000000000 -0700
@@ -586,6 +586,17 @@
 	  system.
 	  Say N if you are unsure.
 
+config NOTE_LATENCY
+	bool "Note irq-thread wake latency"
+	depends on PREEMPT_HARDIRQS && HPET
+	default n
+	help
+	  This options timestamp marks exception frame wake events to the
+	  irq-thread in question and shoves it into a statistically scalable
+	  histogram. Timestamp events can be "zoomed" in that are of interest
+	  with compile time changes to the struct describing the ranges of
+	  band(s) being saved.
+
 config X86_UP_APIC
 	bool "Local APIC support on uniprocessors" if !SMP
 	depends on !(X86_VISWS || X86_VOYAGER)
diff -rwu linux.voluntary.virgin/arch/i386/kernel/irq.c linux.voluntary/arch/i386/kernel/irq.c
--- linux.voluntary.virgin/arch/i386/kernel/irq.c	2004-10-21 21:52:33.000000000 -0700
+++ linux.voluntary/arch/i386/kernel/irq.c	2004-10-21 22:36:10.000000000 -0700
@@ -54,6 +54,7 @@
 	u32 *isp;
 #endif
 
+
 	irq_enter();
 	__trace((unsigned long)do_IRQ, regs.eip);
 	__trace((unsigned long)do_IRQ, irq);
@@ -101,6 +102,12 @@
 		);
 	} else
 #endif
+
+#ifdef CONFIG_NOTE_LATENCY
+//	irq_desc_t *desc = irq_desc + irq;
+	irq_desc[irq].timestamp = get_cycles();
+#endif
+
 		__do_IRQ(irq, &regs);
 
 	irq_exit();
diff -rwu linux.voluntary.virgin/arch/i386/kernel/kgdb_stub.c linux.voluntary/arch/i386/kernel/kgdb_stub.c
--- linux.voluntary.virgin/arch/i386/kernel/kgdb_stub.c	2004-10-21 21:52:18.000000000 -0700
+++ linux.voluntary/arch/i386/kernel/kgdb_stub.c	2004-10-21 22:36:17.000000000 -0700
@@ -365,8 +365,8 @@
 
 #ifdef CONFIG_SMP
 static int in_kgdb_called;
-static spinlock_t waitlocks[MAX_NO_CPUS] =
-    {[0 ... MAX_NO_CPUS - 1] = SPIN_LOCK_UNLOCKED };
+static raw_spinlock_t waitlocks[MAX_NO_CPUS] =
+    {[0 ... MAX_NO_CPUS - 1] = RAW_SPIN_LOCK_UNLOCKED };
 /*
  * The following array has the thread pointer of each of the "other"
  * cpus.  We make it global so it can be seen by gdb.
@@ -374,9 +374,9 @@
 volatile int in_kgdb_entry_log[MAX_NO_CPUS];
 volatile struct pt_regs *in_kgdb_here_log[MAX_NO_CPUS];
 /*
-static spinlock_t continuelocks[MAX_NO_CPUS];
+static raw_spinlock_t continuelocks[MAX_NO_CPUS];
 */
-spinlock_t kgdb_spinlock = SPIN_LOCK_UNLOCKED;
+raw_spinlock_t kgdb_spinlock = RAW_SPIN_LOCK_UNLOCKED;
 /* waiters on our spinlock plus us */
 static atomic_t spinlock_waiters = ATOMIC_INIT(1);
 static int spinlock_count = 0;
@@ -2404,7 +2404,7 @@
 void
 kgdb_tstamp(int line, char *source, int data0, int data1)
 {
-	static spinlock_t ts_spin = SPIN_LOCK_UNLOCKED;
+	static raw_spinlock_t ts_spin = RAW_SPIN_LOCK_UNLOCKED;
 	int flags;
 	kgdb_local_irq_save(flags);
 	spin_lock(&ts_spin);
diff -rwu linux.voluntary.virgin/arch/i386/kernel/timers/timer_hpet.c linux.voluntary/arch/i386/kernel/timers/timer_hpet.c
--- linux.voluntary.virgin/arch/i386/kernel/timers/timer_hpet.c	2004-10-21 21:52:33.000000000 -0700
+++ linux.voluntary/arch/i386/kernel/timers/timer_hpet.c	2004-10-26 14:11:31.000000000 -0700
@@ -49,7 +49,8 @@
 	cyc2ns_scale = (1000 << CYC2NS_SCALE_FACTOR)/cpu_mhz;
 }
 
-static inline unsigned long long cycles_2_ns(unsigned long long cyc)
+//static inline
+unsigned long long cycles_2_ns(unsigned long long cyc)
 {
 	return (cyc * cyc2ns_scale) >> CYC2NS_SCALE_FACTOR;
 }
diff -rwu linux.voluntary.virgin/arch/i386/kernel/traps.c linux.voluntary/arch/i386/kernel/traps.c
--- linux.voluntary.virgin/arch/i386/kernel/traps.c	2004-10-21 21:52:33.000000000 -0700
+++ linux.voluntary/arch/i386/kernel/traps.c	2004-10-21 22:36:25.000000000 -0700
@@ -117,6 +117,7 @@
 	unsigned long addr, prev_frame;
 
 #ifdef CONFIG_KGDB
+#error
 extern void sysenter_past_esp(void);
 #include <asm/kgdb.h>
 #include <linux/init.h>
@@ -785,8 +786,9 @@
 		 * that really belongs to user space.  Others are
 		 * "Ours all ours!"
 		 */
-		if (((regs->xcs & 3) == 0) && ((void *)regs->eip == sysenter_past_esp))
+/*		if (((regs->xcs & 3) == 0) && ((void *)regs->eip == sysenter_past_esp))
 			goto clear_TF_reenable;
+		--billh	*/ 
 #else
 		if ((regs->xcs & 3) == 0)
 			goto clear_TF_reenable;
diff -rwu linux.voluntary.virgin/arch/i386/lib/kgdb_serial.c linux.voluntary/arch/i386/lib/kgdb_serial.c
--- linux.voluntary.virgin/arch/i386/lib/kgdb_serial.c	2004-10-21 21:52:18.000000000 -0700
+++ linux.voluntary/arch/i386/lib/kgdb_serial.c	2004-10-21 22:36:33.000000000 -0700
@@ -104,9 +104,9 @@
  * but we will just depend on the uart status to help keep that straight.
 
  */
-static spinlock_t uart_interrupt_lock = SPIN_LOCK_UNLOCKED;
+static raw_spinlock_t uart_interrupt_lock = RAW_SPIN_LOCK_UNLOCKED;
 #ifdef CONFIG_SMP
-extern spinlock_t kgdb_spinlock;
+extern raw_spinlock_t kgdb_spinlock;
 #endif
 
 static int
@@ -343,7 +343,7 @@
  */
 int kgdb_in_isr = 0;
 int kgdb_in_lsr = 0;
-extern spinlock_t kgdb_spinlock;
+extern raw_spinlock_t kgdb_spinlock;
 
 /* Caller takes needed protections */
 
@@ -381,7 +381,7 @@
 }				/* tty_getDebugChar */
 
 static int count = 3;
-static spinlock_t one_at_atime = SPIN_LOCK_UNLOCKED;
+static raw_spinlock_t one_at_atime = RAW_SPIN_LOCK_UNLOCKED;
 
 static int __init
 kgdb_enable_ints(void)
diff -rwu linux.voluntary.virgin/include/asm-i386/timex.h linux.voluntary/include/asm-i386/timex.h
--- linux.voluntary.virgin/include/asm-i386/timex.h	2004-10-21 21:52:22.000000000 -0700
+++ linux.voluntary/include/asm-i386/timex.h	2004-10-26 16:26:32.000000000 -0700
@@ -7,6 +7,7 @@
 #define _ASMi386_TIMEX_H
 
 #include <linux/config.h>
+#include <asm/types.h>
 #include <asm/processor.h>
 
 #ifdef CONFIG_X86_ELAN
@@ -30,7 +31,7 @@
  * four billion cycles just basically sounds like a good idea,
  * regardless of how fast the machine is. 
  */
-typedef unsigned long long cycles_t;
+typedef u64 cycles_t;
 
 extern cycles_t cacheflush_time;
 
@@ -49,6 +50,21 @@
 	return ret;
 }
 
+static inline cycles_t get_cycles64 (void)
+{
+	union u64_a {
+		u64 intlong;
+		struct u32x2_a {
+			uint32_t eax;
+			uint32_t edx;
+		} uintint;
+	} ulonglong;
+		
+	rdtsc(ulonglong.uintint.eax, ulonglong.uintint.edx);
+	return ulonglong.intlong;
+}
+
+
 extern unsigned long cpu_khz;
 
 #endif
diff -rwu linux.voluntary.virgin/include/linux/irq.h linux.voluntary/include/linux/irq.h
--- linux.voluntary.virgin/include/linux/irq.h	2004-10-21 21:52:33.000000000 -0700
+++ linux.voluntary/include/linux/irq.h	2004-10-21 22:36:54.000000000 -0700
@@ -76,6 +76,9 @@
 	unsigned int irq_count;		/* For detecting broken interrupts */
 	unsigned int irqs_unhandled;
 	struct task_struct *thread;
+#ifdef CONFIG_NOTE_LATENCY
+	u32 timestamp;
+#endif
 	wait_queue_head_t wait_for_handler;
 	raw_spinlock_t lock;
 } ____cacheline_aligned irq_desc_t;
diff -rwu linux.voluntary.virgin/kernel/irq/handle.c linux.voluntary/kernel/irq/handle.c
--- linux.voluntary.virgin/kernel/irq/handle.c	2004-10-21 21:52:33.000000000 -0700
+++ linux.voluntary/kernel/irq/handle.c	2004-10-27 02:50:40.000000000 -0700
@@ -139,6 +139,10 @@
 	struct irqaction * action;
 	unsigned int status;
 
+#ifdef CONFIG_NOTE_LATENCY
+//#error
+	desc->timestamp = get_cycles64();
+#endif
 	kstat_this_cpu.irqs[irq]++;
 	if (desc->status & IRQ_PER_CPU) {
 		irqreturn_t action_ret;
diff -rwu linux.voluntary.virgin/kernel/irq/manage.c linux.voluntary/kernel/irq/manage.c
--- linux.voluntary.virgin/kernel/irq/manage.c	2004-10-21 21:52:33.000000000 -0700
+++ linux.voluntary/kernel/irq/manage.c	2004-10-27 02:51:37.000000000 -0700
@@ -11,6 +11,7 @@
 #include <linux/module.h>
 #include <linux/kthread.h>
 #include <linux/interrupt.h>
+#include <asm/timex.h>
 
 #include "internals.h"
 
@@ -448,6 +449,10 @@
 	local_irq_enable();
 }
 
+#ifdef CONFIG_NOTE_LATENCY
+extern void note_latency_event(cycles_t start_event_time);
+#endif
+
 extern asmlinkage void __do_softirq(void);
 
 static int do_irqd(void * __desc)
@@ -468,6 +473,10 @@
 
 	while (!kthread_should_stop()) {
 		set_current_state(TASK_INTERRUPTIBLE);
+#ifdef CONFIG_NOTE_LATENCY
+//#error
+		note_latency_event(desc->timestamp);
+#endif
 		do_hardirq(desc);
 		cond_resched_all();
 		__do_softirq();
diff -rwu linux.voluntary.virgin/kernel/irq/proc.c linux.voluntary/kernel/irq/proc.c
--- linux.voluntary.virgin/kernel/irq/proc.c	2004-10-21 21:52:33.000000000 -0700
+++ linux.voluntary/kernel/irq/proc.c	2004-10-27 02:54:32.000000000 -0700
@@ -196,6 +196,10 @@
 #undef MAX_NAMELEN
 
 
+#ifdef CONFIG_NOTE_LATENCY
+static int note_latency_proc_init(void);
+#endif
+
 void init_irq_proc(void)
 {
 	int i;
@@ -210,5 +214,198 @@
 	 */
 	for (i = 0; i < NR_IRQS; i++)
 		register_irq_proc(i);
+
+#ifdef CONFIG_NOTE_LATENCY
+	note_latency_proc_init();
+#endif
+}
+
+
+#include <linux/seq_file.h>
+#include <linux/module.h>
+#include <asm/delay.h>
+#include <asm/timex.h>
+#include <asm/div64.h>
+
+/*
+ * Tue Oct 19 15:54:33 PDT 2004
+ * Silly code that prints out the irq-thread latencies.
+ * --billh
+ */
+
+extern
+unsigned long long cycles_2_ns(unsigned long long cyc);
+
+#define NOTE_LATENCY_HISTO_SIZE 3
+
+typedef struct {
+	u64 usec_granularity;
+	u64 n_entries;
+
+	u64 usec_lower_bounds;
+	u64 usec_upper_bounds;
+	unsigned int *vec;
+} note_latency_vec_t;
+
+note_latency_vec_t
+	note_latency_histo_vec[NOTE_LATENCY_HISTO_SIZE] =
+		{ {1,  100,  0, 0, NULL},
+		  {10, 100,  0, 0, NULL},
+		  {50, 1000, 0, 0, NULL} };
+
+unsigned int note_latency_n_events = 0;
+
+void note_latency_init(void) {
+	int i;
+	u64 frame_base = 0;
+
+	for (i = 0; i < NOTE_LATENCY_HISTO_SIZE; ++i) {
+		note_latency_vec_t *t = &note_latency_histo_vec[i];
+
+		t->vec = (unsigned int *) kmalloc(sizeof(unsigned int) * t->n_entries,  GFP_KERNEL);
+		memset(t->vec, 0, sizeof(unsigned int) * t->n_entries); /* hack */
+
+		t->usec_lower_bounds = frame_base;
+		t->usec_upper_bounds = frame_base += t->usec_granularity * t->n_entries;
+	}
+
+	printk("cpu_khz = %d", cpu_khz);
+}
+
+void note_latency_destruct(void) {
+	unsigned int i;
+
+	for (i = 0; i < NOTE_LATENCY_HISTO_SIZE; ++i) {
+		note_latency_vec_t *t = &note_latency_histo_vec[i];
+		kfree((void *) t->vec);
+		t->vec = NULL;
+	}
+}
+
+extern unsigned long notrace cycles_to_usecs(cycles_t delta);
+
+void note_latency_event(cycles_t start_event_time) {
+	unsigned int i, index;
+	note_latency_vec_t *t;
+	cycles_t event_time, s, ss;
+	u32 remainder;
+
+	t = &note_latency_histo_vec[NOTE_LATENCY_HISTO_SIZE -1];
+
+	++note_latency_n_events;
+
+/*
+	ss = get_cycles64();
+	udelay(45);
+	s = get_cycles64();
+	s -= ss;
+*/
+	s = get_cycles64() - start_event_time;
+	remainder = do_div(s, cpu_khz / 1000 +1);
+	event_time = s;
+/*
+*/
+
+//	event_time = cycles_2_ns(get_cycles64() - start_event_time); // more accurate 
+//	event_time = cycles_to_usecs(get_cycles64() - start_event_time);
+
+
+	for (i = 0; i < NOTE_LATENCY_HISTO_SIZE; ++i) {
+		note_latency_vec_t *t2 = &note_latency_histo_vec[i];
+
+		if ((t2->usec_lower_bounds <= event_time) && (event_time < t2->usec_upper_bounds)) {
+			event_time -= t2->usec_lower_bounds;
+			remainder = do_div(event_time, t2->usec_granularity);
+			index = event_time;
+			t2->vec[index] += 1;
+			goto out;
+		}
+
+	}
+
+#if 0
+//	note_latency_histo_vec[1].vec[4] += 1; /* single spike */
+
+	/* over extended values add at the end */
+	if (event_time > 100000)
+		t->vec[t->n_entries - 2] += 1;
+#endif
+	if (event_time < 0)
+		t->vec[t->n_entries - 3] += 1;
+	t->vec[t->n_entries - 1] += 1;
+out:
+
+}
+
+void note_latency_dump_histogram(struct seq_file *s) {
+	int i, j;
+	unsigned int frame_base_time = 0;
+
+	for (i = 0; i < NOTE_LATENCY_HISTO_SIZE; ++i) {
+		note_latency_vec_t *t = &note_latency_histo_vec[i];
+		unsigned int peak;
+
+		seq_printf(s, "<%lld>\n", t->usec_lower_bounds);
+
+		for (j = 0; j < t->n_entries; ++j) {
+			if ( (peak = t->vec[j]) )
+				seq_printf(s, "%lld: %d\n",
+					frame_base_time + (j * t->usec_granularity),
+					peak);
+		}
+
+		seq_printf(s, "<%lld>\n", t->usec_upper_bounds);
+//		seq_printf(s, " ----- \n");
+
+		frame_base_time += t->usec_upper_bounds;
+	}
+	seq_printf(s, "N events = %d\n", note_latency_n_events);
+	seq_printf(s, "end\n");
+}
+
+static
+int note_latency_seq_show(struct seq_file *s, void *v)
+{
+	seq_printf(s, "BEGIN IRQ-task latency histogram (10usec bins)\n");
+	note_latency_dump_histogram(s);
+	seq_printf(s, "END\n");
+
+	return 0;
+}
+
+static
+int note_latency_seq_open(struct inode *inode, struct file *file)
+{
+	single_open(file, note_latency_seq_show, NULL);
+	return 0;
+}
+
+/* Virtual file system methods */
+static
+struct file_operations latency_file_ops = {
+        .owner   = THIS_MODULE,
+        .open    = note_latency_seq_open,
+        .read    = seq_read,
+        .llseek  = seq_lseek,
+        .release = single_release
+};
+
+#define PROC_PATH_ROOT_OBJECT "irq_latency_histogram"
+
+static
+int note_latency_proc_init(void) {
+        struct proc_dir_entry
+		*proc_root_object;
+
+        proc_root_object = create_proc_entry(PROC_PATH_ROOT_OBJECT, 0, NULL);
+        if (!proc_root_object) {
+                printk (KERN_ERR "cannot create /proc/" PROC_PATH_ROOT_OBJECT "\n");
+                return -ENOMEM;
+        }
+        proc_root_object->proc_fops = &latency_file_ops;
+
+	note_latency_init();
+
+	return 0;
 }
 
diff -rwu linux.voluntary.virgin/kernel/latency.c linux.voluntary/kernel/latency.c
--- linux.voluntary.virgin/kernel/latency.c	2004-10-21 21:52:33.000000000 -0700
+++ linux.voluntary/kernel/latency.c	2004-10-21 22:37:22.000000000 -0700
@@ -62,7 +62,8 @@
 
 static DEFINE_PER_CPU(struct cpu_trace, trace);
 
-static unsigned long notrace cycles_to_usecs(cycles_t delta)
+//static
+unsigned long notrace cycles_to_usecs(cycles_t delta)
 {
 #ifdef CONFIG_X86
 	do_div(delta, cpu_khz/1000+1);
diff -rwu linux.voluntary.virgin/lib/rwsem-generic.c linux.voluntary/lib/rwsem-generic.c
--- linux.voluntary.virgin/lib/rwsem-generic.c	2004-10-21 21:52:33.000000000 -0700
+++ linux.voluntary/lib/rwsem-generic.c	2004-10-21 22:37:27.000000000 -0700
@@ -179,7 +179,7 @@
 		 */
 		if (semblk == &kernel_sem.lock)
 			continue;
-		if (semblk && __rwsem_deadlock(semblk)) {
+		if (semblk && __rwsem_deadlock(semblk)) { /* recursive checking here */
 		  	rwsem_trace_on = 0;
 			printk("BUG: circular semaphore deadlock: %s/%d is "
 				"blocked on %p, deadlocking %s/%d\n",

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 15:26                                             ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4 Rui Nuno Capela
  2004-10-27 15:30                                               ` Lee Revell
  2004-10-27 20:01                                               ` Ingo Molnar
@ 2004-10-27 20:51                                               ` Ingo Molnar
  2004-10-27 21:19                                                 ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 20:51 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> On RT-V0.4.1, xruns seems slighly reduced, but plenty enough for my
> taste.
> 
> Running jackd -R with 6 fluidsynth instances gives me 0 (zero) xruns
> on RT-U3, but more than 20 (twenty) on RT-V0.4.1, under a 5 minute
> time frame. It was 30 (thirty something) on RT-V0.4, but overall
> "feel" is about the same.

ok, i've uploaded RT-V0.4.2 which has more of the same: it fixes other
missed preemption checks. Does it make any difference to the xruns on
your UP box?

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 20:49                                                       ` Bill Huey
@ 2004-10-27 20:54                                                         ` Bill Huey
  2004-10-27 21:01                                                           ` Bill Huey
  0 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-27 20:54 UTC (permalink / raw)
  To: Bill Huey
  Cc: Ingo Molnar, K.R. Foley, linux-kernel, Lee Revell,
	Rui Nuno Capela, Mark_H_Johnson, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Andrew Morton

On Wed, Oct 27, 2004 at 01:49:35PM -0700, Bill Huey wrote:
> I've got a latency/histogram patch here, but I've been having problems
> trying to integrate it into Ingo's irq-threads and getting that simple
> subtraction returning something sensible. The basic logic works otherwise.
> 
> Maybe another pair of eyes can figure this out, since I could have missed
> something pretty simple...

It was originally mean to go in between the irq-thread wake attempt and
the actual running of the thread body itself. Somehow this is breaking
in my effort to integrate this logic into Ingo's (your) stuff. Brain
farting severely right now.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 20:54                                                         ` Bill Huey
@ 2004-10-27 21:01                                                           ` Bill Huey
  2004-10-28  7:11                                                             ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-10-27 21:01 UTC (permalink / raw)
  To: Bill Huey
  Cc: Ingo Molnar, K.R. Foley, linux-kernel, Lee Revell,
	Rui Nuno Capela, Mark_H_Johnson, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Andrew Morton

On Wed, Oct 27, 2004 at 01:54:45PM -0700, Bill Huey wrote:
> It was originally mean to go in between the irq-thread wake attempt and
> the actual running of the thread body itself. Somehow this is breaking
> in my effort to integrate this logic into Ingo's (your) stuff. Brain
> farting severely right now.

Another note, it's not meant to be a high resolution latency stats patch
as much as giving a general feel of irq latency in the system. That
information is just useful to have in general, but won't be sufficient
enough to track down specific problems in the kernel. Extending this code
to track all wake ups is beyond the original intention of these
measurements. A method like this only applies to thread of high system
priority with a near RT scheduling class or similar.

bill


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 20:51                                               ` Ingo Molnar
@ 2004-10-27 21:19                                                 ` Ingo Molnar
  2004-10-27 23:31                                                   ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-27 21:19 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese


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

> ok, i've uploaded RT-V0.4.2 which has more of the same: it fixes other
> missed preemption checks. Does it make any difference to the xruns on
> your UP box?

uploaded RT-V0.4.3 - there was a thinko in the latency tracer that
caused early boot failures.

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 19:47                                                                   ` Lee Revell
@ 2004-10-27 21:40                                                                     ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-27 21:40 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton

Lee Revell wrote:
> On Wed, 2004-10-27 at 12:43 -0500, K.R. Foley wrote:
> 
>>OH! And thanks. :)
>>
> 
> 
> Well I tried it and it does not seem to work exactly right.  This might
> be because I enabled the HPET so the RTC is not getting used.  When I
> run amlat for a few minutes I get a histogram with only 38 samples.
> Does this work for you?
> 
> Lee
> 
> 
Sorry it took a while to get back to you. Yes I did try it a little 
earlier and did seem to be getting reasonable numbers. I wouldn't want 
to publish those numbers yet because I haven't done anything with 
priorities and I was seeing some higher numbers. I don't have the HPET 
turned on myself.

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 13:03                                         ` Ingo Molnar
@ 2004-10-27 21:41                                           ` Magnus Naeslund(t)
  2004-10-28  6:55                                             ` Ingo Molnar
  2004-10-28  6:58                                             ` Ingo Molnar
  2004-10-28 14:14                                           ` K.R. Foley
  1 sibling, 2 replies; 951+ messages in thread
From: Magnus Naeslund(t) @ 2004-10-27 21:41 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

I'm testing out this patch on an debian box.
There seems to be a problem with enable_irq in the e100 driver that 
makes the network to b0rk.

What information do you need to get something useful out of this?
I saw that others have this problem, so I've got an serial console to 
the box, if you want me to do any tests, tell me how.


Regards,
Magnus


Setting up IP spoofing protection: rp_filter.
Configuring network interfaces: ifconfig/924: BUG in enable_irq at 
kernel/irq/manage.c:112
  [<c01362a0>] enable_irq+0xe4/0x12c (8)
  [<d08a44f6>] e100_up+0x119/0x224 [e100] (44)
  [<d08a5743>] e100_open+0x2c/0x84 [e100] (44)
  [<c0237dda>] dev_open+0x76/0x85 (28)
  [<c02394a8>] dev_change_flags+0x5d/0x138 (24)
  [<c0237cbd>] dev_load+0x31/0x6c (12)
  [<c027915c>] devinet_ioctl+0x5f9/0x6c6 (20)
  [<c027b1b8>] inet_ioctl+0xc7/0xd3 (104)
  [<c022ea5e>] sock_ioctl+0x19f/0x26a (24)
  [<c016c897>] sys_ioctl+0x1e8/0x249 (28)
  [<c0113eea>] do_page_fault+0x0/0x5ee (24)
  [<c0105bb3>] syscall_call+0x7/0xb (16)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: enable_irq+0x31/0x12c [<c01361ed>] / (0x0 [<00000000>])
.. entry 2: print_traces+0x14/0x47 [<c0130201>] / (0x0 [<00000000>])

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 20:09                                                           ` Andrew Morton
@ 2004-10-27 21:43                                                             ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-10-27 21:43 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Ingo Molnar, rlrevell, linux-kernel, rncbc, Mark_H_Johnson,
	bhuey, doogie, mista.tapas, tglx, xschmi00, nando

Andrew Morton wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
> 
>>>Here is a more up to date version of the rtc-debug patch:
>>
>> > 
>> > http://lkml.org/lkml/2004/9/9/307
>> > 
>> > There is still a bit of 2.4 cruft in there but it works well.  Maybe
>> > this could be included in future patches.
>>
>> the most natural point of inclusion would be Andrew's -mm tree i think
>> :-)
> 
> 
> It's 'orrid.  And iirc it breaks normal use of the RTC.
> 
It definitely changes the output of /dev/rtc if anything uses that.

kr

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 21:19                                                 ` Ingo Molnar
@ 2004-10-27 23:31                                                   ` Rui Nuno Capela
  2004-10-28  6:36                                                     ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-27 23:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
>
>> ok, i've uploaded RT-V0.4.2 which has more of the same: it fixes other
>> missed preemption checks. Does it make any difference to the xruns on
>> your UP box?
>
> uploaded RT-V0.4.3 - there was a thinko in the latency tracer that
> caused early boot failures.
>

Yes, the xrun rate has decreased, slightly. RT-V0.4.3 is now ranking under
10 per 5 min (~2/min), with jackd -R -r44100 -p128 -n2, fluidsynth x 6.

Better still, but not to par as RT-U3, under the very same conditions.

Cya.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 23:31                                                   ` Rui Nuno Capela
@ 2004-10-28  6:36                                                     ` Ingo Molnar
  2004-10-28  8:31                                                       ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-28  6:36 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> >> ok, i've uploaded RT-V0.4.2 which has more of the same: it fixes other
> >> missed preemption checks. Does it make any difference to the xruns on
> >> your UP box?
> >
> > uploaded RT-V0.4.3 - there was a thinko in the latency tracer that
> > caused early boot failures.
> >
> 
> Yes, the xrun rate has decreased, slightly. RT-V0.4.3 is now ranking
> under 10 per 5 min (~2/min), with jackd -R -r44100 -p128 -n2,
> fluidsynth x 6.
> 
> Better still, but not to par as RT-U3, under the very same conditions.

how much idle time do you have in the RT-U3 and in the RT-V0.4 tests,
compared? If it's close to 100% then make sure you have the following
debug options disabled:

 # CONFIG_DEBUG_SLAB is not set
 # CONFIG_DEBUG_PREEMPT is not set
 # CONFIG_DEBUG_SPINLOCK_SLEEP is not set
 # CONFIG_PREEMPT_TIMING is not set
 # CONFIG_RWSEM_DEADLOCK_DETECT is not set
 # CONFIG_FRAME_POINTER is not set
 # CONFIG_DEBUG_STACKOVERFLOW is not set
 # CONFIG_DEBUG_STACK_USAGE is not set
 # CONFIG_DEBUG_PAGEALLOC is not set

RWSEM_DEADLOCK, DEBUG_PREEMPT, PREEMPT_TIMING and LATENCY_TRACE are
especially expensive, so depending on the amount of kernel work done, it
can make or break the total balance of CPU time used and you could get
xruns not only due to kernel latencies but purely due to having not
enough CPU time to generate audio output. (fluidsynth is a software
audio generator?)

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 21:41                                           ` Magnus Naeslund(t)
@ 2004-10-28  6:55                                             ` Ingo Molnar
  2004-10-28  9:31                                               ` Magnus Naeslund(t)
  2004-10-28  6:58                                             ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-28  6:55 UTC (permalink / raw)
  To: Magnus Naeslund(t); +Cc: linux-kernel


* Magnus Naeslund(t) <mag@fbab.net> wrote:

> I'm testing out this patch on an debian box. There seems to be a
> problem with enable_irq in the e100 driver that makes the network to
> b0rk.

this e100 driver warning seems mostly harmless - i get it too and the
device works just fine.

> What information do you need to get something useful out of this? I
> saw that others have this problem, so I've got an serial console to
> the box, if you want me to do any tests, tell me how.

even just using it and reporting any potential breakages you get during
bootup or normal use would be very useful. I'd suggest to initially
enable all the relevant debugging options:

 CONFIG_DEBUG_PREEMPT=y
 CONFIG_PREEMPT_TIMING=y
 CONFIG_PREEMPT_TRACE=y
 CONFIG_LATENCY_TRACE=y
 CONFIG_MCOUNT=y
 CONFIG_RWSEM_DEADLOCK_DETECT=y
 CONFIG_RWSEM_MAX_OWNERS=32
 CONFIG_DEBUG_INFO=y
 CONFIG_EARLY_PRINTK=y

this will slow the kernel down but in case of problems there is a much
higher chance of getting a useful assert on the serial console and not
some silent lockup.

if things look good for normal use then a bit advanced type of testing
would be to enable the wakeup-latency tracer:

  echo 4 > /proc/sys/kernel/tracing_enabled
  echo 5 > /proc/sys/kernel/preempt_max_latency

this will measure the highest wakeup latency of highprio tasks, starting
at 5 microseconds. You'll get a short 1-line notification of the latest
latency in the syslog, and the latest trace will always be available in
/proc/latency_trace. Depending on the speed of the system, 'larger'
latencies should be reported to me. 'larger' means more than 20 usecs on
a 2 GHz box or more than 40 usecs on a 1 GHz box. (Dont worry about
reporting duplicates, i can skip them quickly.)

then if things are still looking good (i'm not betting on it though :-),
you could try various stesstests, running LTP's:

	./runalltests.sh -x 20

and things like that. If you have a stable system then it would also be
nice to try to trigger as high wakeup-latencies as possible. E.g. run a
couple of thousand tasks on it, or try to start as many mozilla
instances, or make it go into heavy swapping. I.e. if the core is ok,
explore the edges a bit. The kernel is supposed to offer very low
(wakeup-) latencies no matter what the load. [this doesnt mean your
system will necessarily feel fast - if it's running lots of tasks, even
if the highest prio one is woken up quickly, then it's gonna be slow.]

	Ingo

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

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 21:41                                           ` Magnus Naeslund(t)
  2004-10-28  6:55                                             ` Ingo Molnar
@ 2004-10-28  6:58                                             ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-28  6:58 UTC (permalink / raw)
  To: Magnus Naeslund(t); +Cc: linux-kernel


* Magnus Naeslund(t) <mag@fbab.net> wrote:

> What information do you need to get something useful out of this? I
> saw that others have this problem, so I've got an serial console to
> the box, if you want me to do any tests, tell me how.

also, if you hit problems make sure you have the latest patch, i
sometimes upload a small update with a trivial fix without announcing it
(or the announcement lags on lkml), and i upload larger changes roughly
daily. The current latest version is RT-V0.4.3.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0
  2004-10-27 21:01                                                           ` Bill Huey
@ 2004-10-28  7:11                                                             ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-28  7:11 UTC (permalink / raw)
  To: Bill Huey
  Cc: K.R. Foley, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Andrew Morton


* Bill Huey <bhuey@lnxw.com> wrote:

> On Wed, Oct 27, 2004 at 01:54:45PM -0700, Bill Huey wrote:
> > It was originally mean to go in between the irq-thread wake attempt and
> > the actual running of the thread body itself. Somehow this is breaking
> > in my effort to integrate this logic into Ingo's (your) stuff. Brain
> > farting severely right now.
> 
> Another note, it's not meant to be a high resolution latency stats
> patch as much as giving a general feel of irq latency in the system.
> That information is just useful to have in general, but won't be
> sufficient enough to track down specific problems in the kernel.
> Extending this code to track all wake ups is beyond the original
> intention of these measurements. [...]

yeah, the wakeup-tracing we have now is mostly for debugging, it doesnt
generate a histogram at the moment. But you could extend it to be that -
the trace_start_sched_wakeup() and trace_stop_sched_switched() hooks in
the latest patch are precisely that. Note the magic done there, it is
important to establish that only the _highest prio_ task's wakeup
latency counts, and the tests in those functions do just that. 
(otherwise we'd have to do nested latency tracing which is quite
elaborous. I've done it before and it's neither fun, nor truly useful.)

So i think you can put a histogram generator into check_wakeup_timing()
(without needing any outside code), the 'latency' variable established
there is precisely the latency you want to track.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28  6:36                                                     ` Ingo Molnar
@ 2004-10-28  8:31                                                       ` Rui Nuno Capela
  2004-10-28  8:56                                                         ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-28  8:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
>
> * Rui Nuno Capela wrote:
>
>> >> ok, i've uploaded RT-V0.4.2 which has more of the same: it fixes
>> >> other missed preemption checks. Does it make any difference to the
>> >> xruns on your UP box?
>> >
>> > uploaded RT-V0.4.3 - there was a thinko in the latency tracer that
>> > caused early boot failures.
>> >
>>
>> Yes, the xrun rate has decreased, slightly. RT-V0.4.3 is now ranking
>> under 10 per 5 min (~2/min), with jackd -R -r44100 -p128 -n2,
>> fluidsynth x 6.
>>
>> Better still, but not to par as RT-U3, under the very same conditions.
>
> how much idle time do you have in the RT-U3 and in the RT-V0.4 tests,
> compared? If it's close to 100% then make sure you have the following
> debug options disabled:
>
>  # CONFIG_DEBUG_SLAB is not set
>  # CONFIG_DEBUG_PREEMPT is not set
>  # CONFIG_DEBUG_SPINLOCK_SLEEP is not set
>  # CONFIG_PREEMPT_TIMING is not set
>  # CONFIG_RWSEM_DEADLOCK_DETECT is not set
>  # CONFIG_FRAME_POINTER is not set
>  # CONFIG_DEBUG_STACKOVERFLOW is not set
>  # CONFIG_DEBUG_STACK_USAGE is not set
>  # CONFIG_DEBUG_PAGEALLOC is not set
>
> RWSEM_DEADLOCK, DEBUG_PREEMPT, PREEMPT_TIMING and LATENCY_TRACE are
> especially expensive, so depending on the amount of kernel work done, it
> can make or break the total balance of CPU time used and you could get
> xruns not only due to kernel latencies but purely due to having not
> enough CPU time to generate audio output. (fluidsynth is a software
> audio generator?)
>

As far as nmeter can tell, this a rough cpu usage pattern between RT-U3
and RT-V0.4.3, during my jackd + 6*fluidsynth "benchmark" tests:

  cpu usage                    RT-U3.0    RT-V0.4.3
  ---------------------------- ---------- ---------
  system (kernel)              <10%        10%
  user                          30%        60%
  ---------------------------- ---------- ---------
  total                        <40%        70%


The following table compares the state between my RT-U3 and RT-V0.4.3
configurations, regarding only the mentioned options:

  option                       RT-U3.0    RT-V0.4.3
  ---------------------------- ---------- ---------
  CONFIG_DEBUG_SLAB              n          n
  CONFIG_DEBUG_PREEMPT           y          y
  CONFIG_DEBUG_SPINLOCK_SLEEP    n          -
  CONFIG_PREEMPT_TIMING          n          n
  CONFIG_RWSEM_DEADLOCK_DETECT   -          y
  CONFIG_FRAME_POINTER           y          y
  CONFIG_DEBUG_STACKOVERFLOW     y          y
  CONFIG_DEBUG_STACK_USAGE       n          n
  CONFIG_DEBUG_PAGEALLOC         n          n

(dash "-" means that the option is not available in the config).

As you can see, it can only be CONFIG_RWSEM_DEADLOCK_DETECT, being new in
RT-V0.4.3, that is probably affecting on RT-V0.4.3. I'll try to rebuild
and test all over without it, and see if it gets any better.

BBL
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28  8:31                                                       ` Rui Nuno Capela
@ 2004-10-28  8:56                                                         ` Ingo Molnar
  2004-10-28  9:17                                                           ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-28  8:56 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> The following table compares the state between my RT-U3 and RT-V0.4.3
> configurations, regarding only the mentioned options:
> 
>   option                       RT-U3.0    RT-V0.4.3
>   ---------------------------- ---------- ---------
>   CONFIG_DEBUG_SLAB              n          n
>   CONFIG_DEBUG_PREEMPT           y          y
>   CONFIG_DEBUG_SPINLOCK_SLEEP    n          -
>   CONFIG_PREEMPT_TIMING          n          n
>   CONFIG_RWSEM_DEADLOCK_DETECT   -          y
>   CONFIG_FRAME_POINTER           y          y
>   CONFIG_DEBUG_STACKOVERFLOW     y          y
>   CONFIG_DEBUG_STACK_USAGE       n          n
>   CONFIG_DEBUG_PAGEALLOC         n          n
> 
> (dash "-" means that the option is not available in the config).
> 
> As you can see, it can only be CONFIG_RWSEM_DEADLOCK_DETECT, being new
> in RT-V0.4.3, that is probably affecting on RT-V0.4.3. I'll try to
> rebuild and test all over without it, and see if it gets any better.

note that DEBUG_PREEMPT got more expensive in the -V kernels. I'd
suggest to disable all the 'y' ones in both the -U and -V kernel and
compare them then.

but especially the userspace overhead seems to be significantly higher
in the -V kernel so i'm not quite sure it can all be attributed to
debugging overhead. We'll see.

also, how does the context-switching rate compare between the two tests? 
This test is pretty steady when it's running, so the context-switch
rates can be directly compared, correct?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28  8:56                                                         ` Ingo Molnar
@ 2004-10-28  9:17                                                           ` Rui Nuno Capela
  2004-10-28  9:32                                                             ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-28  9:17 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
>
> * Rui Nuno Capela wrote:
>
>> The following table compares the state between my RT-U3 and RT-V0.4.3
>> configurations, regarding only the mentioned options:
>>
>>   option                       RT-U3.0    RT-V0.4.3
>>   ---------------------------- ---------- ---------
>>   CONFIG_DEBUG_SLAB              n          n
>>   CONFIG_DEBUG_PREEMPT           y          y
>>   CONFIG_DEBUG_SPINLOCK_SLEEP    n          -
>>   CONFIG_PREEMPT_TIMING          n          n
>>   CONFIG_RWSEM_DEADLOCK_DETECT   -          y
>>   CONFIG_FRAME_POINTER           y          y
>>   CONFIG_DEBUG_STACKOVERFLOW     y          y
>>   CONFIG_DEBUG_STACK_USAGE       n          n
>>   CONFIG_DEBUG_PAGEALLOC         n          n
>>
>> (dash "-" means that the option is not available in the config).
>>
>> As you can see, it can only be CONFIG_RWSEM_DEADLOCK_DETECT, being new
>> in RT-V0.4.3, that is probably affecting on RT-V0.4.3. I'll try to
>> rebuild and test all over without it, and see if it gets any better.
>
> note that DEBUG_PREEMPT got more expensive in the -V kernels. I'd
> suggest to disable all the 'y' ones in both the -U and -V kernel and
> compare them then.
>
> but especially the userspace overhead seems to be significantly higher
> in the -V kernel so i'm not quite sure it can all be attributed to
> debugging overhead. We'll see.
>
> also, how does the context-switching rate compare between the two tests?
> This test is pretty steady when it's running, so the context-switch
> rates can be directly compared, correct?
>

OK. That was it. After switching off CONFIG_RWSEM_DEADLOCK_DETECT on
RT-V0.4.3, I can say that it's now on par to RT-U3.

Later today, I will conduct some extendeded testing, where I'll able to
compare the jackd performance between vanilla, RT-U3 and RT-V0.4.3, on my
UP laptop. All kernel configurations will be stripped off from all the
debug options.

I will take note of xrun rate, jackd scheduling delay histogram, and cpu
usage. Context switch rate will be also acquainted.

Anything else?
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28  6:55                                             ` Ingo Molnar
@ 2004-10-28  9:31                                               ` Magnus Naeslund(t)
  0 siblings, 0 replies; 951+ messages in thread
From: Magnus Naeslund(t) @ 2004-10-28  9:31 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Ingo Molnar wrote:
> * Magnus Naeslund(t) <mag@fbab.net> wrote:
> 
> 
>>I'm testing out this patch on an debian box. There seems to be a
>>problem with enable_irq in the e100 driver that makes the network to
>>b0rk.
> 
> 
> this e100 driver warning seems mostly harmless - i get it too and the
> device works just fine.
> 
> 

Well, this isn't my experience.
I can't even ping another box on the same net with e100 or eepro100 
driver. I'm running a UP p4 2.4 ghz box with 2.6.9-mm1-RT-V0.4.3.

After letting it ping a while, this turns up:

NETDEV WATCHDOG: eth0: transmit timed out
ksoftirqd/0/2: BUG in enable_irq at kernel/irq/manage.c:112
  [<c01384d9>] enable_irq+0xe1/0x122 (12)
  [<d08055ab>] e100_up+0x112/0x211 [e100] (48)
  [<c0247e37>] dev_watchdog+0x0/0xb6 (36)
  [<c0247eeb>] dev_watchdog+0xb4/0xb6 (12)
  [<c0124391>] run_timer_softirq+0x1c9/0x48b (20)
  [<c0111ac0>] mcount+0x14/0x18 (32)
  [<c012018e>] ___do_softirq+0x4e/0xd6 (20)
  [<c01202a0>] _do_softirq+0x8/0x22 (8)
  [<c012066a>] ksoftirqd+0xa5/0xeb (4)
  [<c01202b8>] _do_softirq+0x20/0x22 (28)
  [<c012066a>] ksoftirqd+0xa5/0xeb (8)
  [<c013015e>] kthread+0xa1/0xce (28)
  [<c01205c5>] ksoftirqd+0x0/0xeb (20)
  [<c01300bd>] kthread+0x0/0xce (12)
  [<c0104195>] kernel_thread_helper+0x5/0xb (16)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: enable_irq+0x33/0x122 [<c013842b>] / (e100_up+0x112/0x211 
[e100] [<d08055ab>])
.. entry 2: print_traces+0x1b/0x55 [<c013243e>] / (dump_stack+0x23/0x25 
[<c0106eb8>])




Other latecy traces are:

(ksoftirqd/0/2/CPU#0): new 22 us maximum-latency critical section.
  => started at timestamp 116357664: <call_console_drivers+0x8c/0x163>
  =>   ended at timestamp 116357686: <__sched_text_start+0x30e/0x6c1>
  [<c0131d71>] sub_preempt_count+0x62/0xc5 (4)
  [<c01319e9>] check_preempt_timing+0x20b/0x2da (8)
  [<c0289ece>] __sched_text_start+0x30e/0x6c1 (8)
  [<c0106a10>] common_interrupt+0x18/0x20 (24)
  [<c013007b>] kthread_exit_files+0x14/0x56 (32)
  [<c0131d71>] sub_preempt_count+0x62/0xc5 (20)
  [<c0289ece>] __sched_text_start+0x30e/0x6c1 (8)
  [<c0289ece>] __sched_text_start+0x30e/0x6c1 (20)
  [<c028a2aa>] schedule+0x29/0xd1 (84)
  [<c0111ac0>] mcount+0x14/0x18 (8)
  [<c01206ae>] ksoftirqd+0xe9/0xeb (28)
  [<c013015e>] kthread+0xa1/0xce (28)
  [<c01205c5>] ksoftirqd+0x0/0xeb (20)
  [<c01300bd>] kthread+0x0/0xce (12)
  [<c0104195>] kernel_thread_helper+0x5/0xb (16)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __sched_text_start+0x4e/0x6c1 [<c0289c0e>] / 
(schedule+0x29/0xd1 [<c028a2aa>])
.. entry 2: print_traces+0x1b/0x55 [<c013243e>] / (dump_stack+0x23/0x25 
[<c0106eb8>])

  =>   dump-end timestamp 116461059
(bash/1156/CPU#0): new 16 us maximum-latency critical section.
  => started at timestamp 227980588: <call_console_drivers+0x8c/0x163>
  =>   ended at timestamp 227980604: <irq_exit+0x3c/0x45>
  [<c0131d71>] sub_preempt_count+0x62/0xc5 (4)
  [<c01319e9>] check_preempt_timing+0x20b/0x2da (8)
  [<c01380a1>] irq_exit+0x3c/0x45 (8)
  [<c0115f81>] try_to_wake_up+0x135/0x137 (28)
  [<c0131d71>] sub_preempt_count+0x62/0xc5 (48)
  [<c01380a1>] irq_exit+0x3c/0x45 (8)
  [<c01380a1>] irq_exit+0x3c/0x45 (20)
  [<c0108784>] do_IRQ+0x5c/0x81 (12)
  [<c0106a10>] common_interrupt+0x18/0x20 (20)
  [<c0114ab3>] do_page_fault+0x8e/0x5e7 (44)
  [<c0131d71>] sub_preempt_count+0x62/0xc5 (72)
  [<c013183a>] check_preempt_timing+0x5c/0x2da (16)
  [<c0131d71>] sub_preempt_count+0x62/0xc5 (4)
  [<c01163ff>] schedule_tail+0x37/0x8f (4)
  [<c0114a25>] do_page_fault+0x0/0x5e7 (36)
  [<c0106acd>] error_code+0x2d/0x38 (8)
  [<c011007b>] set_fixed_ranges+0x62/0xd1 (40)
  [<c0116447>] schedule_tail+0x7f/0x8f (12)
  [<c0114a25>] do_page_fault+0x0/0x5e7 (20)
  [<c0106acd>] error_code+0x2d/0x38 (8)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __do_IRQ+0x104/0x196 [<c01382a6>] / (do_IRQ+0x57/0x81 
[<c010877f>])
.. entry 2: print_traces+0x1b/0x55 [<c013243e>] / (dump_stack+0x23/0x25 
[<c0106eb8>])

  =>   dump-end timestamp 228101445

(ksoftirqd/0/2/CPU#0): new 18 us maximum-latency critical section.
  => started at timestamp 228104930: <call_console_drivers+0x8c/0x163>
  =>   ended at timestamp 228104948: <__sched_text_start+0x30e/0x6c1>
  [<c0131d71>] sub_preempt_count+0x62/0xc5 (4)
  [<c01319e9>] check_preempt_timing+0x20b/0x2da (8)
  [<c0289ece>] __sched_text_start+0x30e/0x6c1 (8)
  [<c0106a10>] common_interrupt+0x18/0x20 (24)
  [<c013007b>] kthread_exit_files+0x14/0x56 (32)
  [<c0131d71>] sub_preempt_count+0x62/0xc5 (20)
  [<c0289ece>] __sched_text_start+0x30e/0x6c1 (8)
  [<c0289ece>] __sched_text_start+0x30e/0x6c1 (20)
  [<c028a2aa>] schedule+0x29/0xd1 (84)
  [<c0111ac0>] mcount+0x14/0x18 (8)
  [<c01206ae>] ksoftirqd+0xe9/0xeb (28)
  [<c013015e>] kthread+0xa1/0xce (28)
  [<c01205c5>] ksoftirqd+0x0/0xeb (20)
  [<c01300bd>] kthread+0x0/0xce (12)
  [<c0104195>] kernel_thread_helper+0x5/0xb (16)
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: __sched_text_start+0x4e/0x6c1 [<c0289c0e>] / 
(schedule+0x29/0xd1 [<c028a2aa>])
.. entry 2: print_traces+0x1b/0x55 [<c013243e>] / (dump_stack+0x23/0x25 
[<c0106eb8>])

  =>   dump-end timestamp 228208260


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28  9:17                                                           ` Rui Nuno Capela
@ 2004-10-28  9:32                                                             ` Ingo Molnar
  2004-10-28 13:57                                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5.2 Ingo Molnar
  2004-10-28 16:33                                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4 Rui Nuno Capela
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-28  9:32 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> OK. That was it. After switching off CONFIG_RWSEM_DEADLOCK_DETECT on
> RT-V0.4.3, I can say that it's now on par to RT-U3.

great!

> Later today, I will conduct some extendeded testing, where I'll able
> to compare the jackd performance between vanilla, RT-U3 and RT-V0.4.3,
> on my UP laptop. All kernel configurations will be stripped off from
> all the debug options.
>
> I will take note of xrun rate, jackd scheduling delay histogram, and
> cpu usage. Context switch rate will be also acquainted.
> 
> Anything else?

yeah, that's good enough. I'd still suggest to first test new kernels
with all the debug options on, to make sure it's stable. For performance
comparisons turn all the debug options off.

i'd also suggest to turn the NMI watchdog off (if enabled), that can
inject a 10-20 usec latency into any critical path. For the absolute
lowest latencies i'd also suggest to turn off all the APIC options
(possible in a UP kernel only, and only if the XT-PIC setup doesnt cause
unacceptable IRQ-line sharing), the IO-APIC mask handling is a bit
expensive compared to the XT-PIC.

If you find (or suspect) larger latencies anywhere then PREEMPT_TIMING +
LATENCY_TRACE + preempt_enable=4 is the preferred variant to use. (right
now it's not possible to do wakeup-timing without LATENCY_TRACE, i'll
fix that.)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5
  2004-10-27 17:25                                             ` Michal Schmidt
@ 2004-10-28 11:57                                               ` Ingo Molnar
  2004-10-30  0:02                                                 ` Bill Huey
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-28 11:57 UTC (permalink / raw)
  To: Michal Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:

> > i've uploaded -V0.4.1 with a fix that could fix this networking
> > deadlock. Does it work any better?
> 
> Unfortunately, no. It's only slightly different:

ok. I've uploaded -RT-V0.5 which includes a different approach to
solving these netfilter related deadlocks. It can be downloaded from the 
usual place:

	http://redhat.com/~mingo/realtime-preempt/

there's a fair chance that you will still see a deadlock, so in -V0.5
i've improved the deadlock-detection infrastructure with a number of new
debugging features:

 - track the code (by EIP) that acquired the semaphore

 - track the place (by file:line) where the locking object got defined
   or initialized. Print this symbolic info out when printing locking 
   objects - this is easier to read than the hexa address alone.

 - added a global registry for all mutexes, rwsems, spinlocks and
   rwlocks, which registry is printed during the deadlock-printout. 
   (including the current holder of the lock and the place where the
   lock was acquired.)

 - print out all the locks held by the task(s) involved in any deadlock
   scenario.

 - print out a summary of all tasks in the system, whether they are
   blocked on a locking object, and if they are, on which lock.

 - the 'all locks' and 'all tasks' printout can also be triggered via
   sysrq-d or 'echo d > /proc/sysrq-trigger'.

 - turn off deadlock tracing when the first deadlock has been detected. 
   This is to get a more robust printout of a stable locking state and
   usually it's the first deadlock that matters so there's no point in
   printing out more.

 - cleaned up formatting of various existing printouts like the 
   preemption backtrace and messages from the deadlock detector.

all this info will greatly simplify the tracking down of deadlocks. 
There is no additional configuration needed to active the above
features, other than to enable CONFIG_RWSEM_DEADLOCK_DETECT. Below i've
attached a sample printout.

	Ingo


down()-ing unlocked semaphore. should succeed.
good. now down()ing locked semaphore. should deadlock.

===============================================
[ BUG: semaphore recursion deadlock detected! ]
-----------------------------------------------
already locked:  [c065eee0] {r:0,a:-1,kernel/time.c:100}
.. held by:      gettimeofday/ 3008 [f1b374c0]
... acquired at:  sys_gettimeofday+0xfa/0x3f8

-{backtrace}--------------------------------->
 [<c0241d47>] __rwsem_deadlock+0xf9/0x188 (12)
 [<c011f1eb>] sys_gettimeofday+0xfa/0x3f8 (8)
 [<c058f68e>] _down_write+0xe/0x325 (16)
 [<c011f201>] sys_gettimeofday+0x110/0x3f8 (4)
 [<c011f201>] sys_gettimeofday+0x110/0x3f8 (20)
 [<c058f7e0>] _down_write+0x160/0x325 (8)
 [<c0130903>] __mcount+0x1d/0x1f (16)
 [<c0242561>] down+0x8/0x11 (4)
 [<c011f201>] sys_gettimeofday+0x110/0x3f8 (4)
 [<c011f201>] sys_gettimeofday+0x110/0x3f8 (36)
 [<c014d641>] sys_munmap+0x42/0x4b (12)
 [<c010601d>] sysenter_past_esp+0x52/0x71 (28)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c058f8bd>] .... _down_write+0x23d/0x325
.....[<c011f201>] ..   ( <= sys_gettimeofday+0x110/0x3f8)
.. [<c0131be1>] .... print_traces+0x1b/0x5a
.....[<c0106608>] ..   ( <= dump_stack+0x23/0x25)


------------------------------
| showing all locks held by: |  (gettimeofday/3008 [f1b374c0]):
------------------------------

#001:             [c065eee0] {r:0,a:-1,kernel/time.c:100}
... acquired at:  sys_gettimeofday+0xfa/0x3f8

showing all tasks:
s            init/    1 [c2a77080] (not blocked)
s     ksoftirqd/0/    2 [c2a76850] (not blocked)
s       desched/0/    3 [c2a76020] (not blocked)
s        events/0/    4 [c2a950c0] (not blocked)
s         khelper/    5 [c2a94890] (not blocked)
s         kthread/   10 [c2a94060] (not blocked)
s          kacpid/   18 [c2ab1100] (not blocked)
s           IRQ 9/   19 [c2ab08d0] (not blocked)
s       kblockd/0/   94 [c2ab00a0] (not blocked)
s           khubd/  107 [f7cf1140] (not blocked)
s         pdflush/  330 [f7cf0910] (not blocked)
s         pdflush/  331 [f7cf00e0] (not blocked)
s           aio/0/  333 [f7d56950] (not blocked)
s         kswapd0/  332 [f7d57180] (not blocked)
s           IRQ 8/  918 [f7d56120] (not blocked)
s          IRQ 12/  931 [f7eca990] (not blocked)
s         kseriod/  925 [f7ecb1c0] (not blocked)
s           IRQ 6/  946 [f7eca160] (not blocked)
s           IRQ 5/  978 [f7f01200] (not blocked)
s          IRQ 14/  997 [f7f009d0] (not blocked)
s          IRQ 15/  999 [f7f001a0] (not blocked)
s        khpsbpkt/ 1013 [f7f51240] (not blocked)
s          IRQ 11/ 1024 [f7f50a10] (not blocked)
s     knodemgrd_0/ 1025 [f7f501e0] (not blocked)
s           IRQ 1/ 1131 [f7f91280] (not blocked)
s          IRQ 10/ 1169 [f7f90a50] (not blocked)
D       kjournald/ 1180 [f7f90220] (not blocked)
s           udevd/ 1242 [f5ec76c0] (not blocked)
s           IRQ 4/ 1615 [f610c2e0] (not blocked)
s           IRQ 3/ 1616 [f59f0a50] (not blocked)
D         syslogd/ 2503 [f5d6ad90] (not blocked)
s           klogd/ 2507 [f610d340] (not blocked)
s         portmap/ 2526 [f5ae0120] (not blocked)
s   mDNSResponder/ 2559 [f63aa420] (not blocked)
s   mDNSResponder/ 2560 [f2bc6b90] (not blocked)
s           acpid/ 2580 [f2af9340] (not blocked)
s            sshd/ 2590 [f2af82e0] (not blocked)
s         distccd/ 2619 [f610cb10] (not blocked)
s         distccd/ 2620 [f59f0220] (not blocked)
s             gpm/ 2630 [f2b6cb50] (not blocked)
s           crond/ 2640 [f2af8b10] (not blocked)
s            sshd/ 2653 [f5a59100] (not blocked)
s         distccd/ 2656 [f5ae0950] (not blocked)
s            sshd/ 2667 [f5a580a0] (not blocked)
s             xfs/ 2670 [f5ec6660] (not blocked)
s            bash/ 2672 [f2bc73c0] (not blocked)
s         anacron/ 2704 [f5ec6e90] (not blocked)
s         distccd/ 2706 [f2b6c320] (not blocked)
s             atd/ 2714 [f59f1280] (not blocked)
s   dbus-daemon-1/ 2724 [f2bc6360] (not blocked)
s cups-config-dae/ 2734 [f63aac50] (not blocked)
s          agetty/ 2748 [f5a588d0] (not blocked)
s        mingetty/ 2749 [f5d6b5c0] (not blocked)
s        mingetty/ 2750 [f63ab480] (not blocked)
s        mingetty/ 2751 [f1a73400] (not blocked)
s        mingetty/ 2752 [f1a72bd0] (not blocked)
s        mingetty/ 2753 [f2b6d380] (not blocked)
s        mingetty/ 2754 [f1a723a0] (not blocked)
s         hotplug/ 2839 [f1b36460] (not blocked)
s         hotplug/ 2856 [f14e6d90] (not blocked)
s         hotplug/ 2857 [f155d600] (not blocked)
s 10-udev.hotplug/ 2916 [f1b36c90] (not blocked)
s 10-udev.hotplug/ 2917 [f14e75c0] (not blocked)
s 10-udev.hotplug/ 2918 [f14e6560] (not blocked)
s            udev/ 2959 [f1629680] (not blocked)
s            udev/ 2965 [f1702ed0] (not blocked)
s            udev/ 2981 [f17d5780] (not blocked)
s            udev/ 2987 [f11240a0] (not blocked)
D    gettimeofday/ 3008 [f1b374c0] (not blocked)

---------------------------
| showing all locks held: |
---------------------------

#001:             [c07f809c] {r:0,a:-1,drivers/ide/ide.c:228}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x8b/0x15c

#002:             [c07f7bb4] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#003:             [c07f7e0c] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#004:             [c07f8890] {r:0,a:-1,drivers/ide/ide.c:228}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x8b/0x15c

#005:             [c07f83a8] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#006:             [c07f8600] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#007:             [c07f9084] {r:0,a:-1,drivers/ide/ide.c:228}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x8b/0x15c

#008:             [c07f8b9c] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#009:             [c07f8df4] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#010:             [c07f9878] {r:0,a:-1,drivers/ide/ide.c:228}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x8b/0x15c

#011:             [c07f9390] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#012:             [c07f95e8] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#013:             [c07fa06c] {r:0,a:-1,drivers/ide/ide.c:228}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x8b/0x15c

#014:             [c07f9b84] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#015:             [c07f9ddc] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#016:             [c07fa860] {r:0,a:-1,drivers/ide/ide.c:228}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x8b/0x15c

#017:             [c07fa378] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#018:             [c07fa5d0] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#019:             [c07fb054] {r:0,a:-1,drivers/ide/ide.c:228}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x8b/0x15c

#020:             [c07fab6c] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#021:             [c07fadc4] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#022:             [c07fb848] {r:0,a:-1,drivers/ide/ide.c:228}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x8b/0x15c

#023:             [c07fb360] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#024:             [c07fb5b8] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#025:             [c07fc03c] {r:0,a:-1,drivers/ide/ide.c:228}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x8b/0x15c

#026:             [c07fbb54] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#027:             [c07fbdac] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#028:             [c07fc830] {r:0,a:-1,drivers/ide/ide.c:228}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x8b/0x15c

#029:             [c07fc348] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#030:             [c07fc5a0] {r:0,a:-1,drivers/ide/ide.c:252}
.. held by:              init/    1 [c2a77080]
... acquired at:  init_hwif_data+0x14b/0x15c

#031:             [c06a8f40] {r:0,a:-1,drivers/ieee1394/nodemgr.c:111}
.. held by:       knodemgrd_0/ 1025 [f7f501e0]
... acquired at:  nodemgr_host_thread+0x89/0x186

#032:             [f2b7cfcc] {r:0,a:-1,drivers/char/tty_io.c:2641}
.. held by:          mingetty/ 2749 [f5d6b5c0]
... acquired at:  read_chan+0x471/0x7a2

#033:             [f1ba4fcc] {r:0,a:-1,drivers/char/tty_io.c:2641}
.. held by:          mingetty/ 2751 [f1a73400]
... acquired at:  read_chan+0x471/0x7a2

#034:             [f157efcc] {r:0,a:-1,drivers/char/tty_io.c:2641}
.. held by:          mingetty/ 2754 [f1a723a0]
... acquired at:  read_chan+0x471/0x7a2

#035:             [f1722fcc] {r:0,a:-1,drivers/char/tty_io.c:2641}
.. held by:          mingetty/ 2752 [f1a72bd0]
... acquired at:  read_chan+0x471/0x7a2

#036:             [f10dafcc] {r:0,a:-1,drivers/char/tty_io.c:2641}
.. held by:          mingetty/ 2753 [f2b6d380]
... acquired at:  read_chan+0x471/0x7a2

#037:             [f150efcc] {r:0,a:-1,drivers/char/tty_io.c:2641}
.. held by:          mingetty/ 2750 [f63ab480]
... acquired at:  read_chan+0x471/0x7a2

#038:             [f1a92fcc] {r:0,a:-1,drivers/char/tty_io.c:2641}
.. held by:            agetty/ 2748 [f5a588d0]
... acquired at:  read_chan+0x471/0x7a2

#039:             [f2a11ba4] {r:0,a:-1,fs/inode.c:198}
.. held by:           syslogd/ 2503 [f5d6ad90]
... acquired at:  sys_fsync+0x56/0xb7

#040:             [c065eee0] {r:0,a:-1,kernel/time.c:100}
.. held by:      gettimeofday/ 3008 [f1b374c0]
... acquired at:  sys_gettimeofday+0xfa/0x3f8

#041:             [c0748a00] {r:0,a:-1,kernel/fork.c:64}
.. held by:      gettimeofday/ 3008 [f1b374c0]
... acquired at:  show_all_locks+0x30/0x148
=============================================


^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5.2
  2004-10-28  9:32                                                             ` Ingo Molnar
@ 2004-10-28 13:57                                                               ` Ingo Molnar
  2004-10-28 14:10                                                                 ` DaMouse
  2004-10-28 16:33                                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4 Rui Nuno Capela
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-28 13:57 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Ingo Molnar <mingo@elte.hu> wrote:

> (right now it's not possible to do wakeup-timing without
> LATENCY_TRACE, i'll fix that.)

i've fixed this in -RT-V0.5.2. Also, the trace_enabled=4 method is
deprecated now and the new mechanism is to use:

    /proc/sys/kernel/preempt_wakeup_timing

this flag is default-enabled. So starting at -RT-V0.5.2 to activate
wakeup timing it's enough to enable PREEMPT_TIMING and reset the max
after bootup:

    echo 0 > /proc/sys/kernel/preempt_max_latency

this will switch back to critical-section timing/tracing:

    echo 0 > /proc/sys/kernel/preempt_wakeup_timing

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5.2
  2004-10-28 13:57                                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5.2 Ingo Molnar
@ 2004-10-28 14:10                                                                 ` DaMouse
  2004-10-28 14:18                                                                   ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: DaMouse @ 2004-10-28 14:10 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

On Thu, 28 Oct 2004 15:57:06 +0200, Ingo Molnar <mingo@elte.hu> wrote:
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > (right now it's not possible to do wakeup-timing without
> > LATENCY_TRACE, i'll fix that.)
> 
> i've fixed this in -RT-V0.5.2. Also, the trace_enabled=4 method is
> deprecated now and the new mechanism is to use:
> 
>     /proc/sys/kernel/preempt_wakeup_timing
> 
> this flag is default-enabled. So starting at -RT-V0.5.2 to activate
> wakeup timing it's enough to enable PREEMPT_TIMING and reset the max
> after bootup:
> 
>     echo 0 > /proc/sys/kernel/preempt_max_latency
> 
> this will switch back to critical-section timing/tracing:
> 
>     echo 0 > /proc/sys/kernel/preempt_wakeup_timing

What kind of benchmarking tools about from the inkernel timing/tracing
do you use for testing REALTIME_PREEMPT?

> 
>         Ingo

-DaMouse

-- 
I know I broke SOMETHING but its their fault for not fixing it before me

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-27 13:03                                         ` Ingo Molnar
  2004-10-27 21:41                                           ` Magnus Naeslund(t)
@ 2004-10-28 14:14                                           ` K.R. Foley
  2004-10-28 14:20                                             ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-10-28 14:14 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
> i have released the -V0.4 Real-Time Preemption patch, which can be
> downloaded from:
> 
>    http://redhat.com/~mingo/realtime-preempt/
> 

I have been having problems on my UP system at home with all of the more 
recent patches (since U10.X). Some would boot and then the networking 
was severely busted (slowdowns, hangs, etc.), some would not even boot. 
V0.4.3 was of the no boot variety. Just for grins I disabled kudzu, and 
the thing boots fine with no networking or other problems. This very 
well may have been a fluke, but I have successfully booted this kernel 
twice now. It did hang on a reboot at the point when it should have been 
doing the actual reboot and I had to press the button. I didn't have 
time this morning to turn kudzu back on to see if was just a fluke that 
it didn't boot the first time. Not sure what, if anything, this means, 
but V0.4.3 is running very nicely on my UP system with no lag or 
noticeable problems.

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5.2
  2004-10-28 14:10                                                                 ` DaMouse
@ 2004-10-28 14:18                                                                   ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-28 14:18 UTC (permalink / raw)
  To: DaMouse; +Cc: LKML


* DaMouse <damouse@gmail.com> wrote:

> >     echo 0 > /proc/sys/kernel/preempt_max_latency
> > 
> > this will switch back to critical-section timing/tracing:
> > 
> >     echo 0 > /proc/sys/kernel/preempt_wakeup_timing
> 
> What kind of benchmarking tools about from the inkernel timing/tracing
> do you use for testing REALTIME_PREEMPT?

amlat's 'realfeel' with the patch i posted yesterday.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28 14:14                                           ` K.R. Foley
@ 2004-10-28 14:20                                             ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-28 14:20 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese


* K.R. Foley <kr@cybsft.com> wrote:

> I have been having problems on my UP system at home with all of the
> more recent patches (since U10.X). Some would boot and then the
> networking was severely busted (slowdowns, hangs, etc.), some would
> not even boot.  V0.4.3 was of the no boot variety. Just for grins I
> disabled kudzu, and the thing boots fine with no networking or other
> problems. This very well may have been a fluke, but I have
> successfully booted this kernel twice now. It did hang on a reboot at
> the point when it should have been doing the actual reboot and I had
> to press the button. I didn't have time this morning to turn kudzu
> back on to see if was just a fluke that it didn't boot the first time.
> Not sure what, if anything, this means, but V0.4.3 is running very
> nicely on my UP system with no lag or noticeable problems.

just to make sure - could try to run kudzu manually after bootup and
observe what happens? Do you have a udev based system? I recently
corrupted my udev database via a crash and had to remove the
/dev/.udev.tdb file and had to regenerate it via 'udevstart'. (be
careful doing that though, it might mess up your system.) The symtoms
were a hung kudzu - while in reality it 'hung' because udev and udevinfo
processes looped in userspace forever. Weirdly, the stock Fedora kernel
didnt hang in this same phase, so there might still be a
PREEMPT_REALTIME bug here.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28  9:32                                                             ` Ingo Molnar
  2004-10-28 13:57                                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5.2 Ingo Molnar
@ 2004-10-28 16:33                                                               ` Rui Nuno Capela
  2004-10-28 19:16                                                                 ` Ingo Molnar
  2004-10-29 14:31                                                                 ` Florian Schmidt
  1 sibling, 2 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-28 16:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
>
> * Rui Nuno Capela wrote:
>
>> OK. That was it. After switching off CONFIG_RWSEM_DEADLOCK_DETECT on
>> RT-V0.4.3, I can say that it's now on par to RT-U3.
>
> great!
>
>> Later today, I will conduct some extendeded testing, where I'll able
>> to compare the jackd performance between vanilla, RT-U3 and RT-V0.4.3,
>> on my UP laptop. All kernel configurations will be stripped off from
>> all the debug options.
>>
>> I will take note of xrun rate, jackd scheduling delay histogram, and
>> cpu usage. Context switch rate will be also acquainted.
>>
>> Anything else?
>
> yeah, that's good enough.


OK. Here are my early consolidated results. Feel free to comment.

                                    2.6.9     RT-U3   RT-V0.4.3
                                  --------- --------- ---------
  XRUN Rate . . . . . . . . . . .     424         8         4    /hour
  Delay Rate (>spare time)  . . .     496         0         0    /hour
  Delay Rate (>1000 usecs)  . . .     940         8         4    /hour
  Maximum Delay . . . . . . . . .    6904       921       721    usecs
  Maximum Process Cycle . . . . .    1449      1469      1590    usecs
  Average DSP CPU Load  . . . . .      38        39        40    %
  Average Context-Switch Rate . .    7480      8929      9726    /sec

Note: all tests were carried out running jackd -v -dalsa -dhw:0 -r44100
-p128 -n2 -S -P, loaded with 9 (nine) fluidsynth instances, on a
P4@2.533Ghz laptop, against the onboard sound device (snd-ali5451).

On the RT kernels only, the following optimizations were issued:

   chrt --pid --fifo 90 2                (pidof "ksoftirqd/0" = 2)
   chrt --pid --fifo 60 `pidof "IRQ 5"`  (snd-ali5451)

Take care.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28 16:33                                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4 Rui Nuno Capela
@ 2004-10-28 19:16                                                                 ` Ingo Molnar
  2004-10-28 23:49                                                                   ` Rui Nuno Capela
  2004-10-29 14:31                                                                 ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-28 19:16 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> OK. Here are my early consolidated results. Feel free to comment.
> 
>                                     2.6.9     RT-U3   RT-V0.4.3
>                                   --------- --------- ---------
>   XRUN Rate . . . . . . . . . . .     424         8         4    /hour
>   Delay Rate (>spare time)  . . .     496         0         0    /hour
>   Delay Rate (>1000 usecs)  . . .     940         8         4    /hour
>   Maximum Delay . . . . . . . . .    6904       921       721    usecs
>   Maximum Process Cycle . . . . .    1449      1469      1590    usecs
>   Average DSP CPU Load  . . . . .      38        39        40    %
>   Average Context-Switch Rate . .    7480      8929      9726    /sec

looks pretty good, doesnt it?

how is the 'maximum delay' calculated? Could you put in a tracing hook
into jackd whenever such a ~720 usecs maximum is hit? I'd _love_ to see 
how such a latency path looks like, it seems a bit long.

It should be a relatively simple hack to jackd. Firstly, download the 
-V0.5.3 patch and enable LATENCY_TRACE, then do:

	echo 2 > /proc/sys/kernel/trace_enabled

this activates the 'application-triggered kernel tracer' functionality. 

No tracing happens by default, but tracing starts if the application
executes this function:

	gettimeofday(0,1);

and tracing stops if the application does:

	gettimeofday(0,0);

whenever the app does this (0,0) call the trace gets saved and you can
retrieve it from /proc/latency_trace where you can retrieve it. There is
no combination of these parameters that can break the kernel, so it's a
100% safe tracing facility. You can 'ignore' a latency [e.g. if it's not
a maximum] by simply not doing the (0,0) call. The next (0,1) call done
will override the previous, already running trace.

[stupid function but this combination of the syscall parameters is not
used otherwise so the latency tracer hijacks it.]

i dont know how Jackd does things, but i'd suggest to enable tracing the
first time possible when getting an interrupt - in theory this should
happen as soon as the wakeup-latency-tracer says - i.e. at most in like
30 usecs. The bulk of the remaining 700 usecs will be spent in jackd, 
and you can trace those 700 usecs.

or if you would be willing to do a little bit of ALSA hacking, you could
add this to the ALSA interrupt handler:

	#include <linux/syscalls.h>

	...
	sys_gettimeofday(0, 1);

[the attached patch implements this for ali5451.]

and do the gettimeofday(0,0) in jackd [if the latency measured there is
a new maximum]! This way tracing is turned on within the kernel IRQ
handler (i.e. as soon as possible) and turned off within ALSA. This will
enable us to see an even more complete latency path.

NOTE: there can only be one trace active at a time. So if there can be
multiple channels active at a time then this user-triggered tracer might
be less useful. Do these channels have any priority? Or if multiple
channels are necessary then you could modify the patch to only do the
(0,1) call for say channel #0:

	if (channel == 0)
		sys_gettimeofday(0, 1);

in this case the trace-off-save (0,0) call in Jackd must also only do
this for channel 0 processing! (or whichever channel you find the most
interesting.)

also, i looked at the sound/pci/ali5451/ali5451.c driver code and it has
one weird piece of code on line 988:

	udelay(100);

that adds a 100 usecs latency to the main path, for no good reason! It
also spends that time burning CPU time, delaying other processing. Could 
you add an IRQs/sec measurement too if possible, so that we can compare 
the IRQ rates of various kernels?

Also, i'd suggest to simply remove that line (or apply the attached
patch) - does the driver still work fine with that?

plus i've also got questions about how Jackd interfaces with ALSA: does
it use SIGIO, or some direct driver ioctl? If SIGIO is used then how is
it done precisely - is an 'RT' queued signal used or ordinary SIGIO? 
Also, how is the 'channel' information established upon getting a SIGIO,
is it in the siginfo structure?

	Ingo

--- linux/sound/pci/ali5451/ali5451.c.orig
+++ linux/sound/pci/ali5451/ali5451.c
@@ -33,6 +33,7 @@
 #include <linux/pci.h>
 #include <linux/slab.h>
 #include <linux/moduleparam.h>
+#include <linux/syscalls.h>
 #include <sound/core.h>
 #include <sound/pcm.h>
 #include <sound/info.h>
@@ -985,11 +986,11 @@ static void snd_ali_update_ptr(ali_t *co
 	pvoice = &codec->synth.voices[channel];
 	runtime = pvoice->substream->runtime;
 
-	udelay(100);
 	spin_lock(&codec->reg_lock);
 
 	if (pvoice->pcm && pvoice->substream) {
 		/* pcm interrupt */
+		sys_gettimeofday((void *)0, (void *)1); // start the tracer
 #ifdef ALI_DEBUG
 		outb((u8)(pvoice->number), ALI_REG(codec, ALI_GC_CIR));
 		temp = inw(ALI_REG(codec, ALI_CSO_ALPHA_FMS + 2));

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28 19:16                                                                 ` Ingo Molnar
@ 2004-10-28 23:49                                                                   ` Rui Nuno Capela
  2004-10-29  0:07                                                                     ` Lee Revell
  2004-10-29  7:30                                                                     ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-28 23:49 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
>
> * Rui Nuno Capela wrote:
>
>> OK. Here are my early consolidated results. Feel free to comment.
>>
>>                                     2.6.9     RT-U3   RT-V0.4.3
>>                                   --------- --------- ---------
>>   XRUN Rate . . . . . . . . . . .     424         8         4    /hour
>>   Delay Rate (>spare time)  . . .     496         0         0    /hour
>>   Delay Rate (>1000 usecs)  . . .     940         8         4    /hour
>>   Maximum Delay . . . . . . . . .    6904       921       721    usecs
>>   Maximum Process Cycle . . . . .    1449      1469      1590    usecs
>>   Average DSP CPU Load  . . . . .      38        39        40    %
>>   Average Context-Switch Rate . .    7480      8929      9726    /sec
>
> looks pretty good, doesnt it?
>

Yes indeed :)


> how is the 'maximum delay' calculated? Could you put in a tracing hook
> into jackd whenever such a ~720 usecs maximum is hit? I'd _love_ to see
> how such a latency path looks like, it seems a bit long.
>

That 'maximum delay' is collected on each jackd process cycle. AFAICS, it
is the figure of a scheduling delay, as measured by jackd as the time
interval between interrupt and effective jackd process handler (re)entry.

Please note that I'm not a JACK developer. I'm just a regular user
with ancient coding skills ;) I do however subscribe to the jackit-devel
maillist. And the author of qjackctl, if that matters...

For reading this 'maximum delay' I am actually using a custom patch
against jack-0.99.7cvs, being a Lee Revell's original.


> It should be a relatively simple hack to jackd. Firstly, download the
> -V0.5.3 patch and enable LATENCY_TRACE, then do:
>
>         echo 2 > /proc/sys/kernel/trace_enabled
>
> this activates the 'application-triggered kernel tracer' functionality.
>
> No tracing happens by default, but tracing starts if the application
> executes this function:
>
>         gettimeofday(0,1);
>
> and tracing stops if the application does:
>
>         gettimeofday(0,0);
>
> whenever the app does this (0,0) call the trace gets saved and you can
> retrieve it from /proc/latency_trace where you can retrieve it. There is
> no combination of these parameters that can break the kernel, so it's a
> 100% safe tracing facility. You can 'ignore' a latency [e.g. if it's not
> a maximum] by simply not doing the (0,0) call. The next (0,1) call done
> will override the previous, already running trace.
>
> [stupid function but this combination of the syscall parameters is not
> used otherwise so the latency tracer hijacks it.]
>
> i dont know how Jackd does things, but i'd suggest to enable tracing the
> first time possible when getting an interrupt - in theory this should
> happen as soon as the wakeup-latency-tracer says - i.e. at most in like
> 30 usecs. The bulk of the remaining 700 usecs will be spent in jackd,
> and you can trace those 700 usecs.
>
> or if you would be willing to do a little bit of ALSA hacking, you could
> add this to the ALSA interrupt handler:
>
>         #include <linux/syscalls.h>
>
>         ...
>         sys_gettimeofday(0, 1);
>
> [the attached patch implements this for ali5451.]
>
> and do the gettimeofday(0,0) in jackd [if the latency measured there is
> a new maximum]! This way tracing is turned on within the kernel IRQ
> handler (i.e. as soon as possible) and turned off within ALSA. This will
> enable us to see an even more complete latency path.
>
> NOTE: there can only be one trace active at a time. So if there can be
> multiple channels active at a time then this user-triggered tracer might
> be less useful. Do these channels have any priority? Or if multiple
> channels are necessary then you could modify the patch to only do the
> (0,1) call for say channel #0:
>
>         if (channel == 0)
>                 sys_gettimeofday(0, 1);
>
> in this case the trace-off-save (0,0) call in Jackd must also only do
> this for channel 0 processing! (or whichever channel you find the most
> interesting.)
>

Ouch. This is a bit too much to digest in so little time :) I'll try to
re-read this from cache, erm... tomorrow ;)

BTW, this means that I have to re-enable LATENCY_TIMING back again? Notice
that all my results were taken with a production configuration, that is,
with all debug options now set to off (OK, I think I've left the
stack-overflow on, but that was the only one).

OTOH, this latency timing has been troublesome on either of my setups,
recently. But I'll give it another try...


> also, i looked at the sound/pci/ali5451/ali5451.c driver code and it has
> one weird piece of code on line 988:
>
>         udelay(100);
>
> that adds a 100 usecs latency to the main path, for no good reason! It
> also spends that time burning CPU time, delaying other processing. Could
> you add an IRQs/sec measurement too if possible, so that we can compare
> the IRQ rates of various kernels?
>

Yes, I can add interrupts/sec measuring with nmeter. Neat utility indeed,
thanks to Denis Vlasenko.


> Also, i'd suggest to simply remove that line (or apply the attached
> patch) - does the driver still work fine with that?
>

Now that you call, I remember to hack that very same line, some time go,
but couldn't get no better than a udelay(33). Removing that line just
ended in some kind of malfunction, but can't remember what exactly. One
thing's for sure, sound didn't came out of it :-/


> plus i've also got questions about how Jackd interfaces with ALSA: does
> it use SIGIO, or some direct driver ioctl? If SIGIO is used then how is
> it done precisely - is an 'RT' queued signal used or ordinary SIGIO?
> Also, how is the 'channel' information established upon getting a SIGIO,
> is it in the siginfo structure?
>

Now that's really pushing me over. Any ALSA-JACK developers around here to
comment?

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28 23:49                                                                   ` Rui Nuno Capela
@ 2004-10-29  0:07                                                                     ` Lee Revell
  2004-10-29  7:30                                                                     ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-29  0:07 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, linux-kernel, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

On Fri, 2004-10-29 at 00:49 +0100, Rui Nuno Capela wrote:
> > plus i've also got questions about how Jackd interfaces with ALSA: does
> > it use SIGIO, or some direct driver ioctl? If SIGIO is used then how is
> > it done precisely - is an 'RT' queued signal used or ordinary SIGIO?
> > Also, how is the 'channel' information established upon getting a SIGIO,
> > is it in the siginfo structure?
> >
> 
> Now that's really pushing me over. Any ALSA-JACK developers around here to
> comment?
> 

I think it uses a direct driver ioctl to open the device.  Then jack
uses mmap to talk to the audio device. 

Anyway I forwarded your question to Paul Davis, the author of JACK, and
cc'ed jackit-devel.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28 23:49                                                                   ` Rui Nuno Capela
  2004-10-29  0:07                                                                     ` Lee Revell
@ 2004-10-29  7:30                                                                     ` Ingo Molnar
  2004-10-29 15:00                                                                       ` Rui Nuno Capela
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-29  7:30 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> BTW, this means that I have to re-enable LATENCY_TIMING back again?

yes. I'd suggest to start with the simplest setup - i.e. just one
fluidsynth instance running. I suspect 3-4 instances later on will be
enough to trigger some xruns or at least some of the bigger delays.

you possibly wont be able to debug the 'production' setup, but that's
not an issue because the latencies should show up under just 2-3
instances running as well.

> > Also, i'd suggest to simply remove that line (or apply the attached
> > patch) - does the driver still work fine with that?
> >
> 
> Now that you call, I remember to hack that very same line, some time
> go, but couldn't get no better than a udelay(33). Removing that line
> just ended in some kind of malfunction, but can't remember what
> exactly. One thing's for sure, sound didn't came out of it :-/

ugh. Possibly some sort of interaction with the firmware and/or an
outright driver bug?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-29 14:31                                                                 ` Florian Schmidt
@ 2004-10-29 14:25                                                                   ` Ingo Molnar
  2004-10-29 15:09                                                                     ` Florian Schmidt
  2004-10-29 14:53                                                                   ` Florian Schmidt
  2004-10-30  3:09                                                                   ` Lee Revell
  2 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-10-29 14:25 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> Here's some setup info:
> 
> ksoftirqd/0:
> mango:~# chrt -p 2
> pid 2's current scheduling policy: SCHED_FIFO
> pid 2's current scheduling priority: 99

dont do this ... ksoftirqd can spend alot of time processing various
stuff and it should not be relevant to the audio path. It should be
SCHED_OTHER.

> Hmm, it seems i haven't disabled all debugging. This is from dmesg:
> 
> BUG: atomic counter underflow at:
>  [<c010649e>] dump_stack+0x1e/0x20 (20)
>  [<c025f319>] qdisc_destroy+0xd9/0xe0 (28)

this is automatic and doesnt introduce alot of overhead (unless the
printout happens while you are testing latencies). You can remove the
WARN_ON from include/asm-i386/atomic.h.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-28 16:33                                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4 Rui Nuno Capela
  2004-10-28 19:16                                                                 ` Ingo Molnar
@ 2004-10-29 14:31                                                                 ` Florian Schmidt
  2004-10-29 14:25                                                                   ` Ingo Molnar
                                                                                     ` (2 more replies)
  1 sibling, 3 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-29 14:31 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese

[-- Attachment #1: Type: text/plain, Size: 6302 bytes --]

On Thu, 28 Oct 2004 17:33:50 +0100 (WEST)
"Rui Nuno Capela" <rncbc@rncbc.org> wrote:

> OK. Here are my early consolidated results. Feel free to comment.
> 
>                                     2.6.9     RT-U3   RT-V0.4.3
>                                   --------- --------- ---------
>   XRUN Rate . . . . . . . . . . .     424         8         4    /hour
>   Delay Rate (>spare time)  . . .     496         0         0    /hour
>   Delay Rate (>1000 usecs)  . . .     940         8         4    /hour
>   Maximum Delay . . . . . . . . .    6904       921       721    usecs
>   Maximum Process Cycle . . . . .    1449      1469      1590    usecs
>   Average DSP CPU Load  . . . . .      38        39        40    %
>   Average Context-Switch Rate . .    7480      8929      9726    /sec
> 
> Note: all tests were carried out running jackd -v -dalsa -dhw:0 -r44100
> -p128 -n2 -S -P, loaded with 9 (nine) fluidsynth instances, on a
> P4@2.533Ghz laptop, against the onboard sound device (snd-ali5451).
> 
> On the RT kernels only, the following optimizations were issued:
> 
>    chrt --pid --fifo 90 2                (pidof "ksoftirqd/0" = 2)
>    chrt --pid --fifo 60 `pidof "IRQ 5"`  (snd-ali5451)
> 
> Take care.

hi,

i tried a V0.5.2 with PREEMPT_REALTIME and all debugging off (config
attached). I cannot reproduce your results. I have experienced around 30
xruns in 10 minutes. And big ones, too (> 5ms). I don't know exactly what
kind of load triggers them. Here's a bit of qjackctl message window (btw:
jackd was idle, no clients connected, except for qjackctl):

**** alsa_pcm: xrun of at least 0.594 msecs
**** alsa_pcm: xrun of at least 0.037 msecs
16:20:44.832 XRUN callback (2).
16:20:44.840 XRUN callback (3).
**** alsa_pcm: xrun of at least 0.024 msecs
**** alsa_pcm: xrun of at least 3.682 msecs
16:22:59.834 XRUN callback (4).
16:22:59.839 XRUN callback (5).
**** alsa_pcm: xrun of at least 0.016 msecs
**** alsa_pcm: xrun of at least 3.460 msecs
16:23:03.513 XRUN callback (6).
**** alsa_pcm: xrun of at least 2.028 msecs
16:23:03.869 XRUN callback (7).
**** alsa_pcm: xrun of at least 7.061 msecs
**** alsa_pcm: xrun of at least 4.510 msecs
16:23:03.894 XRUN callback (8).
16:23:03.895 XRUN callback (9).
**** alsa_pcm: xrun of at least 0.428 msecs
**** alsa_pcm: xrun of at least 0.157 msecs
16:23:54.546 XRUN callback (10).
16:23:54.547 XRUN callback (11).
16:23:54.549 XRUN callback (12).
**** alsa_pcm: xrun of at least 1.507 msecs
16:25:49.194 XRUN callback (13).
subgraph starting at qjackctl-1013 timed out (subgraph_wait_fd=14, status = 0, state = Triggered)
**** alsa_pcm: xrun of at least 1.534 msecs
16:28:23.530 XRUN callback (14).
**** alsa_pcm: xrun of at least 0.222 msecs
**** alsa_pcm: xrun of at least 2.674 msecs
**** alsa_pcm: xrun of at least 3.904 msecs
16:28:26.790 XRUN callback (15).
16:28:26.794 XRUN callback (16).
16:28:26.795 XRUN callback (17).
**** alsa_pcm: xrun of at least 0.701 msecs

Here's some setup info:

ksoftirqd/0:
mango:~# chrt -p 2
pid 2's current scheduling policy: SCHED_FIFO
pid 2's current scheduling priority: 99

snd-cs46xx:
mango:~# chrt -p `pidof "IRQ 3"`
pid 118's current scheduling policy: SCHED_FIFO
pid 118's current scheduling priority: 90

mango:~# pidof jackd
1014
mango:~# chrt -p 1014
pid 1014's current scheduling policy: SCHED_OTHER
pid 1014's current scheduling priority: 0
mango:~# chrt -p 1015
pid 1015's current scheduling policy: SCHED_OTHER
pid 1015's current scheduling priority: 0
mango:~# chrt -p 1016
pid 1016's current scheduling policy: SCHED_FIFO
pid 1016's current scheduling priority: 70
mango:~# chrt -p 1017
pid 1017's current scheduling policy: SCHED_FIFO
pid 1017's current scheduling priority: 60

Hmm, it seems i haven't disabled all debugging. This is from dmesg:

BUG: atomic counter underflow at:
 [<c010649e>] dump_stack+0x1e/0x20 (20)
 [<c025f319>] qdisc_destroy+0xd9/0xe0 (28)
 [<c025f506>] dev_shutdown+0x36/0xb0 (28)
 [<c0254679>] unregister_netdevice+0x129/0x2b0 (40)
 [<c0221919>] unregister_netdev+0x19/0x40 (16)
 [<f0902134>] ppp_shutdown_interface+0x64/0xd0 [ppp_generic] (36)
 [<f08fe0a6>] ppp_release+0x86/0x90 [ppp_generic] (16)
 [<c0155c3f>] __fput+0x14f/0x170 (36)
 [<c0154457>] filp_close+0x57/0x80 (28)
 [<c01544f0>] sys_close+0x70/0x90 (32)
 [<c0105ecf>] syscall_call+0x7/0xb (-8124)

Here's some context from syslog:

Oct 29 15:04:01 mango pppd[324]: LCP: timeout sending Config-Requests 
Oct 29 15:04:01 mango pppd[324]: Connection terminated.
Oct 29 15:04:01 mango kernel: BUG: atomic counter underflow at:
Oct 29 15:04:01 mango kernel:  [valid_stack_ptr+46/96] dump_stack+0x1e/0x20 (20)
Oct 29 15:04:01 mango kernel:  [unregister_netdevice+553/672] qdisc_destroy+0xd9/0xe0 (28)
Oct 29 15:04:01 mango kernel:  [ethtool_op_get_tso+6/32] dev_shutdown+0x36/0xb0 (28)
Oct 29 15:04:01 mango kernel:  [__sock_create+185/704] unregister_netdevice+0x129/0x2b0 (40)
Oct 29 15:04:01 mango kernel:  [blk_wait_queue_drained+25/304] unregister_netdev+0x19/0x40 (16)
Oct 29 15:04:01 mango kernel:  [pg0+810783028/1069765632] ppp_shutdown_interface+0x64/0xd0 [ppp_generic] (36)
Oct 29 15:04:01 mango kernel:  [pg0+810766502/1069765632] ppp_release+0x86/0x90 [ppp_generic] (16)
Oct 29 15:04:01 mango kernel:  [shmem_writepage+463/480] __fput+0x14f/0x170 (36)
Oct 29 15:04:01 mango kernel:  [sys_swapon+1591/2080] filp_close+0x57/0x80 (28)
Oct 29 15:04:01 mango kernel:  [sys_swapon+1744/2080] sys_close+0x70/0x90 (32)
Oct 29 15:04:01 mango kernel:  [do_notify_resume+15/76] syscall_call+0x7/0xb (-8124)
Oct 29 15:04:10 mango pppoe[326]: Timeout waiting for PADS packets
Oct 29 15:04:31 mango pppd[324]: Serial connection established.
Oct 29 15:04:31 mango pppd[324]: Using interface ppp0
Oct 29 15:04:31 mango pppd[324]: Connect: ppp0 <--> /dev/pts/0
Oct 29 15:04:47 mango pppoe[822]: PADS: Service-Name: ''
Oct 29 15:04:47 mango pppoe[822]: PPP session is 2133
Oct 29 15:04:47 mango pppd[324]: CHAP authentication succeeded
Oct 29 15:04:48 mango pppd[324]: Cannot determine ethernet address for proxy ARP
Oct 29 15:04:48 mango pppd[324]: local  IP address 213.23.197.161
Oct 29 15:04:48 mango pppd[324]: remote IP address 145.253.4.148
Oct 29 15:04:48 mango pppd[324]: primary   DNS address 195.50.140.250
Oct 29 15:04:48 mango pppd[324]: secondary DNS address 145.253.2.11

flo

[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 26261 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-mm1-RT-V0.5.6
# Fri Oct 29 13:09:33 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION="-rt"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=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

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# 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_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_GENERIC=y
CONFIG_GENERIC_SEMAPHORES=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_X86_USE_3DNOW=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
CONFIG_PREEMPT_BKL=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_KERN_PHYS_OFFSET=1
# 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 is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD 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=m
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_TASKFILE_IO is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 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 is not set
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 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=y
# 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_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_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_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

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT 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_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM 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_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_STUB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
# CONFIG_SENSORS_LM87 is not set
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY 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_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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=m
CONFIG_RXRPC=m

#
# 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=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_PREEMPT_TIMING is not set
# CONFIG_RWSEM_DEADLOCK_DETECT is not set
# CONFIG_DEBUG_INFO is not set
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
# CONFIG_SECURITY_SELINUX is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-29 14:31                                                                 ` Florian Schmidt
  2004-10-29 14:25                                                                   ` Ingo Molnar
@ 2004-10-29 14:53                                                                   ` Florian Schmidt
  2004-10-30  3:09                                                                   ` Lee Revell
  2 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-29 14:53 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Rui Nuno Capela, Ingo Molnar, linux-kernel, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese

On Fri, 29 Oct 2004 16:31:35 +0200
Florian Schmidt <mista.tapas@gmx.net> wrote:

> i tried a V0.5.2 with PREEMPT_REALTIME and all debugging off (config
> attached). I cannot reproduce your results. I have experienced around 30
> xruns in 10 minutes. And big ones, too (> 5ms). I don't know exactly what
> kind of load triggers them. Here's a bit of qjackctl message window (btw:
> jackd was idle, no clients connected, except for qjackctl):
> 
[snip]

i forgot to mention though that i do use jack in full duplex mode and with a
periodsize of 64:

/usr/bin/jackd -R -P60 -t20000 -dalsa -dhw:0 -r48000 -p64 -n2

The results are thus not really comparable. Anyways, 7ms xruns still
shouldn't happen (with the older VP patches i could run 32 frames full
duplex for hours w/o xruns).

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-29  7:30                                                                     ` Ingo Molnar
@ 2004-10-29 15:00                                                                       ` Rui Nuno Capela
  2004-10-29 17:57                                                                         ` Lee Revell
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-10-29 15:00 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
>
> * Rui Nuno Capela wrote:
>
>> BTW, this means that I have to re-enable LATENCY_TIMING back again?
>
> yes. I'd suggest to start with the simplest setup - i.e. just one
> fluidsynth instance running. I suspect 3-4 instances later on will be
> enough to trigger some xruns or at least some of the bigger delays.
>
> you possibly wont be able to debug the 'production' setup, but that's
> not an issue because the latencies should show up under just 2-3
> instances running as well.
>
>> > Also, i'd suggest to simply remove that line (or apply the attached
>> > patch) - does the driver still work fine with that?
>> >
>>
>> Now that you call, I remember to hack that very same line, some time
>> go, but couldn't get no better than a udelay(33). Removing that line
>> just ended in some kind of malfunction, but can't remember what
>> exactly. One thing's for sure, sound didn't came out of it :-/
>
> ugh. Possibly some sort of interaction with the firmware and/or an
> outright driver bug?
>

Just confirmed that, by removing that udelay(100) line on ali5451.c, the
result is crappy sound (worst than normally is :) and most relevant to the
subject, I get a nasty jackd XRUN storm, without even blinking an eye.
Useless.

Regarding my test results, maybe this is just a distraction. I was just
comparing the kernels, not the hardware, jackd or the ali5451 alsa driver,
which were kept as constants along the evaluation.

In fact, those tests were only about to confirm, by numbers on-the-field,
that RT-V0 is on par to RT-U3. Don't bother to compare it to your own
setup and/or hardware. These are the kind of things that YMMCV = Your
Mileage Certainly Varies :)

For example, in my own case, if those tests are done with ACPI disabled
(yes, with acpi=off), this laptop of mine just skews the results
completely: vanilla 2.6.9 gets better results, while the RT ones go
slumber. Go figure ;)

OK. I'm really running out of time now. Family's calling for the weekend.

On the next few days I'll take the latency_trace route, as Ingo proposed,
patching ali5451 and jackd to issue a sys_gettimeofday(0, 0) and
gettimeofday(0, 1) trace on/off instrumentation respectively, while using
a proper RT-V0.5.x kernel patch line (or newer).

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-29 14:25                                                                   ` Ingo Molnar
@ 2004-10-29 15:09                                                                     ` Florian Schmidt
  0 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-10-29 15:09 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese

On Fri, 29 Oct 2004 16:25:38 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> > ksoftirqd/0:
> > mango:~# chrt -p 2
> > pid 2's current scheduling policy: SCHED_FIFO
> > pid 2's current scheduling priority: 99
> 
> dont do this ... ksoftirqd can spend alot of time processing various
> stuff and it should not be relevant to the audio path. It should be
> SCHED_OTHER.

ah ok, i was wondering about this.. i saw it in rui's setup [SCHED_FIFO with
high prio]. Doesn't seem to make a difference though on first sight. still
xruns plenty above 1ms. 

playback only or rmmod'ing the network adapter driver or using the dummy
soundcard driver instead of snd-cs46xx doesn't make a difference either.

after rmmoding the network card driver i saw:

sis900 0000:00:03.0: Device was removed without properly calling
pci_disable_device(). This may need fixing.

in m dmesg. rmmod'ing snd-cs46xx gives me:

Sound Fusion CS46xx 0000:00:0f.0: Device was removed without properly
calling pci_disable_device(). This may need fixing.

too, so maybe i have already hit a BUG in the kernel and this screwed up all
further test results.

Will build a kernel with debugging stuff to see what's up. I'll also build a
VP only version to see if i still get these pci_disable_device() messages
with a "more vanilla" kernel ;)

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-29 15:00                                                                       ` Rui Nuno Capela
@ 2004-10-29 17:57                                                                         ` Lee Revell
  0 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-10-29 17:57 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, linux-kernel, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

On Fri, 2004-10-29 at 16:00 +0100, Rui Nuno Capela wrote:
> For example, in my own case, if those tests are done with ACPI disabled
> (yes, with acpi=off), this laptop of mine just skews the results
> completely: vanilla 2.6.9 gets better results, while the RT ones go
> slumber. Go figure ;)

I suspect that your laptop uses SMM traps to talk to the battery.  That
could certainly explain the 700 us xruns, because SMM disables all
interrupts.  This was covered recently in another thread.  According to
Alan Cox most laptops work this way.

Has anyone been able to reproduce the problem on a desktop system?

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5
  2004-10-28 11:57                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 Ingo Molnar
@ 2004-10-30  0:02                                                 ` Bill Huey
  2004-10-30 11:46                                                   ` Ingo Molnar
  2004-11-02  8:56                                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems) Bill Huey
  0 siblings, 2 replies; 951+ messages in thread
From: Bill Huey @ 2004-10-30  0:02 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Michal Schmidt, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Thomas Gleixner, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

On Thu, Oct 28, 2004 at 01:57:19PM +0200, Ingo Molnar wrote: > 
> * Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:
> 
> > > i've uploaded -V0.4.1 with a fix that could fix this networking
> > > deadlock. Does it work any better?
> > 
> > Unfortunately, no. It's only slightly different:
> 
> ok. I've uploaded -RT-V0.5 which includes a different approach to
> solving these netfilter related deadlocks. It can be downloaded from the 
> usual place:

This is in -V5.14

bill



[-- Attachment #2: t --]
[-- Type: application/x-troff, Size: 16924 bytes --]

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-29 14:31                                                                 ` Florian Schmidt
  2004-10-29 14:25                                                                   ` Ingo Molnar
  2004-10-29 14:53                                                                   ` Florian Schmidt
@ 2004-10-30  3:09                                                                   ` Lee Revell
  2004-10-30  3:22                                                                     ` Joe
  2 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-10-30  3:09 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Rui Nuno Capela, Ingo Molnar, linux-kernel, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese

On Fri, 2004-10-29 at 16:31 +0200, Florian Schmidt wrote:
> i tried a V0.5.2 with PREEMPT_REALTIME and all debugging off (config
> attached). I cannot reproduce your results. I have experienced around 30
> xruns in 10 minutes. And big ones, too (> 5ms). I don't know exactly what
> kind of load triggers them. Here's a bit of qjackctl message window (btw:
> jackd was idle, no clients connected, except for qjackctl):
> 

I am seeing the same behavior, about 30 xruns in 10 minutes.  It seems
to be triggered by display activity, among other things.  This cannot be
a jackd issue, because with an earlier version (T3) I can run for 24
hours without a single xrun.

There has to be a bug somewhere in the RT preempt patch.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
  2004-10-30  3:09                                                                   ` Lee Revell
@ 2004-10-30  3:22                                                                     ` Joe
  0 siblings, 0 replies; 951+ messages in thread
From: Joe @ 2004-10-30  3:22 UTC (permalink / raw)
  To: Lee Revell
  Cc: Florian Schmidt, Rui Nuno Capela, Ingo Molnar, linux-kernel,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese

On Fri, 29 Oct 2004 23:09:24 -0400, Lee Revell <rlrevell@joe-job.com> wrote:
> On Fri, 2004-10-29 at 16:31 +0200, Florian Schmidt wrote:
> > i tried a V0.5.2 with PREEMPT_REALTIME and all debugging off (config
> > attached). I cannot reproduce your results. I have experienced around 30
> > xruns in 10 minutes. And big ones, too (> 5ms). I don't know exactly what
> > kind of load triggers them. Here's a bit of qjackctl message window (btw:
> > jackd was idle, no clients connected, except for qjackctl):
> >
> 
> I am seeing the same behavior, about 30 xruns in 10 minutes.  It seems
> to be triggered by display activity, among other things.  This cannot be
> a jackd issue, because with an earlier version (T3) I can run for 24
> hours without a single xrun.
> 
> There has to be a bug somewhere in the RT preempt patch.
> 
> Lee

There is, this has been a well-known issue with many versions of
real-time voluntary preemption, which is also a main reason as to why
I avoid it, voluntary preemption performs flawlessly however RT has
been horrendous.  Hopefully the bugs will get smoothed out.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5
  2004-10-30  0:02                                                 ` Bill Huey
@ 2004-10-30 11:46                                                   ` Ingo Molnar
  2004-11-02  8:56                                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems) Bill Huey
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-10-30 11:46 UTC (permalink / raw)
  To: Bill Huey
  Cc: Michal Schmidt, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Bill Huey <bhuey@lnxw.com> wrote:

> On Thu, Oct 28, 2004 at 01:57:19PM +0200, Ingo Molnar wrote: > 
> > * Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:
> > 
> > > > i've uploaded -V0.4.1 with a fix that could fix this networking
> > > > deadlock. Does it work any better?
> > > 
> > > Unfortunately, no. It's only slightly different:
> > 
> > ok. I've uploaded -RT-V0.5 which includes a different approach to
> > solving these netfilter related deadlocks. It can be downloaded from the 
> > usual place:
> 
> This is in -V5.14

thanks - excellent trace - i hopefully fixed this in -V0.5.16, freshly
uploaded. This also made me notice an upstream buglet.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems)
  2004-10-30  0:02                                                 ` Bill Huey
  2004-10-30 11:46                                                   ` Ingo Molnar
@ 2004-11-02  8:56                                                   ` Bill Huey
  2004-11-02  9:37                                                     ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-11-02  8:56 UTC (permalink / raw)
  To: Bill Huey
  Cc: Ingo Molnar, Michal Schmidt, linux-kernel, Lee Revell,
	Rui Nuno Capela, Mark_H_Johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Thomas Gleixner, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese

[-- Attachment #1: Type: text/plain, Size: 141 bytes --]

On Fri, Oct 29, 2004 at 05:02:34PM -0700, Bill Huey wrote:
> This is in -V5.14

[nasty networking crash trace]

Didn't fix it all...

bill



[-- Attachment #2: t --]
[-- Type: application/x-troff, Size: 7868 bytes --]

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems)
  2004-11-02  8:56                                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems) Bill Huey
@ 2004-11-02  9:37                                                     ` Ingo Molnar
  2004-11-02 11:08                                                       ` Bill Huey
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-02  9:37 UTC (permalink / raw)
  To: Bill Huey
  Cc: Michal Schmidt, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Bill Huey <bhuey@lnxw.com> wrote:

> On Fri, Oct 29, 2004 at 05:02:34PM -0700, Bill Huey wrote:
> > This is in -V5.14
> 
> [nasty networking crash trace]
> 
> Didn't fix it all...

thanks for the trace - i've uploaded -V0.6.6 to the usual place:

    http://redhat.com/~mingo/realtime-preempt/

which attempts to fix this particular deadlock.

other changes in -V0.6.6:

 - increased debuggability by turning deadlock detection on for ordinary
   Linux semaphores and rwsems. I suspect that some of the recently
   reported hangs were semaphore related deadlocks. Those who see hangs 
   please re-try with -V0.6.6 and deadlock detection turned on, does it
   produce a usable deadlock printout?

 - show_all_locks() build bug fix from Daniel Walker.

 - another debuggability feature: deadlock tracing stops after the 
   first dump and the kernel tries to continue (we tried to do this
   before but it wasnt complete). Sometimes the deadlock is in fact some
   'interesting' use of Linux semaphores and the system will not
   really deadlock. The dump we can use to fix up that interesting use
   of semaphores, and the system wont crash.

 - crash fix: the dump_own_stack() code was buggered - removed it. The 
   stock kernel does pretty good stackdumping by itself, all that was
   needed to activate it was to set CONFIG_FRAME_POINTERS.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems)
  2004-11-02  9:37                                                     ` Ingo Molnar
@ 2004-11-02 11:08                                                       ` Bill Huey
  2004-11-02 11:45                                                         ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-11-02 11:08 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, Michal Schmidt, linux-kernel, Lee Revell,
	Rui Nuno Capela, Mark_H_Johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Thomas Gleixner, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese

On Tue, Nov 02, 2004 at 10:37:58AM +0100, Ingo Molnar wrote:
> * Bill Huey <bhuey@lnxw.com> wrote:
> > [nasty networking crash trace]
...
> which attempts to fix this particular deadlock.

getting closer...

http:590 BUG: lock held at task exit time!
 [c03f9e84] {r:0,a:-1,kernel_sem.lock}
 .. held by:              http/  590 [dc0508a0, 121]
 ... acquired at:  __schedule+0x3ac/0x850


bill


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems)
  2004-11-02 11:08                                                       ` Bill Huey
@ 2004-11-02 11:45                                                         ` Ingo Molnar
  2004-11-02 12:02                                                           ` Ingo Molnar
                                                                             ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-02 11:45 UTC (permalink / raw)
  To: Bill Huey
  Cc: Michal Schmidt, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Bill Huey <bhuey@lnxw.com> wrote:

> On Tue, Nov 02, 2004 at 10:37:58AM +0100, Ingo Molnar wrote:
> > * Bill Huey <bhuey@lnxw.com> wrote:
> > > [nasty networking crash trace]
> ...
> > which attempts to fix this particular deadlock.
> 
> getting closer...
> 
> http:590 BUG: lock held at task exit time!
>  [c03f9e84] {r:0,a:-1,kernel_sem.lock}
>  .. held by:              http/  590 [dc0508a0, 121]
>  ... acquired at:  __schedule+0x3ac/0x850

hm. Something called do_exit() with the BKL held which is a no-no. Do
you have a stacktrace, is this sys_exit() or some other code calling
do_exit()?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems)
  2004-11-02 11:45                                                         ` Ingo Molnar
@ 2004-11-02 12:02                                                           ` Ingo Molnar
  2004-11-02 17:34                                                             ` Karsten Wiese
  2004-11-02 13:35                                                           ` Ingo Molnar
  2004-11-02 22:08                                                           ` Bill Huey
  2 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-02 12:02 UTC (permalink / raw)
  To: Bill Huey
  Cc: Michal Schmidt, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Ingo Molnar <mingo@elte.hu> wrote:

> > http:590 BUG: lock held at task exit time!
> >  [c03f9e84] {r:0,a:-1,kernel_sem.lock}
> >  .. held by:              http/  590 [dc0508a0, 121]
> >  ... acquired at:  __schedule+0x3ac/0x850
> 
> hm. Something called do_exit() with the BKL held which is a no-no. Do
> you have a stacktrace, is this sys_exit() or some other code calling
> do_exit()?

i've uploaded -V0.6.7 with a bug fixed in the new priority code
(affecting RT tasks and probably causing some of the deadlocks reported
while running Jackd or other RT apps). I also fixed another networking
deadlock.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems)
  2004-11-02 11:45                                                         ` Ingo Molnar
  2004-11-02 12:02                                                           ` Ingo Molnar
@ 2004-11-02 13:35                                                           ` Ingo Molnar
  2004-11-02 22:08                                                           ` Bill Huey
  2 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-02 13:35 UTC (permalink / raw)
  To: Bill Huey
  Cc: Michal Schmidt, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Karsten Wiese


* Ingo Molnar <mingo@elte.hu> wrote:

> > getting closer...
> > 
> > http:590 BUG: lock held at task exit time!
> >  [c03f9e84] {r:0,a:-1,kernel_sem.lock}
> >  .. held by:              http/  590 [dc0508a0, 121]
> >  ... acquired at:  __schedule+0x3ac/0x850
> 
> hm. Something called do_exit() with the BKL held which is a no-no. Do
> you have a stacktrace, is this sys_exit() or some other code calling
> do_exit()?

ok, Thomas reported a similar one too, which comes from the NFS code. 
Does the patch below fix the warning?

	Ingo

--- linux/kernel/module.c.orig
+++ linux/kernel/module.c
@@ -35,6 +35,7 @@
 #include <linux/notifier.h>
 #include <linux/stop_machine.h>
 #include <linux/device.h>
+#include <linux/smp_lock.h>
 #include <asm/uaccess.h>
 #include <asm/semaphore.h>
 #include <asm/cacheflush.h>
@@ -97,6 +98,11 @@ static inline int strong_try_module_get(
 void __module_put_and_exit(struct module *mod, long code)
 {
 	module_put(mod);
+	/*
+	 * Release the kernel lock if held:
+	 */
+	while (current->lock_depth != -1)
+		unlock_kernel();
 	do_exit(code);
 }
 EXPORT_SYMBOL(__module_put_and_exit);

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems)
  2004-11-02 12:02                                                           ` Ingo Molnar
@ 2004-11-02 17:34                                                             ` Karsten Wiese
  0 siblings, 0 replies; 951+ messages in thread
From: Karsten Wiese @ 2004-11-02 17:34 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, Michal Schmidt, linux-kernel, Lee Revell,
	Rui Nuno Capela, Mark_H_Johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Thomas Gleixner, Fernando Pablo Lopez-Lezcano

Am Dienstag 02 November 2004 13:02 schrieb Ingo Molnar:
> * Ingo Molnar <mingo@elte.hu> wrote:
> > > http:590 BUG: lock held at task exit time!
> > >  [c03f9e84] {r:0,a:-1,kernel_sem.lock}
> > >  .. held by:              http/  590 [dc0508a0, 121]
> > >  ... acquired at:  __schedule+0x3ac/0x850
> >
> > hm. Something called do_exit() with the BKL held which is a no-no. Do
> > you have a stacktrace, is this sys_exit() or some other code calling
> > do_exit()?
>
> i've uploaded -V0.6.7 with a bug fixed in the new priority code
> (affecting RT tasks and probably causing some of the deadlocks reported
> while running Jackd or other RT apps). I also fixed another networking
> deadlock.
>
Hi

This showed via netconsole when shutting down V0.6.7 (maybe already fixed in 
V0.6.8?):
>>>>>> some noise while in runlevel 5, just for context:
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
loop: loaded (max 8 devices)
>>>>>> Here or...
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be 
trying access hardware directly.
>>>>>> ...here the shutdown takes over
usbcore: deregistering driver snd-usb-usx2y
ALSA /home/ka/kernel/2.6/linux-2.6.9-mm1-RT-V0.6.7/sound/usb/usbmidi.c:154: 
urb status -108
ALSA /home/ka/kernel/2.6/linux-2.6.9-mm1-RT-V0.6.7/sound/usb/usbmidi.c:139: 
usb_submit_urb: -90
VIA 82xx Audio 0000:00:07.5: Device was removed without properly calling 
pci_disable_device(). This may need fixing.
>>>>>> (I think there was nothing mounted via nfs, so) this looks odd to me:
nfsd:2468 BUG: lock held at task exit time!
 [c032d2e4] {r:0,a:-1,kernel_sem.lock}
.. held by:              nfsd/ 2468 [ce1a3750, 116]
... acquired at:  __sched_text_start+0x36b/0x6d0
nfsd/2468: BUG in __up_write 
at /home/ka/kernel/2.6/linux-2.6.9-mm1-RT-V0.6.7/lib/rwsem-generic.c:1058
BUG: sleeping function called from invalid context nfsd(2468) 
at /home/ka/kernel/2.6/linux-2.6.9-mm1-RT-V0.6.7/kernel/mutex.c:30
in_atomic():1 [00000003], irqs_disabled():0
 [<c0107923>] dump_stack+0x23/0x30 (20)
 [<c011a5aa>] __might_sleep+0xca/0xe0 (36)
 [<c0134b89>] __mutex_lock+0x39/0x60 (24)
 [<c0134bcd>] _mutex_lock+0x1d/0x30 (16)
 [<c01494d5>] kmem_cache_alloc+0x45/0x110 (32)
 [<c0277388>] alloc_skb+0x28/0xf0 (32)
 [<c02894e6>] find_skb+0x36/0xb0 (24)
 [<c0289671>] netpoll_send_udp+0x41/0x2b0 (48)
 [<d08d106a>] write_msg+0x6a/0x120 [netconsole] (52)
 [<c011de6e>] __call_console_drivers+0x6e/0x70 (32)
 [<c011dfa6>] call_console_drivers+0xb6/0x160 (40)
 [<c011e3c1>] release_console_sem+0x71/0x110 (36)
 [<c011e260>] vprintk+0x110/0x180 (36)
 [<c011e13d>] printk+0x1d/0x30 (16)
 [<c01bb9d6>] __up_write+0x186/0x540 (68)
 [<c01bc798>] up+0x78/0xd0 (36)
 [<c02dcc46>] __sched_text_start+0x606/0x6d0 (84)
 [<c0120852>] do_exit+0x2d2/0x560 (40)
 [<c01381a1>] __module_put_and_exit+0x51/0x70 (16)
 [<d0929574>] nfsd+0x2d4/0x3b0 [nfsd] (72)
 [<c0105325>] kernel_thread_helper+0x5/0x10 (836747284)
---------------------------
| preempt count: 00000004 ]
| 4-level deep critical section nesting:
----------------------------------------
.. [<c02dc68e>] .... __sched_text_start+0x4e/0x6d0
.....[<c0120852>] ..   ( <= do_exit+0x2d2/0x560)
.. [<c01bc743>] .... up+0x23/0xd0
.....[<c02dcc46>] ..   ( <= __sched_text_start+0x606/0x6d0)
.. [<c01bbd04>] .... __up_write+0x4b4/0x540
.....[<c01bc798>] ..   ( <= up+0x78/0xd0)
.. [<c01368ad>] .... print_traces+0x1d/0x60
.....[<c0107923>] ..   ( <= dump_stack+0x23/0x30)

 [<c0107923>] dump_stack+0x23/0x30 (20)
 [<c01bb9db>] __up_write+0x18b/0x540 (68)
 [<c01bc798>] up+0x78/0xd0 (36)
 [<c02dcc46>] __sched_text_start+0x606/0x6d0 (84)
 [<c0120852>] do_exit+0x2d2/0x560 (40)
 [<c01381a1>] __module_put_and_exit+0x51/0x70 (16)
 [<d0929574>] nfsd+0x2d4/0x3b0 [nfsd] (72)
 [<c0105325>] kernel_thread_helper+0x5/0x10 (836747284)
---------------------------
| preempt count: 00000004 ]
| 4-level deep critical section nesting:
----------------------------------------
.. [<c02dc68e>] .... __sched_text_start+0x4e/0x6d0
.....[<c0120852>] ..   ( <= do_exit+0x2d2/0x560)
.. [<c01bc743>] .... up+0x23/0xd0
.....[<c02dcc46>] ..   ( <= __sched_text_start+0x606/0x6d0)
.. [<c01bbd04>] .... __up_write+0x4b4/0x540
.....[<c01bc798>] ..   ( <= up+0x78/0xd0)
.. [<c01368ad>] .... print_traces+0x1d/0x60
.....[<c0107923>] ..   ( <= dump_stack+0x23/0x30)

nfsd: last server has exited
nfsd: unexporting all filesystems
<<<<<<

Best,
Karsten

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems)
  2004-11-02 11:45                                                         ` Ingo Molnar
  2004-11-02 12:02                                                           ` Ingo Molnar
  2004-11-02 13:35                                                           ` Ingo Molnar
@ 2004-11-02 22:08                                                           ` Bill Huey
  2 siblings, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-11-02 22:08 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, Michal Schmidt, linux-kernel, Lee Revell,
	Rui Nuno Capela, Mark_H_Johnson, K.R. Foley, Adam Heath,
	Florian Schmidt, Thomas Gleixner, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

On Tue, Nov 02, 2004 at 12:45:22PM +0100, Ingo Molnar wrote:
> * Bill Huey <bhuey@lnxw.com> wrote:
> > getting closer...
> > 
> > http:590 BUG: lock held at task exit time!
> >  [c03f9e84] {r:0,a:-1,kernel_sem.lock}
> >  .. held by:              http/  590 [dc0508a0, 121]
> >  ... acquired at:  __schedule+0x3ac/0x850
> 
> hm. Something called do_exit() with the BKL held which is a no-no. Do
> you have a stacktrace, is this sys_exit() or some other code calling
> do_exit()?

Attached:

bill


[-- Attachment #2: t --]
[-- Type: application/x-troff, Size: 1190 bytes --]

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-10-27  0:15                                       ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Ingo Molnar
                                                           ` (4 preceding siblings ...)
  2004-10-27 13:03                                         ` Ingo Molnar
@ 2004-11-03 10:58                                         ` Ingo Molnar
  2004-11-03 13:44                                           ` Lorenzo Allegrucci
                                                             ` (4 more replies)
  5 siblings, 5 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-03 10:58 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	K.R. Foley


i have released the -V0.7.1 Real-Time Preemption patch, which can be
downloaded from:

    http://redhat.com/~mingo/realtime-preempt/

this release is mainly a merge of -V0.6.9 to 2.6.10-rc2-mm2.

I havent done a proper changelog for a couple of days so here is a list
of bigger changes since -V0.4:

 - implemented a first version of the priority inheritance handling and
   priority inversion avoidance logic. This feature, after some initial
   stability problems, solved the jackd and rtc_wakeup latencies that
   were introduced by the ultra-finegrained locking in the -V series.

   (the -T/U series had a coarser locking scheme triggered much lower
   levels of priority inversion scenarios. The locking in the -V series
   was clearly the tipping point.)

   The new PI code covers all synchronization objects in Linux (on
   PREEMPT_REALTIME): spinlocks, rwlocks, semaphores and rwsems. 
   Feedback on the design of this code would be welcome, and patches as
   well, if you have a better scheme. The code is pretty modular so feel 
   free to experiment with alternative schemes.

 - completely reworked the debugging framework. All lock types
   (spinlocks, rwlocks, semaphores and rwsems) are now tracked, both
   their symbolic name and their place of acquire are traced and printed
   out upon detection of a deadlock. More and better information is
   printed upon a deadlock. Got rid of the 'semaphore owners array' in
   debugging mode, this reduces the footprint of semaphores quite
   significantly and speeds up deadlock detection.

 - got rid of the separate 'counted semaphores' implementation, it was
   too intrusive. Made the core 'generic semaphores' implementation
   compatible with vanilla Linux counted semaphore semantics. This also
   enabled the unrolling of the completion-handling cleanups which,
   while being very nice, were getting intrusive as well.

 - countless build and driver related reports/fixes from lots of people

 - more latency breaks in the remaining critical sections. A
   particularly important one was the irqs-off latency bugfix from
   Thomas Gleixner.

 - sped up the i8259 PIC and the PIT timer hardirq handling routines -
   these are now in the path of the longest latency.

 - cleaned up IRQ and signal preemption - there were missed
   check-rescheds and possibilities for IRQ recursion.

 - made ALSA's ioctl()s not use the BKL - this fixes more jackd
   latencies.

to create a -V0.7.1 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm2/2.6.10-rc1-mm2.bz2
   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm2-V0.7.1

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-11-03 10:58                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 Ingo Molnar
@ 2004-11-03 13:44                                           ` Lorenzo Allegrucci
  2004-11-03 13:46                                             ` Ingo Molnar
  2004-11-03 19:33                                           ` john cooper
                                                             ` (3 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: Lorenzo Allegrucci @ 2004-11-03 13:44 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Wednesday 03 November 2004 11:58, Ingo Molnar wrote:
> 
> i have released the -V0.7.1 Real-Time Preemption patch, which can be
> downloaded from:
> 
>     http://redhat.com/~mingo/realtime-preempt/
> 
> this release is mainly a merge of -V0.6.9 to 2.6.10-rc2-mm2.

  AS      arch/i386/lib/checksum.o
  CC      arch/i386/lib/dec_and_lock.o
  CC      arch/i386/lib/delay.o
  AS      arch/i386/lib/getuser.o
  CC      arch/i386/lib/memcpy.o
  CC      arch/i386/lib/mmx.o
  CC      arch/i386/lib/strstr.o
  CC      arch/i386/lib/usercopy.o
  AR      arch/i386/lib/lib.a
  GEN     .version
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/mounts.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
net/built-in.o(.text+0x1887f): In function `netpoll_setup':
: undefined reference to `rcu_read_lock_up_read'
net/built-in.o(.text+0x188ed): In function `netpoll_setup':
: undefined reference to `rcu_read_lock_up_read'
make: *** [.tmp_vmlinux1] Error 1

CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y

-- 
I route therefore you are

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-11-03 13:44                                           ` Lorenzo Allegrucci
@ 2004-11-03 13:46                                             ` Ingo Molnar
  2004-11-03 17:53                                               ` Lorenzo Allegrucci
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-03 13:46 UTC (permalink / raw)
  To: Lorenzo Allegrucci; +Cc: linux-kernel


* Lorenzo Allegrucci <l_allegrucci@yahoo.it> wrote:

>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> net/built-in.o(.text+0x1887f): In function `netpoll_setup':
> : undefined reference to `rcu_read_lock_up_read'
> net/built-in.o(.text+0x188ed): In function `netpoll_setup':
> : undefined reference to `rcu_read_lock_up_read'
> make: *** [.tmp_vmlinux1] Error 1

fixed in -V0.7.3.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-11-03 13:46                                             ` Ingo Molnar
@ 2004-11-03 17:53                                               ` Lorenzo Allegrucci
  2004-11-03 20:41                                                 ` Lorenzo Allegrucci
  0 siblings, 1 reply; 951+ messages in thread
From: Lorenzo Allegrucci @ 2004-11-03 17:53 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Wednesday 03 November 2004 14:46, Ingo Molnar wrote:
> 
> * Lorenzo Allegrucci <l_allegrucci@yahoo.it> wrote:
> 
> >   LD      init/built-in.o
> >   LD      .tmp_vmlinux1
> > net/built-in.o(.text+0x1887f): In function `netpoll_setup':
> > : undefined reference to `rcu_read_lock_up_read'
> > net/built-in.o(.text+0x188ed): In function `netpoll_setup':
> > : undefined reference to `rcu_read_lock_up_read'
> > make: *** [.tmp_vmlinux1] Error 1
> 
> fixed in -V0.7.3.

I've just tried V0.7.3 but my PS/2 mouse and keyboard don't work.
No message from the kernel.  I attach my .config

-- 
I route therefore you are

[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 8427 bytes --]

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-11-03 10:58                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 Ingo Molnar
  2004-11-03 13:44                                           ` Lorenzo Allegrucci
@ 2004-11-03 19:33                                           ` john cooper
  2004-11-03 23:03                                           ` Magnus Naeslund(t)
                                                             ` (2 subsequent siblings)
  4 siblings, 0 replies; 951+ messages in thread
From: john cooper @ 2004-11-03 19:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, john cooper

Ingo Molnar wrote:

>    The new PI code covers all synchronization objects in Linux (on
>    PREEMPT_REALTIME): spinlocks, rwlocks, semaphores and rwsems. 
>    Feedback on the design of this code would be welcome, and patches as
>    well, if you have a better scheme. The code is pretty modular so feel 
>    free to experiment with alternative schemes.

I didn't see closure being performed of a possible blocked-owner
dependency chain, but only promotion of the immediate owner.  It
is possible for a mutex owner to itself be blocked on another mutex
requiring promotion of the latter mutex owner(s).

-- 
john.cooper@timesys.com

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-11-03 17:53                                               ` Lorenzo Allegrucci
@ 2004-11-03 20:41                                                 ` Lorenzo Allegrucci
  2004-11-03 20:43                                                   ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Lorenzo Allegrucci @ 2004-11-03 20:41 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Wednesday 03 November 2004 18:53, Lorenzo Allegrucci wrote:
> On Wednesday 03 November 2004 14:46, Ingo Molnar wrote:
> > 
> > * Lorenzo Allegrucci <l_allegrucci@yahoo.it> wrote:
> > 
> > >   LD      init/built-in.o
> > >   LD      .tmp_vmlinux1
> > > net/built-in.o(.text+0x1887f): In function `netpoll_setup':
> > > : undefined reference to `rcu_read_lock_up_read'
> > > net/built-in.o(.text+0x188ed): In function `netpoll_setup':
> > > : undefined reference to `rcu_read_lock_up_read'
> > > make: *** [.tmp_vmlinux1] Error 1
> > 
> > fixed in -V0.7.3.
> 
> I've just tried V0.7.3 but my PS/2 mouse and keyboard don't work.
> No message from the kernel.  I attach my .config

Problem solved disabling ACPI.

-- 
I route therefore you are

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-11-03 20:41                                                 ` Lorenzo Allegrucci
@ 2004-11-03 20:43                                                   ` Ingo Molnar
  2004-11-03 21:05                                                     ` Lorenzo Allegrucci
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-03 20:43 UTC (permalink / raw)
  To: Lorenzo Allegrucci; +Cc: linux-kernel


* Lorenzo Allegrucci <l_allegrucci@yahoo.it> wrote:

> On Wednesday 03 November 2004 18:53, Lorenzo Allegrucci wrote:
> > On Wednesday 03 November 2004 14:46, Ingo Molnar wrote:
> > > 
> > > * Lorenzo Allegrucci <l_allegrucci@yahoo.it> wrote:
> > > 
> > > >   LD      init/built-in.o
> > > >   LD      .tmp_vmlinux1
> > > > net/built-in.o(.text+0x1887f): In function `netpoll_setup':
> > > > : undefined reference to `rcu_read_lock_up_read'
> > > > net/built-in.o(.text+0x188ed): In function `netpoll_setup':
> > > > : undefined reference to `rcu_read_lock_up_read'
> > > > make: *** [.tmp_vmlinux1] Error 1
> > > 
> > > fixed in -V0.7.3.
> > 
> > I've just tried V0.7.3 but my PS/2 mouse and keyboard don't work.
> > No message from the kernel.  I attach my .config
> 
> Problem solved disabling ACPI.

does the same problem happen in vanilla 2.6.10-rc1-mm2 too?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-11-03 20:43                                                   ` Ingo Molnar
@ 2004-11-03 21:05                                                     ` Lorenzo Allegrucci
  0 siblings, 0 replies; 951+ messages in thread
From: Lorenzo Allegrucci @ 2004-11-03 21:05 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Wednesday 03 November 2004 21:43, Ingo Molnar wrote:
> 
> * Lorenzo Allegrucci <l_allegrucci@yahoo.it> wrote:
> 
> > On Wednesday 03 November 2004 18:53, Lorenzo Allegrucci wrote:
> > > On Wednesday 03 November 2004 14:46, Ingo Molnar wrote:
> > > > 
> > > > * Lorenzo Allegrucci <l_allegrucci@yahoo.it> wrote:
> > > > 
> > > > >   LD      init/built-in.o
> > > > >   LD      .tmp_vmlinux1
> > > > > net/built-in.o(.text+0x1887f): In function `netpoll_setup':
> > > > > : undefined reference to `rcu_read_lock_up_read'
> > > > > net/built-in.o(.text+0x188ed): In function `netpoll_setup':
> > > > > : undefined reference to `rcu_read_lock_up_read'
> > > > > make: *** [.tmp_vmlinux1] Error 1
> > > > 
> > > > fixed in -V0.7.3.
> > > 
> > > I've just tried V0.7.3 but my PS/2 mouse and keyboard don't work.
> > > No message from the kernel.  I attach my .config
> > 
> > Problem solved disabling ACPI.
> 
> does the same problem happen in vanilla 2.6.10-rc1-mm2 too?

No it doesn't.

-- 
I route therefore you are

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-11-03 10:58                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 Ingo Molnar
  2004-11-03 13:44                                           ` Lorenzo Allegrucci
  2004-11-03 19:33                                           ` john cooper
@ 2004-11-03 23:03                                           ` Magnus Naeslund(t)
  2004-11-04  6:56                                             ` Ingo Molnar
  2004-11-04 19:34                                           ` Gunther Persoons
  2004-11-06 15:57                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18 Ingo Molnar
  4 siblings, 1 reply; 951+ messages in thread
From: Magnus Naeslund(t) @ 2004-11-03 23:03 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Ingo Molnar wrote:
> i have released the -V0.7.1 Real-Time Preemption patch, which can be
> downloaded from:
> 
>     http://redhat.com/~mingo/realtime-preempt/
> 
> this release is mainly a merge of -V0.6.9 to 2.6.10-rc2-mm2.
> 
[snip]

I just wanted to tell you that my network problems with the e100 driver 
disappeared. I still get the BUG in enable_irq, but now the network 
works. I dunno if this is due to 2.6.10-rc2-mm2 fixes or your own fixes, 
but i'm now happy :)

I'm going to try this patch on a network game server, that's pretty 
latency demanding.

Regards,
Magnus


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-11-03 23:03                                           ` Magnus Naeslund(t)
@ 2004-11-04  6:56                                             ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-04  6:56 UTC (permalink / raw)
  To: Magnus Naeslund(t); +Cc: linux-kernel


* Magnus Naeslund(t) <mag@fbab.net> wrote:

> Ingo Molnar wrote:
> >i have released the -V0.7.1 Real-Time Preemption patch, which can be
> >downloaded from:
> >
> >    http://redhat.com/~mingo/realtime-preempt/
> >
> >this release is mainly a merge of -V0.6.9 to 2.6.10-rc2-mm2.
> >
> [snip]
> 
> I just wanted to tell you that my network problems with the e100
> driver disappeared. I still get the BUG in enable_irq, but now the
> network works. I dunno if this is due to 2.6.10-rc2-mm2 fixes or your
> own fixes, but i'm now happy :)

while doing the merge i noticed and removed an older hack i added to the
e100 driver (and the rtl8139 driver) - possibly this could be related.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-11-03 10:58                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 Ingo Molnar
                                                             ` (2 preceding siblings ...)
  2004-11-03 23:03                                           ` Magnus Naeslund(t)
@ 2004-11-04 19:34                                           ` Gunther Persoons
  2004-11-04 20:31                                             ` Chris Friesen
  2004-11-06 15:57                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18 Ingo Molnar
  4 siblings, 1 reply; 951+ messages in thread
From: Gunther Persoons @ 2004-11-04 19:34 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

Ingo Molnar wrote:

>i have released the -V0.7.1 Real-Time Preemption patch, which can be
>downloaded from:
>
>    http://redhat.com/~mingo/realtime-preempt/
>
>this release is mainly a merge of -V0.6.9 to 2.6.10-rc2-mm2.
>
>I havent done a proper changelog for a couple of days so here is a list
>of bigger changes since -V0.4:
>
> - implemented a first version of the priority inheritance handling and
>   priority inversion avoidance logic. This feature, after some initial
>   stability problems, solved the jackd and rtc_wakeup latencies that
>   were introduced by the ultra-finegrained locking in the -V series.
>
>   (the -T/U series had a coarser locking scheme triggered much lower
>   levels of priority inversion scenarios. The locking in the -V series
>   was clearly the tipping point.)
>
>   The new PI code covers all synchronization objects in Linux (on
>   PREEMPT_REALTIME): spinlocks, rwlocks, semaphores and rwsems. 
>   Feedback on the design of this code would be welcome, and patches as
>   well, if you have a better scheme. The code is pretty modular so feel 
>   free to experiment with alternative schemes.
>
> - completely reworked the debugging framework. All lock types
>   (spinlocks, rwlocks, semaphores and rwsems) are now tracked, both
>   their symbolic name and their place of acquire are traced and printed
>   out upon detection of a deadlock. More and better information is
>   printed upon a deadlock. Got rid of the 'semaphore owners array' in
>   debugging mode, this reduces the footprint of semaphores quite
>   significantly and speeds up deadlock detection.
>
> - got rid of the separate 'counted semaphores' implementation, it was
>   too intrusive. Made the core 'generic semaphores' implementation
>   compatible with vanilla Linux counted semaphore semantics. This also
>   enabled the unrolling of the completion-handling cleanups which,
>   while being very nice, were getting intrusive as well.
>
> - countless build and driver related reports/fixes from lots of people
>
> - more latency breaks in the remaining critical sections. A
>   particularly important one was the irqs-off latency bugfix from
>   Thomas Gleixner.
>
> - sped up the i8259 PIC and the PIT timer hardirq handling routines -
>   these are now in the path of the longest latency.
>
> - cleaned up IRQ and signal preemption - there were missed
>   check-rescheds and possibilities for IRQ recursion.
>
> - made ALSA's ioctl()s not use the BKL - this fixes more jackd
>   latencies.
>
>to create a -V0.7.1 tree from scratch, the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
>   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
>   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm2/2.6.10-rc1-mm2.bz2
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm2-V0.7.1
>
>	Ingo
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
Hey,
I get a lock up with my wireless pcmcia cisco card. When i try to run to 
dhcpcd command or iwconfig it just hangs. Also when
i insert my card at boot time it hangs when running the net init 
scripts. I had this with version V0.7.8 and V0.7.10, have tested any 
other RT patches, i didn't have this problem with VP-T3. Also i can now 
mount and use my reiser4 partition.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
  2004-11-04 19:34                                           ` Gunther Persoons
@ 2004-11-04 20:31                                             ` Chris Friesen
  0 siblings, 0 replies; 951+ messages in thread
From: Chris Friesen @ 2004-11-04 20:31 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel


> Ingo Molnar wrote:

>> - implemented a first version of the priority inheritance handling and
>>   priority inversion avoidance logic. This feature, after some initial
>>   stability problems, solved the jackd and rtc_wakeup latencies that
>>   were introduced by the ultra-finegrained locking in the -V series.

How does this play with Inaky's priority inheritance patch?  Could they be 
combined somehow?

Chris

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18
  2004-11-03 10:58                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 Ingo Molnar
                                                             ` (3 preceding siblings ...)
  2004-11-04 19:34                                           ` Gunther Persoons
@ 2004-11-06 15:57                                           ` Ingo Molnar
  2004-11-06 17:17                                             ` Gunther Persoons
                                                               ` (5 more replies)
  4 siblings, 6 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-06 15:57 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese


i have released the -V0.7.18 Real-Time Preemption patch, which can be
downloaded from:

   http://redhat.com/~mingo/realtime-preempt/

this release includes fixes and cleanups.

Changes between -V0.7.12 and -V0.7.18:

 - merged to 2.6.10-rc1-mm3

 - fixed the e1000 xmit warnings reported by Amit Shah. Same fix for tg3
   too.

 - added irq-latency fix from Thomas Gleixner: re-enable interrupts
   before adding timings to the entropy pool.

 - fixed excessive ksoftirqd overhead during outgoing TCP traffic. 
   ksoftirqd kept getting re-woken while it had no way to progress.

 - added upstream fix from Andi Kleen for the vmalloc bug causing module
   load problems/crashes. Added ipc/shm fix too.

Changes between -V0.7.1 and -V0.7.12:

 - big source level cleanups: completely rearranged the mutex type
   definitions and source files, to make it reflect the code. Made
   all locking objects based on a new, central lock type: struct
   rt_mutex. This type is never exposed externally, it is internal to
   the RT code. Unified all the RT locking code in kernel/rt.c, this 
   also simplified and sped things up. Undid collateral damage to the
   generic rwsem code - it is now untouched and independent of the RT
   code.

 - rearranged the way spinlocks interact with the RT code and cleaned 
   up the RT spinlock definitions. Found and fixed a bug in the process:
   rwlocks were dropping the BKL upon contention.

 - small x86 speedup: call __schedule not preempt_schedule_irq from
   work_resched.

 - ported PREEMPT_RT to x64. This resulted in the generalization of some
   of the x86 changes.

 - hopefully fixed fbcon kernel logging

 - hacked reiser4 to make it work on PREEMPT_REALTIME.

 - dropped the swap-layout-improvements patch. While it was working fine 
   it's not necessary for latencies anymore under the PREEMPT_REALTIME
   approach, and the swap-patch was getting intrusive.

 - fixed preemption-bug in drain_cpu_caches() on SMP [bug introduced by
   PREEMPT_REALTIME]

 - new attempt at getting rid of the networking related deadlocks

 - selinux deadlock fix and RCU-code conversion to RT semantics

to create a -V0.7.18 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.18

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18
  2004-11-06 15:57                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18 Ingo Molnar
@ 2004-11-06 17:17                                             ` Gunther Persoons
  2004-11-06 19:25                                               ` Lorenzo Allegrucci
  2004-11-06 17:55                                             ` Rui Nuno Capela
                                                               ` (4 subsequent siblings)
  5 siblings, 1 reply; 951+ messages in thread
From: Gunther Persoons @ 2004-11-06 17:17 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

Ingo Molnar wrote:

>i have released the -V0.7.18 Real-Time Preemption patch, which can be
>downloaded from:
>
>   http://redhat.com/~mingo/realtime-preempt/
>
>this release includes fixes and cleanups.
>
>Changes between -V0.7.12 and -V0.7.18:
>
> - merged to 2.6.10-rc1-mm3
>
> - fixed the e1000 xmit warnings reported by Amit Shah. Same fix for tg3
>   too.
>
> - added irq-latency fix from Thomas Gleixner: re-enable interrupts
>   before adding timings to the entropy pool.
>
> - fixed excessive ksoftirqd overhead during outgoing TCP traffic. 
>   ksoftirqd kept getting re-woken while it had no way to progress.
>
> - added upstream fix from Andi Kleen for the vmalloc bug causing module
>   load problems/crashes. Added ipc/shm fix too.
>
>Changes between -V0.7.1 and -V0.7.12:
>
> - big source level cleanups: completely rearranged the mutex type
>   definitions and source files, to make it reflect the code. Made
>   all locking objects based on a new, central lock type: struct
>   rt_mutex. This type is never exposed externally, it is internal to
>   the RT code. Unified all the RT locking code in kernel/rt.c, this 
>   also simplified and sped things up. Undid collateral damage to the
>   generic rwsem code - it is now untouched and independent of the RT
>   code.
>
> - rearranged the way spinlocks interact with the RT code and cleaned 
>   up the RT spinlock definitions. Found and fixed a bug in the process:
>   rwlocks were dropping the BKL upon contention.
>
> - small x86 speedup: call __schedule not preempt_schedule_irq from
>   work_resched.
>
> - ported PREEMPT_RT to x64. This resulted in the generalization of some
>   of the x86 changes.
>
> - hopefully fixed fbcon kernel logging
>
> - hacked reiser4 to make it work on PREEMPT_REALTIME.
>
> - dropped the swap-layout-improvements patch. While it was working fine 
>   it's not necessary for latencies anymore under the PREEMPT_REALTIME
>   approach, and the swap-patch was getting intrusive.
>
> - fixed preemption-bug in drain_cpu_caches() on SMP [bug introduced by
>   PREEMPT_REALTIME]
>
> - new attempt at getting rid of the networking related deadlocks
>
> - selinux deadlock fix and RCU-code conversion to RT semantics
>
>to create a -V0.7.18 tree from scratch, the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
>   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
>   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.18
>
>	Ingo
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
Got a bug:

Assertion failure in __journal_unfile_buffer() at 
fs/jbd/transaction.c:1447: "jbd_is_locked_bh_state(bh)"
BUG at fs/jbd/transaction.c:1447!
------------[ cut here ]------------
kernel BUG at fs/jbd/transaction.c:1447!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: reiser4 radeon airo_cs airo ohci_hcd ehci_hcd 8139cp 
mii ohci1394 ieee1394 snd_intel8x0 snd_ac97_codec usbhid uhci_hcd 
intel_agp agpgart snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device 
snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd usbcore 
vfat fat
CPU:    0
EIP:    0060:[<c01d69d2>]    Not tainted VLI
EFLAGS: 00010246   (2.6.10-rc1-mm3-RT-V0.7.18)
EIP is at __journal_unfile_buffer+0x102/0x230
eax: 00000022   ebx: c0ef211c   ecx: c0378081   edx: cf951d7c
esi: cb2185c4   edi: cb2185c4   ebp: 00000000   esp: cf951d78
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process kjournald (pid: 6286, threadinfo=cf950000 task=cf941320)
Stack: c0378081 c037f479 000005a7 c0386db4 c036b2a3 c037f479 000005a7 
c037f5e4
       c0ef211c cb2185c4 00000000 cb299580 c01d7aec c0ef211c cf651250 
00000001
       cb2995b8 cf651014 cf950000 cf950000 c0137f43 00000000 00000000 
00000000
Call Trace:
 [<c01d7aec>] journal_commit_transaction+0x2dc/0x12a0 (52)
 [<c0137f43>] __up_mutex+0x293/0x470 (32)
 [<c011ccf0>] recalc_task_prio+0xd0/0x210 (28)
 [<c011ce8b>] activate_task+0x5b/0x90 (40)
 [<c013947a>] trace_start_sched_wakeup+0xca/0xf0 (16)
 [<c01daf39>] kjournald+0xe9/0x260 (284)
 [<c0136720>] autoremove_wake_function+0x0/0x40 (32)
 [<c0136720>] autoremove_wake_function+0x0/0x40 (32)
 [<c011d3de>] finish_task_switch+0x3e/0xb0 (20)
 [<c012a4c6>] __mod_timer+0x36/0x1c0 (48)
 [<c01dae30>] commit_timeout+0x0/0x10 (24)
 [<c01dae50>] kjournald+0x0/0x260 (12)
 [<c01042b5>] kernel_thread_helper+0x5/0x10 (16)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c0106971>] .... die+0x31/0x180
.....[<00000000>] ..   ( <= 0x0)
.. [<c013960c>] .... print_traces+0xc/0x40
.....[<00000000>] ..   ( <= 0x0)

Code: 05 00 00 68 79 f4 37 c0 68 a3 b2 36 c0 68 b4 6d 38 c0 e8 a2 b4 f4 
ff 68 a7 05 00 00 68 79 f4 37 c0 68 81 80 37 c0 e8 8e b4 f4 ff <0f> 0b 
a7 05 79 f4 37 c0 83 c4 20 e9 07 ff ff ff 8d b4 26 00 00
 kjournald:6286 BUG: lock held at task exit time!
 [cf651250] {&journal->j_list_lock}
.. held by:         kjournald/ 6286 [cf941320, 116]
... acquired at:  journal_commit_transaction+0x2a9/0x12a0

BUG at kernel/timer.c:166!
------------[ cut here ]------------
kernel BUG at kernel/timer.c:166!
invalid operand: 0000 [#2]
PREEMPT
Modules linked in: reiser4 radeon airo_cs airo ohci_hcd ehci_hcd 8139cp 
mii ohci1394 ieee1394 snd_intel8x0 snd_ac97_codec usbhid uhci_hcd 
intel_agp agpgart snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device 
snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd usbcore 
vfat fat
CPU:    0
EIP:    0060:[<c012a5f2>]    Not tainted VLI
EFLAGS: 00010296   (2.6.10-rc1-mm3-RT-V0.7.18)
EIP is at __mod_timer+0x162/0x1c0
eax: 0000001b   ebx: 00000000   ecx: c0378081   edx: c13ddcc8
esi: cf951f90   edi: cb299480   ebp: cf651014   esp: c13ddcc4
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process pdflush (pid: 165, threadinfo=c13dc000 task=c13db970)
Stack: c0378081 c037a8eb 000000a6 00000000 c037f48e cb299480 cf651000 
cb299480
       cf651014 c01d4c37 cf951f90 0008ec57 00000000 cf651000 c01d4d60 
cf651000
       cb299480 cf651014 c13e7780 c13e77c4 c0138573 c13e77c4 00000001 
c0149843
Call Trace:
 [<c01d4c37>] get_transaction+0x67/0xd0 (40)
 [<c01d4d60>] start_this_handle+0xc0/0x3e0 (20)
 [<c0138573>] up_mutex+0x23/0xa0 (24)
 [<c0149843>] cache_grow+0x133/0x250 (12)
 [<c0137f43>] __up_mutex+0x293/0x470 (36)
 [<c0149e5b>] kmem_cache_alloc+0x4b/0xd0 (16)
 [<c0149e5b>] kmem_cache_alloc+0x4b/0xd0 (12)
 [<c0138573>] up_mutex+0x23/0xa0 (12)
 [<c0149e5b>] kmem_cache_alloc+0x4b/0xd0 (12)
 [<c0149e5b>] kmem_cache_alloc+0x4b/0xd0 (12)
 [<c01d5154>] journal_start+0x94/0xc0 (32)
 [<c01c7dd5>] ext3_ordered_writepage+0x65/0x190 (24)
 [<c0183fc1>] mpage_writepages+0x261/0x410 (28)
 [<c01c7d70>] ext3_ordered_writepage+0x0/0x190 (24)
 [<c0137f43>] __up_mutex+0x293/0x470 (52)
 [<c0182063>] __sync_single_inode+0x53/0x280 (16)
 [<c01466f9>] do_writepages+0x39/0x40 (28)
 [<c018206f>] __sync_single_inode+0x5f/0x280 (16)
 [<c01822be>] __writeback_single_inode+0x2e/0x140 (36)
 [<c036483d>] __down_mutex+0xed/0x390 (24)
 [<c036483d>] __down_mutex+0xed/0x390 (12)
 [<c0364a04>] __down_mutex+0x2b4/0x390 (16)
 [<c0182569>] generic_sync_sb_inodes+0x199/0x300 (40)
 [<c01827cc>] writeback_inodes+0xcc/0xe0 (48)
 [<c0146f80>] pdflush+0x0/0x30 (24)
 [<c01464d3>] wb_kupdate+0x93/0x110 (4)
 [<c0146e78>] __pdflush+0xb8/0x1c0 (56)
 [<c0146e80>] __pdflush+0xc0/0x1c0 (36)
 [<c0146f9e>] pdflush+0x1e/0x30 (20)
 [<c0146440>] wb_kupdate+0x0/0x110 (20)
 [<c03634f1>] schedule+0x31/0x100 (20)
 [<c0136243>] kthread+0x83/0xc0 (8)
 [<c01361c0>] kthread+0x0/0xc0 (20)
 [<c01042b5>] kernel_thread_helper+0x5/0x10 (16)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c0106971>] .... die+0x31/0x180
.....[<00000000>] ..   ( <= 0x0)
.. [<c013960c>] .... print_traces+0xc/0x40
.....[<00000000>] ..   ( <= 0x0)

Code: e4 00 00 39 5e 4c 58 0f 84 6a ff ff ff 68 e0 32 3c c0 e9 27 ff ff 
ff 68 a6 00 00 00 68 eb a8 37 c0 68 81 80 37 c0 e8 6e 78 ff ff <0f> 0b 
a6 00 eb a8 37 c0 83 c4 0c e9 ab fe ff ff 68 a5 00 00 00
 pdflush:165 BUG: lock held at task exit time!
 [cf725840] {&s->s_umount}
.. held by:           pdflush/  165 [c13db970, 115]
... acquired at:  writeback_inodes+0x4b/0xe0
pdflush:165 BUG: lock held at task exit time!
 [cf651014] {&journal->j_state_lock}
.. held by:           pdflush/  165 [c13db970, 115]
... acquired at:  start_this_handle+0x61/0x3e0


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18
  2004-11-06 15:57                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18 Ingo Molnar
  2004-11-06 17:17                                             ` Gunther Persoons
@ 2004-11-06 17:55                                             ` Rui Nuno Capela
  2004-11-06 18:56                                               ` Peter Zijlstra
  2004-11-06 22:52                                             ` Rui Nuno Capela
                                                               ` (3 subsequent siblings)
  5 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-06 17:55 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
>
> i have released the -V0.7.18 Real-Time Preemption patch, which can be
> downloaded from:
>
>    http://redhat.com/~mingo/realtime-preempt/
>
> this release includes fixes and cleanups.
>

Sorry. Build error for a non-debug configuration:

drivers/char/drm/drm_stub.c: In function `drm_fill_in_dev':
drivers/char/drm/drm_stub.c:60: error: parse error before '{' token
make[3]: *** [drivers/char/drm/drm_stub.o] Error 1
make[2]: *** [drivers/char/drm] Error 2
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

If CONFIG_DEBUG_PREEMPT and/or CONFIG_RT_DEADLOCK_DETECT are set, the
RT-V0.7.18 build succeeds.

Not big deal. However, my personal benchmarks (jackd-R + 8*fluidsynth) are
being based on production-like kernel configurations (no kernel debug
options set), so I guess it will have to wait :)

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18
  2004-11-06 17:55                                             ` Rui Nuno Capela
@ 2004-11-06 18:56                                               ` Peter Zijlstra
  0 siblings, 0 replies; 951+ messages in thread
From: Peter Zijlstra @ 2004-11-06 18:56 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, LKML, Lee Revell, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese

On Sat, 2004-11-06 at 17:55 +0000, Rui Nuno Capela wrote:

> 
> Sorry. Build error for a non-debug configuration:
> 
> drivers/char/drm/drm_stub.c: In function `drm_fill_in_dev':
> drivers/char/drm/drm_stub.c:60: error: parse error before '{' token
> make[3]: *** [drivers/char/drm/drm_stub.o] Error 1
> make[2]: *** [drivers/char/drm] Error 2
> make[1]: *** [drivers/char] Error 2
> make: *** [drivers] Error 2
> 

make that line look like: 
	spin_lock_init( &dev->count_lock );

> If CONFIG_DEBUG_PREEMPT and/or CONFIG_RT_DEADLOCK_DETECT are set, the
> RT-V0.7.18 build succeeds.
> 
> Not big deal. However, my personal benchmarks (jackd-R + 8*fluidsynth) are
> being based on production-like kernel configurations (no kernel debug
> options set), so I guess it will have to wait :)
> 
> Cheers.
-- 
Peter Zijlstra <a.p.zijlstra@chello.nl>


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18
  2004-11-06 17:17                                             ` Gunther Persoons
@ 2004-11-06 19:25                                               ` Lorenzo Allegrucci
  0 siblings, 0 replies; 951+ messages in thread
From: Lorenzo Allegrucci @ 2004-11-06 19:25 UTC (permalink / raw)
  To: Gunther Persoons; +Cc: Ingo Molnar, linux-kernel

On Saturday 06 November 2004 18:17, Gunther Persoons wrote:
> Got a bug:
> 
> Assertion failure in __journal_unfile_buffer() at 
> fs/jbd/transaction.c:1447: "jbd_is_locked_bh_state(bh)"
> BUG at fs/jbd/transaction.c:1447!

<AOL>
Me too.
</AOL>

-- 
I route therefore you are

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18
  2004-11-06 15:57                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18 Ingo Molnar
  2004-11-06 17:17                                             ` Gunther Persoons
  2004-11-06 17:55                                             ` Rui Nuno Capela
@ 2004-11-06 22:52                                             ` Rui Nuno Capela
  2004-11-07 22:22                                             ` Karsten Wiese
                                                               ` (2 subsequent siblings)
  5 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-06 22:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese

Ingo Molnar wrote:
>
> i have released the -V0.7.18 Real-Time Preemption patch, which can be
> downloaded from:
>
>    http://redhat.com/~mingo/realtime-preempt/
>

I'm having trouble modprobe'ing the alsasound drivers ever since
RT-V0.7.11, to latest RT-V0.7.18, and I suspect this applies to -mm3 as
well.

The most evident trouble happens while unloading the modules, either on
shutdown or doing simple modprobe -r or rmmod. The system hangs
completely. On my P4/SMT machine it doesn't spit anything out to the
serial console. Nada. OTOH, on my P4/UP laptop, I found that it does
behave a litle more verbose, as the following syslog excerpt:


Nov  6 20:29:52 lambda alsa: Shutting down ALSA sound driver (version 1.0.6):
Nov  6 20:29:55 lambda kernel: usbcore: deregistering driver snd-usb-usx2y
Nov  6 20:29:55 lambda alsa: /etc/rc6.d/K70alsa: line 287: 15938
Segmentation fault      /sbin/rmmod `echo $line | cut -d ' ' -f 1`
>/dev/null 2>&1
Nov  6 20:29:55 lambda kernel: BUG: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
Nov  6 20:29:55 lambda kernel:  printing eip:
Nov  6 20:29:55 lambda kernel: c012ae47
Nov  6 20:29:55 lambda kernel: *pde = 00000000
Nov  6 20:29:55 lambda kernel: Oops: 0000 [#1]
Nov  6 20:29:55 lambda kernel: PREEMPT
Nov  6 20:29:55 lambda kernel: Modules linked in: realtime commoncap
snd_usb_usx2y snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd_ali5451
snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore prism2_cs
p80211 pcmcia yenta_socket pcmcia_core natsemi crc32 loop subfs evdev
pl2303 usbserial ohci_hcd usbcore
Nov  6 20:29:55 lambda kernel: CPU:    0
Nov  6 20:29:55 lambda kernel: EIP:    0060:[__up_write+109/721]    Not
tainted VLI
Nov  6 20:29:55 lambda kernel: EIP:    0060:[<c012ae47>]    Not tainted VLI
Nov  6 20:29:55 lambda kernel: EFLAGS: 00010083   (2.6.10-rc1-mm2-RT-V0.7.7)
Nov  6 20:29:55 lambda kernel: EIP is at __up_write+0x6d/0x2d1
Nov  6 20:29:55 lambda kernel: eax: 00000000   ebx: d6cb8000   ecx:
00000064   edx: 00000064
Nov  6 20:29:55 lambda alsa: /etc/rc6.d/K70alsa: line 287: 15965
Segmentation fault      /sbin/rmmod `echo $line | cut -d ' ' -f 1`
>/dev/null 2>&1
Nov  6 20:29:55 lambda kernel: esi: e011b5cc   edi: ddd7ce30   ebp:
e0061e78   esp: d6cb9eb8
Nov  6 20:29:55 lambda kernel: ds: 007b   es: 007b   ss: 0068   preempt:
00000004
Nov  6 20:29:55 lambda kernel: Process rmmod (pid: 15938,
threadinfo=d6cb8000 task=ded203b0)
Nov  6 20:29:55 lambda kernel: Stack: c015258f df760280 00000008 c013baa4
ddc02028 00000246 d6cb8000 00000246
Nov  6 20:29:55 lambda kernel:        df767400 00000000 d6cb8000 e011b5c8
e0061e68 e0061e78 c012b957 00000246
Nov  6 20:29:55 lambda kernel:        ded203b0 d6cb8000 00000246 c02ff3c0
de3db4e8 e011b5e8 c030ac28 c01b1cef
Nov  6 20:29:55 lambda kernel: Call Trace:
Nov  6 20:29:55 lambda kernel:  [invalidate_inode_buffers+26/240]
invalidate_inode_buffers+0x1a/0xf0 (4)
Nov  6 20:29:55 lambda kernel:  [<c015258f>]
invalidate_inode_buffers+0x1a/0xf0 (4)
Nov  6 20:29:55 lambda kernel:  [cache_flusharray+69/161]
cache_flusharray+0x45/0xa1 (12)
Nov  6 20:29:55 lambda kernel:  [<c013baa4>] cache_flusharray+0x45/0xa1 (12)
Nov  6 20:29:55 lambda kernel:  [up+80/173] up+0x50/0xad (44)
Nov  6 20:29:55 lambda kernel:  [<c012b957>] up+0x50/0xad (44)
Nov  6 20:29:55 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:55 lambda kernel:  [<c01b1cef>] kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:55 lambda kernel:  [kobject_release+0/8]
kobject_release+0x0/0x8 (8)
Nov  6 20:29:55 lambda kernel:  [<c01b1cf1>] kobject_release+0x0/0x8 (8)
Nov  6 20:29:55 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov  6 20:29:55 lambda kernel:  [<c01b2597>] kref_put+0x51/0xc2 (12)
Nov  6 20:29:55 lambda kernel:  [bus_remove_driver+63/72]
bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:55 lambda kernel:  [<c01f79d2>] bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:55 lambda kernel:  [driver_unregister+11/26]
driver_unregister+0xb/0x1a (8)
Nov  6 20:29:55 lambda kernel:  [<c01f7d44>] driver_unregister+0xb/0x1a (8)
Nov  6 20:29:55 lambda kernel:  [pg0+533397933/1069954048]
usb_deregister+0x31/0x3f [usbcore] (8)
Nov  6 20:29:55 lambda kernel:  [<e004b1ad>] usb_deregister+0x31/0x3f
[usbcore] (8)
Nov  6 20:29:55 lambda kernel:  [sys_delete_module+287/299]
sys_delete_module+0x11f/0x12b (20)
Nov  6 20:29:55 lambda kernel:  [<c012d91f>] sys_delete_module+0x11f/0x12b
(20)
Nov  6 20:29:55 lambda kernel:  [blk_queue_bounce+29/132]
blk_queue_bounce+0x1d/0x84 (20)
Nov  6 20:29:55 lambda kernel:  [<c0140079>] blk_queue_bounce+0x1d/0x84 (20)
Nov  6 20:29:55 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176
(12)
Nov  6 20:29:55 lambda kernel:  [<c0144f7a>] do_munmap+0x11a/0x176 (12)
Nov  6 20:29:55 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:55 lambda kernel:  [<c014500e>] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:55 lambda kernel:  [sysenter_past_esp+82/113]
sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:55 lambda kernel:  [<c0103bc1>] sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:55 lambda kernel: Code: 75 0b 8b 46 04 85 c0 0f 84 71 01 00
00 b8 00 e0 ff ff 21 e0 83 40 14 01 8b 46 0c e8 d0 81 fe ff 8b 7e 0c 89 c2
8b 87 60 05 00 00 <8b> 08 0f 18 01 90 8d 9f 60 05 00 00 eb 10 8b 40 0c 39
d0 0f 4c
Nov  6 20:29:55 lambda kernel:  <6>note: rmmod[15938] exited with
preempt_count 3
Nov  6 20:29:55 lambda kernel: BUG: scheduling while atomic:
rmmod/0x00000003/15938
Nov  6 20:29:55 lambda kernel: caller is do_exit+0x289/0x4b2
Nov  6 20:29:55 lambda kernel:  [__schedule+1194/1525]
__sched_text_start+0x4aa/0x5f5 (8)
Nov  6 20:29:55 lambda kernel:  [<c02ac2fa>]
__sched_text_start+0x4aa/0x5f5 (8)
Nov  6 20:29:55 lambda kernel:  [exit_notify+1154/2290]
exit_notify+0x482/0x8f2 (24)
Nov  6 20:29:55 lambda kernel:  [<c01187ba>] exit_notify+0x482/0x8f2 (24)
Nov  6 20:29:55 lambda kernel:  [kmem_cache_free+72/197]
kmem_cache_free+0x48/0xc5 (24)
Nov  6 20:29:55 lambda kernel:  [<c013bd6d>] kmem_cache_free+0x48/0xc5 (24)
Nov  6 20:29:55 lambda kernel:  [do_exit+649/1202] do_exit+0x289/0x4b2 (32)
Nov  6 20:29:55 lambda kernel:  [<c0118eb3>] do_exit+0x289/0x4b2 (32)
Nov  6 20:29:55 lambda kernel:  [do_divide_error+0/330]
do_divide_error+0x0/0x14a (40)
Nov  6 20:29:55 lambda kernel:  [<c0104d83>] do_divide_error+0x0/0x14a (40)
Nov  6 20:29:55 lambda kernel:  [do_page_fault+920/1425]
do_page_fault+0x398/0x591 (64)
Nov  6 20:29:55 lambda kernel:  [<c0111313>] do_page_fault+0x398/0x591 (64)
Nov  6 20:29:55 lambda kernel:  [preempt_schedule+80/106]
preempt_schedule+0x50/0x6a (80)
Nov  6 20:29:55 lambda kernel:  [<c02ac5ab>] preempt_schedule+0x50/0x6a (80)
Nov  6 20:29:55 lambda kernel:  [queue_work+44/101] queue_work+0x2c/0x65 (20)
Nov  6 20:29:55 lambda kernel:  [<c0125d66>] queue_work+0x2c/0x65 (20)
Nov  6 20:29:55 lambda kernel:  [call_usermodehelper+274/316]
call_usermodehelper+0x112/0x13c (24)
Nov  6 20:29:55 lambda kernel:  [<c0125caa>]
call_usermodehelper+0x112/0x13c (24)
Nov  6 20:29:55 lambda kernel:  [__call_usermodehelper+0/72]
__call_usermodehelper+0x0/0x48 (20)
Nov  6 20:29:55 lambda kernel:  [<c0125b50>]
__call_usermodehelper+0x0/0x48 (20)
Nov  6 20:29:55 lambda kernel:  [do_page_fault+0/1425]
do_page_fault+0x0/0x591 (52)
Nov  6 20:29:55 lambda kernel:  [<c0110f7b>] do_page_fault+0x0/0x591 (52)
Nov  6 20:29:55 lambda kernel:  [error_code+45/56] error_code+0x2d/0x38 (8)
Nov  6 20:29:55 lambda kernel:  [<c010461d>] error_code+0x2d/0x38 (8)
Nov  6 20:29:55 lambda kernel:  [__up_write+109/721] __up_write+0x6d/0x2d1
(52)
Nov  6 20:29:55 lambda kernel:  [<c012ae47>] __up_write+0x6d/0x2d1 (52)
Nov  6 20:29:55 lambda kernel:  [invalidate_inode_buffers+26/240]
invalidate_inode_buffers+0x1a/0xf0 (12)
Nov  6 20:29:55 lambda kernel:  [<c015258f>]
invalidate_inode_buffers+0x1a/0xf0 (12)
Nov  6 20:29:55 lambda kernel:  [cache_flusharray+69/161]
cache_flusharray+0x45/0xa1 (12)
Nov  6 20:29:55 lambda kernel:  [<c013baa4>] cache_flusharray+0x45/0xa1 (12)
Nov  6 20:29:55 lambda kernel:  [up+80/173] up+0x50/0xad (44)
Nov  6 20:29:55 lambda kernel:  [<c012b957>] up+0x50/0xad (44)
Nov  6 20:29:55 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:55 lambda kernel:  [<c01b1cef>] kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:55 lambda kernel:  [kobject_release+0/8]
kobject_release+0x0/0x8 (8)
Nov  6 20:29:55 lambda kernel:  [<c01b1cf1>] kobject_release+0x0/0x8 (8)
Nov  6 20:29:55 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov  6 20:29:55 lambda kernel:  [<c01b2597>] kref_put+0x51/0xc2 (12)
Nov  6 20:29:55 lambda kernel:  [bus_remove_driver+63/72]
bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:55 lambda kernel:  [<c01f79d2>] bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:55 lambda kernel:  [driver_unregister+11/26]
driver_unregister+0xb/0x1a (8)
Nov  6 20:29:55 lambda kernel:  [<c01f7d44>] driver_unregister+0xb/0x1a (8)
Nov  6 20:29:55 lambda kernel:  [pg0+533397933/1069954048]
usb_deregister+0x31/0x3f [usbcore] (8)
Nov  6 20:29:55 lambda kernel:  [<e004b1ad>] usb_deregister+0x31/0x3f
[usbcore] (8)
Nov  6 20:29:55 lambda kernel:  [sys_delete_module+287/299]
sys_delete_module+0x11f/0x12b (20)
Nov  6 20:29:55 lambda kernel:  [<c012d91f>] sys_delete_module+0x11f/0x12b
(20)
Nov  6 20:29:55 lambda kernel:  [blk_queue_bounce+29/132]
blk_queue_bounce+0x1d/0x84 (20)
Nov  6 20:29:55 lambda kernel:  [<c0140079>] blk_queue_bounce+0x1d/0x84 (20)
Nov  6 20:29:55 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176
(12)
Nov  6 20:29:55 lambda kernel:  [<c0144f7a>] do_munmap+0x11a/0x176 (12)
Nov  6 20:29:55 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:55 lambda kernel:  [<c014500e>] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:55 lambda kernel:  [sysenter_past_esp+82/113]
sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:55 lambda kernel:  [<c0103bc1>] sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:55 lambda kernel: ALI 5451 0000:00:06.0: Device was removed
without properly calling pci_disable_device(). This may need fixing.
Nov  6 20:29:55 lambda kernel: BUG: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
Nov  6 20:29:55 lambda kernel:  printing eip:
Nov  6 20:29:55 lambda kernel: c012ae47
Nov  6 20:29:55 lambda kernel: *pde = 00000000
Nov  6 20:29:55 lambda kernel: Oops: 0000 [#2]
Nov  6 20:29:55 lambda kernel: PREEMPT
Nov  6 20:29:55 lambda kernel: Modules linked in: realtime commoncap
snd_usb_usx2y snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd_ali5451
snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore prism2_cs
p80211 pcmcia yenta_socket pcmcia_core natsemi crc32 loop subfs evdev
pl2303 usbserial ohci_hcd usbcore
Nov  6 20:29:55 lambda kernel: CPU:    0
Nov  6 20:29:55 lambda kernel: EIP:    0060:[__up_write+109/721]    Not
tainted VLI
Nov  6 20:29:55 lambda kernel: EIP:    0060:[<c012ae47>]    Not tainted VLI
Nov  6 20:29:55 lambda kernel: EFLAGS: 00010083   (2.6.10-rc1-mm2-RT-V0.7.7)
Nov  6 20:29:55 lambda kernel: EIP is at __up_write+0x6d/0x2d1
Nov  6 20:29:55 lambda kernel: eax: 00000000   ebx: d6cb8000   ecx:
00000064   edx: 00000064
Nov  6 20:29:55 lambda kernel: esi: e00ef894   edi: ddd7ce30   ebp:
c0303198   esp: d6cb9ec4
Nov  6 20:29:55 lambda kernel: ds: 007b   es: 007b   ss: 0068   preempt:
00000004
Nov  6 20:29:55 lambda kernel: Process rmmod (pid: 15965,
threadinfo=d6cb8000 task=ded203b0)
Nov  6 20:29:55 lambda kernel: Stack: c015258f ded203b0 00000000 00000096
de536d84 00000246 d6cb8000 00000246
Nov  6 20:29:56 lambda kernel:        df767400 00000000 d6cb8000 e00ef890
c0303188 c0303198 c012b957 00000246
Nov  6 20:29:56 lambda kernel:        ded203b0 d6cb8000 00000246 c02ff3c0
deb50cc8 e00ef8b0 c030ac28 c01b1cef
Nov  6 20:29:56 lambda kernel: Call Trace:
Nov  6 20:29:56 lambda kernel:  [invalidate_inode_buffers+26/240]
invalidate_inode_buffers+0x1a/0xf0 (4)
Nov  6 20:29:56 lambda kernel:  [<c015258f>]
invalidate_inode_buffers+0x1a/0xf0 (4)
Nov  6 20:29:56 lambda kernel:  [up+80/173] up+0x50/0xad (56)
Nov  6 20:29:56 lambda kernel:  [<c012b957>] up+0x50/0xad (56)
Nov  6 20:29:56 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:56 lambda kernel:  [<c01b1cef>] kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:56 lambda kernel:  [kobject_release+0/8]
kobject_release+0x0/0x8 (8)
Nov  6 20:29:56 lambda kernel:  [<c01b1cf1>] kobject_release+0x0/0x8 (8)
Nov  6 20:29:56 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov  6 20:29:56 lambda kernel:  [<c01b2597>] kref_put+0x51/0xc2 (12)
Nov  6 20:29:56 lambda kernel:  [bus_remove_driver+63/72]
bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:56 lambda kernel:  [<c01f79d2>] bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:56 lambda kernel:  [driver_unregister+11/26]
driver_unregister+0xb/0x1a (8)
Nov  6 20:29:56 lambda kernel:  [<c01f7d44>] driver_unregister+0xb/0x1a (8)
Nov  6 20:29:56 lambda kernel:  [pci_unregister_driver+11/19]
pci_unregister_driver+0xb/0x13 (8)
Nov  6 20:29:56 lambda kernel:  [<c01b95e4>]
pci_unregister_driver+0xb/0x13 (8)
Nov  6 20:29:56 lambda kernel:  [sys_delete_module+287/299]
sys_delete_module+0x11f/0x12b (8)
Nov  6 20:29:56 lambda kernel:  [<c012d91f>] sys_delete_module+0x11f/0x12b
(8)
Nov  6 20:29:56 lambda kernel:  [unmap_vma_list+14/23]
unmap_vma_list+0xe/0x17 (20)
Nov  6 20:29:56 lambda kernel:  [<c0144c7d>] unmap_vma_list+0xe/0x17 (20)
Nov  6 20:29:56 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176
(12)
Nov  6 20:29:56 lambda kernel:  [<c0144f7a>] do_munmap+0x11a/0x176 (12)
Nov  6 20:29:56 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:56 lambda kernel:  [<c014500e>] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:56 lambda kernel:  [sysenter_past_esp+82/113]
sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:56 lambda kernel:  [<c0103bc1>] sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:56 lambda kernel: Code: 75 0b 8b 46 04 85 c0 0f 84 71 01 00
00 b8 00 e0 ff ff 21 e0 83 40 14 01 8b 46 0c e8 d0 81 fe ff 8b 7e 0c 89 c2
8b 87 60 05 00 00 <8b> 08 0f 18 01 90 8d 9f 60 05 00 00 eb 10 8b 40 0c 39
d0 0f 4c
Nov  6 20:29:56 lambda kernel:  <6>note: rmmod[15965] exited with
preempt_count 3
Nov  6 20:29:56 lambda kernel: BUG: scheduling while atomic:
rmmod/0x10000003/15965
Nov  6 20:29:56 lambda kernel: caller is __cond_resched+0x36/0x41
Nov  6 20:29:56 lambda kernel:  [__schedule+1194/1525]
__sched_text_start+0x4aa/0x5f5 (8)
Nov  6 20:29:56 lambda kernel:  [<c02ac2fa>]
__sched_text_start+0x4aa/0x5f5 (8)
Nov  6 20:29:56 lambda kernel:  [__cond_resched+54/65]
__cond_resched+0x36/0x41 (80)
Nov  6 20:29:56 lambda kernel:  [<c0113715>] __cond_resched+0x36/0x41 (80)
Nov  6 20:29:56 lambda kernel:  [cond_resched+28/37]
cond_resched+0x1c/0x25 (12)
Nov  6 20:29:56 lambda kernel:  [<c02acedb>] cond_resched+0x1c/0x25 (12)
Nov  6 20:29:56 lambda kernel:  [unmap_vmas+374/385]
unmap_vmas+0x176/0x181 (8)
Nov  6 20:29:56 lambda kernel:  [<c0140cff>] unmap_vmas+0x176/0x181 (8)
Nov  6 20:29:56 lambda kernel:  [exit_mmap+79/268] exit_mmap+0x4f/0x10c (64)
Nov  6 20:29:56 lambda kernel:  [<c01452df>] exit_mmap+0x4f/0x10c (64)
Nov  6 20:29:56 lambda kernel:  [mmput+78/295] mmput+0x4e/0x127 (40)
Nov  6 20:29:56 lambda kernel:  [<c01141d7>] mmput+0x4e/0x127 (40)
Nov  6 20:29:56 lambda kernel:  [do_exit+304/1202] do_exit+0x130/0x4b2 (24)
Nov  6 20:29:56 lambda kernel:  [<c0118d5a>] do_exit+0x130/0x4b2 (24)
Nov  6 20:29:56 lambda kernel:  [do_divide_error+0/330]
do_divide_error+0x0/0x14a (40)
Nov  6 20:29:56 lambda kernel:  [<c0104d83>] do_divide_error+0x0/0x14a (40)
Nov  6 20:29:56 lambda kernel:  [do_page_fault+920/1425]
do_page_fault+0x398/0x591 (64)
Nov  6 20:29:56 lambda kernel:  [<c0111313>] do_page_fault+0x398/0x591 (64)
Nov  6 20:29:56 lambda kernel:  [preempt_schedule+80/106]
preempt_schedule+0x50/0x6a (80)
Nov  6 20:29:56 lambda kernel:  [<c02ac5ab>] preempt_schedule+0x50/0x6a (80)
Nov  6 20:29:56 lambda kernel:  [queue_work+44/101] queue_work+0x2c/0x65 (20)
Nov  6 20:29:56 lambda kernel:  [<c0125d66>] queue_work+0x2c/0x65 (20)
Nov  6 20:29:56 lambda kernel:  [call_usermodehelper+274/316]
call_usermodehelper+0x112/0x13c (24)
Nov  6 20:29:56 lambda kernel:  [<c0125caa>]
call_usermodehelper+0x112/0x13c (24)
Nov  6 20:29:56 lambda kernel:  [__call_usermodehelper+0/72]
__call_usermodehelper+0x0/0x48 (20)
Nov  6 20:29:56 lambda kernel:  [<c0125b50>]
__call_usermodehelper+0x0/0x48 (20)
Nov  6 20:29:56 lambda kernel:  [do_page_fault+0/1425]
do_page_fault+0x0/0x591 (52)
Nov  6 20:29:56 lambda kernel:  [<c0110f7b>] do_page_fault+0x0/0x591 (52)
Nov  6 20:29:56 lambda kernel:  [error_code+45/56] error_code+0x2d/0x38 (8)
Nov  6 20:29:56 lambda kernel:  [<c010461d>] error_code+0x2d/0x38 (8)
Nov  6 20:29:56 lambda kernel:  [__up_write+109/721] __up_write+0x6d/0x2d1
(52)
Nov  6 20:29:56 lambda kernel:  [<c012ae47>] __up_write+0x6d/0x2d1 (52)
Nov  6 20:29:56 lambda kernel:  [invalidate_inode_buffers+26/240]
invalidate_inode_buffers+0x1a/0xf0 (12)
Nov  6 20:29:56 lambda kernel:  [<c015258f>]
invalidate_inode_buffers+0x1a/0xf0 (12)
Nov  6 20:29:56 lambda kernel:  [up+80/173] up+0x50/0xad (56)
Nov  6 20:29:56 lambda kernel:  [<c012b957>] up+0x50/0xad (56)
Nov  6 20:29:56 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:56 lambda kernel:  [<c01b1cef>] kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:56 lambda kernel:  [kobject_release+0/8]
kobject_release+0x0/0x8 (8)
Nov  6 20:29:56 lambda kernel:  [<c01b1cf1>] kobject_release+0x0/0x8 (8)
Nov  6 20:29:56 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov  6 20:29:56 lambda kernel:  [<c01b2597>] kref_put+0x51/0xc2 (12)
Nov  6 20:29:56 lambda kernel:  [bus_remove_driver+63/72]
bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:56 lambda kernel:  [<c01f79d2>] bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:56 lambda kernel:  [driver_unregister+11/26]
driver_unregister+0xb/0x1a (8)
Nov  6 20:29:56 lambda kernel:  [<c01f7d44>] driver_unregister+0xb/0x1a (8)
Nov  6 20:29:56 lambda kernel:  [pci_unregister_driver+11/19]
pci_unregister_driver+0xb/0x13 (8)
Nov  6 20:29:56 lambda kernel:  [<c01b95e4>]
pci_unregister_driver+0xb/0x13 (8)
Nov  6 20:29:56 lambda kernel:  [sys_delete_module+287/299]
sys_delete_module+0x11f/0x12b (8)
Nov  6 20:29:56 lambda kernel:  [<c012d91f>] sys_delete_module+0x11f/0x12b
(8)
Nov  6 20:29:56 lambda kernel:  [unmap_vma_list+14/23]
unmap_vma_list+0xe/0x17 (20)
Nov  6 20:29:56 lambda kernel:  [<c0144c7d>] unmap_vma_list+0xe/0x17 (20)
Nov  6 20:29:56 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176
(12)
Nov  6 20:29:56 lambda kernel:  [<c0144f7a>] do_munmap+0x11a/0x176 (12)
Nov  6 20:29:56 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:56 lambda kernel:  [<c014500e>] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:56 lambda kernel:  [sysenter_past_esp+82/113]
sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:56 lambda kernel:  [<c0103bc1>] sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:56 lambda kernel: BUG: scheduling while atomic:
rmmod/0x10000003/15965
Nov  6 20:29:56 lambda kernel: caller is __cond_resched+0x36/0x41
Nov  6 20:29:56 lambda kernel:  [__schedule+1194/1525]
__sched_text_start+0x4aa/0x5f5 (8)
Nov  6 20:29:56 lambda kernel:  [<c02ac2fa>]
__sched_text_start+0x4aa/0x5f5 (8)
Nov  6 20:29:56 lambda kernel:  [do_exit+328/1202] do_exit+0x148/0x4b2 (36)
Nov  6 20:29:56 lambda kernel:  [<c0118d72>] do_exit+0x148/0x4b2 (36)
Nov  6 20:29:56 lambda kernel:  [down_write_mutex+333/518]
down_write_mutex+0x14d/0x206 (4)
Nov  6 20:29:56 lambda kernel:  [<c02ad5f9>] down_write_mutex+0x14d/0x206 (4)
Nov  6 20:29:56 lambda kernel:  [remove_vm_struct+93/129]
remove_vm_struct+0x5d/0x81 (8)
Nov  6 20:29:56 lambda kernel:  [<c0143446>] remove_vm_struct+0x5d/0x81 (8)
Nov  6 20:29:56 lambda kernel:  [__cond_resched+54/65]
__cond_resched+0x36/0x41 (32)
Nov  6 20:29:56 lambda kernel:  [<c0113715>] __cond_resched+0x36/0x41 (32)
Nov  6 20:29:56 lambda kernel:  [cond_resched+28/37]
cond_resched+0x1c/0x25 (12)
Nov  6 20:29:56 lambda kernel:  [<c02acedb>] cond_resched+0x1c/0x25 (12)
Nov  6 20:29:56 lambda kernel:  [put_files_struct+146/269]
put_files_struct+0x92/0x10d (8)
Nov  6 20:29:56 lambda kernel:  [<c0117ec3>] put_files_struct+0x92/0x10d (8)
Nov  6 20:29:56 lambda kernel:  [do_exit+352/1202] do_exit+0x160/0x4b2 (32)
Nov  6 20:29:56 lambda kernel:  [<c0118d8a>] do_exit+0x160/0x4b2 (32)
Nov  6 20:29:56 lambda kernel:  [do_divide_error+0/330]
do_divide_error+0x0/0x14a (40)
Nov  6 20:29:56 lambda kernel:  [<c0104d83>] do_divide_error+0x0/0x14a (40)
Nov  6 20:29:56 lambda kernel:  [do_page_fault+920/1425]
do_page_fault+0x398/0x591 (64)
Nov  6 20:29:56 lambda kernel:  [<c0111313>] do_page_fault+0x398/0x591 (64)
Nov  6 20:29:56 lambda kernel:  [preempt_schedule+80/106]
preempt_schedule+0x50/0x6a (80)
Nov  6 20:29:56 lambda kernel:  [<c02ac5ab>] preempt_schedule+0x50/0x6a (80)
Nov  6 20:29:56 lambda kernel:  [queue_work+44/101] queue_work+0x2c/0x65 (20)
Nov  6 20:29:56 lambda kernel:  [<c0125d66>] queue_work+0x2c/0x65 (20)
Nov  6 20:29:56 lambda kernel:  [call_usermodehelper+274/316]
call_usermodehelper+0x112/0x13c (24)
Nov  6 20:29:56 lambda kernel: aa>] call_usermodehelper+0x112/0x13c (24)
Nov  6 20:29:56 lambda kernel:  [__call_usermodehelper+0/72]
__call_usermodehelper+0x0/0x48 (20)
Nov  6 20:29:56 lambda kernel:  [<c0125b50>]
__call_usermodehelper+0x0/0x48 (20)
Nov  6 20:29:56 lambda kernel:  [do_page_fault+0/1425]
do_page_fault+0x0/0x591 (52)
Nov  6 20:29:56 lambda kernel:  [<c0110f7b>] do_page_fault+0x0/0x591 (52)
Nov  6 20:29:56 lambda kernel:  [error_code+45/56] error_code+0x2d/0x38 (8)
Nov  6 20:29:56 lambda kernel:  [<c010461d>] error_code+0x2d/0x38 (8)
Nov  6 20:29:56 lambda kernel:  [__up_write+109/721] __up_write+0x6d/0x2d1
(52)
Nov  6 20:29:56 lambda kernel:  [<c012ae47>] __up_write+0x6d/0x2d1 (52)
Nov  6 20:29:56 lambda kernel:  [invalidate_inode_buffers+26/240]
invalidate_inode_buffers+0x1a/0xf0 (12)
Nov  6 20:29:56 lambda kernel:  [<c015258f>]
invalidate_inode_buffers+0x1a/0xf0 (12)
Nov  6 20:29:56 lambda kernel:  [up+80/173] up+0x50/0xad (56)
Nov  6 20:29:56 lambda kernel:  [<c012b957>] up+0x50/0xad (56)
Nov  6 20:29:56 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:56 lambda kernel:  [<c01b1cef>] kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:56 lambda kernel:  [kobject_release+0/8]
kobject_release+0x0/0x8 (8)
Nov  6 20:29:56 lambda kernel:  [<c01b1cf1>] kobject_release+0x0/0x8 (8)
Nov  6 20:29:56 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov  6 20:29:56 lambda kernel:  [<c01b2597>] kref_put+0x51/0xc2 (12)
Nov  6 20:29:56 lambda kernel:  [bus_remove_driver+63/72]
bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:56 lambda kernel:  [<c01f79d2>] bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:56 lambda kernel:  [driver_unregister+11/26]
driver_unregister+0xb/0x1a (8)
Nov  6 20:29:56 lambda kernel:  [<c01f7d44>] driver_unregister+0xb/0x1a (8)
Nov  6 20:29:56 lambda kernel:  [pci_unregister_driver+11/19]
pci_unregister_driver+0xb/0x13 (8)
Nov  6 20:29:56 lambda kernel:  [<c01b95e4>]
pci_unregister_driver+0xb/0x13 (8)
Nov  6 20:29:56 lambda kernel:  [sys_delete_module+287/299]
sys_delete_module+0x11f/0x12b (8)
Nov  6 20:29:56 lambda kernel:  [<c012d91f>] sys_delete_module+0x11f/0x12b
(8)
Nov  6 20:29:56 lambda kernel:  [unmap_vma_list+14/23]
unmap_vma_list+0xe/0x17 (20)
Nov  6 20:29:56 lambda kernel:  [<c0144c7d>] unmap_vma_list+0xe/0x17 (20)
Nov  6 20:29:56 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176
(12)
Nov  6 20:29:56 lambda kernel:  [<c0144f7a>] do_munmap+0x11a/0x176 (12)
Nov  6 20:29:56 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:56 lambda kernel:  [<c014500e>] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:56 lambda kernel:  [sysenter_past_esp+82/113]
sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:56 lambda kernel:  [<c0103bc1>] sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:56 lambda kernel: BUG: scheduling while atomic:
rmmod/0x00000003/15965
Nov  6 20:29:56 lambda kernel: caller is do_exit+0x289/0x4b2
Nov  6 20:29:56 lambda kernel:  [__schedule+1194/1525]
__sched_text_start+0x4aa/0x5f5 (8)
Nov  6 20:29:56 lambda kernel:  [<c02ac2fa>]
__sched_text_start+0x4aa/0x5f5 (8)
Nov  6 20:29:56 lambda kernel:  [exit_notify+1154/2290]
exit_notify+0x482/0x8f2 (24)
Nov  6 20:29:56 lambda kernel:  [<c01187ba>] exit_notify+0x482/0x8f2 (24)
Nov  6 20:29:56 lambda kernel:  [kmem_cache_free+72/197]
kmem_cache_free+0x48/0xc5 (24)
Nov  6 20:29:56 lambda kernel:  [<c013bd6d>] kmem_cache_free+0x48/0xc5 (24)
Nov  6 20:29:56 lambda kernel:  [do_exit+649/1202] do_exit+0x289/0x4b2 (32)
Nov  6 20:29:56 lambda kernel:  [<c0118eb3>] do_exit+0x289/0x4b2 (32)
Nov  6 20:29:56 lambda kernel:  [do_divide_error+0/330]
do_divide_error+0x0/0x14a (40)
Nov  6 20:29:56 lambda kernel:  [<c0104d83>] do_divide_error+0x0/0x14a (40)
Nov  6 20:29:56 lambda kernel:  [do_page_fault+920/1425]
do_page_fault+0x398/0x591 (64)
Nov  6 20:29:56 lambda kernel:  [<c0111313>] do_page_fault+0x398/0x591 (64)
Nov  6 20:29:56 lambda kernel:  [preempt_schedule+80/106]
preempt_schedule+0x50/0x6a (80)
Nov  6 20:29:56 lambda kernel:  [<c02ac5ab>] preempt_schedule+0x50/0x6a (80)
Nov  6 20:29:56 lambda kernel:  [queue_work+44/101] queue_work+0x2c/0x65 (20)
Nov  6 20:29:56 lambda kernel:  [<c0125d66>] queue_work+0x2c/0x65 (20)
Nov  6 20:29:56 lambda kernel:  [call_usermodehelper+274/316]
call_usermodehelper+0x112/0x13c (24)
Nov  6 20:29:56 lambda kernel:  [<c0125caa>]
call_usermodehelper+0x112/0x13c (24)
Nov  6 20:29:56 lambda kernel:  [__call_usermodehelper+0/72]
__call_usermodehelper+0x0/0x48 (20)
Nov  6 20:29:56 lambda kernel:  [<c0125b50>]
__call_usermodehelper+0x0/0x48 (20)
Nov  6 20:29:56 lambda kernel:  [do_page_fault+0/1425]
do_page_fault+0x0/0x591 (52)
Nov  6 20:29:56 lambda kernel:  [<c0110f7b>] do_page_fault+0x0/0x591 (52)
Nov  6 20:29:56 lambda kernel:  [error_code+45/56] error_code+0x2d/0x38 (8)
Nov  6 20:29:56 lambda kernel:  [<c010461d>] error_code+0x2d/0x38 (8)
Nov  6 20:29:56 lambda kernel:  [__up_write+109/721] __up_write+0x6d/0x2d1
(52)
Nov  6 20:29:56 lambda kernel:  [<c012ae47>] __up_write+0x6d/0x2d1 (52)
Nov  6 20:29:56 lambda kernel:  [invalidate_inode_buffers+26/240]
invalidate_inode_buffers+0x1a/0xf0 (12)
Nov  6 20:29:56 lambda kernel:  [<c015258f>]
invalidate_inode_buffers+0x1a/0xf0 (12)
Nov  6 20:29:56 lambda kernel:  [up+80/173] up+0x50/0xad (56)
Nov  6 20:29:56 lambda kernel:  [<c012b957>] up+0x50/0xad (56)
Nov  6 20:29:56 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:56 lambda kernel:  [<c01b1cef>] kobject_cleanup+0x8e/0x90 (36)
Nov  6 20:29:56 lambda kernel:  [kobject_release+0/8]
kobject_release+0x0/0x8 (8)
Nov  6 20:29:56 lambda kernel:  [<c01b1cf1>] kobject_release+0x0/0x8 (8)
Nov  6 20:29:56 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov  6 20:29:56 lambda kernel:  [<c01b2597>] kref_put+0x51/0xc2 (12)
Nov  6 20:29:56 lambda kernel:  [bus_remove_driver+63/72]
bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:56 lambda kernel:  [<c01f79d2>] bus_remove_driver+0x3f/0x48 (36)
Nov  6 20:29:56 lambda kernel:  [driver_unregister+11/26]
driver_unregister+0xb/0x1a (8)
Nov  6 20:29:56 lambda kernel:  [<c01f7d44>] driver_unregister+0xb/0x1a (8)
Nov  6 20:29:56 lambda kernel:  [pci_unregister_driver+11/19]
pci_unregister_driver+0xb/0x13 (8)
Nov  6 20:29:56 lambda kernel:  [<c01b95e4>]
pci_unregister_driver+0xb/0x13 (8)
Nov  6 20:29:56 lambda kernel:  [sys_delete_module+287/299]
sys_delete_module+0x11f/0x12b (8)
Nov  6 20:29:56 lambda kernel:  [<c012d91f>] sys_delete_module+0x11f/0x12b
(8)
Nov  6 20:29:56 lambda kernel:  [unmap_vma_list+14/23]
unmap_vma_list+0xe/0x17 (20)
Nov  6 20:29:56 lambda kernel:  [<c0144c7d>] unmap_vma_list+0xe/0x17 (20)
Nov  6 20:29:56 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176
(12)
Nov  6 20:29:56 lambda kernel:  [<c0144f7a>] do_munmap+0x11a/0x176 (12)
Nov  6 20:29:56 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:56 lambda kernel:  [<c014500e>] sys_munmap+0x38/0x45 (36)
Nov  6 20:29:56 lambda kernel:  [sysenter_past_esp+82/113]
sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:56 lambda kernel:  [<c0103bc1>] sysenter_past_esp+0x52/0x71 (12)
Nov  6 20:29:56 lambda alsa:  succeeded
Nov  6 20:29:56 lambda rc: Stopping alsa:  succeeded

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18
  2004-11-06 15:57                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18 Ingo Molnar
                                                               ` (2 preceding siblings ...)
  2004-11-06 22:52                                             ` Rui Nuno Capela
@ 2004-11-07 22:22                                             ` Karsten Wiese
  2004-11-08  8:21                                               ` Ingo Molnar
  2004-11-08  7:50                                             ` Eran Mann
  2004-11-08  9:16                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19 Ingo Molnar
  5 siblings, 1 reply; 951+ messages in thread
From: Karsten Wiese @ 2004-11-07 22:22 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano

Am Samstag 06 November 2004 16:57 schrieb Ingo Molnar:
> 
> i have released the -V0.7.18 Real-Time Preemption patch, which can be
> downloaded from:
> 

Hi Ingo

got this on a netconsole when I hit <TAB> in bash to complete "cat /proc/acpi":
>>>>>>
BUG: sleeping function called from invalid context bash(5364) at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/kernel/rt.c:1322
in_atomic():1 [00000001], irqs_disabled():0
 [<c010803e>] <3>BUG: scheduling while atomic: bash/0x00000001/5364
caller is schedule+0x38/0x12e
 [<c010803e>] dump_stack+0x23/0x25 (20)
 [<c0311096>] __sched_text_start+0x9f6/0xdb4 (124)
 [<c031148c>] schedule+0x38/0x12e (36)
 [<c0312904>] __down_mutex+0x231/0x31a (84)
 [<c013d23a>] __spin_lock+0x46/0x50 (24)
 [<c013d2be>] _spin_lock_irqsave+0x1d/0x21 (16)
 [<c025f03b>] e100_xmit_frame+0x3c/0x2d8 (60)
 [<c02ae6c0>] netpoll_send_skb+0x23/0xb3 (28)
 [<c0263066>] write_msg+0x56/0xfa (52)
 [<c0124099>] __call_console_drivers+0x59/0x6c (32)
 [<c01241c0>] call_console_drivers+0x8c/0x163 (36)
 [<c01245bd>] release_console_sem+0x33/0xde (32)
 [<c01244c3>] vprintk+0x134/0x16d (36)
 [<c012438d>] printk+0x1d/0x1f (16)
 [<c0107f18>] show_trace+0x65/0xcd (36)
 [<c010803e>] dump_stack+0x23/0x25 (20)
 [<c01203ab>] __might_sleep+0xbc/0xcf (36)
 [<c013d228>] __spin_lock+0x34/0x50 (24)
 [<c013d2be>] _spin_lock_irqsave+0x1d/0x21 (16)
 [<c01437cd>] search_module_extables+0x1c/0x87 (32)
 [<c01375d9>] search_exception_tables+0x39/0x3b (24)
 [<c011b5d6>] fixup_exception+0x1a/0x34 (16)
 [<c011ae50>] do_page_fault+0x37e/0x64e (220)
 [<c0107c63>] error_code+0x2b/0x30 (100)
 [<c0199214>] proc_lookup+0x81/0xc9 (52)
 [<c0176318>] real_lookup+0xb2/0xd6 (36)
 [<c017663f>] do_lookup+0x82/0x8d (32)
 [<c0176dbf>] link_path_walk+0x775/0x1071 (108)
 [<c01779e2>] path_lookup+0xa5/0x1b0 (32)
 [<c0177c8f>] __user_walk+0x30/0x4d (32)
 [<c017211b>] vfs_stat+0x1f/0x5a (92)
 [<c01727b4>] sys_stat64+0x1e/0x3d (100)
 [<c0107191>] sysenter_past_esp+0x52/0x71 (-4028)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c031300b>] .... _raw_spin_lock+0x1c/0x73
.....[<c011bb74>] ..   ( <= task_rq_lock+0x32/0x5b)
.. [<c013ec19>] .... print_traces+0x1b/0x52
.....[<c010803e>] ..   ( <= dump_stack+0x23/0x25)
<<<<<<
then follow lots of
>>>>>>
BUG: scheduling while atomic: bash/0x00000001/5364
caller is schedule+0x38/0x12e
 [<c010803e>] dump_stack+0x23/0x25 (20)
 [<c0311096>] __sched_text_start+0x9f6/0xdb4 (124)
 [<c031148c>] schedule+0x38/0x12e (36)
 [<c0312904>] __down_mutex+0x231/0x31a (84)
 [<c013d23a>] __spin_lock+0x46/0x50 (24)
 [<c013d2be>] _spin_lock_irqsave+0x1d/0x21 (16)
 [<c025f03b>] e100_xmit_frame+0x3c/0x2d8 (60)
 [<c02ae6c0>] netpoll_send_skb+0x23/0xb3 (28)
 [<c0263066>] write_msg+0x56/0xfa (52)
 [<c0124099>] __call_console_drivers+0x59/0x6c (32)
 [<c01241e0>] call_console_drivers+0xac/0x163 (36)
 [<c01245bd>] release_console_sem+0x33/0xde (32)
 [<c01244c3>] vprintk+0x134/0x16d (36)
 [<c012438d>] printk+0x1d/0x1f (16)
 [<c0107f18>] show_trace+0x65/0xcd (36)
 [<c010803e>] dump_stack+0x23/0x25 (20)
 [<c01203ab>] __might_sleep+0xbc/0xcf (36)
 [<c013d228>] __spin_lock+0x34/0x50 (24)
 [<c013d2be>] _spin_lock_irqsave+0x1d/0x21 (16)
 [<c01437cd>] search_module_extables+0x1c/0x87 (32)
 [<c01375d9>] search_exception_tables+0x39/0x3b (24)
 [<c011b5d6>] fixup_exception+0x1a/0x34 (16)
 [<c011ae50>] do_page_fault+0x37e/0x64e (220)
 [<c0107c63>] error_code+0x2b/0x30 (100)
 [<c0199214>] proc_lookup+0x81/0xc9 (52)
 [<c0176318>] real_lookup+0xb2/0xd6 (36)
 [<c017663f>] do_lookup+0x82/0x8d (32)
 [<c0176dbf>] link_path_walk+0x775/0x1071 (108)
 [<c01779e2>] path_lookup+0xa5/0x1b0 (32)
 [<c0177c8f>] __user_walk+0x30/0x4d (32)
 [<c017211b>] vfs_stat+0x1f/0x5a (92)
 [<c01727b4>] sys_stat64+0x1e/0x3d (100)
 [<c0107191>] sysenter_past_esp+0x52/0x71 (-4028)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c031300b>] .... _raw_spin_lock+0x1c/0x73
.....[<c011bb74>] ..   ( <= task_rq_lock+0x32/0x5b)
.. [<c013ec19>] .... print_traces+0x1b/0x52
.....[<c010803e>] ..   ( <= dump_stack+0x23/0x25)
<<<<<<

then the machine is frozen.

Best regards,
Karsten

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18
  2004-11-06 15:57                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18 Ingo Molnar
                                                               ` (3 preceding siblings ...)
  2004-11-07 22:22                                             ` Karsten Wiese
@ 2004-11-08  7:50                                             ` Eran Mann
  2004-11-08  9:45                                               ` Ingo Molnar
  2004-11-08  9:16                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19 Ingo Molnar
  5 siblings, 1 reply; 951+ messages in thread
From: Eran Mann @ 2004-11-08  7:50 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

Ingo Molnar wrote:
> i have released the -V0.7.18 Real-Time Preemption patch, which can be
> downloaded from:
> 
>    http://redhat.com/~mingo/realtime-preempt/

I got the attached oops on 2.6.10-rc1-mm3-RT-V0.7.18 (probably during the
daily cron job). Later in the morning when I tried to access some 
filesystems
I got the attached deadlock report.
Relevant parts of the config:
...
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_REALTIME=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
...
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
CONFIG_PREEMPT_TIMING=y
# CONFIG_LATENCY_TRACE is not set
CONFIG_RT_DEADLOCK_DETECT=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_INFO is not set
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
# CONFIG_KGDB is not set
...

-- 
Eran Mann
Tel: 972-4-9936297
Fax: 972-4-9890430

[-- Attachment #2: oops2 --]
[-- Type: text/plain, Size: 3233 bytes --]

Nov  8 04:19:32 eran kernel: BUG at include/linux/spinlock.h:767!
Nov  8 04:19:32 eran kernel: ------------[ cut here ]------------
Nov  8 04:19:32 eran kernel: kernel BUG at include/linux/spinlock.h:767!
Nov  8 04:19:32 eran kernel: invalid operand: 0000 [#1]
Nov  8 04:19:32 eran kernel: PREEMPT
Nov  8 04:19:32 eran kernel: Modules linked in: snd_via82xx snd_ac97_codec snd_mpu401_uart snd_rawmidi snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd soundcore md5 ipv6 autofs 3c59x mii parport_pc parport nls_cp437 nls_iso8859_1 ntfs usbcore video thinkpad_acpi thermal processor fan button battery ac rtc
Nov  8 04:19:32 eran kernel: CPU:    0
Nov  8 04:19:32 eran kernel: EIP:    0060:[<c01e5a65>]    Not tainted VLI
Nov  8 04:19:32 eran kernel: EFLAGS: 00010286   (2.6.10-rc1-mm3-RT-V0.7.18)
Nov  8 04:19:32 eran kernel: EIP is at __try_to_free_cp_buf+0xc5/0xd0
Nov  8 04:19:32 eran kernel: eax: 00000025   ebx: ce29bfbc   ecx: 00000001   edx: 00000000
Nov  8 04:19:32 eran kernel: esi: 000002ff   edi: cf1f8760   ebp: cfa05d5c   esp: cfa05d48
Nov  8 04:19:32 eran kernel: ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Nov  8 04:19:32 eran kernel: Process kjournald (pid: 1445, threadinfo=cfa04000 task=cf9866c0)
Nov  8 04:19:32 eran kernel: Stack: c03ecd70 c03f40ba 000002ff ce55f20c ce55f1dc cfa05d88 c01e643d ce55f20c
Nov  8 04:19:32 eran kernel:        cfa04000 ce55f1dc 00000000 cf1f8760 cf1f8760 00000000 cd659880 00000000
Nov  8 04:19:32 eran kernel:        cfa05f28 c01e3563 cf4ebc00 cf1f8760 00000003 00009f35 cf3a7770 cf3a7770
Nov  8 04:19:32 eran kernel: Call Trace:
Nov  8 04:19:32 eran kernel:  [<c01080bf>] show_stack+0x7f/0xa0 (28)
Nov  8 04:19:32 eran kernel:  [<c0108275>] show_registers+0x165/0x1d0 (56)
Nov  8 04:19:32 eran kernel:  [<c010848c>] die+0xec/0x190 (64)
Nov  8 04:19:32 eran kernel:  [<c0108a5e>] do_invalid_op+0x11e/0x120 (192)
Nov  8 04:19:32 eran kernel:  [<c0107d07>] error_code+0x2b/0x30 (80)
Nov  8 04:19:32 eran kernel:  [<c01e643d>] __journal_clean_checkpoint_list+0x5d/0x90 (44)
Nov  8 04:19:32 eran kernel:  [<c01e3563>] journal_commit_transaction+0x273/0x1ac0 (416)
Nov  8 04:19:32 eran kernel:  [<c01e7d9d>] kjournald+0x18d/0x430 (196)
Nov  8 04:19:32 eran kernel:  [<c0105315>] kernel_thread_helper+0x5/0x10 (811573268)
Nov  8 04:19:32 eran kernel: Code: 4f 00 00 89 1c 24 e8 7b de f7 ff eb 9b c7 04 24 70 cd 3e c0 b9 ba 40 3f c0 be ff 02 00 00 89 74 24 08 89 4c 24 04 e8 2b 9f f3 ff <0f> 0b ff 02 ba 40 3f c0 eb bd 90 55 89 e5 57 56 53 83 ec 08 8b
Nov  8 04:19:32 eran kernel:  kjournald:1445 BUG: lock held at task exit time!
Nov  8 04:19:32 eran kernel:  [cf4ebc14] {&journal->j_state_lock}
Nov  8 04:19:32 eran kernel: .. held by:         kjournald/ 1445 [cf9866c0, 115]Nov  8 04:19:32 eran kernel: ... acquired at:  journal_commit_transaction+0xdf/0x1ac0
Nov  8 04:19:32 eran kernel: kjournald:1445 BUG: lock held at task exit time!
Nov  8 04:19:32 eran kernel:  [cf4ebe50] {&journal->j_list_lock}
Nov  8 04:19:32 eran kernel: .. held by:         kjournald/ 1445 [cf9866c0, 115]Nov  8 04:19:32 eran kernel: ... acquired at:  journal_commit_transaction+0x268/0x1ac0
Nov  8 07:20:22 eran kernel: IRQ#7 thread RT prio: 39.

2.6.10-rc1-mm3-RT-V0.7.18

[-- Attachment #3: deadlock --]
[-- Type: text/plain, Size: 14139 bytes --]

 [<c01080bf>] show_stack+0x7f/0xa0 (28)
 [<c0108275>] show_registers+0x165/0x1d0 (56)
 [<c010848c>] die+0xec/0x190 (64)
 [<c0108a5e>] do_invalid_op+0x11e/0x120 (192)
 [<c0107d07>] error_code+0x2b/0x30 (80)
 [<c01e643d>] __journal_clean_checkpoint_list+0x5d/0x90 (44)
 [<c01e3563>] journal_commit_transaction+0x273/0x1ac0 (416)
 [<c01e7d9d>] kjournald+0x18d/0x430 (196)
 [<c0105315>] kernel_thread_helper+0x5/0x10 (811573268)
Code: 4f 00 00 89 1c 24 e8 7b de f7 ff eb 9b c7 04 24 70 cd 3e c0 b9 ba 40 3f c0 be ff 02 00 00 89 74 24 08 89 4c 24 04 e8 2b 9f f3 ff <0f> 0b ff 02 ba 40 3f c0 eb bd 90 55 89 e5 57 56 53 83 ec 08 8b
 kjournald:1445 BUG: lock held at task exit time!
 [cf4ebc14] {&journal->j_state_lock}
.. held by:         kjournald/ 1445 [cf9866c0, 115]
... acquired at:  journal_commit_transaction+0xdf/0x1ac0
kjournald:1445 BUG: lock held at task exit time!
 [cf4ebe50] {&journal->j_list_lock}
.. held by:         kjournald/ 1445 [cf9866c0, 115]
... acquired at:  journal_commit_transaction+0x268/0x1ac0
IRQ#7 thread RT prio: 39.
 
============================================
[ BUG: circular locking deadlock detected! ]
--------------------------------------------
bash/3986 is deadlocking current task bash/10630
 
 
1) bash/10630 is trying to acquire this lock:
 [cdc048e0] {&inode->i_sem}
.. held by:              bash/ 3986 [c8c87890, 115]
... acquired at:  vfs_readdir+0x53/0xa0
... trying at:   vfs_readdir+0x53/0xa0
 
2) bash/3986 is blocked on this lock:
 [cf4ebc14] {&journal->j_state_lock}
.. held by:              bash/10630 [cf9866c0, 115]
... acquired at:  journal_commit_transaction+0xdf/0x1ac0
 
------------------------------
| showing all locks held by: |  (bash/10630 [cf9866c0, 115]):
------------------------------
 
------------------------------
| showing all locks held by: |  (bash/3986 [c8c87890, 115]):
------------------------------
 
#001:             [cdc048e0] {&inode->i_sem}
... acquired at:  vfs_readdir+0x53/0xa0
 
bash/3986's [blocked] stackdump:
 
c3873d70 00000086 c8c87890 c0560060 c04a0440 00000001 00000246 c8c87890
       c01451f9 00000001 c044f318 c044f318 00000001 00000000 24535cc0 000f7cf3
       c8c87a54 c3872000 c3872000 c8c87890 c3873d94 c03c981b c044f318 00000282
Call Trace:
 [<c03c981b>] schedule+0x3b/0x130 (36)
 [<c03cae11>] __down_mutex+0x311/0x3b0 (84)
 [<c0138091>] __spin_lock+0x31/0x40 (24)
 [<c01380b8>] _spin_lock+0x18/0x20 (16)
 [<c01dfb96>] start_this_handle+0x66/0x4f0 (152)
 [<c01e0136>] journal_start+0xc6/0xf0 (40)
 [<c01d41e8>] ext3_dirty_inode+0x38/0xd0 (36)
 [<c01855e1>] __mark_inode_dirty+0x1d1/0x1e0 (64)
 [<c017cde1>] update_atime+0xd1/0xe0 (52)
 [<c01747b3>] vfs_readdir+0x93/0xa0 (36)
 [<c0174bdb>] sys_getdents64+0x6b/0xb0 (48)
 [<c010720d>] sysenter_past_esp+0x52/0x71 (-8124)
 
bash/10630's [current] stackdump:
 
 [<c01080fe>] dump_stack+0x1e/0x30 (20)
 [<c0136313>] check_deadlock+0x1c3/0x2a0 (44)
 [<c0136a22>] task_blocks_on_lock+0x1b2/0x1d0 (48)
 [<c03ca976>] __down+0x226/0x350 (76)
 [<c0137abe>] down+0x2e/0x160 (48)
 [<c0174773>] vfs_readdir+0x53/0xa0 (36)
 [<c0174bdb>] sys_getdents64+0x6b/0xb0 (48)
 [<c010720d>] sysenter_past_esp+0x52/0x71 (-8124)
 
showing all tasks:
s            init/    1 [c1279770, 116] (not blocked)
s     ksoftirqd/0/    2 [c12791a0, 105] (not blocked)
s       desched/0/    3 [c1278bd0, 105] (not blocked)
s        events/0/    4 [c1278600,  98] (not blocked)
s         khelper/    5 [c1278030, 106] (not blocked)
s         kthread/   10 [cffdb790, 105] (not blocked)
s          kacpid/   18 [cffdb1c0, 115] (not blocked)
s           IRQ 9/   19 [cffdabf0, 115] (not blocked)
s       kblockd/0/   67 [cffda620, 105] (not blocked)
s         pdflush/  133 [cffda050, 116] (not blocked)
s         pdflush/  134 [cfebb7b0, 116] (not blocked)
s           aio/0/  136 [cfebac10, 106] (not blocked)
s         kswapd0/  135 [cfebb1e0, 116] (not blocked)
s          IRQ 12/  748 [cfeba070,  53] (not blocked)
s           IRQ 6/  763 [c13ab7d0,  50] (not blocked)
s         kseriod/  742 [cfeba640, 125] (not blocked)
s          IRQ 14/  786 [c13ab200,  51] (not blocked)
s          IRQ 15/  789 [c13aac30,  52] (not blocked)
s           IRQ 1/  819 [c13aa660,  54] (not blocked)
s      reiserfs/0/  824 [c13aa090, 105] (not blocked)
s           IRQ 8/ 1163 [cf987260,  55] (not blocked)
s           khubd/ 1357 [cf1b4820, 119] (not blocked)
s           IRQ 4/ 1604 [cf987830,  56] (not blocked)
s           IRQ 3/ 1605 [cfbb2700,  57] (not blocked)
s           IRQ 7/ 1637 [cf3a7770,  60] (not blocked)
s          IRQ 10/ 1970 [cf9860f0,  58] (not blocked)
s          IRQ 11/ 2044 [cf5c87a0,  59] (not blocked)
s          dhcpcd/ 2056 [cf5c8d70, 117] (not blocked)
s         syslogd/ 2097 [cfbb3870, 116] (not blocked)
s           klogd/ 2101 [cf2a39b0, 116] (not blocked)
s         portmap/ 2127 [cf1b5990, 116] (not blocked)
s       rpc.statd/ 2146 [cf1b53c0, 119] (not blocked)
s           rsync/ 2223 [cf2a2270, 118] (not blocked)
s             atd/ 2281 [cfd0c0b0, 116] (not blocked)
s          smartd/ 2291 [cf3a6600, 116] (not blocked)
s            sshd/ 2300 [cf1b4df0, 121] (not blocked)
s          xinetd/ 2313 [cd4a2bf0, 117] (not blocked)
s           dhcpd/ 2322 [cf2a33e0, 119] (not blocked)
s        sendmail/ 2339 [cf1b4250, 116] (not blocked)
s        sendmail/ 2347 [cfd0cc50, 117] (not blocked)
s             gpm/ 2357 [cd4a3790, 116] (not blocked)
s           crond/ 2366 [cfd0d7f0, 116] (not blocked)
s             xfs/ 2394 [cf986c90, 116] (not blocked)
s   dbus-daemon-1/ 2411 [cd4a31c0, 116] (not blocked)
s           cupsd/ 2422 [cfd0c680, 116] (not blocked)
s        mingetty/ 2632 [cfbb2cd0, 119] (not blocked)
s        mingetty/ 2633 [cf5c9910, 119] (not blocked)
s        mingetty/ 2634 [cf3a6bd0, 119] (not blocked)
s        mingetty/ 2635 [cf2a2e10, 118] (not blocked)
s        mingetty/ 2638 [cf5c9340, 118] (not blocked)
s        mingetty/ 2639 [cf2a2840, 118] (not blocked)
s      gdm-binary/ 2640 [cf5c81d0, 116] (not blocked)
s      gdm-binary/ 2875 [cc3271e0, 117] (not blocked)
s               X/ 2888 [cc366c30, 115] (not blocked)
s   gnome-session/ 2923 [cfd0d220, 115] (not blocked)
s       ssh-agent/ 2985 [cd4a2620, 116] (not blocked)
s        gconfd-2/ 2996 [cc366090, 116] (not blocked)
s bonobo-activati/ 3519 [c8d1ed10, 116] (not blocked)
s gnome-settings-/ 3521 [cc326070, 115] (not blocked)
s    xscreensaver/ 3917 [cc367200, 115] (not blocked)
s   gnome-smproxy/ 3944 [cc366660, 117] (not blocked)
s        metacity/ 3946 [cf3a6030, 115] (not blocked)
s     gnome-panel/ 3948 [c92ff260, 115] (not blocked)
s        nautilus/ 3950 [c92fec90, 115] (not blocked)
s        nautilus/ 3955 [cc3677d0, 116] (not blocked)
s        nautilus/ 3956 [cfbb32a0, 117] (not blocked)
s        nautilus/ 3957 [c892a230, 116] (not blocked)
s        nautilus/ 3958 [c8d1f2e0, 115] (not blocked)
s        nautilus/ 3959 [c8c86150, 117] (not blocked)
s        nautilus/ 3960 [c8d1f8b0, 116] (not blocked)
s        nautilus/ 3961 [c8d1e170, 116] (not blocked)
s        nautilus/ 3962 [c8d1e740, 116] (not blocked)
s        nautilus/ 3963 [cd4a2050, 116] (not blocked)
s        nautilus/ 3964 [cf3a71a0, 116] (not blocked)
s        magicdev/ 3952 [cc326640, 115] (not blocked)
R  gnome-terminal/ 3954 [c8ac4e50, 116] (not blocked)
s  mapping-daemon/ 3966 [c8ac4880, 116] (not blocked)
s gnome-pty-helpe/ 3985 [c8c86720, 116] (not blocked)
D            bash/ 3986 [c8c87890, 115] blocked on: [cf4ebc14] {&journal->j_state_lock}
.. held by:              bash/10630 [cf9866c0, 115]
... acquired at:  journal_commit_transaction+0xdf/0x1ac0
s notification-ar/ 3988 [c8c872c0, 115] (not blocked)
s            bash/ 3989 [c8c86cf0, 115] (not blocked)
s     wnck-applet/ 4029 [c892b970, 115] (not blocked)
s multiload-apple/ 4071 [c892a800, 116] (not blocked)
s    gkb-applet-2/ 4079 [c892b3a0, 115] (not blocked)
s            tail/ 4166 [c8ac42b0, 116] (not blocked)
s     thunderbird/10586 [cc3277b0, 118] (not blocked)
s  run-mozilla.sh/10598 [c92ff830, 119] (not blocked)
s thunderbird-bin/10603 [cc326c10, 115] (not blocked)
s thunderbird-bin/10604 [cfbb2130, 116] (not blocked)
s thunderbird-bin/10606 [c8ac5420, 116] (not blocked)
D            bash/10630 [cf9866c0, 115] (not blocked)
 
---------------------------
| showing all locks held: |
---------------------------
 
#001:             [c057a080] {&hwif->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x98/0x180
 
#002:             [c0579c94] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#003:             [c0579e70] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#004:             [c057a6fc] {&hwif->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x98/0x180
 
#005:             [c057a310] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#006:             [c057a4ec] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#007:             [c057ad78] {&hwif->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x98/0x180
 
#008:             [c057a98c] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#009:             [c057ab68] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#010:             [c057b3f4] {&hwif->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x98/0x180
 
#011:             [c057b008] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#012:             [c057b1e4] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#013:             [c057ba70] {&hwif->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x98/0x180
 
#014:             [c057b684] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#015:             [c057b860] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#016:             [c057c0ec] {&hwif->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x98/0x180
 
#017:             [c057bd00] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#018:             [c057bedc] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#019:             [c057c768] {&hwif->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x98/0x180
 
#020:             [c057c37c] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#021:             [c057c558] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#022:             [c057cde4] {&hwif->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x98/0x180
 
#023:             [c057c9f8] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#024:             [c057cbd4] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#025:             [c057d460] {&hwif->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x98/0x180
 
#026:             [c057d074] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#027:             [c057d250] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#028:             [c057dadc] {&hwif->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x98/0x180
 
#029:             [c057d6f0] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#030:             [c057d8cc] {&drive->gendev_rel_sem}
.. held by:              init/    1 [c1279770, 116]
... acquired at:  init_hwif_data+0x16d/0x180
 
#031:             [cfd07cf0] {&tty->atomic_read}
.. held by:          mingetty/ 2632 [cfbb2cd0, 119]
... acquired at:  read_chan+0x6c9/0x720
 
#032:             [cc280cf0] {&tty->atomic_read}
.. held by:          mingetty/ 2633 [cf5c9910, 119]
... acquired at:  read_chan+0x6c9/0x720
 
#033:             [cc349cf0] {&tty->atomic_read}
.. held by:          mingetty/ 2638 [cf5c9340, 118]
... acquired at:  read_chan+0x6c9/0x720
 
#034:             [cc39fcf0] {&tty->atomic_read}
.. held by:          mingetty/ 2639 [cf2a2840, 118]
... acquired at:  read_chan+0x6c9/0x720
 
#035:             [cc32bcf0] {&tty->atomic_read}
.. held by:          mingetty/ 2635 [cf2a2e10, 118]
... acquired at:  read_chan+0x6c9/0x720
 
#036:             [cc3e1cf0] {&tty->atomic_read}
.. held by:          mingetty/ 2634 [cf3a6bd0, 119]
... acquired at:  read_chan+0x6c9/0x720
 
#037:             [c4031cf0] {&tty->atomic_read}
.. held by:              bash/ 3989 [c8c86cf0, 115]
... acquired at:  read_chan+0x6c9/0x720
 
#038:             [cdc048e0] {&inode->i_sem}
.. held by:              bash/ 3986 [c8c87890, 115]
... acquired at:  vfs_readdir+0x53/0xa0
=============================================
 
[ turning off deadlock detection. Please report this trace. ]
 


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18
  2004-11-07 22:22                                             ` Karsten Wiese
@ 2004-11-08  8:21                                               ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-08  8:21 UTC (permalink / raw)
  To: Karsten Wiese
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano


* Karsten Wiese <annabellesgarden@yahoo.de> wrote:

> got this on a netconsole when I hit <TAB> in bash to complete "cat
> /proc/acpi":

does the patch below help?

	Ingo

--- linux/kernel/module.c.orig
+++ linux/kernel/module.c
@@ -53,7 +54,7 @@
 #define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))
 
 /* Protects module list */
-static spinlock_t modlist_lock = SPIN_LOCK_UNLOCKED;
+static DECLARE_RAW_SPINLOCK(modlist_lock);
 
 /* List of modules, protected by module_mutex AND modlist_lock */
 static DECLARE_MUTEX(module_mutex);

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19
  2004-11-08  9:16                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19 Ingo Molnar
@ 2004-11-08  9:15                                               ` Karsten Wiese
  2004-11-08 10:19                                                 ` Ingo Molnar
  2004-11-08 10:24                                                 ` Ingo Molnar
  2004-11-08  9:50                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.20 Ingo Molnar
                                                                 ` (2 subsequent siblings)
  3 siblings, 2 replies; 951+ messages in thread
From: Karsten Wiese @ 2004-11-08  9:15 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Gunther Persoons, emann, Shane Shrybman

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

Am Montag 08 November 2004 10:16 schrieb Ingo Molnar:
> 
> i have released the -V0.7.19 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>    http://redhat.com/~mingo/realtime-preempt/
> 
> this release includes fixes only.
> 
> Changes since -V0.7.18:
> 
>  - fixed a merge bug introduced in -V0.7.18, breaking bit-spinlocks used
>    by ext3's journalling code. This could/should fix the kjournald crash
>    reported by Adam Heath, Gunther Persoons and Eran Mann. Bug triggered
>    on !SMP kernels only.
> 
>  - added upstream patch to fix a crash in bttv/btcx_riscmem_free(), 
>    reported by Shane Shrybman.
> 
>  - made modlist_lock raw again - this could fix the /proc/acpi related
>    asserts reported by Karsten Wiese.

Doesn't. Please see attached logs.

RT-V0.7.19-dmesg_after_boot_rl3.log is a freshly booted dmesg output after logging on via ssh.
RT-V0.7.19-proc_acpi_TAB.log is captured via netconsole. This log started after logging in locally,
then typing in "cat /proc/acpi", then first <TAB> gives an additional "/", 2nd <TAB> gives no visual effect, 3rd <TAB> produces whats in the log.

thanks,
Karsten

[-- Attachment #2: RT-V0.7.19-dmesg_after_boot_rl3.log.bz2 --]
[-- Type: application/x-bzip2, Size: 2809 bytes --]

[-- Attachment #3: RT-V0.7.19-proc_acpi_TAB.log.bz2 --]
[-- Type: application/x-bzip2, Size: 2583 bytes --]

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19
  2004-11-06 15:57                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18 Ingo Molnar
                                                               ` (4 preceding siblings ...)
  2004-11-08  7:50                                             ` Eran Mann
@ 2004-11-08  9:16                                             ` Ingo Molnar
  2004-11-08  9:15                                               ` Karsten Wiese
                                                                 ` (3 more replies)
  5 siblings, 4 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-08  9:16 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman


i have released the -V0.7.19 Real-Time Preemption patch, which can be
downloaded from the usual place:

   http://redhat.com/~mingo/realtime-preempt/

this release includes fixes only.

Changes since -V0.7.18:

 - fixed a merge bug introduced in -V0.7.18, breaking bit-spinlocks used
   by ext3's journalling code. This could/should fix the kjournald crash
   reported by Adam Heath, Gunther Persoons and Eran Mann. Bug triggered
   on !SMP kernels only.

 - added upstream patch to fix a crash in bttv/btcx_riscmem_free(), 
   reported by Shane Shrybman.

 - made modlist_lock raw again - this could fix the /proc/acpi related
   asserts reported by Karsten Wiese.

 - fixed -RT locking bug in zap_completion_queue(), this could fix the 
   asserts reported by Shane Shrybman and others.

to create a -V0.7.19 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.19

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18
  2004-11-08  7:50                                             ` Eran Mann
@ 2004-11-08  9:45                                               ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-08  9:45 UTC (permalink / raw)
  To: Eran Mann; +Cc: linux-kernel


* Eran Mann <emann@mrv.com> wrote:

> Ingo Molnar wrote:
> >i have released the -V0.7.18 Real-Time Preemption patch, which can be
> >downloaded from:
> >
> >   http://redhat.com/~mingo/realtime-preempt/
> 
> I got the attached oops on 2.6.10-rc1-mm3-RT-V0.7.18 (probably during the
> daily cron job). Later in the morning when I tried to access some 
> filesystems
> I got the attached deadlock report.

> Nov  8 04:19:32 eran kernel: BUG at include/linux/spinlock.h:767!
> Nov  8 04:19:32 eran kernel: ------------[ cut here ]------------
> Nov  8 04:19:32 eran kernel: kernel BUG at include/linux/spinlock.h:767!

ok, your bugreport pinpointed the bug: an RT-patch merging mistake when
i merged -RT to the spinlock-checker changes in recent BK.

the fix is below, but i've also put it into -V0.7.20 (which i released a
couple of minutes ago). Does this patch (or -V0.7.20) fix the kjournald
crash for you?

	Ingo

--- linux/include/linux/spinlock.h.orig
+++ linux/include/linux/spinlock.h
@@ -750,7 +750,7 @@ static inline void bit_spin_lock(int bit
  */
 static inline int bit_spin_trylock(int bitnum, unsigned long *addr)
 {
-#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
+#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK) || defined(CONFIG_PREEMPT)
 	if (test_and_set_bit(bitnum, addr))
 		return 0;
 #endif

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.20
  2004-11-08  9:16                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19 Ingo Molnar
  2004-11-08  9:15                                               ` Karsten Wiese
@ 2004-11-08  9:50                                               ` Ingo Molnar
  2004-11-08 13:13                                                 ` Lorenzo Allegrucci
                                                                   ` (2 more replies)
  2004-11-08 16:57                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21 Ingo Molnar
  2004-11-08 22:21                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19 Adam Heath
  3 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-08  9:50 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Peter Zijlstra


i have released the -V0.7.20 Real-Time Preemption patch, which can be
downloaded from the usual place:

   http://redhat.com/~mingo/realtime-preempt/

this release includes a single fix relative to -V0.7.19: it fixes the
nondebug build errors reported by Rui Nuno Capela and Peter Zijlstra,
introduced in -V0.7.18.

to create a -V0.7.20 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.20

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19
  2004-11-08  9:15                                               ` Karsten Wiese
@ 2004-11-08 10:19                                                 ` Ingo Molnar
  2004-11-08 12:42                                                   ` Karsten Wiese
  2004-11-08 10:24                                                 ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-08 10:19 UTC (permalink / raw)
  To: Karsten Wiese
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Gunther Persoons, emann, Shane Shrybman


* Karsten Wiese <annabellesgarden@yahoo.de> wrote:

> RT-V0.7.19-dmesg_after_boot_rl3.log is a freshly booted dmesg output
> after logging on via ssh. RT-V0.7.19-proc_acpi_TAB.log is captured via
> netconsole. This log started after logging in locally, then typing in
> "cat /proc/acpi", then first <TAB> gives an additional "/", 2nd <TAB>
> gives no visual effect, 3rd <TAB> produces whats in the log.

could you try this with vanilla -mm3 too? The crash seems to be generic:

 [<c011ae89>] do_page_fault+0x3b7/0x64e (220)
 [<c0107c63>] error_code+0x2b/0x30 (100)
 [<c01991e4>] proc_lookup+0x81/0xc9 (52)
 [<c01762e8>] real_lookup+0xb2/0xd6 (36)
 [<c017660f>] do_lookup+0x82/0x8d (32)
 [<c0176d8f>] link_path_walk+0x775/0x1071 (108)
 [<c01779b2>] path_lookup+0xa5/0x1b0 (32)
 [<c0177c5f>] __user_walk+0x30/0x4d (32)
 [<c01720eb>] vfs_stat+0x1f/0x5a (92)
 [<c0172784>] sys_stat64+0x1e/0x3d (100)
 [<c0107191>] sysenter_past_esp+0x52/0x71 (-4028)

while -RT made it a bit more murky by emitting an assert while the
kernel tried to crash in a critical section, it doesnt seem to be a 
genuine -RT related crash.

(if it doesnt trigger in vanilla -mm3 then could you try -RT with
PREEMPT_REALTIME disabled?)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19
  2004-11-08  9:15                                               ` Karsten Wiese
  2004-11-08 10:19                                                 ` Ingo Molnar
@ 2004-11-08 10:24                                                 ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-08 10:24 UTC (permalink / raw)
  To: Karsten Wiese
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Gunther Persoons, emann, Shane Shrybman


* Karsten Wiese <annabellesgarden@yahoo.de> wrote:

> RT-V0.7.19-dmesg_after_boot_rl3.log is a freshly booted dmesg output
> after logging on via ssh. RT-V0.7.19-proc_acpi_TAB.log is captured via
> netconsole. This log started after logging in locally, then typing in
> "cat /proc/acpi", then first <TAB> gives an additional "/", 2nd <TAB>
> gives no visual effect, 3rd <TAB> produces whats in the log.

there's at least one more netconsole buglet causing asserts, which
should be fixed by the patch below.

	Ingo

--- linux/net/core/netpoll.c.orig
+++ linux/net/core/netpoll.c
@@ -194,7 +194,7 @@ repeat:
 	}
 
 	spin_lock(&np->dev->xmit_lock);
-	np->dev->xmit_lock_owner = smp_processor_id();
+	np->dev->xmit_lock_owner = _smp_processor_id();
 
 	/*
 	 * network drivers do not expect to be called if the queue is

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19
  2004-11-08 10:19                                                 ` Ingo Molnar
@ 2004-11-08 12:42                                                   ` Karsten Wiese
  0 siblings, 0 replies; 951+ messages in thread
From: Karsten Wiese @ 2004-11-08 12:42 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Gunther Persoons, emann, Shane Shrybman

Am Montag 08 November 2004 11:19 schrieb Ingo Molnar:
> 
> * Karsten Wiese <annabellesgarden@yahoo.de> wrote:
> 
> > RT-V0.7.19-dmesg_after_boot_rl3.log is a freshly booted dmesg output
> > after logging on via ssh. RT-V0.7.19-proc_acpi_TAB.log is captured via
> > netconsole. This log started after logging in locally, then typing in
> > "cat /proc/acpi", then first <TAB> gives an additional "/", 2nd <TAB>
> > gives no visual effect, 3rd <TAB> produces whats in the log.
> 
> could you try this with vanilla -mm3 too? The crash seems to be generic:
> 
>  [<c011ae89>] do_page_fault+0x3b7/0x64e (220)
>  [<c0107c63>] error_code+0x2b/0x30 (100)
>  [<c01991e4>] proc_lookup+0x81/0xc9 (52)
>  [<c01762e8>] real_lookup+0xb2/0xd6 (36)
>  [<c017660f>] do_lookup+0x82/0x8d (32)
>  [<c0176d8f>] link_path_walk+0x775/0x1071 (108)
>  [<c01779b2>] path_lookup+0xa5/0x1b0 (32)
>  [<c0177c5f>] __user_walk+0x30/0x4d (32)
>  [<c01720eb>] vfs_stat+0x1f/0x5a (92)
>  [<c0172784>] sys_stat64+0x1e/0x3d (100)
>  [<c0107191>] sysenter_past_esp+0x52/0x71 (-4028)

right, on -mm3 bash crashes alike on "cat /proc/acpi" + 3*<TAB>.
Sent a dmesg output to Andrew under the "2.6.10-rc1-mm3"-thread.

Thanks,
Karsten

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.20
  2004-11-08  9:50                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.20 Ingo Molnar
@ 2004-11-08 13:13                                                 ` Lorenzo Allegrucci
  2004-11-08 14:15                                                 ` Rui Nuno Capela
  2004-11-08 16:17                                                 ` Florian Schmidt
  2 siblings, 0 replies; 951+ messages in thread
From: Lorenzo Allegrucci @ 2004-11-08 13:13 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Monday 08 November 2004 10:50, you wrote:
> 
> i have released the -V0.7.20 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>    http://redhat.com/~mingo/realtime-preempt/

At boot time:

BUG: sleeping function called from invalid context modprobe(1782) at kernel/rt.c:1322
in_atomic():1 [00000001], irqs_disabled():1
 [dump_stack+35/48] dump_stack+0x23/0x30 (20)
 [__might_sleep+194/224] __might_sleep+0xc2/0xe0 (36)
 [__spin_lock+56/96] __spin_lock+0x38/0x60 (24)
 [_spin_lock+29/32] _spin_lock+0x1d/0x20 (16)
 [kmem_cache_alloc+71/272] kmem_cache_alloc+0x47/0x110 (32)
 [use_module+164/320] use_module+0xa4/0x140 (32)
 [resolve_symbol+171/192] resolve_symbol+0xab/0xc0 (48)
 [simplify_symbols+178/288] simplify_symbols+0xb2/0x120 (44)
 [load_module+1395/2704] load_module+0x573/0xa90 (160)
 [sys_init_module+107/576] sys_init_module+0x6b/0x240 (32)
 [syscall_call+7/11] syscall_call+0x7/0xb (-4028)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [resolve_symbol+33/192] .... resolve_symbol+0x21/0xc0
.....[simplify_symbols+178/288] ..   ( <= simplify_symbols+0xb2/0x120)
.. [print_traces+29/144] .... print_traces+0x1d/0x90
.....[dump_stack+35/48] ..   ( <= dump_stack+0x23/0x30)


-- 
I route therefore you are

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.20
  2004-11-08  9:50                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.20 Ingo Molnar
  2004-11-08 13:13                                                 ` Lorenzo Allegrucci
@ 2004-11-08 14:15                                                 ` Rui Nuno Capela
  2004-11-08 16:17                                                 ` Florian Schmidt
  2 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-08 14:15 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Peter Zijlstra

Ingo Molnar wrote:
>
> i have released the -V0.7.20 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/
>

I'm seeing many of these on dmesg, almost everytime a module is getting
loaded:

BUG: sleeping function called from invalid context insmod(1357) at
kernel/rt.c:1322
in_atomic():1 [00000001], irqs_disabled():1
 [<c0105040>] dump_stack+0x23/0x25 (20)
 [<c0116026>] __might_sleep+0xbc/0xcf (36)
 [<c01321d1>] __spin_lock+0x38/0x57 (24)
 [<c013220d>] _spin_lock+0x1d/0x1f (16)
 [<c0145386>] kmem_cache_alloc+0x3f/0xfe (32)
 [<c01358ff>] use_module+0xa8/0x13a (32)
 [<c01363db>] resolve_symbol+0x79/0x8c (40)
 [<c0136a1d>] simplify_symbols+0xc4/0xfe (44)
 [<c013779b>] load_module+0x64f/0x989 (144)
 [<c0137b2c>] sys_init_module+0x57/0x23d (32)
 [<c0104201>] sysenter_past_esp+0x52/0x71 (-8124)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c013637f>] .... resolve_symbol+0x1d/0x8c
.....[<c0136a1d>] ..   ( <= simplify_symbols+0xc4/0xfe)
.. [<c0133cdf>] .... print_traces+0x1b/0x54
.....[<c0105040>] ..   ( <= dump_stack+0x23/0x25)


Another critical issue is that USB is not working properly; the ohci_hcd
module gets loaded but devices don't get listed by lsusb at all, which I
think is a "bonus" from upstream 2.6.9-rc1-mm3.

In fact I think -mm3 is breaking many things around here, at least on my
laptop; another notorious is my wifi stuff (linux-wlan-ng/prism2_cs) now
failing due to unresolved symbols, such as these:

prism2_cs: Unknown symbol p80211netdev_rx
prism2_cs: Unknown symbol register_wlandev
prism2_cs: Unknown symbol wlan_unsetup
prism2_cs: Unknown symbol unregister_wlandev
prism2_cs: Unknown symbol p80211netdev_hwremoved
prism2_cs: Unknown symbol wlan_setup
prism2_cs: Unknown symbol p80211skb_rxmeta_attach

But I guess this is off-topic by now.

Take care.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.20
  2004-11-08  9:50                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.20 Ingo Molnar
  2004-11-08 13:13                                                 ` Lorenzo Allegrucci
  2004-11-08 14:15                                                 ` Rui Nuno Capela
@ 2004-11-08 16:17                                                 ` Florian Schmidt
  2 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-08 16:17 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Peter Zijlstra

On Mon, 8 Nov 2004 10:50:48 +0100
Ingo Molnar <mingo@elte.hu> wrote:


> i have released the -V0.7.20 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>    http://redhat.com/~mingo/realtime-preempt/
> 
> this release includes a single fix relative to -V0.7.19: it fixes the
> nondebug build errors reported by Rui Nuno Capela and Peter Zijlstra,
> introduced in -V0.7.18.
> 
> to create a -V0.7.20 tree from scratch, the patching order is:
> 
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
>   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
>   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.20

Hi,

i just wanted to let you know that this one doesn't lock up for me. I
actually built for 486 [to be able to run the image in qemu first]. After
the run in qemu showed no problems, i went to boot the kernel on my real
machine. It seems to work fine so far with rtc_wakeup showing max. jitters
around 30 usec (at f=1024) under load (find's + kernel compile)..

Will build a kernel (0.7.21) with debugging enabled to see if i miss any
BUG's.

flo


^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21
  2004-11-08  9:16                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19 Ingo Molnar
  2004-11-08  9:15                                               ` Karsten Wiese
  2004-11-08  9:50                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.20 Ingo Molnar
@ 2004-11-08 16:57                                               ` Ingo Molnar
  2004-11-08 17:41                                                 ` Gunther Persoons
                                                                   ` (2 more replies)
  2004-11-08 22:21                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19 Adam Heath
  3 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-08 16:57 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman


i have released the -V0.7.21 Real-Time Preemption patch, which can be
downloaded from the usual place:

   http://redhat.com/~mingo/realtime-preempt/

this release includes fixes and debugging-improvements.

Changes since -V0.7.20:

 - reverted the modlist_lock change - it caused more problems than it 
   solved.

 - implemented irqs-off critical section timing/tracing, inspired by the 
   positive results Thomas Gleixner got with a different kind of cli/sti
   tracer. To activate it, enable CONFIG_CRITICAL_TIMING and 
   CONFIG_CRITICAL_IRQSOFF_TIMING and cli/sti latencies will be reported
   'integrated' into the preempt on/off latencies.

 - sped up tracing in a number of ways. Performance of the tracer slowly
   eroded in the past week or two, it needed alignment and size fixes ,
   inlining/branch-prediction updates and i got rid of unnecessary code.
   The max latency is now traced in cycles - this got rid of an
   expensive 64-bit division in the fastpath. (the /proc/sys tunables
   are still in usecs so userspace should not notice anything.) It's
   still not cheap but roughly 5 times faster than -V0.7.20's tracer, on
   a fast desktop box.

 - renamed CONFIG_PREEMPT_REALTIME to CONFIG_PREEMPT_RT - it's shorter.

 - renamed CONFIG_PREEMPT_TIMING to CONFIG_CRITICAL_TIMING and 
   introduced CONFIG_CRITICAL_IRQSOFF_TIMING to enable cli/sti timing.

to create a -V0.7.21 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.21

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21
  2004-11-08 16:57                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21 Ingo Molnar
@ 2004-11-08 17:41                                                 ` Gunther Persoons
  2004-11-08 23:41                                                   ` Ingo Molnar
  2004-11-08 17:59                                                 ` Norberto Bensa
  2004-11-09 16:05                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23 Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Gunther Persoons @ 2004-11-08 17:41 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

Ingo Molnar wrote:

>i have released the -V0.7.21 Real-Time Preemption patch, which can be
>downloaded from the usual place:
>
>   http://redhat.com/~mingo/realtime-preempt/
>
>this release includes fixes and debugging-improvements.
>
>Changes since -V0.7.20:
>
> - reverted the modlist_lock change - it caused more problems than it 
>   solved.
>
> - implemented irqs-off critical section timing/tracing, inspired by the 
>   positive results Thomas Gleixner got with a different kind of cli/sti
>   tracer. To activate it, enable CONFIG_CRITICAL_TIMING and 
>   CONFIG_CRITICAL_IRQSOFF_TIMING and cli/sti latencies will be reported
>   'integrated' into the preempt on/off latencies.
>
> - sped up tracing in a number of ways. Performance of the tracer slowly
>   eroded in the past week or two, it needed alignment and size fixes ,
>   inlining/branch-prediction updates and i got rid of unnecessary code.
>   The max latency is now traced in cycles - this got rid of an
>   expensive 64-bit division in the fastpath. (the /proc/sys tunables
>   are still in usecs so userspace should not notice anything.) It's
>   still not cheap but roughly 5 times faster than -V0.7.20's tracer, on
>   a fast desktop box.
>
> - renamed CONFIG_PREEMPT_REALTIME to CONFIG_PREEMPT_RT - it's shorter.
>
> - renamed CONFIG_PREEMPT_TIMING to CONFIG_CRITICAL_TIMING and 
>   introduced CONFIG_CRITICAL_IRQSOFF_TIMING to enable cli/sti timing.
>
>to create a -V0.7.21 tree from scratch, the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
>   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
>   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.21
>
>	Ingo
>
>  
>
When trying to patch my kernel i get following notice:
patching file include/linux/highmem.h
patch unexpectedly ends in middle of line
patch: **** unexpected end of file in patch

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21
  2004-11-08 16:57                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21 Ingo Molnar
  2004-11-08 17:41                                                 ` Gunther Persoons
@ 2004-11-08 17:59                                                 ` Norberto Bensa
  2004-11-08 19:01                                                   ` K.R. Foley
  2004-11-09 16:05                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23 Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Norberto Bensa @ 2004-11-08 17:59 UTC (permalink / raw)
  To: linux-kernel
  Cc: Ingo Molnar, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman

Hello Ingo,

Ingo Molnar wrote:
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V
>0.7.21

Unfortunately, it seems corrupted.

Regards,
Norberto

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21
  2004-11-08 17:59                                                 ` Norberto Bensa
@ 2004-11-08 19:01                                                   ` K.R. Foley
  2004-11-08 23:42                                                     ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-11-08 19:01 UTC (permalink / raw)
  To: Norberto Bensa
  Cc: linux-kernel, Ingo Molnar, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman

Norberto Bensa wrote:
> Hello Ingo,
> 
> Ingo Molnar wrote:
> 
>>http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V
>>0.7.21
> 
> 
> Unfortunately, it seems corrupted.
> 
> Regards,
> Norberto
> 

Yeah, what he said. :)

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19
  2004-11-08  9:16                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19 Ingo Molnar
                                                                 ` (2 preceding siblings ...)
  2004-11-08 16:57                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21 Ingo Molnar
@ 2004-11-08 22:21                                               ` Adam Heath
  3 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-11-08 22:21 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman

On Mon, 8 Nov 2004, Ingo Molnar wrote:

>
> i have released the -V0.7.19 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/
>
> this release includes fixes only.
>
> Changes since -V0.7.18:
>
>  - fixed a merge bug introduced in -V0.7.18, breaking bit-spinlocks used
>    by ext3's journalling code. This could/should fix the kjournald crash
>    reported by Adam Heath, Gunther Persoons and Eran Mann. Bug triggered
>    on !SMP kernels only.

The last kernel I tried was v0.7.13, so I doubt it was a recent introduction.

Will try something newer soon.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21
  2004-11-08 17:41                                                 ` Gunther Persoons
@ 2004-11-08 23:41                                                   ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-08 23:41 UTC (permalink / raw)
  To: Gunther Persoons; +Cc: linux-kernel


* Gunther Persoons <gunther_persoons@spymac.com> wrote:

> When trying to patch my kernel i get following notice:
> patching file include/linux/highmem.h
> patch unexpectedly ends in middle of line
> patch: **** unexpected end of file in patch

yeah ... the result of an incomplete upload. I've uploaded -V0.7.22 that
is a full patch. (no other changes)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21
  2004-11-08 19:01                                                   ` K.R. Foley
@ 2004-11-08 23:42                                                     ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-08 23:42 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Norberto Bensa, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman


* K.R. Foley <kr@cybsft.com> wrote:

> >Unfortunately, it seems corrupted.

> Yeah, what he said. :)

i've uploaded -V0.7.22, please try that instead.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-08 16:57                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21 Ingo Molnar
  2004-11-08 17:41                                                 ` Gunther Persoons
  2004-11-08 17:59                                                 ` Norberto Bensa
@ 2004-11-09 16:05                                                 ` Ingo Molnar
  2004-11-10 13:52                                                   ` Karsten Wiese
                                                                     ` (3 more replies)
  2 siblings, 4 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-09 16:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


i have released the -V0.7.23 Real-Time Preemption patch, which can be
downloaded from the usual place:

    http://redhat.com/~mingo/realtime-preempt/

this release includes fixes, development/debugging improvements and
latency improvements and other speedups.

the biggest change is the reworked timing/tracing framework. Wakeup
timing became a compile-time thing and can be selected independently of
the preemption mode - i.e. it can now be used on near-vanilla !PREEMPT
kernels too, providing good wakeup-latency comparison of the various
preemption models.

irqs-off and preempt-off critical section timing/tracing can be selected
if wakeup timing is disabled, the two options can be selected separately
or together as well.

another improvement is that wakeup-timing now works correctly on SMP too
- the tracer 'follows' the highest-priority task in the system as it
gets bounced between CPUs and always traces the CPU where the task is
pending.

other changes since -V0.7.22:

 - semaphore livelock fix: feedback from Mark H. Johnson pinpointed a 
   bug in the down_trylock() semaphore code: if preempted in the wrong
   moment a lower-prio task could cause a higher-prio task to livelock
   indefinitely. This fix could solve the 'keventd looping' problem 
   reported by Mark.

   the fix is to make the down_trylock() code a bit simpler, but this
   also introduces the potential for down_trylock() to get 'spurious' 
   locking-rejects. Hopefully this wont be a big problem - we dont 
   really guarantee that down_trylock() succeeds - but code using higher
   semaphore counts to track resources could be negatively impacted by
   this. We'll see.

 - console assert fix: implemented a different type of fbcon
   RT-preemption handling variant, this could solve the assert reported
   by Amit Shah.

 - debugging improvement: implemented a sequence counter for max latency 
   traces. This has the advantage of solving the 'slow console on SMP
   problem': the latency-timing code used to get confused by another CPU 
   printing a timing message to a slow console and thus delaying that 
   other CPU. Now any latency that gets generated while a maximum is 
   printed is skipped.

 - further shrunk the non-debug size of struct rt_mutex by moving the 
   save_state logic into the debug paths - size is now 4 machine-words.

 - fixed CONFIG_HIGHMEM latencies: all atomic-kmap APIs are now wrapped 
   seemlessly and in a preemptible way.

 - implemented an IO-APIC register cache to speed up the IRQ-redirection
   latency hotpath. Also, made the POST flush a bit faster.

 - disable KGDB if PREEMPT_RT - it's broken for now.

 - move some runtime checks to under DEBUG_PREEMPT - this speeds up 
   CRITICAL_PREEMPT_TIMING.

to create a -V0.7.23 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.23

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-09 16:05                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23 Ingo Molnar
@ 2004-11-10 13:52                                                   ` Karsten Wiese
  2004-11-10 13:58                                                     ` Karsten Wiese
  2004-11-10 15:01                                                     ` Ingo Molnar
  2004-11-11  4:34                                                   ` K.R. Foley
                                                                     ` (2 subsequent siblings)
  3 siblings, 2 replies; 951+ messages in thread
From: Karsten Wiese @ 2004-11-10 13:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

Am Dienstag 09 November 2004 17:05 schrieb Ingo Molnar:
> 
> i have released the -V0.7.23 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>     http://redhat.com/~mingo/realtime-preempt/

Hi

On SMP/HT/P4 I get:
 BUG: lock held at task exit time!

This was captured via netconsole:
<NETCONSOLELOG>
apm: disabled - APM is not SMP safe.
sh:5429 BUG: lock held at task exit time!
 [c03af1c4] {kernel_sem.lock}
.. held by:                sh/ 5429 [f4d2c420, 117]
... acquired at:  __reacquire_kernel_lock+0x2e/0x60
sh/5429: BUG in __up_mutex at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/kernel/rt.c:1064
BUG: sleeping function called from invalid context sh(5429) at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/kernel/rt.c:1314
in_atomic():1 [00000003], irqs_disabled():0
 [<c010704e>] dump_stack+0x23/0x25 (20)
 [<c011d10b>] __might_sleep+0xbc/0xcf (36)
 [<c013a136>] __spin_lock+0x34/0x50 (24)
 [<c013a16f>] _spin_lock+0x1d/0x1f (16)
 [<c014e36b>] kmem_cache_alloc+0x37/0xf1 (32)
 [<c02c95d4>] alloc_skb+0x28/0xe6 (32)
 [<c02da818>] find_skb+0x31/0x9b (24)
 [<c02da97a>] netpoll_send_udp+0x40/0x25a (48)
 [<c028f246>] write_msg+0x56/0xfa (52)
 [<c0120e06>] __call_console_drivers+0x56/0x65 (32)
 [<c0120f49>] call_console_drivers+0xac/0x163 (36)
 [<c0121326>] release_console_sem+0x33/0xde (32)
 [<c012122c>] vprintk+0x134/0x16d (36)
 [<c01210f6>] printk+0x1d/0x1f (16)
 [<c01390ee>] __up_mutex+0x270/0x443 (68)
 [<c0139fc2>] up+0xe0/0xec (36)
 [<c0342e95>] __schedule+0x985/0xdb4 (124)
 [<c0123afc>] do_exit+0x331/0x59f (48)
 [<c0123e81>] do_group_exit+0x39/0xd1 (40)
 [<c01061a1>] sysenter_past_esp+0x52/0x71 (-4028)
---------------------------
| preempt count: 00000004 ]
| 4-level deep critical section nesting:
----------------------------------------
.. [<c0344e5b>] .... _raw_spin_lock+0x1c/0x73
.....[<c0142848>] ..   ( <= __do_IRQ+0xf6/0x16e)
.. [<c0344e5b>] .... _raw_spin_lock+0x1c/0x73
.....[<c010b340>] ..   ( <= timer_interrupt+0xd3/0x10f)
.. [<c0344e5b>] .... _raw_spin_lock+0x1c/0x73
.....[<c013b1c9>] ..   ( <= trace_start_sched_wakeup+0x22/0x7e)
.. [<c013b764>] .... print_traces+0x1b/0x52
.....[<c010704e>] ..   ( <= dump_stack+0x23/0x25)

 [<c010704e>] dump_stack+0x23/0x25 (20)
 [<c01390f3>] __up_mutex+0x275/0x443 (68)
 [<c0139fc2>] up+0xe0/0xec (36)
 [<c0342e95>] __schedule+0x985/0xdb4 (124)
 [<c0123afc>] do_exit+0x331/0x59f (48)
 [<c0123e81>] do_group_exit+0x39/0xd1 (40)
 [<c01061a1>] sysenter_past_esp+0x52/0x71 (-4028)
---------------------------
| preempt count: 00000004 ]
| 4-level deep critical section nesting:
----------------------------------------
.. [<c0344e5b>] .... _raw_spin_lock+0x1c/0x73
.....[<c0142848>] ..   ( <= __do_IRQ+0xf6/0x16e)
.. [<c0344e5b>] .... _raw_spin_lock+0x1c/0x73
.....[<c010b340>] ..   ( <= timer_interrupt+0xd3/0x10f)
.. [<c0344e5b>] .... _raw_spin_lock+0x1c/0x73
.....[<c013b1c9>] ..   ( <= trace_start_sched_wakeup+0x22/0x7e)
.. [<c013b764>] .... print_traces+0x1b/0x52
.....[<c010704e>] ..   ( <= dump_stack+0x23/0x25)

autom4te/5419: BUG in lock_new_owner at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/kernel/rt.c:651
 [<c010704e>] dump_stack+0x23/0x25 (20)
BUG: scheduling while atomic: autom4te/0x00000001/5419
caller is schedule+0x38/0x12e
 [<c010704e>] dump_stack+0x23/0x25 (20)
 [<c0342f06>] __schedule+0x9f6/0xdb4 (124)
 [<c03432fc>] schedule+0x38/0x12e (36)
 [<c0344758>] __down_mutex+0x225/0x30f (84)
 [<c013a148>] __spin_lock+0x46/0x50 (24)
 [<c013a1cc>] _spin_lock_irqsave+0x1d/0x21 (16)
 [<c028b31e>] e100_xmit_frame+0x13f/0x2d8 (60)
 [<c02da8a5>] netpoll_send_skb+0x23/0xb8 (28)
 [<c028f246>] write_msg+0x56/0xfa (52)
 [<c0120e06>] __call_console_drivers+0x56/0x65 (32)
 [<c0120f49>] call_console_drivers+0xac/0x163 (36)
 [<c0121326>] release_console_sem+0x33/0xde (32)
 [<c012122c>] vprintk+0x134/0x16d (36)
 [<c01210f6>] printk+0x1d/0x1f (16)
 [<c0106f4c>] show_trace+0x89/0xcd (36)
 [<c010704e>] dump_stack+0x23/0x25 (20)
 [<c0138be0>] lock_new_owner+0xbe/0xe2 (40)
 [<c034462e>] __down_mutex+0xfb/0x30f (84)
 [<c013a148>] __spin_lock+0x46/0x50 (24)
 [<c013a1cc>] _spin_lock_irqsave+0x1d/0x21 (16)
 [<c012a6d8>] del_timer+0x2c/0xe4 (32)
 [<c012a7e1>] del_timer_sync+0x51/0x14b (104)
 [<c0330469>] __rpc_execute+0x8d/0x3db (112)
 [<c032bd4e>] rpc_call_sync+0x9b/0xc8 (40)
 [<c01b7b4d>] nfs3_rpc_wrapper+0x3d/0x82 (40)
 [<c01b7d31>] nfs3_proc_getattr+0x50/0x81 (40)
 [<c01aeeec>] __nfs_revalidate_inode+0xf3/0x3b7 (192)
 [<c01aac1c>] nfs_lookup_revalidate+0x37e/0x54c (352)
 [<c0173220>] do_lookup+0x53/0x8d (32)
 [<c01733da>] link_path_walk+0x180/0x1071 (108)
 [<c01745f2>] path_lookup+0xa5/0x1b0 (32)
 [<c017489f>] __user_walk+0x30/0x4d (32)
 [<c016ed2b>] vfs_stat+0x1f/0x5a (92)
 [<c016f3c4>] sys_stat64+0x1e/0x3d (100)
 [<c01061a1>] sysenter_past_esp+0x52/0x71 (-4028)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c0344e5b>] .... _raw_spin_lock+0x1c/0x73
.....[<c0118894>] ..   ( <= task_rq_lock+0x32/0x5b)
.. [<c013b764>] .... print_traces+0x1b/0x52
.....[<c010704e>] ..   ( <= dump_stack+0x23/0x25)
</NETCONSOLELOG>

The "lock_new_owner" BUGs then repeated until the machine was restarted.

With HIGHMEM enabled, there were really weired things happening.
<HIGHMEMENABLEDLOG>
BUG at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/mm/highmem.c:191!
------------[ cut here ]------------
BUG: sleeping function called from invalid context init(1) at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/kernel/rt.c:1314
in_atomic():1 [00000001], irqs_disabled():0
 [<c010704e>] dump_stack+0x23/0x25 (20)
 [<c011d3db>] __might_sleep+0xbc/0xcf (36)
 [<c013a3e6>] __spin_lock+0x34/0x50 (24)
 [<c013a41f>] _spin_lock+0x1d/0x1f (16)
 [<c014e632>] kmem_cache_alloc+0x37/0xf1 (32)
 [<c02ca4f4>] alloc_skb+0x28/0xe6 (32)
 [<c02db938>] find_skb+0x31/0x9b (24)
 [<c02dba9a>] netpoll_send_udp+0x40/0x25a (48)
 [<c02900c6>] write_msg+0x56/0xfa (52)
 [<c01210d6>] __call_console_drivers+0x56/0x65 (32)
 [<c0121219>] call_console_drivers+0xac/0x163 (36)
 [<c01215f6>] release_console_sem+0x33/0xde (32)
 [<c01214fc>] vprintk+0x134/0x16d (36)
 [<c01213c6>] printk+0x1d/0x1f (16)
 [<c0107299>] handle_BUG+0x63/0x9e (28)
 [<c0107356>] die+0x82/0x195 (64)
 [<c01079ac>] do_invalid_op+0x127/0x129 (192)
 [<c0106c73>] error_code+0x2b/0x30 (76)
 [<c01541dc>] copy_pte_range+0xd8/0x1e3 (48)
 [<c015439b>] copy_pmd_range+0xb4/0xca (52)
 [<c015441e>] copy_pgd_range+0x6d/0x8c (48)
 [<c0154483>] copy_page_range+0x46/0x4e (48)
 [<c011e76c>] copy_mm+0x28a/0x3ac (76)
 [<c011f352>] copy_process+0x54a/0xf1b (76)
 [<c011fe2c>] do_fork+0x6e/0x1ce (132)
 [<c0104d08>] sys_fork+0x3d/0x3f (32)
 [<c01061a1>] sysenter_past_esp+0x52/0x71 (-4028)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c0345fad>] .... _raw_spin_lock_irqsave+0x1b/0x70
.....[<c0107318>] ..   ( <= die+0x44/0x195)
.. [<c013ba14>] .... print_traces+0x1b/0x52
.....[<c010704e>] ..   ( <= dump_stack+0x23/0x25)

</HIGHMEMENABLEDLOG>

looks like some machinecode was undigestible for the cpu, no?

Best regards,
Karsten

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-10 13:52                                                   ` Karsten Wiese
@ 2004-11-10 13:58                                                     ` Karsten Wiese
  2004-11-10 15:01                                                     ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Karsten Wiese @ 2004-11-10 13:58 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

Am Mittwoch 10 November 2004 14:52 schrieb Karsten Wiese:
> Am Dienstag 09 November 2004 17:05 schrieb Ingo Molnar:
> > 
> > i have released the -V0.7.23 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> > 
> >     http://redhat.com/~mingo/realtime-preempt/
> 
> Hi
> 
> On SMP/HT/P4 I get:
>  BUG: lock held at task exit time!

Forgot to write that this happened with V0.7.24.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-10 15:01                                                     ` Ingo Molnar
@ 2004-11-10 14:20                                                       ` Karsten Wiese
  2004-11-10 14:50                                                         ` Karsten Wiese
  2004-11-10 15:33                                                         ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Karsten Wiese @ 2004-11-10 14:20 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

Am Mittwoch 10 November 2004 16:01 schrieb Ingo Molnar:
> 
> * Karsten Wiese <annabellesgarden@yahoo.de> wrote:
> 
> > Hi
> > 
> > On SMP/HT/P4 I get:
> >  BUG: lock held at task exit time!
> 
> > sh/5429: BUG in __up_mutex at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/kernel/rt.c:1064
> > BUG: sleeping function called from invalid context sh(5429) at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/kernel/rt.c:1314
> > in_atomic():1 [00000003], irqs_disabled():0
> 
> hm, apparently something leaked a BKL count. Unfortunately we dont know
> precisely what did it, only that it happened. Did this happen during
> bootup, or during normal use. Can you trigger it arbitrarily?

Yes, it always happens, when callling ./cvscompile script of a project, that is mounted via nfs.
Haven't tried to do that ./cvscompile locally, should I?

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-10 14:20                                                       ` Karsten Wiese
@ 2004-11-10 14:50                                                         ` Karsten Wiese
  2004-11-10 15:33                                                         ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Karsten Wiese @ 2004-11-10 14:50 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

Am Mittwoch 10 November 2004 15:20 schrieb Karsten Wiese:
> Am Mittwoch 10 November 2004 16:01 schrieb Ingo Molnar:
> > 
> > * Karsten Wiese <annabellesgarden@yahoo.de> wrote:
> > 
> > > Hi
> > > 
> > > On SMP/HT/P4 I get:
> > >  BUG: lock held at task exit time!
> > 
> > > sh/5429: BUG in __up_mutex at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/kernel/rt.c:1064
> > > BUG: sleeping function called from invalid context sh(5429) at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/kernel/rt.c:1314
> > > in_atomic():1 [00000003], irqs_disabled():0
> > 
> > hm, apparently something leaked a BKL count. Unfortunately we dont know
> > precisely what did it, only that it happened. Did this happen during
> > bootup, or during normal use. Can you trigger it arbitrarily?
> 
> Yes, it always happens, when callling ./cvscompile script of a project, that is mounted via nfs.
> Haven't tried to do that ./cvscompile locally, should I?

./cvscompile locally is ok.
Also if I disable HT in BIOS, the machine survives the crash "./cvscompile"ing via nfs 
and the next "./cvscompile"s over nfs are ok. Also if I unmount / mount the nfs share again.
So it always happens the first time calling this ./cvscompile via nfs.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-10 13:52                                                   ` Karsten Wiese
  2004-11-10 13:58                                                     ` Karsten Wiese
@ 2004-11-10 15:01                                                     ` Ingo Molnar
  2004-11-10 14:20                                                       ` Karsten Wiese
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-10 15:01 UTC (permalink / raw)
  To: Karsten Wiese
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Karsten Wiese <annabellesgarden@yahoo.de> wrote:

> Hi
> 
> On SMP/HT/P4 I get:
>  BUG: lock held at task exit time!

> sh/5429: BUG in __up_mutex at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/kernel/rt.c:1064
> BUG: sleeping function called from invalid context sh(5429) at /home/ka/kernel/2.6/linux-2.6.9-rc1-mm3-RT/kernel/rt.c:1314
> in_atomic():1 [00000003], irqs_disabled():0

hm, apparently something leaked a BKL count. Unfortunately we dont know
precisely what did it, only that it happened. Did this happen during
bootup, or during normal use. Can you trigger it arbitrarily?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-10 14:20                                                       ` Karsten Wiese
  2004-11-10 14:50                                                         ` Karsten Wiese
@ 2004-11-10 15:33                                                         ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-10 15:33 UTC (permalink / raw)
  To: Karsten Wiese
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Karsten Wiese <annabellesgarden@yahoo.de> wrote:

> Yes, it always happens, when callling ./cvscompile script of a
> project, that is mounted via nfs. Haven't tried to do that
> ./cvscompile locally, should I?

very interesting, nfs is indeed one of the frequent BKL users.

a 'BKL leak' is an unbalanced lock, e.g.:

	lock_kernel();
	... do stuff ...
	if (error)
		return;
	... do more stuff ...
	unlock_kernel();

the BKL is a very special type of lock which fact has the side-effect
that in the stock kernel a 'BKL leak' can go unnoticed very easily: it
causes no problems other than hard-to-debug (but severe) scalability
regressions. The moment the BKL count leaked from the NFS code that
process has been 'scalability-poisoned' and will be handicapped until it
exits.

In the PREEMPT_RT patchset i added a strict locking checker to do_exit()
that found this apparent NFS bug. Unfortunately the deadlock detector
only reported a pretty common place where the BKL gets
dropped/reacquired frequently so we dont know where the NFS code has the
lock/unlock imbalance. Could you report this bug to the NFS maintainers
(along with the above and the previous analysis)?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-09 16:05                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23 Ingo Molnar
  2004-11-10 13:52                                                   ` Karsten Wiese
@ 2004-11-11  4:34                                                   ` K.R. Foley
  2004-11-11  5:01                                                   ` K.R. Foley
  2004-11-11 14:44                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0 Ingo Molnar
  3 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-11-11  4:34 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

Ingo Molnar wrote:
> i have released the -V0.7.23 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>     http://redhat.com/~mingo/realtime-preempt/
> 

I have found some test results that I find interesting with -V0.7.24. I 
modified the rtc-debug patch to work with any program that can use the 
rtc driver. It measures the latency between handling an interrupt and 
the actual read. The amlat program normally used with this patch sets up 
a signal handler that reads /dev/rtc when there is data available and 
then sleeps until it receives the signal. Realfeel just does a blocking 
read on /dev/rtc. Oh and both of them setup the rtc for periodic 
interrupts. I would probably expect the blocking read to be a bit faster 
but not dramatically. Here are the results of a couple of very short 
runs to illustrate the difference:

amlat results (sleep/sighandler):
Nov 10 21:10:39 daffy kernel: rtc histogram:
Nov 10 21:10:39 daffy kernel: 26 1
Nov 10 21:10:39 daffy kernel: 28 2152
Nov 10 21:10:39 daffy kernel: 29 4286
Nov 10 21:10:39 daffy kernel: 30 6857
Nov 10 21:10:39 daffy kernel: 31 408
Nov 10 21:10:39 daffy kernel: 32 9
Nov 10 21:10:39 daffy kernel: 33 32
Nov 10 21:10:39 daffy kernel: 34 217
Nov 10 21:10:39 daffy kernel: 35 145
Nov 10 21:10:39 daffy kernel: 36 26
Nov 10 21:10:39 daffy kernel: 40 2
Nov 10 21:10:39 daffy kernel: 41 9
Nov 10 21:10:39 daffy kernel: 42 100
Nov 10 21:10:39 daffy kernel: 43 180
Nov 10 21:10:39 daffy kernel: 44 113
Nov 10 21:10:39 daffy kernel: 45 30
Nov 10 21:10:39 daffy kernel: 46 2
Nov 10 21:10:39 daffy kernel: 47 4
Nov 10 21:10:39 daffy kernel: 48 15
Nov 10 21:10:39 daffy kernel: 49 4
Nov 10 21:10:39 daffy kernel: 50 5
Nov 10 21:10:39 daffy kernel:
Nov 10 21:10:39 daffy kernel: Total samples: 14597

realfeel results (blocking read):
Nov 10 21:11:32 daffy kernel: rtc histogram:
Nov 10 21:11:32 daffy kernel: 3 17844
Nov 10 21:11:32 daffy kernel: 4 859
Nov 10 21:11:32 daffy kernel: 5 34
Nov 10 21:11:32 daffy kernel: 6 1
Nov 10 21:11:32 daffy kernel: 8 1
Nov 10 21:11:32 daffy kernel: 12 19
Nov 10 21:11:32 daffy kernel: 13 41
Nov 10 21:11:32 daffy kernel: 14 7
Nov 10 21:11:32 daffy kernel:
Nov 10 21:11:32 daffy kernel: Total samples: 18806

Both of the above runs were with 'IRQ 8' running at SCHED_FF 99. Amlat 
and realfeel were both running at SCHED_FF 98. The updated  rtc-debug 
patch to follow in case anyone is interested.

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-09 16:05                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23 Ingo Molnar
  2004-11-10 13:52                                                   ` Karsten Wiese
  2004-11-11  4:34                                                   ` K.R. Foley
@ 2004-11-11  5:01                                                   ` K.R. Foley
  2004-11-11  9:52                                                     ` Ingo Molnar
  2004-11-11 10:20                                                     ` Ingo Molnar
  2004-11-11 14:44                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0 Ingo Molnar
  3 siblings, 2 replies; 951+ messages in thread
From: K.R. Foley @ 2004-11-11  5:01 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

Ingo Molnar wrote:
> i have released the -V0.7.23 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 

Here is the updated rtc-debug patch. This version unlike previous 
versions doesn't change the way the rtc driver works. The output of 
/dev/rtc is preserved also so it doesn't break the existing 
functionality of rtc. By the same token it won't produce output usable 
by amlat, but it works for measuring the latency from interrupt to read. 
It doesn't measure when a poll is satisfied yet because I didn't need 
that yet. It doesn't trigger the end until the read.

kr

[-- Attachment #2: rtc-debug2.patch --]
[-- Type: text/x-patch, Size: 4504 bytes --]

--- linux-2.6.10-rc1-mm3/drivers/char/rtc.c.orig	2004-11-10 21:27:39.106900807 -0600
+++ linux-2.6.10-rc1-mm3/drivers/char/rtc.c	2004-11-10 20:45:39.000000000 -0600
@@ -86,6 +86,18 @@
 #include <asm/hpet.h>
 #endif
 
+static unsigned long long last_interrupt_time;
+
+#include <asm/timex.h>
+
+
+#define CPU_MHZ	(cpu_khz / 1000)
+#define HISTSIZE	10000
+static int histogram[HISTSIZE];
+
+int rtc_debug;
+int rtc_running;
+
 #ifdef __sparc__
 #include <linux/pci.h>
 #include <asm/ebus.h>
@@ -191,6 +203,14 @@
 static const unsigned char days_in_mo[] = 
 {0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
 
+static int rtc_state;
+
+enum rtc_states {
+	S_IDLE,			/* Waiting for an interrupt */
+	S_WAITING_FOR_READ,	/* Signal delivered. waiting for rtc_read() */
+	S_READ_MISSED,		/* Signal delivered, read() deadline missed */
+};
+
 /*
  * Returns true if a clock update is in progress
  */
@@ -259,7 +279,37 @@
 	spin_unlock_irqrestore(&rtc_task_lock, flags);
 	wake_up_interruptible(&rtc_wait);	
 
-	kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+	if (!(rtc_status & RTC_IS_OPEN))
+		goto tata;
+
+	switch (rtc_state) {
+	case S_IDLE:			/* Waiting for an interrupt */
+		rdtscll(last_interrupt_time);
+		kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+		rtc_state = S_WAITING_FOR_READ;
+		break;
+	case S_WAITING_FOR_READ:	/* Signal has been delivered. waiting for rtc_read() */
+		/*
+		 * Well foo.  The usermode application didn't schedule and read in time.
+		 */
+		rtc_state = S_READ_MISSED;
+		if (strcmp(current->comm, "amlat") != 0) {
+			printk("`%s'[%d] is being piggy.  "
+					"need_resched=%d, cpu=%d\n",
+				current->comm, current->pid,
+				need_resched(), smp_processor_id());
+			/* show_trace_smp(); */
+		}
+		printk("Read missed before next interrupt\n");
+		break;
+	case S_READ_MISSED:		/* Signal has been delivered, read() deadline was missed */
+		/*
+		 * Not much we can do here.  We're waiting for the usermode
+		 * application to read the rtc
+		 */
+		break;
+	}
+tata:
 
 	return IRQ_HANDLED;
 }
@@ -328,6 +378,7 @@
 	DECLARE_WAITQUEUE(wait, current);
 	unsigned long data;
 	ssize_t retval;
+	unsigned long long now;
 	
 	if (rtc_has_irq == 0)
 		return -EIO;
@@ -363,6 +414,56 @@
 		schedule();
 	} while (1);
 
+	rdtscll(now);
+
+	switch (rtc_state) {
+	case S_IDLE:			/* Waiting for an interrupt */
+		/*
+		 * err...  This can't be happening
+		 */
+		printk("rtc_read(): called in state S_IDLE!\n");
+		break;
+	case S_WAITING_FOR_READ:	/*
+					 * Signal has been delivered.
+					 * waiting for rtc_read()
+					 */
+		/*
+		 * Well done
+		 */
+	case S_READ_MISSED:		/*
+					 * Signal has been delivered, read()
+					 * deadline was missed
+					 */
+		/*
+		 * So, you finally got here.
+		 */
+		if (last_interrupt_time == 0)
+			printk("rtc_read(): we screwed up.  "
+					"last_interrupt_time = 0\n");
+		rtc_state = S_IDLE;
+		{
+			unsigned long long latency = now - last_interrupt_time;
+			unsigned long delta;	/* Nocroseconds */
+
+			delta = latency;
+			delta /= CPU_MHZ;
+			if (delta > 1000 * 1000) {
+				printk("rtc: eek\n");
+			} else {
+				unsigned long slot = delta;
+				if (slot >= HISTSIZE)
+					slot = HISTSIZE - 1;
+				histogram[slot]++;
+				if (delta > 2000)
+					printk("wow!  That was a "
+							"%ld millisec bump\n",
+						delta / 1000);
+			}
+		}
+		rtc_state = S_IDLE;
+		break;
+	}
+
 	if (count < sizeof(unsigned long))
 		retval = put_user(data, (unsigned int __user *)buf) ?: sizeof(int); 
 	else
@@ -692,6 +793,8 @@
  * needed here. Or anywhere else in this driver. */
 static int rtc_open(struct inode *inode, struct file *file)
 {
+	int i;
+
 	spin_lock_irq (&rtc_lock);
 
 	if(rtc_status & RTC_IS_OPEN)
@@ -700,6 +803,14 @@
 	rtc_status |= RTC_IS_OPEN;
 
 	rtc_irq_data = 0;
+	last_interrupt_time = 0;
+	rtc_state = S_IDLE;
+	rtc_irq_data = 0;
+
+	rtc_running = 1;
+	for (i = 0; i < HISTSIZE; i++)
+		histogram[i] = 0;
+
 	spin_unlock_irq (&rtc_lock);
 	return 0;
 
@@ -753,6 +864,19 @@
 	rtc_irq_data = 0;
 	rtc_status &= ~RTC_IS_OPEN;
 	spin_unlock_irq (&rtc_lock);
+	{
+		int i = 0;
+		unsigned long total = 0;
+		printk("rtc histogram:\n");
+		for (i = 0; i < HISTSIZE; i++) {
+			if (histogram[i]) {
+				total += histogram[i];
+				printk("%d %d\n", i, histogram[i]);
+			}
+		}
+		printk("\nTotal samples: %lu\n", total);
+		rtc_running = 0;
+	}
 	return 0;
 }
 
@@ -1127,6 +1251,7 @@
 	wake_up_interruptible(&rtc_wait);
 
 	kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+	return;
 }
 #endif
 

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-11  5:01                                                   ` K.R. Foley
@ 2004-11-11  9:52                                                     ` Ingo Molnar
  2004-11-11 10:20                                                     ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-11  9:52 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Andrew Morton


* K.R. Foley <kr@cybsft.com> wrote:

> Ingo Molnar wrote:
> >i have released the -V0.7.23 Real-Time Preemption patch, which can be
> >downloaded from the usual place:
> >
> 
> Here is the updated rtc-debug patch. This version unlike previous
> versions doesn't change the way the rtc driver works. The output of
> /dev/rtc is preserved also so it doesn't break the existing
> functionality of rtc. By the same token it won't produce output usable
> by amlat, but it works for measuring the latency from interrupt to
> read. 

looks good - i've added this to my tree. (with minor portability fixes:
rdtscll -> get_cycles(), long long -> cycles_t)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-11  5:01                                                   ` K.R. Foley
  2004-11-11  9:52                                                     ` Ingo Molnar
@ 2004-11-11 10:20                                                     ` Ingo Molnar
  2004-11-11 13:05                                                       ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-11 10:20 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]


* K.R. Foley <kr@cybsft.com> wrote:

> Here is the updated rtc-debug patch. This version unlike previous
> versions doesn't change the way the rtc driver works. The output of
> /dev/rtc is preserved also so it doesn't break the existing
> functionality of rtc. By the same token it won't produce output usable
> by amlat, but it works for measuring the latency from interrupt to
> read.  It doesn't measure when a poll is satisfied yet because I
> didn't need that yet. It doesn't trigger the end until the read.

i've done some further cleanups: made it .config configurable
(CONFIG_RTC_HISTOGRAM), moved the latency-histogram construction code
into separate functions to make it more apparent that there is no impact
to the normal codepaths. Patch attached.

	Ingo

[-- Attachment #2: rtc-hist-2.6.10-rc1-mm3-A0 --]
[-- Type: text/plain, Size: 5121 bytes --]

--- linux/drivers/char/Kconfig.orig
+++ linux/drivers/char/Kconfig
@@ -729,6 +729,15 @@ config RTC
 	  To compile this driver as a module, choose M here: the
 	  module will be called rtc.
 
+config RTC_HISTOGRAM
+	tristate "Real Time Clock Histogram Support"
+	default y
+	depends on RTC
+	---help---
+	  If you say Y here then the kernel will track the delivery and
+	  wakeup latency of /dev/rtc using tasks and will report a
+	  histogram to the kernel log when the application closes /dev/rtc.
+
 config SGI_DS1286
 	tristate "SGI DS1286 RTC support"
 	depends on SGI_IP22
--- linux/drivers/char/rtc.c.orig
+++ linux/drivers/char/rtc.c
@@ -86,6 +86,28 @@
 #include <asm/hpet.h>
 #endif
 
+#ifdef CONFIG_RTC_HISTOGRAM
+
+static int rtc_running;
+static cycles_t last_interrupt_time;
+
+#include <asm/timex.h>
+
+#define CPU_MHZ		(cpu_khz / 1000)
+
+#define HISTSIZE	10000
+static int histogram[HISTSIZE];
+
+static int rtc_state;
+
+enum rtc_states {
+	S_IDLE,			/* Waiting for an interrupt */
+	S_WAITING_FOR_READ,	/* Signal delivered. waiting for rtc_read() */
+	S_READ_MISSED,		/* Signal delivered, read() deadline missed */
+};
+
+#endif
+
 #ifdef __sparc__
 #include <linux/pci.h>
 #include <asm/ebus.h>
@@ -205,6 +227,132 @@ static inline unsigned char rtc_is_updat
 }
 
 #ifdef RTC_IRQ
+
+static inline void rtc_open_event(void)
+{
+#ifdef CONFIG_RTC_HISTOGRAM
+	int i;
+
+	last_interrupt_time = 0;
+	rtc_state = S_IDLE;
+	rtc_irq_data = 0;
+
+	rtc_running = 1;
+	for (i = 0; i < HISTSIZE; i++)
+		histogram[i] = 0;
+#endif
+}
+
+static inline void rtc_wake_event(void)
+{
+#ifndef CONFIG_RTC_HISTOGRAM
+	kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+#else
+	if (!(rtc_status & RTC_IS_OPEN))
+		return;
+
+	switch (rtc_state) {
+	case S_IDLE:			/* Waiting for an interrupt */
+		last_interrupt_time = get_cycles();
+		kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+		rtc_state = S_WAITING_FOR_READ;
+		break;
+	case S_WAITING_FOR_READ:	/* Signal has been delivered. waiting for rtc_read() */
+		/*
+		 * Well foo.  The usermode application didn't schedule and read in time.
+		 */
+		rtc_state = S_READ_MISSED;
+		if (strcmp(current->comm, "amlat") != 0) {
+			printk("`%s'[%d] is being piggy.  "
+					"need_resched=%d, cpu=%d\n",
+				current->comm, current->pid,
+				need_resched(), smp_processor_id());
+			/* show_trace_smp(); */
+		}
+		printk("Read missed before next interrupt\n");
+		break;
+	case S_READ_MISSED:		/* Signal has been delivered, read() deadline was missed */
+		/*
+		 * Not much we can do here.  We're waiting for the usermode
+		 * application to read the rtc
+		 */
+		break;
+	}
+#endif
+}
+
+static inline void rtc_read_event(void)
+{
+#ifdef CONFIG_RTC_HISTOGRAM
+	cycles_t now = get_cycles();
+
+	switch (rtc_state) {
+	case S_IDLE:			/* Waiting for an interrupt */
+		/*
+		 * err...  This can't be happening
+		 */
+		printk("rtc_read(): called in state S_IDLE!\n");
+		break;
+	case S_WAITING_FOR_READ:	/*
+					 * Signal has been delivered.
+					 * waiting for rtc_read()
+					 */
+		/*
+		 * Well done
+		 */
+	case S_READ_MISSED:		/*
+					 * Signal has been delivered, read()
+					 * deadline was missed
+					 */
+		/*
+		 * So, you finally got here.
+		 */
+		if (last_interrupt_time == 0)
+			printk("rtc_read(): we screwed up.  "
+					"last_interrupt_time = 0\n");
+		rtc_state = S_IDLE;
+		{
+			cycles_t latency = now - last_interrupt_time;
+			unsigned long delta;	/* Nocroseconds */
+
+			delta = latency;
+			delta /= CPU_MHZ;
+			if (delta > 1000 * 1000) {
+				printk("rtc: eek\n");
+			} else {
+				unsigned long slot = delta;
+				if (slot >= HISTSIZE)
+					slot = HISTSIZE - 1;
+				histogram[slot]++;
+				if (delta > 2000)
+					printk("wow!  That was a "
+							"%ld millisec bump\n",
+						delta / 1000);
+			}
+		}
+		rtc_state = S_IDLE;
+		break;
+	}
+#endif
+}
+
+static inline void rtc_close_event(void)
+{
+#ifdef CONFIG_RTC_HISTOGRAM
+	int i = 0;
+	unsigned long total = 0;
+	printk("rtc histogram:\n");
+	for (i = 0; i < HISTSIZE; i++) {
+		if (histogram[i]) {
+			total += histogram[i];
+			printk("%d %d\n", i, histogram[i]);
+		}
+	}
+	printk("\nTotal samples: %lu\n", total);
+	rtc_running = 0;
+#endif
+}
+
 /*
  *	A very tiny interrupt handler. It runs with SA_INTERRUPT set,
  *	but there is possibility of conflicting with the set_rtc_mmss()
@@ -250,7 +398,7 @@ irqreturn_t rtc_interrupt(int irq, void 
 	spin_unlock(&rtc_task_lock);
 	wake_up_interruptible(&rtc_wait);	
 
-	kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+	rtc_wake_event();
 
 	return IRQ_HANDLED;
 }
@@ -354,6 +502,8 @@ static ssize_t rtc_read(struct file *fil
 		schedule();
 	} while (1);
 
+	rtc_read_event();
+
 	if (count < sizeof(unsigned long))
 		retval = put_user(data, (unsigned int __user *)buf) ?: sizeof(int); 
 	else
@@ -692,6 +848,7 @@ static int rtc_open(struct inode *inode,
 	rtc_status |= RTC_IS_OPEN;
 
 	rtc_irq_data = 0;
+	rtc_open_event();
 	spin_unlock_irq (&rtc_lock);
 	return 0;
 
@@ -744,6 +901,7 @@ no_irq:
 	rtc_irq_data = 0;
 	rtc_status &= ~RTC_IS_OPEN;
 	spin_unlock_irq (&rtc_lock);
+	rtc_close_event();
 	return 0;
 }
 

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-11 13:05                                                       ` Ingo Molnar
@ 2004-11-11 12:27                                                         ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-11-11 12:27 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Andrew Morton

Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> 
>>i've done some further cleanups: made it .config configurable
>>(CONFIG_RTC_HISTOGRAM), moved the latency-histogram construction code
>>into separate functions to make it more apparent that there is no
>>impact to the normal codepaths. Patch attached.
> 
> 
> i've attached another update with a few more smaller details fixed:
> 
>  - only print the histogram if a /dev/rtc using application indeed used 
>    it to get interrupts. This removes bogus printouts triggered by 
>    hwclock.
> 
>  - skip the first RTC interrupt from the histogram - most of the
>    /dev/rtc applications do not handle the first event very well,
>    skewing the histogram.
> 
> 	Ingo

Very nicely done. Also much less of a hack now the way you took all of 
the code out of the normal codepaths and made it into inlines that 
pretty much compile out if not being used.

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23
  2004-11-11 10:20                                                     ` Ingo Molnar
@ 2004-11-11 13:05                                                       ` Ingo Molnar
  2004-11-11 12:27                                                         ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-11 13:05 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]


* Ingo Molnar <mingo@elte.hu> wrote:

> i've done some further cleanups: made it .config configurable
> (CONFIG_RTC_HISTOGRAM), moved the latency-histogram construction code
> into separate functions to make it more apparent that there is no
> impact to the normal codepaths. Patch attached.

i've attached another update with a few more smaller details fixed:

 - only print the histogram if a /dev/rtc using application indeed used 
   it to get interrupts. This removes bogus printouts triggered by 
   hwclock.

 - skip the first RTC interrupt from the histogram - most of the
   /dev/rtc applications do not handle the first event very well,
   skewing the histogram.

	Ingo

[-- Attachment #2: rtc-hist-2.6.10-rc1-mm3-A1 --]
[-- Type: text/plain, Size: 5237 bytes --]

--- linux/drivers/char/Kconfig.orig
+++ linux/drivers/char/Kconfig
@@ -729,6 +729,15 @@ config RTC
 	  To compile this driver as a module, choose M here: the
 	  module will be called rtc.
 
+config RTC_HISTOGRAM
+	tristate "Real Time Clock Histogram Support"
+	default y
+	depends on RTC
+	---help---
+	  If you say Y here then the kernel will track the delivery and
+	  wakeup latency of /dev/rtc using tasks and will report a
+	  histogram to the kernel log when the application closes /dev/rtc.
+
 config SGI_DS1286
 	tristate "SGI DS1286 RTC support"
 	depends on SGI_IP22
--- linux/drivers/char/rtc.c.orig
+++ linux/drivers/char/rtc.c
@@ -86,6 +86,28 @@
 #include <asm/hpet.h>
 #endif
 
+#ifdef CONFIG_RTC_HISTOGRAM
+
+static cycles_t last_interrupt_time;
+
+#include <asm/timex.h>
+
+#define CPU_MHZ		(cpu_khz / 1000)
+
+#define HISTSIZE	10000
+static int histogram[HISTSIZE];
+
+static int rtc_state;
+
+enum rtc_states {
+	S_STARTUP,		/* First round - let the application start */
+	S_IDLE,			/* Waiting for an interrupt */
+	S_WAITING_FOR_READ,	/* Signal delivered. waiting for rtc_read() */
+	S_READ_MISSED,		/* Signal delivered, read() deadline missed */
+};
+
+#endif
+
 #ifdef __sparc__
 #include <linux/pci.h>
 #include <asm/ebus.h>
@@ -205,6 +227,144 @@ static inline unsigned char rtc_is_updat
 }
 
 #ifdef RTC_IRQ
+
+static inline void rtc_open_event(void)
+{
+#ifdef CONFIG_RTC_HISTOGRAM
+	int i;
+
+	last_interrupt_time = 0;
+	rtc_state = S_STARTUP;
+	rtc_irq_data = 0;
+
+	for (i = 0; i < HISTSIZE; i++)
+		histogram[i] = 0;
+#endif
+}
+
+static inline void rtc_wake_event(void)
+{
+#ifndef CONFIG_RTC_HISTOGRAM
+	kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+#else
+	if (!(rtc_status & RTC_IS_OPEN))
+		return;
+
+	switch (rtc_state) {
+	/* Startup */
+	case S_STARTUP:
+		kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+		break;
+	/* Waiting for an interrupt */
+	case S_IDLE:
+		kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+		last_interrupt_time = get_cycles();
+		rtc_state = S_WAITING_FOR_READ;
+		break;
+
+	/* Signal has been delivered. waiting for rtc_read() */
+	case S_WAITING_FOR_READ:
+		/*
+		 * Well foo.  The usermode application didn't
+		 * schedule and read in time.
+		 */
+		rtc_state = S_READ_MISSED;
+		printk("`%s'[%d] is being piggy. need_resched=%d, cpu=%d\n",
+			current->comm, current->pid,
+				need_resched(), smp_processor_id());
+		printk("Read missed before next interrupt\n");
+		break;
+	/* Signal has been delivered, read() deadline was missed */
+	case S_READ_MISSED:
+		/*
+		 * Not much we can do here.  We're waiting for the usermode
+		 * application to read the rtc
+		 */
+		break;
+	}
+#endif
+
+}
+
+static inline void rtc_read_event(void)
+{
+#ifdef CONFIG_RTC_HISTOGRAM
+	cycles_t now = get_cycles();
+
+	switch (rtc_state) {
+	/* Startup */
+	case S_STARTUP:
+		rtc_state = S_IDLE;
+		break;
+		
+	/* Waiting for an interrupt */
+	case S_IDLE:
+		printk("bug in rtc_read(): called in state S_IDLE!\n");
+		break;
+	case S_WAITING_FOR_READ:	/*
+					 * Signal has been delivered.
+					 * waiting for rtc_read()
+					 */
+		/*
+		 * Well done
+		 */
+	case S_READ_MISSED:		/*
+					 * Signal has been delivered, read()
+					 * deadline was missed
+					 */
+		/*
+		 * So, you finally got here.
+		 */
+		if (!last_interrupt_time)
+			printk("bug in rtc_read(): last_interrupt_time = 0\n");
+		rtc_state = S_IDLE;
+		{
+			cycles_t latency = now - last_interrupt_time;
+			unsigned long delta;	/* Microseconds */
+
+			delta = latency;
+			delta /= CPU_MHZ;
+
+			if (delta > 1000 * 1000) {
+				printk("rtc: eek\n");
+			} else {
+				unsigned long slot = delta;
+				if (slot >= HISTSIZE)
+					slot = HISTSIZE - 1;
+				histogram[slot]++;
+				if (delta > 2000)
+					printk("wow!  That was a "
+							"%ld millisec bump\n",
+						delta / 1000);
+			}
+		}
+		rtc_state = S_IDLE;
+		break;
+	}
+#endif
+
+}
+
+static inline void rtc_close_event(void)
+{
+#ifdef CONFIG_RTC_HISTOGRAM
+	int i = 0;
+	unsigned long total = 0;
+
+	for (i = 0; i < HISTSIZE; i++)
+		total += histogram[i];
+	if (!total)
+		return;
+
+	printk("\nrtc latency histogram of {%s/%d, %lu samples}:\n",
+		current->comm, current->pid, total);
+	for (i = 0; i < HISTSIZE; i++) {
+		if (histogram[i])
+			printk("%d %d\n", i, histogram[i]);
+	}
+#endif
+}
+
 /*
  *	A very tiny interrupt handler. It runs with SA_INTERRUPT set,
  *	but there is possibility of conflicting with the set_rtc_mmss()
@@ -250,7 +410,7 @@ irqreturn_t rtc_interrupt(int irq, void 
 	spin_unlock(&rtc_task_lock);
 	wake_up_interruptible(&rtc_wait);	
 
-	kill_fasync (&rtc_async_queue, SIGIO, POLL_IN);
+	rtc_wake_event();
 
 	return IRQ_HANDLED;
 }
@@ -354,6 +514,8 @@ static ssize_t rtc_read(struct file *fil
 		schedule();
 	} while (1);
 
+	rtc_read_event();
+
 	if (count < sizeof(unsigned long))
 		retval = put_user(data, (unsigned int __user *)buf) ?: sizeof(int); 
 	else
@@ -689,6 +857,7 @@ static int rtc_open(struct inode *inode,
 	if(rtc_status & RTC_IS_OPEN)
 		goto out_busy;
 
+	rtc_open_event();
 	rtc_status |= RTC_IS_OPEN;
 
 	rtc_irq_data = 0;
@@ -744,6 +913,7 @@ no_irq:
 	rtc_irq_data = 0;
 	rtc_status &= ~RTC_IS_OPEN;
 	spin_unlock_irq (&rtc_lock);
+	rtc_close_event();
 	return 0;
 }
 

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-09 16:05                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23 Ingo Molnar
                                                                     ` (2 preceding siblings ...)
  2004-11-11  5:01                                                   ` K.R. Foley
@ 2004-11-11 14:44                                                   ` Ingo Molnar
  2004-11-11 16:03                                                     ` Gunther Persoons
                                                                       ` (3 more replies)
  3 siblings, 4 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-11 14:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


i have released the -V0.7.25-0 Real-Time Preemption patch, which can be
downloaded from the usual place:

    http://redhat.com/~mingo/realtime-preempt/

this release includes fixes, new features and latency improvements.

the biggest change is the threading of the lone remaining non-threaded
external interrupt: the timer interrupt (IRQ#0).

It was not threaded until now because unlike device interrupts the timer
interrupt is quite deeply attached to Linux's architecture, driving
process timing, profiling and the scheduler. I separated these into
stuff that can be done from a thread context and stuff that needs to
execute directly.

Fortunately most of the expensive and latency-generating stuff could be
pushed into the irq thread. As a side-effect this enabled the turning of
rtc_lock and xtime_lock into a mutex. Also, it removed some ugly hacks
from rtc.c and should improve worst-case latencies.

the other bigger change is the reworking of the .config space. Instead
of the deep hierarchy of hard-to-understand technical PREEMPT options,
there's now a flattened out choice of 4 preemption models:

                ( ) No Forced Preemption (Server)
                ( ) Voluntary Kernel Preemption (Desktop)
                ( ) Preemptible Kernel (Low-Latency Desktop)
                (X) Complete Preemption (Real-Time)

and updated help texts. Plus for the preemption models where it can be
freely turned off, softirq and hardirq threading is an additional
option.

the third bigger change is the reworking of the tracer to make it easier
to drive it from user-space. There are 3 runtime flags now:

 /proc/sys/kernel/trace_enabled           (default: 1)
 /proc/sys/kernel/trace_user_triggered    (default: 0)
 /proc/sys/kernel/trace_freerunning       (default: 0)

semantics of user-triggered tracing: if enabled then any active tracing
of wakeup and/or critical sections stops and userspace drives start/stop
events via gettimeofday(0,1)/gettimeofday(0,0). The latter saves the
current trace into /proc/latency_trace, the former clears the trace
buffer and starts tracing anew. Doing another gettimeofday(0,1) on an
already running tracer clears the trace and restarts it without saving
the current trace into /proc/latency_trace. Doing a gettimeofday(0,0) on
an already stopped tracer has no effect (i.e. /proc/latency_trace wont
be saved a second time). The tracer does timing for userspace
automatically the same way it does it for the built-in timing
mechanisms, and it can be configured via the preempt_max_latency and
preempt_tresh tunables.

also, wakeup-timing, irq-off and preempt-off critical section timing can
now be done at once again, the /proc/sys/kernel/preempt_wakeup_timing
flag switches between the modes. (default: 1)

other changes since -V0.7.24:

 - debug feature: added the RTC-debug patch sanitized by K.R. Foley,
   plus further cleanups.

 - added upstream fix for kobject related crash, pointed out by Shane 
   Shrybman.

 - cleanup: Kconfig help text fixes from Amit Shah

 - latency improvement: on UP-IOAPIC, when redirecting an interrupt, do
   not ack the APIC. This is the method used for direct interrupts and
   on UP it might as well work out fine. It is certainly faster than
   masking/unmasking, making UP-IOAPIC the fastest PIC mode again.

 - livelock fix: the timer-irq threading unearthed a seqlock related
   livelock scenario, which triggered in do_gettimeoffset() big-time. 
   The solution is to serialize seqlock readers with writers _iff_ the 
   seqlock status is 'invalid'. This is a rare event, but when it
   happens it saves the day.

 - debugging helper: the /proc/sys/kernel/debug_direct_keyboard flag 
   (default: 0) will hack the keyboard IRQ into being direct. NOTE: the 
   keyboard in this mode should only be used to access SysRq 
   functionality that is not possible via the threaded keyboard handler. 
   The direct keyboard IRQ can crash the system.

 - new kernel profiling features: added profile=preempt to profile 
   whether interrupts hit the kernel in preemptible mode or in a 
   critical section. Added /proc/sys/kernel/prof_pid to profile a
   specific PID only. (default: -1, meaning all tasks profiled) Added
   /proc/irq/prof_cpu_mask back.

 - robustness improvement: do not report atomicity-warnings during
   kernel oopses - it's more important to get the oops out to the
   console.

to create a -V0.7.25-0 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.25-0

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 14:44                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0 Ingo Molnar
@ 2004-11-11 16:03                                                     ` Gunther Persoons
  2004-11-11 16:08                                                       ` Ingo Molnar
  2004-11-11 20:56                                                     ` Remi Colinet
                                                                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 951+ messages in thread
From: Gunther Persoons @ 2004-11-11 16:03 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

Ingo Molnar wrote:

>i have released the -V0.7.25-0 Real-Time Preemption patch, which can be
>downloaded from the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/
>
>this release includes fixes, new features and latency improvements.
>
>the biggest change is the threading of the lone remaining non-threaded
>external interrupt: the timer interrupt (IRQ#0).
>
>It was not threaded until now because unlike device interrupts the timer
>interrupt is quite deeply attached to Linux's architecture, driving
>process timing, profiling and the scheduler. I separated these into
>stuff that can be done from a thread context and stuff that needs to
>execute directly.
>
>Fortunately most of the expensive and latency-generating stuff could be
>pushed into the irq thread. As a side-effect this enabled the turning of
>rtc_lock and xtime_lock into a mutex. Also, it removed some ugly hacks
>from rtc.c and should improve worst-case latencies.
>
>the other bigger change is the reworking of the .config space. Instead
>of the deep hierarchy of hard-to-understand technical PREEMPT options,
>there's now a flattened out choice of 4 preemption models:
>
>                ( ) No Forced Preemption (Server)
>                ( ) Voluntary Kernel Preemption (Desktop)
>                ( ) Preemptible Kernel (Low-Latency Desktop)
>                (X) Complete Preemption (Real-Time)
>
>and updated help texts. Plus for the preemption models where it can be
>freely turned off, softirq and hardirq threading is an additional
>option.
>
>the third bigger change is the reworking of the tracer to make it easier
>to drive it from user-space. There are 3 runtime flags now:
>
> /proc/sys/kernel/trace_enabled           (default: 1)
> /proc/sys/kernel/trace_user_triggered    (default: 0)
> /proc/sys/kernel/trace_freerunning       (default: 0)
>
>semantics of user-triggered tracing: if enabled then any active tracing
>of wakeup and/or critical sections stops and userspace drives start/stop
>events via gettimeofday(0,1)/gettimeofday(0,0). The latter saves the
>current trace into /proc/latency_trace, the former clears the trace
>buffer and starts tracing anew. Doing another gettimeofday(0,1) on an
>already running tracer clears the trace and restarts it without saving
>the current trace into /proc/latency_trace. Doing a gettimeofday(0,0) on
>an already stopped tracer has no effect (i.e. /proc/latency_trace wont
>be saved a second time). The tracer does timing for userspace
>automatically the same way it does it for the built-in timing
>mechanisms, and it can be configured via the preempt_max_latency and
>preempt_tresh tunables.
>
>also, wakeup-timing, irq-off and preempt-off critical section timing can
>now be done at once again, the /proc/sys/kernel/preempt_wakeup_timing
>flag switches between the modes. (default: 1)
>
>other changes since -V0.7.24:
>
> - debug feature: added the RTC-debug patch sanitized by K.R. Foley,
>   plus further cleanups.
>
> - added upstream fix for kobject related crash, pointed out by Shane 
>   Shrybman.
>
> - cleanup: Kconfig help text fixes from Amit Shah
>
> - latency improvement: on UP-IOAPIC, when redirecting an interrupt, do
>   not ack the APIC. This is the method used for direct interrupts and
>   on UP it might as well work out fine. It is certainly faster than
>   masking/unmasking, making UP-IOAPIC the fastest PIC mode again.
>
> - livelock fix: the timer-irq threading unearthed a seqlock related
>   livelock scenario, which triggered in do_gettimeoffset() big-time. 
>   The solution is to serialize seqlock readers with writers _iff_ the 
>   seqlock status is 'invalid'. This is a rare event, but when it
>   happens it saves the day.
>
> - debugging helper: the /proc/sys/kernel/debug_direct_keyboard flag 
>   (default: 0) will hack the keyboard IRQ into being direct. NOTE: the 
>   keyboard in this mode should only be used to access SysRq 
>   functionality that is not possible via the threaded keyboard handler. 
>   The direct keyboard IRQ can crash the system.
>
> - new kernel profiling features: added profile=preempt to profile 
>   whether interrupts hit the kernel in preemptible mode or in a 
>   critical section. Added /proc/sys/kernel/prof_pid to profile a
>   specific PID only. (default: -1, meaning all tasks profiled) Added
>   /proc/irq/prof_cpu_mask back.
>
> - robustness improvement: do not report atomicity-warnings during
>   kernel oopses - it's more important to get the oops out to the
>   console.
>
>to create a -V0.7.25-0 tree from scratch, the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
>   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
>   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.25-0
>
>	Ingo
>
>  
>
Got 2 times a hard lock up with this one. Happened while i was typing 
something and downloading both after 15-20 minutes.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 16:03                                                     ` Gunther Persoons
@ 2004-11-11 16:08                                                       ` Ingo Molnar
  2004-11-11 16:12                                                         ` Ingo Molnar
  2004-11-11 16:16                                                         ` Gunther Persoons
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-11 16:08 UTC (permalink / raw)
  To: Gunther Persoons; +Cc: linux-kernel


* Gunther Persoons <gunther_persoons@spymac.com> wrote:

> Got 2 times a hard lock up with this one. Happened while i was typing
> something and downloading both after 15-20 minutes.

.config?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 16:08                                                       ` Ingo Molnar
@ 2004-11-11 16:12                                                         ` Ingo Molnar
  2004-11-11 16:25                                                           ` Gunther Persoons
  2004-11-11 16:30                                                           ` Ingo Molnar
  2004-11-11 16:16                                                         ` Gunther Persoons
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-11 16:12 UTC (permalink / raw)
  To: Gunther Persoons; +Cc: linux-kernel


* Ingo Molnar <mingo@elte.hu> wrote:

> * Gunther Persoons <gunther_persoons@spymac.com> wrote:
> 
> > Got 2 times a hard lock up with this one. Happened while i was typing
> > something and downloading both after 15-20 minutes.
> 
> .config?

just in case you are using UP-IOAPIC, could you enable CONFIG_SMP (even
if you are running an UP box) and see whether the lockup goes away? 
Which was the last -RT kernel that you tried that didnt lock up in this
fashion?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 16:08                                                       ` Ingo Molnar
  2004-11-11 16:12                                                         ` Ingo Molnar
@ 2004-11-11 16:16                                                         ` Gunther Persoons
  1 sibling, 0 replies; 951+ messages in thread
From: Gunther Persoons @ 2004-11-11 16:16 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

Ingo Molnar wrote:

>* Gunther Persoons <gunther_persoons@spymac.com> wrote:
>
>  
>
>>Got 2 times a hard lock up with this one. Happened while i was typing
>>something and downloading both after 15-20 minutes.
>>    
>>
>
>.config?
>
>	Ingo
>
>  
>
Attached

[-- Attachment #2: config --]
[-- Type: text/plain, Size: 31696 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-rc1-mm3-RT-V0.7.25-0
# Thu Nov 11 16:07:49 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
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

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
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_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_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_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_X86_UP_APIC=y
# CONFIG_X86_UP_IOAPIC is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_KERN_PHYS_OFFSET=1
# 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_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_THINKPAD=m
CONFIG_ACPI_IBM=m
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=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=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_DEBUG is not set
# CONFIG_CPU_FREQ_PROC_INTF is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_24_API is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
CONFIG_CPU_FREQ_TABLE=y

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=y
CONFIG_X86_POWERNOW_K6=y
CONFIG_X86_POWERNOW_K7=y
CONFIG_X86_POWERNOW_K7_ACPI=y
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y
CONFIG_X86_GX_SUSPMOD=y
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_X86_SPEEDSTEP_SMI=y
CONFIG_X86_P4_CLOCKMOD=y
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
CONFIG_X86_LONGRUN=y
CONFIG_X86_LONGHAUL=y

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_X86_SPEEDSTEP_LIB=y
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=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=y
# CONFIG_PCMCIA_DEBUG is not set
# CONFIG_PCMCIA_OBSOLETE is not set
CONFIG_PCMCIA=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=m
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
# CONFIG_ISAPNP is not set
# CONFIG_PNPBIOS is not set
# CONFIG_PNPACPI is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD 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_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
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

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_IDE_TASK_IOCTL=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X 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=y
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_BLK_DEV_HPT366=y
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
CONFIG_BLK_DEV_PDC202XX_OLD=y
# CONFIG_PDC202XX_BURST is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_TRM290=y
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=m
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set

#
# 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=m
# CONFIG_SCSI_FC_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 is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO 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_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 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

#
# PCMCIA SCSI adapter support
#
# CONFIG_PCMCIA_AHA152X is not set
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_NINJA_SCSI is not set
# CONFIG_PCMCIA_QLOGIC is not set
# CONFIG_PCMCIA_SYM53C500 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=m
CONFIG_FUSION_MAX_SGE=40
CONFIG_FUSION_CTL=m

#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_IEEE1394_OUI_DB is not set
# CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set

#
# Device Drivers
#

#
# Texas Instruments PCILynx requires I2C
#
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
# CONFIG_IEEE1394_VIDEO1394 is not set
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_CMP=m
CONFIG_IEEE1394_AMDTP=m

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP 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=m
CONFIG_INET_ESP=m
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER is not set
CONFIG_XFRM=y
CONFIG_XFRM_USER=m

#
# 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

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
CONFIG_LANCE=m
CONFIG_NET_VENDOR_SMC=y
# CONFIG_WD80x3 is not set
# CONFIG_ULTRA is not set
# CONFIG_SMC9194 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=m
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_AMD8111_ETH=m
# CONFIG_AMD8111E_NAPI is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
CONFIG_APRICOT=m
CONFIG_B44=m
CONFIG_FORCEDETH=m
# CONFIG_CS89x0 is not set
CONFIG_DGRS=m
# CONFIG_EEPRO100 is not set
CONFIG_E100=m
# CONFIG_E100_NAPI is not set
# CONFIG_FEALNX is not set
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
# CONFIG_DL2K is not set
CONFIG_E1000=m
# CONFIG_E1000_NAPI is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_R8169=m
# CONFIG_R8169_NAPI is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=m

#
# Ethernet (10000 Mbit)
#
CONFIG_IXGB=m
# CONFIG_IXGB_NAPI is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
# CONFIG_WAVELAN is not set
# CONFIG_PCMCIA_WAVELAN is not set
# CONFIG_PCMCIA_NETWAVE is not set

#
# Wireless 802.11 Frequency Hopping cards support
#
# CONFIG_PCMCIA_RAYCS is not set

#
# Wireless 802.11b ISA/PCI cards support
#
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set

#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
CONFIG_AIRO_CS=m
# CONFIG_PCMCIA_WL3501 is not set

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
# CONFIG_PRISM54 is not set
CONFIG_NET_WIRELESS=y

#
# PCMCIA network device support
#
# CONFIG_NET_PCMCIA is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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 I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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

#
# 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_CS 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_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
CONFIG_RTC=y
CONFIG_RTC_HISTOGRAM=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
CONFIG_SONYPI=m

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
CONFIG_AGP_ALI=m
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=m
CONFIG_AGP_AMD64=m
CONFIG_AGP_INTEL=m
# CONFIG_AGP_INTEL_MCH is not set
CONFIG_AGP_NVIDIA=m
CONFIG_AGP_SIS=m
CONFIG_AGP_SWORKS=m
CONFIG_AGP_VIA=m
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
# CONFIG_DRM_I830 is not set
# CONFIG_DRM_I915 is not set
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS 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

#
# I2C support
#
# CONFIG_I2C is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
CONFIG_FB=y
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_RTCTIMER is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# ISA devices
#
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_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_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_ALI5451=m
# 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=m
# CONFIG_SND_BT87X is not set
CONFIG_SND_CS46XX=m
# CONFIG_SND_CS46XX_NEW_DSP is not set
CONFIG_SND_CS4281=m
CONFIG_SND_EMU10K1=m
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
CONFIG_SND_NM256=m
# CONFIG_SND_RME32 is not set
CONFIG_SND_RME96=m
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
CONFIG_SND_TRIDENT=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_ALS4000=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
# 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=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
CONFIG_SND_VIA82XX=m
# CONFIG_SND_VX222 is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set

#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_VXP440 is not set
# CONFIG_SND_PDAUDIOCF is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_UHCI_HCD=m

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_RW_DETECT 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_HP8200e 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=m
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network adaptors
#
# 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

#
# USB port drivers
#

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_TEST is not set

#
# USB ATM/DSL drivers
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISER4_FS=m
CONFIG_REISER4_LARGE_KEY=y
# CONFIG_REISER4_CHECK is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_POSIX is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_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

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_WAKEUP_TIMING=y
CONFIG_PREEMPT_TRACE=y
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
CONFIG_LATENCY_TIMING=y
# CONFIG_LATENCY_TRACE is not set
CONFIG_RT_DEADLOCK_DETECT=y
# CONFIG_USE_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# 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=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_KHAZAD is not set
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 16:12                                                         ` Ingo Molnar
@ 2004-11-11 16:25                                                           ` Gunther Persoons
  2004-11-11 16:30                                                           ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Gunther Persoons @ 2004-11-11 16:25 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Ingo Molnar wrote:

>* Ingo Molnar <mingo@elte.hu> wrote:
>
>  
>
>>* Gunther Persoons <gunther_persoons@spymac.com> wrote:
>>
>>    
>>
>>>Got 2 times a hard lock up with this one. Happened while i was typing
>>>something and downloading both after 15-20 minutes.
>>>      
>>>
>>.config?
>>    
>>
>
>just in case you are using UP-IOAPIC, could you enable CONFIG_SMP (even
>if you are running an UP box) and see whether the lockup goes away? 
>  
>
Ok. Going to build a new kernel.

>Which was the last -RT kernel that you tried that didnt lock up in this
>fashion?
>  
>
V0.7.24.

>	Ingo
>
>  
>


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 16:12                                                         ` Ingo Molnar
  2004-11-11 16:25                                                           ` Gunther Persoons
@ 2004-11-11 16:30                                                           ` Ingo Molnar
  2004-11-11 17:36                                                             ` Gunther Persoons
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-11 16:30 UTC (permalink / raw)
  To: Gunther Persoons; +Cc: linux-kernel


* Ingo Molnar <mingo@elte.hu> wrote:

> just in case you are using UP-IOAPIC, could you enable CONFIG_SMP
> (even if you are running an UP box) and see whether the lockup goes
> away?  Which was the last -RT kernel that you tried that didnt lock up
> in this fashion?

if with CONFIG_SMP it's more stable, could you try the following: turn
off CONFIG_SMP again and edit arch/i386/kernel/io_apic.c and remove this
string:

	&& defined(CONFIG_SMP)

(there should be only one occurence of this string.)

this will turn the previous IO-APIC logic (used in -V0.7.24) back on.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 16:30                                                           ` Ingo Molnar
@ 2004-11-11 17:36                                                             ` Gunther Persoons
  0 siblings, 0 replies; 951+ messages in thread
From: Gunther Persoons @ 2004-11-11 17:36 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Ingo Molnar wrote:

>* Ingo Molnar <mingo@elte.hu> wrote:
>
>  
>
>>just in case you are using UP-IOAPIC, could you enable CONFIG_SMP
>>(even if you are running an UP box) and see whether the lockup goes
>>away?  Which was the last -RT kernel that you tried that didnt lock up
>>in this fashion?
>>    
>>
>
>if with CONFIG_SMP it's more stable, could you try the following: turn
>off CONFIG_SMP again and edit arch/i386/kernel/io_apic.c and remove this
>string:
>
>	&& defined(CONFIG_SMP)
>
>(there should be only one occurence of this string.)
>
>this will turn the previous IO-APIC logic (used in -V0.7.24) back on.
>
>	Ingo
>
>  
>
It locked up after 20 minutes with CONFIG_SMP enabled.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 20:56                                                     ` Remi Colinet
@ 2004-11-11 18:12                                                       ` K.R. Foley
  2004-11-11 18:42                                                       ` K.R. Foley
  1 sibling, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-11-11 18:12 UTC (permalink / raw)
  To: Remi Colinet; +Cc: Ingo Molnar, LKML

Remi Colinet wrote:
> Ingo Molnar wrote:
> 
>> i have released the -V0.7.25-0 Real-Time Preemption patch, which can be
>> downloaded from the usual place:
>>
>>    http://redhat.com/~mingo/realtime-preempt/
>>
>>
>>  
>>
> Hi,
> 
> I'm getting the following warning with V0.7.25-0
> 
> INSTALL sound/drivers/opl3/snd-opl3-lib.ko
> INSTALL sound/drivers/opl3/snd-opl3-synth.ko
> INSTALL sound/drivers/snd-dummy.ko
> INSTALL sound/drivers/snd-mtpav.ko
> INSTALL sound/drivers/snd-serial-u16550.ko
> INSTALL sound/drivers/snd-virmidi.ko
> INSTALL sound/pci/snd-sonicvibes.ko
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map 
> 2.6.10-rc1-mm3-RT-V0.7.25-0; fi
> WARNING: 
> /lib/modules/2.6.10-rc1-mm3-RT-V0.7.25-0/kernel/drivers/char/rtc.ko 
> needs unknown symbol rtc_close_event
> WARNING: 
> /lib/modules/2.6.10-rc1-mm3-RT-V0.7.25-0/kernel/drivers/char/rtc.ko 
> needs unknown symbol rtc_open_event
> [root@tigre01 im]#
> 
> .config file attached
> 
> Remi
> 

Does the patch below fix this?

kr

--- linux-2.6.10-rc1-mm3/drivers/char/rtc.c.orig        2004-11-11 
11:35:00.898841565 -0600
+++ linux-2.6.10-rc1-mm3/drivers/char/rtc.c     2004-11-11 
12:07:54.019642611 -0600
@@ -863,7 +863,9 @@ 
                 if(rtc_status & RTC_IS_OPEN)
                 goto out_busy;
+#ifdef RTC_IRQ 
                 rtc_open_event();
+#endif 
                 rtc_status |= RTC_IS_OPEN;
 
                  rtc_irq_data = 0;
@@ -920,7 +922,9 @@ 
                 rtc_irq_data = 0;
         rtc_status &= ~RTC_IS_OPEN; 
                  spin_unlock_irq (&rtc_lock);
+#ifdef RTC_IRQ 
                 rtc_close_event();
+#endif 
                 return 0;
  }



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 20:56                                                     ` Remi Colinet
  2004-11-11 18:12                                                       ` K.R. Foley
@ 2004-11-11 18:42                                                       ` K.R. Foley
  2004-11-11 21:41                                                         ` Ingo Molnar
  2004-11-12  3:49                                                         ` Remi Colinet
  1 sibling, 2 replies; 951+ messages in thread
From: K.R. Foley @ 2004-11-11 18:42 UTC (permalink / raw)
  To: Remi Colinet; +Cc: Ingo Molnar, LKML

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

Remi Colinet wrote:
> Ingo Molnar wrote:
> 
>> i have released the -V0.7.25-0 Real-Time Preemption patch, which can be
>> downloaded from the usual place:
>>
>>    http://redhat.com/~mingo/realtime-preempt/
>>
>>
>>  
>>
> Hi,
> 
> I'm getting the following warning with V0.7.25-0
> 
> INSTALL sound/drivers/opl3/snd-opl3-lib.ko
> INSTALL sound/drivers/opl3/snd-opl3-synth.ko
> INSTALL sound/drivers/snd-dummy.ko
> INSTALL sound/drivers/snd-mtpav.ko
> INSTALL sound/drivers/snd-serial-u16550.ko
> INSTALL sound/drivers/snd-virmidi.ko
> INSTALL sound/pci/snd-sonicvibes.ko
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map 
> 2.6.10-rc1-mm3-RT-V0.7.25-0; fi
> WARNING: 
> /lib/modules/2.6.10-rc1-mm3-RT-V0.7.25-0/kernel/drivers/char/rtc.ko 
> needs unknown symbol rtc_close_event
> WARNING: 
> /lib/modules/2.6.10-rc1-mm3-RT-V0.7.25-0/kernel/drivers/char/rtc.ko 
> needs unknown symbol rtc_open_event
> [root@tigre01 im]#
> 
> .config file attached
> 
> Remi
> 

Damn. Here is the patch again. Last one was hosed by wrap. Sorry.

kr

[-- Attachment #2: rtc.fix --]
[-- Type: text/plain, Size: 494 bytes --]

--- linux-2.6.10-rc1-mm3/drivers/char/rtc.c.orig	2004-11-11 11:35:00.898841565 -0600
+++ linux-2.6.10-rc1-mm3/drivers/char/rtc.c	2004-11-11 12:07:54.019642611 -0600
@@ -863,7 +863,9 @@
 	if(rtc_status & RTC_IS_OPEN)
 		goto out_busy;
 
+#ifdef RTC_IRQ
 	rtc_open_event();
+#endif
 	rtc_status |= RTC_IS_OPEN;
 
 	rtc_irq_data = 0;
@@ -920,7 +922,9 @@
 	rtc_irq_data = 0;
 	rtc_status &= ~RTC_IS_OPEN;
 	spin_unlock_irq (&rtc_lock);
+#ifdef RTC_IRQ
 	rtc_close_event();
+#endif
 	return 0;
 }
 

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 14:44                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0 Ingo Molnar
  2004-11-11 16:03                                                     ` Gunther Persoons
@ 2004-11-11 20:56                                                     ` Remi Colinet
  2004-11-11 18:12                                                       ` K.R. Foley
  2004-11-11 18:42                                                       ` K.R. Foley
  2004-11-11 21:38                                                     ` Ingo Molnar
  2004-11-11 21:51                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1 Ingo Molnar
  3 siblings, 2 replies; 951+ messages in thread
From: Remi Colinet @ 2004-11-11 20:56 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

Ingo Molnar wrote:

>i have released the -V0.7.25-0 Real-Time Preemption patch, which can be
>downloaded from the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/
>
>
>  
>
Hi,

I'm getting the following warning with V0.7.25-0

INSTALL sound/drivers/opl3/snd-opl3-lib.ko
INSTALL sound/drivers/opl3/snd-opl3-synth.ko
INSTALL sound/drivers/snd-dummy.ko
INSTALL sound/drivers/snd-mtpav.ko
INSTALL sound/drivers/snd-serial-u16550.ko
INSTALL sound/drivers/snd-virmidi.ko
INSTALL sound/pci/snd-sonicvibes.ko
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 
2.6.10-rc1-mm3-RT-V0.7.25-0; fi
WARNING: 
/lib/modules/2.6.10-rc1-mm3-RT-V0.7.25-0/kernel/drivers/char/rtc.ko 
needs unknown symbol rtc_close_event
WARNING: 
/lib/modules/2.6.10-rc1-mm3-RT-V0.7.25-0/kernel/drivers/char/rtc.ko 
needs unknown symbol rtc_open_event
[root@tigre01 im]#

.config file attached

Remi








[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 42168 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-rc1-mm3-RT-V0.7.25-0
# Thu Nov 11 19:53:49 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_CPUSETS=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

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_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_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_SMP=y
CONFIG_NR_CPUS=8
# CONFIG_SCHED_SMT is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT_DESKTOP is not set
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_HAVE_DEC_LOCK=y

#
# Performance-monitoring counters support
#
CONFIG_PERFCTR=y
CONFIG_PERFCTR_INIT_TESTS=y
CONFIG_PERFCTR_VIRTUAL=y
CONFIG_PERFCTR_INTERRUPT_SUPPORT=y
CONFIG_PERFCTR_CPUS_FORBIDDEN_MASK=y
CONFIG_KERN_PHYS_OFFSET=1
# CONFIG_KEXEC is not set

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_DEBUG=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
# CONFIG_ACPI_VIDEO is not set
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
# CONFIG_ACPI_HOTPLUG_CPU is not set
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_THINKPAD=m
CONFIG_ACPI_IBM=y
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_PROC_INTF=m
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=m
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_24_API=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_TABLE=y

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=m
CONFIG_X86_SPEEDSTEP_SMI=m
CONFIG_X86_P4_CLOCKMOD=m
CONFIG_X86_CPUFREQ_NFORCE2=m
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set

#
# shared options
#
CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y

#
# 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_PCI_MSI=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
CONFIG_EISA=y
CONFIG_EISA_VLB_PRIMING=y
CONFIG_EISA_PCI_EISA=y
CONFIG_EISA_VIRTUAL_ROOT=y
CONFIG_EISA_NAMES=y
CONFIG_MCA=y
CONFIG_MCA_LEGACY=y
CONFIG_MCA_PROC_FS=y
CONFIG_SCx200=m
CONFIG_HOTPLUG_CPU=y

#
# PCCARD (PCMCIA/CardBus) support
#
CONFIG_PCCARD=m
CONFIG_PCMCIA_DEBUG=y
CONFIG_PCMCIA_OBSOLETE=y
CONFIG_PCMCIA=m
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=m
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_FAKE=m
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
CONFIG_HOTPLUG_PCI_ACPI=m
# CONFIG_HOTPLUG_PCI_ACPI_IBM is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_PCIE=m
CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE=y
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
CONFIG_DEBUG_DRIVER=y

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_PC_PCMCIA is not set
# CONFIG_PARPORT_OTHER is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_PS2 is not set
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_SX8=m
CONFIG_BLK_DEV_UB=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_INITRAMFS_SOURCE=""
CONFIG_LBD=y
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
CONFIG_CDROM_PKTCDVD_WCACHE=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y

#
# 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=y
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_IDE_TASK_IOCTL=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=m
# CONFIG_BLK_DEV_CMD640 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 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_IDEDMA_FORCED=y
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=y
# 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_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_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

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
CONFIG_SCSI_FC_ATTRS=m

#
# 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_AHA1740 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 is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_SCSI_SATA=y
CONFIG_SCSI_SATA_AHCI=m
# CONFIG_SCSI_SATA_SVW is not set
CONFIG_SCSI_ATA_PIIX=y
# CONFIG_SCSI_SATA_NV is not set
# CONFIG_SCSI_SATA_PROMISE is not set
# CONFIG_SCSI_SATA_SX4 is not set
# CONFIG_SCSI_SATA_SIL is not set
# CONFIG_SCSI_SATA_SIS is not set
# 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_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_FD_MCS 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_IBMMCA 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_NCR_D700 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_NCR_Q720 is not set
# CONFIG_SCSI_MCA_53C9X is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA6322 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SIM710 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=m

#
# PCMCIA SCSI adapter support
#
# CONFIG_PCMCIA_AHA152X is not set
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_NINJA_SCSI is not set
# CONFIG_PCMCIA_QLOGIC is not set
# CONFIG_PCMCIA_SYM53C500 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

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
CONFIG_INET_TUNNEL=m
# CONFIG_IP_TCPDIAG is not set
# CONFIG_IP_TCPDIAG_IPV6 is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_INET6_TUNNEL=m
CONFIG_IPV6_TUNNEL=m
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_CT_ACCT=y
# CONFIG_IP_NF_CONNTRACK_MARK is not set
CONFIG_IP_NF_CT_PROTO_SCTP=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
# CONFIG_IP_NF_MATCH_PKTTYPE is not set
# CONFIG_IP_NF_MATCH_MARK is not set
# CONFIG_IP_NF_MATCH_MULTIPORT is not set
# CONFIG_IP_NF_MATCH_TOS is not set
# CONFIG_IP_NF_MATCH_RECENT is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_DSCP is not set
# CONFIG_IP_NF_MATCH_AH_ESP is not set
# CONFIG_IP_NF_MATCH_LENGTH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
# CONFIG_IP_NF_MATCH_TCPMSS is not set
# CONFIG_IP_NF_MATCH_HELPER is not set
# CONFIG_IP_NF_MATCH_STATE is not set
# CONFIG_IP_NF_MATCH_CONNTRACK is not set
# CONFIG_IP_NF_MATCH_OWNER is not set
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_REALM is not set
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
# CONFIG_IP_NF_TARGET_ULOG is not set
# CONFIG_IP_NF_TARGET_TCPMSS is not set
# CONFIG_IP_NF_NAT is not set
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set

#
# IPv6: Netfilter Configuration
#
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
# CONFIG_IP6_NF_MATCH_OPTS is not set
# CONFIG_IP6_NF_MATCH_FRAG is not set
# CONFIG_IP6_NF_MATCH_HL is not set
# CONFIG_IP6_NF_MATCH_MULTIPORT is not set
# CONFIG_IP6_NF_MATCH_OWNER is not set
# CONFIG_IP6_NF_MATCH_MARK is not set
# CONFIG_IP6_NF_MATCH_IPV6HEADER is not set
# CONFIG_IP6_NF_MATCH_AHESP is not set
# CONFIG_IP6_NF_MATCH_LENGTH is not set
# CONFIG_IP6_NF_MATCH_EUI64 is not set
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
# CONFIG_IP6_NF_MANGLE is not set
# CONFIG_IP6_NF_RAW is not set
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
CONFIG_ATM_CLIP_NO_ICMP=y
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
CONFIG_ATM_BR2684=m
CONFIG_ATM_BR2684_IPFILTER=y
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=m
CONFIG_LLC2=m
# 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

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_KGDBOE is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET 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_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
CONFIG_EL3=m
# CONFIG_3C515 is not set
# CONFIG_ELMC is not set
# CONFIG_ELMC_II is not set
# CONFIG_VORTEX is not set
# CONFIG_TYPHOON 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_SKMC is not set
# CONFIG_NE2_MCA is not set
# CONFIG_IBMLANA 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=m
CONFIG_E100=m
# CONFIG_E100_NAPI is not set
# CONFIG_LNE390 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_NE3210 is not set
# CONFIG_ES3210 is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
# CONFIG_WAVELAN is not set
# CONFIG_PCMCIA_WAVELAN is not set
# CONFIG_PCMCIA_NETWAVE is not set

#
# Wireless 802.11 Frequency Hopping cards support
#
# CONFIG_PCMCIA_RAYCS is not set

#
# Wireless 802.11b ISA/PCI cards support
#
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set

#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
# CONFIG_AIRO_CS is not set
# CONFIG_PCMCIA_WL3501 is not set

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
# CONFIG_PRISM54 is not set
CONFIG_NET_WIRELESS=y

#
# PCMCIA network device support
#
# CONFIG_NET_PCMCIA is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# ATM drivers
#
CONFIG_ATM_TCP=m
# CONFIG_ATM_LANAI is not set
# CONFIG_ATM_ENI is not set
# CONFIG_ATM_FIRESTREAM is not set
# CONFIG_ATM_ZATM is not set
# CONFIG_ATM_NICSTAR is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
# CONFIG_ATM_HORIZON is not set
# CONFIG_ATM_IA is not set
# CONFIG_ATM_FORE200E_MAYBE is not set
# CONFIG_ATM_HE is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_EVBUG=m

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PARKBD=m
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m

#
# 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=m
CONFIG_KEYBOARD_NEWTON=m
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=m
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_DIGI is not set
# CONFIG_ESPSERIAL is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
CONFIG_N_HDLC=m
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_CS is not set
CONFIG_SERIAL_8250_ACPI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_MULTIPORT is not set
# CONFIG_SERIAL_8250_RSA is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=y
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
# CONFIG_TIPAR is not set

#
# IPMI
#
CONFIG_IPMI_HANDLER=m
CONFIG_IPMI_PANIC_EVENT=y
CONFIG_IPMI_PANIC_STRING=y
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I8XX_TCO is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_SCx200_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_MACHZ_WDT is not set

#
# ISA-based Watchdog Cards
#
# CONFIG_PCWATCHDOG is not set
# CONFIG_MIXCOMWD is not set
# CONFIG_WDT is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_HW_RANDOM=m
CONFIG_NVRAM=m
CONFIG_RTC=m
CONFIG_RTC_HISTOGRAM=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_INTEL_MCH is not set
CONFIG_AGP_NVIDIA=m
# 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_GAMMA is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
# CONFIG_DRM_I915 is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_MWAVE is not set
# CONFIG_SCx200_GPIO is not set
CONFIG_RAW_DRIVER=m
CONFIG_HPET=y
CONFIG_HPET_RTC_IRQ=y
CONFIG_HPET_MMAP=y
CONFIG_MAX_RAW_DEVS=256
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
# CONFIG_I2C_ISA is not set
CONFIG_I2C_NFORCE2=m
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
CONFIG_I2C_PIIX4=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_IT87 is not set
CONFIG_SENSORS_LM75=m
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set

#
# Other I2C Chip support
#
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_DEBUG_CHIP=y

#
# Dallas's 1-wire bus
#
CONFIG_W1=m
# CONFIG_W1_MATROX is not set
# CONFIG_W1_DS9490 is not set
CONFIG_W1_THERM=m
# CONFIG_W1_SMEM is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_ZR36120 is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
CONFIG_FB_RIVA=m
# CONFIG_FB_RIVA_I2C is not set
# CONFIG_FB_RIVA_DEBUG is not set
CONFIG_FB_I810=m
CONFIG_FB_I810_GTF=y
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
CONFIG_FB_SAVAGE=m
CONFIG_FB_SAVAGE_I2C=m
CONFIG_FB_SAVAGE_ACCEL=m
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_MDA_CONSOLE=m
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=m
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
CONFIG_FONT_MINI_4x6=y
CONFIG_FONT_SUN8x16=y
# CONFIG_FONT_SUN12x22 is not set

#
# Logo configuration
#
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
# CONFIG_LOGO_LINUX_VGA16 is not set
# CONFIG_LOGO_LINUX_CLUT224 is not set

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=y
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
CONFIG_SND_DEBUG_MEMORY=y
CONFIG_SND_DEBUG_DETECT=y

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m

#
# ISA devices
#
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_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_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=y
# 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_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
# CONFIG_SND_INTEL8X0M is not set
CONFIG_SND_SONICVIBES=m
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set

#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_VXP440 is not set
# CONFIG_SND_PDAUDIOCF is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB=y
CONFIG_USB_DEBUG=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_UHCI_HCD=m

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_STORAGE is not set

#
# USB Input Devices
#
# CONFIG_USB_HID is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set

#
# USB Network adaptors
#
# 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

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_TEST is not set

#
# USB ATM/DSL drivers
#
# CONFIG_USB_ATM is not set
# CONFIG_USB_SPEEDTOUCH is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=y

#
# Caches
#
CONFIG_FSCACHE=m
CONFIG_CACHEFS=m

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_DEVPTS_FS_SECURITY=y
CONFIG_TMPFS=y
CONFIG_TMPFS_XATTR=y
CONFIG_TMPFS_SECURITY=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS 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_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
# CONFIG_ROOT_NFS is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
CONFIG_RPCSEC_GSS_SPKM3=m
# 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

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=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=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_SCHEDSTATS=y
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_WAKEUP_TIMING=y
CONFIG_PREEMPT_TRACE=y
CONFIG_CRITICAL_PREEMPT_TIMING=y
CONFIG_CRITICAL_IRQSOFF_TIMING=y
CONFIG_CRITICAL_TIMING=y
CONFIG_LATENCY_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_RT_DEADLOCK_DETECT=y
CONFIG_DEBUG_KOBJECT=y
CONFIG_DEBUG_INFO=y
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_KPROBES=y
CONFIG_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=m
CONFIG_SECURITY_ROOTPLUG=m
# CONFIG_SECURITY_SECLVL is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_MLS=y

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_TEST=m

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 14:44                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0 Ingo Molnar
  2004-11-11 16:03                                                     ` Gunther Persoons
  2004-11-11 20:56                                                     ` Remi Colinet
@ 2004-11-11 21:38                                                     ` Ingo Molnar
  2004-11-11 21:51                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1 Ingo Molnar
  3 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-11 21:38 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Gunther Persoons


found the bug that i think caused the freezes and deadlocks reported by 
Mark and Gunther. Here's the announcement of a debug feature:

>  - debugging helper: the /proc/sys/kernel/debug_direct_keyboard flag 
>    (default: 0) will hack the keyboard IRQ into being direct. NOTE: the 
>    keyboard in this mode should only be used to access SysRq 
>    functionality that is not possible via the threaded keyboard handler. 
>    The direct keyboard IRQ can crash the system.

it turns out i accidentally left debug_direct_keyboard default-enabled
... no wonder it caused lockups!

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 18:42                                                       ` K.R. Foley
@ 2004-11-11 21:41                                                         ` Ingo Molnar
  2004-11-12  3:49                                                         ` Remi Colinet
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-11 21:41 UTC (permalink / raw)
  To: K.R. Foley; +Cc: Remi Colinet, LKML


* K.R. Foley <kr@cybsft.com> wrote:

> +#ifdef RTC_IRQ
>  	rtc_open_event();
> +#endif

> +#ifdef RTC_IRQ
>  	rtc_close_event();
> +#endif

indeed. I fixed it a bit differently in my tree, will upload a new patch
soon.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-11 14:44                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0 Ingo Molnar
                                                                       ` (2 preceding siblings ...)
  2004-11-11 21:38                                                     ` Ingo Molnar
@ 2004-11-11 21:51                                                     ` Ingo Molnar
  2004-11-12  4:08                                                       ` Bill Huey
                                                                         ` (5 more replies)
  3 siblings, 6 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-11 21:51 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


i have released the -V0.7.25-1 Real-Time Preemption patch, which can be
downloaded from the usual place:

    http://redhat.com/~mingo/realtime-preempt/

this is a fixes-only release that resolves a couple of bugs that slipped
into -V0.7.25-0:

 - lockup/deadlock fix: make debug_direct_keyboard default to 0. It is
   only a debug helper to be used for development, it was never intended
   to be enabled. This fix should resolve the bugs reported by Gunther
   Persoons and Mark H. Johnson.

 - fix symbol export problems in rtc.ko, reported by Remi Colinet, based
   on the patch from K.R. Foley.

 - make preempt_wakeup_timing default to 1 if enabled in the .config, as 
   originally intended.

to create a -V0.7.25-1 tree from scratch, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.25-1

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0
  2004-11-11 18:42                                                       ` K.R. Foley
  2004-11-11 21:41                                                         ` Ingo Molnar
@ 2004-11-12  3:49                                                         ` Remi Colinet
  1 sibling, 0 replies; 951+ messages in thread
From: Remi Colinet @ 2004-11-12  3:49 UTC (permalink / raw)
  To: K.R. Foley; +Cc: Ingo Molnar, LKML

K.R. Foley wrote:

> Remi Colinet wrote:
>
>> Ingo Molnar wrote:
>>
>>> i have released the -V0.7.25-0 Real-Time Preemption patch, which can be
>>> downloaded from the usual place:
>>>
>>>    http://redhat.com/~mingo/realtime-preempt/
>>>
>> Hi,
>>
>> I'm getting the following warning with V0.7.25-0
>>
>> INSTALL sound/drivers/opl3/snd-opl3-lib.ko
>> INSTALL sound/drivers/opl3/snd-opl3-synth.ko
>> INSTALL sound/drivers/snd-dummy.ko
>> INSTALL sound/drivers/snd-mtpav.ko
>> INSTALL sound/drivers/snd-serial-u16550.ko
>> INSTALL sound/drivers/snd-virmidi.ko
>> INSTALL sound/pci/snd-sonicvibes.ko
>> if [ -r System.map ]; then /sbin/depmod -ae -F System.map 
>> 2.6.10-rc1-mm3-RT-V0.7.25-0; fi
>> WARNING: 
>> /lib/modules/2.6.10-rc1-mm3-RT-V0.7.25-0/kernel/drivers/char/rtc.ko 
>> needs unknown symbol rtc_close_event
>> WARNING: 
>> /lib/modules/2.6.10-rc1-mm3-RT-V0.7.25-0/kernel/drivers/char/rtc.ko 
>> needs unknown symbol rtc_open_event
>> [root@tigre01 im]#
>>
>> .config file attached
>>
>> Remi
>
>
> Damn. Here is the patch again. Last one was hosed by wrap. Sorry.
>
> kr

Solved with V0.7.25-1
Thanks

Remi

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-11 21:51                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1 Ingo Molnar
@ 2004-11-12  4:08                                                       ` Bill Huey
  2004-11-12  5:03                                                         ` Bill Huey
  2004-11-12 14:31                                                       ` Shane Shrybman
                                                                         ` (4 subsequent siblings)
  5 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-11-12  4:08 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

On Thu, Nov 11, 2004 at 10:51:22PM +0100, Ingo Molnar wrote:
> i have released the -V0.7.25-1 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>     http://redhat.com/~mingo/realtime-preempt/

Patch to get rudimentary kgdb support working.

bill


[-- Attachment #2: kgdb.diff --]
[-- Type: text/plain, Size: 4424 bytes --]

diff -rwu linux.voluntary.virgin/arch/i386/Kconfig linux.voluntary/arch/i386/Kconfig
--- linux.voluntary.virgin/arch/i386/Kconfig	2004-11-11 17:05:32.000000000 -0800
+++ linux.voluntary/arch/i386/Kconfig	2004-11-11 17:11:13.000000000 -0800
@@ -509,6 +509,17 @@
 	default y
 
 
+config NOTE_LATENCY
+	bool "Note irq-thread wake latency"
+	depends on PREEMPT_HARDIRQS && HPET
+	default n
+	help
+	  This options timestamp marks exception frame wake events to the
+	  irq-thread in question and shoves it into a statistically scalable
+	  histogram. Timestamp events can be "zoomed" in that are of interest
+	  with compile time changes to the struct describing the ranges of
+	  band(s) being saved.
+
 config X86_UP_APIC
 	bool "Local APIC support on uniprocessors" if !SMP
 	depends on !(X86_VISWS || X86_VOYAGER)
diff -rwu linux.voluntary.virgin/arch/i386/Kconfig.kgdb linux.voluntary/arch/i386/Kconfig.kgdb
--- linux.voluntary.virgin/arch/i386/Kconfig.kgdb	2004-11-11 17:05:32.000000000 -0800
+++ linux.voluntary/arch/i386/Kconfig.kgdb	2004-11-11 19:44:29.000000000 -0800
@@ -1,6 +1,6 @@
 config KGDB
 	bool "Include kgdb kernel debugger"
-	depends on DEBUG_KERNEL && !KPROBES && !PREEMPT_RT
+	depends on DEBUG_KERNEL && !KPROBES
 	help
 	  If you say Y here, the system will be compiled with the debug
 	  option (-g) and a debugging stub will be included in the
diff -rwu linux.voluntary.virgin/arch/i386/kernel/kgdb_stub.c linux.voluntary/arch/i386/kernel/kgdb_stub.c
--- linux.voluntary.virgin/arch/i386/kernel/kgdb_stub.c	2004-11-11 17:05:32.000000000 -0800
+++ linux.voluntary/arch/i386/kernel/kgdb_stub.c	2004-11-11 17:11:13.000000000 -0800
@@ -365,8 +365,8 @@
 
 #ifdef CONFIG_SMP
 static int in_kgdb_called;
-static spinlock_t waitlocks[MAX_NO_CPUS] =
-    {[0 ... MAX_NO_CPUS - 1] = SPIN_LOCK_UNLOCKED };
+static raw_spinlock_t waitlocks[MAX_NO_CPUS] =
+    {[0 ... MAX_NO_CPUS - 1] = RAW_SPIN_LOCK_UNLOCKED };
 /*
  * The following array has the thread pointer of each of the "other"
  * cpus.  We make it global so it can be seen by gdb.
@@ -374,9 +374,9 @@
 volatile int in_kgdb_entry_log[MAX_NO_CPUS];
 volatile struct pt_regs *in_kgdb_here_log[MAX_NO_CPUS];
 /*
-static spinlock_t continuelocks[MAX_NO_CPUS];
+static raw_spinlock_t continuelocks[MAX_NO_CPUS];
 */
-spinlock_t kgdb_spinlock = SPIN_LOCK_UNLOCKED;
+raw_spinlock_t kgdb_spinlock = RAW_SPIN_LOCK_UNLOCKED;
 /* waiters on our spinlock plus us */
 static atomic_t spinlock_waiters = ATOMIC_INIT(1);
 static int spinlock_count = 0;
@@ -2404,7 +2404,7 @@
 void
 kgdb_tstamp(int line, char *source, int data0, int data1)
 {
-	static spinlock_t ts_spin = SPIN_LOCK_UNLOCKED;
+	static raw_spinlock_t ts_spin = RAW_SPIN_LOCK_UNLOCKED;
 	int flags;
 	kgdb_local_irq_save(flags);
 	spin_lock(&ts_spin);
diff -rwu linux.voluntary.virgin/arch/i386/kernel/timers/timer_hpet.c linux.voluntary/arch/i386/kernel/timers/timer_hpet.c
--- linux.voluntary.virgin/arch/i386/kernel/timers/timer_hpet.c	2004-11-11 17:05:31.000000000 -0800
+++ linux.voluntary/arch/i386/kernel/timers/timer_hpet.c	2004-11-11 17:11:13.000000000 -0800
@@ -49,7 +49,9 @@
 	cyc2ns_scale = (1000 << CYC2NS_SCALE_FACTOR)/cpu_mhz;
 }
 
-static inline unsigned long long cycles_2_ns(unsigned long long cyc)
+//static inline
+//#error
+unsigned long long cycles_2_ns(unsigned long long cyc)
 {
 	return (cyc * cyc2ns_scale) >> CYC2NS_SCALE_FACTOR;
 }
diff -rwu linux.voluntary.virgin/arch/i386/lib/kgdb_serial.c linux.voluntary/arch/i386/lib/kgdb_serial.c
--- linux.voluntary.virgin/arch/i386/lib/kgdb_serial.c	2004-11-11 17:05:32.000000000 -0800
+++ linux.voluntary/arch/i386/lib/kgdb_serial.c	2004-11-11 17:11:13.000000000 -0800
@@ -104,9 +104,9 @@
  * but we will just depend on the uart status to help keep that straight.
 
  */
-static spinlock_t uart_interrupt_lock = SPIN_LOCK_UNLOCKED;
+static raw_spinlock_t uart_interrupt_lock = RAW_SPIN_LOCK_UNLOCKED;
 #ifdef CONFIG_SMP
-extern spinlock_t kgdb_spinlock;
+extern raw_spinlock_t kgdb_spinlock;
 #endif
 
 static int
@@ -343,7 +343,7 @@
  */
 int kgdb_in_isr = 0;
 int kgdb_in_lsr = 0;
-extern spinlock_t kgdb_spinlock;
+extern raw_spinlock_t kgdb_spinlock;
 
 /* Caller takes needed protections */
 
@@ -381,7 +381,7 @@
 }				/* tty_getDebugChar */
 
 static int count = 3;
-static spinlock_t one_at_atime = SPIN_LOCK_UNLOCKED;
+static raw_spinlock_t one_at_atime = RAW_SPIN_LOCK_UNLOCKED;
 
 static int __init
 kgdb_enable_ints(void)

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12  4:08                                                       ` Bill Huey
@ 2004-11-12  5:03                                                         ` Bill Huey
  2004-11-12  8:39                                                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-11-12  5:03 UTC (permalink / raw)
  To: Bill Huey
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

[-- Attachment #1: Type: text/plain, Size: 164 bytes --]

On Thu, Nov 11, 2004 at 08:08:45PM -0800, Bill Huey wrote:
> Patch to get rudimentary kgdb support working.

Resent with some contamination removed from it.

bill


[-- Attachment #2: kgdb.diff --]
[-- Type: text/plain, Size: 3610 bytes --]

diff -rwu linux.voluntary.virgin/arch/i386/Kconfig.kgdb linux.voluntary/arch/i386/Kconfig.kgdb
--- linux.voluntary.virgin/arch/i386/Kconfig.kgdb	2004-11-11 17:05:32.000000000 -0800
+++ linux.voluntary/arch/i386/Kconfig.kgdb	2004-11-11 19:44:29.000000000 -0800
@@ -1,6 +1,6 @@
 config KGDB
 	bool "Include kgdb kernel debugger"
-	depends on DEBUG_KERNEL && !KPROBES && !PREEMPT_RT
+	depends on DEBUG_KERNEL && !KPROBES
 	help
 	  If you say Y here, the system will be compiled with the debug
 	  option (-g) and a debugging stub will be included in the
diff -rwu linux.voluntary.virgin/arch/i386/kernel/kgdb_stub.c linux.voluntary/arch/i386/kernel/kgdb_stub.c
--- linux.voluntary.virgin/arch/i386/kernel/kgdb_stub.c	2004-11-11 17:05:32.000000000 -0800
+++ linux.voluntary/arch/i386/kernel/kgdb_stub.c	2004-11-11 17:11:13.000000000 -0800
@@ -365,8 +365,8 @@
 
 #ifdef CONFIG_SMP
 static int in_kgdb_called;
-static spinlock_t waitlocks[MAX_NO_CPUS] =
-    {[0 ... MAX_NO_CPUS - 1] = SPIN_LOCK_UNLOCKED };
+static raw_spinlock_t waitlocks[MAX_NO_CPUS] =
+    {[0 ... MAX_NO_CPUS - 1] = RAW_SPIN_LOCK_UNLOCKED };
 /*
  * The following array has the thread pointer of each of the "other"
  * cpus.  We make it global so it can be seen by gdb.
@@ -374,9 +374,9 @@
 volatile int in_kgdb_entry_log[MAX_NO_CPUS];
 volatile struct pt_regs *in_kgdb_here_log[MAX_NO_CPUS];
 /*
-static spinlock_t continuelocks[MAX_NO_CPUS];
+static raw_spinlock_t continuelocks[MAX_NO_CPUS];
 */
-spinlock_t kgdb_spinlock = SPIN_LOCK_UNLOCKED;
+raw_spinlock_t kgdb_spinlock = RAW_SPIN_LOCK_UNLOCKED;
 /* waiters on our spinlock plus us */
 static atomic_t spinlock_waiters = ATOMIC_INIT(1);
 static int spinlock_count = 0;
@@ -2404,7 +2404,7 @@
 void
 kgdb_tstamp(int line, char *source, int data0, int data1)
 {
-	static spinlock_t ts_spin = SPIN_LOCK_UNLOCKED;
+	static raw_spinlock_t ts_spin = RAW_SPIN_LOCK_UNLOCKED;
 	int flags;
 	kgdb_local_irq_save(flags);
 	spin_lock(&ts_spin);
diff -rwu linux.voluntary.virgin/arch/i386/kernel/timers/timer_hpet.c linux.voluntary/arch/i386/kernel/timers/timer_hpet.c
--- linux.voluntary.virgin/arch/i386/kernel/timers/timer_hpet.c	2004-11-11 17:05:31.000000000 -0800
+++ linux.voluntary/arch/i386/kernel/timers/timer_hpet.c	2004-11-11 17:11:13.000000000 -0800
@@ -49,7 +49,9 @@
 	cyc2ns_scale = (1000 << CYC2NS_SCALE_FACTOR)/cpu_mhz;
 }
 
-static inline unsigned long long cycles_2_ns(unsigned long long cyc)
+//static inline
+//#error
+unsigned long long cycles_2_ns(unsigned long long cyc)
 {
 	return (cyc * cyc2ns_scale) >> CYC2NS_SCALE_FACTOR;
 }
diff -rwu linux.voluntary.virgin/arch/i386/lib/kgdb_serial.c linux.voluntary/arch/i386/lib/kgdb_serial.c
--- linux.voluntary.virgin/arch/i386/lib/kgdb_serial.c	2004-11-11 17:05:32.000000000 -0800
+++ linux.voluntary/arch/i386/lib/kgdb_serial.c	2004-11-11 17:11:13.000000000 -0800
@@ -104,9 +104,9 @@
  * but we will just depend on the uart status to help keep that straight.
 
  */
-static spinlock_t uart_interrupt_lock = SPIN_LOCK_UNLOCKED;
+static raw_spinlock_t uart_interrupt_lock = RAW_SPIN_LOCK_UNLOCKED;
 #ifdef CONFIG_SMP
-extern spinlock_t kgdb_spinlock;
+extern raw_spinlock_t kgdb_spinlock;
 #endif
 
 static int
@@ -343,7 +343,7 @@
  */
 int kgdb_in_isr = 0;
 int kgdb_in_lsr = 0;
-extern spinlock_t kgdb_spinlock;
+extern raw_spinlock_t kgdb_spinlock;
 
 /* Caller takes needed protections */
 
@@ -381,7 +381,7 @@
 }				/* tty_getDebugChar */
 
 static int count = 3;
-static spinlock_t one_at_atime = SPIN_LOCK_UNLOCKED;
+static raw_spinlock_t one_at_atime = RAW_SPIN_LOCK_UNLOCKED;
 
 static int __init
 kgdb_enable_ints(void)

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12  5:03                                                         ` Bill Huey
@ 2004-11-12  8:39                                                           ` Ingo Molnar
  2004-11-12 10:52                                                             ` Bill Huey
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-12  8:39 UTC (permalink / raw)
  To: Bill Huey
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Bill Huey <bhuey@lnxw.com> wrote:

> > Patch to get rudimentary kgdb support working.

thanks, the patch looks good. Is this one really needed:

> -static inline unsigned long long cycles_2_ns(unsigned long long cyc)
> +//static inline
> +//#error
> +unsigned long long cycles_2_ns(unsigned long long cyc)

?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12  8:39                                                           ` Ingo Molnar
@ 2004-11-12 10:52                                                             ` Bill Huey
  0 siblings, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-11-12 10:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Fri, Nov 12, 2004 at 09:39:38AM +0100, Ingo Molnar wrote:
> * Bill Huey <bhuey@lnxw.com> wrote:
> > > Patch to get rudimentary kgdb support working.
> 
> thanks, the patch looks good. Is this one really needed:

No, it's not. It's for my timing stuff that's going to be release
as soon as I figure out how to deal with the irq balancing code.
(I'm still learning this as I go along)

I'm a newbie to releasing patches, so scold me when you feel it's
appropriate. :)

bill


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-11 21:51                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1 Ingo Molnar
  2004-11-12  4:08                                                       ` Bill Huey
@ 2004-11-12 14:31                                                       ` Shane Shrybman
  2004-11-12 17:27                                                         ` K.R. Foley
  2004-11-12 20:13                                                         ` Ingo Molnar
  2004-11-12 19:48                                                       ` Gunther Persoons
                                                                         ` (3 subsequent siblings)
  5 siblings, 2 replies; 951+ messages in thread
From: Shane Shrybman @ 2004-11-12 14:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Amit Shah

On Thu, 2004-11-11 at 16:51, Ingo Molnar wrote:
> i have released the -V0.7.25-1 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>     http://redhat.com/~mingo/realtime-preempt/
> 
> this is a fixes-only release that resolves a couple of bugs that slipped
> into -V0.7.25-0:
> 
>  - lockup/deadlock fix: make debug_direct_keyboard default to 0. It is
>    only a debug helper to be used for development, it was never intended
>    to be enabled. This fix should resolve the bugs reported by Gunther
>    Persoons and Mark H. Johnson.

Ahh, that probably explains the problems I had with it!

V0.7.25-1 has been stable here with the ivtv driver for 11 hrs. No sign
of the ide dma time out issue either. Out of curiosity, do we know what
solved that problem?

Regards,

Shane


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12 14:31                                                       ` Shane Shrybman
@ 2004-11-12 17:27                                                         ` K.R. Foley
  2004-11-12 17:50                                                           ` Shane Shrybman
  2004-11-12 20:13                                                         ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-11-12 17:27 UTC (permalink / raw)
  To: Shane Shrybman
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Amit Shah

Shane Shrybman wrote:
> On Thu, 2004-11-11 at 16:51, Ingo Molnar wrote:
> 
>>i have released the -V0.7.25-1 Real-Time Preemption patch, which can be
>>downloaded from the usual place:
>>
>>    http://redhat.com/~mingo/realtime-preempt/
>>
>>this is a fixes-only release that resolves a couple of bugs that slipped
>>into -V0.7.25-0:
>>
>> - lockup/deadlock fix: make debug_direct_keyboard default to 0. It is
>>   only a debug helper to be used for development, it was never intended
>>   to be enabled. This fix should resolve the bugs reported by Gunther
>>   Persoons and Mark H. Johnson.
> 
> 
> Ahh, that probably explains the problems I had with it!
> 
> V0.7.25-1 has been stable here with the ivtv driver for 11 hrs. No sign
> of the ide dma time out issue either. Out of curiosity, do we know what
> solved that problem?
> 
> Regards,
> 
> Shane
> 

What sort of errors did you get about the ide dma timeouts?

kr


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12 17:27                                                         ` K.R. Foley
@ 2004-11-12 17:50                                                           ` Shane Shrybman
  0 siblings, 0 replies; 951+ messages in thread
From: Shane Shrybman @ 2004-11-12 17:50 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Amit Shah

On Fri, 2004-11-12 at 12:27, K.R. Foley wrote:
> Shane Shrybman wrote:
> > On Thu, 2004-11-11 at 16:51, Ingo Molnar wrote:
> > 
> >>i have released the -V0.7.25-1 Real-Time Preemption patch, which can be
> >>downloaded from the usual place:
> >>
> >>    http://redhat.com/~mingo/realtime-preempt/
> >>
> >>this is a fixes-only release that resolves a couple of bugs that slipped
> >>into -V0.7.25-0:
> >>
> >> - lockup/deadlock fix: make debug_direct_keyboard default to 0. It is
> >>   only a debug helper to be used for development, it was never intended
> >>   to be enabled. This fix should resolve the bugs reported by Gunther
> >>   Persoons and Mark H. Johnson.
> > 
> > 
> > Ahh, that probably explains the problems I had with it!
> > 
> > V0.7.25-1 has been stable here with the ivtv driver for 11 hrs. No sign
> > of the ide dma time out issue either. Out of curiosity, do we know what
> > solved that problem?
> > 
> > Regards,
> > 
> > Shane
> > 
> 
> What sort of errors did you get about the ide dma timeouts?
> 

Typical example of the error message:

kernel: hde: dma_timer_expiry: dma status == 0x24
kernel: ALSA sound/core/pcm_native.c:1424: playback drain error (DMA or IRQ trouble?)
kernel: PDC202XX: Primary channel reset.
kernel: hde: DMA interrupt recovery
kernel: hde: lost interrupt

This was on a Promise TX2 133 ide card with one IDE disk. The problem
would show itself if using the RT patches and APIC. But the problem seems
to have been resolved now.

> kr
> 

Regards,

Shane


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-11 21:51                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1 Ingo Molnar
  2004-11-12  4:08                                                       ` Bill Huey
  2004-11-12 14:31                                                       ` Shane Shrybman
@ 2004-11-12 19:48                                                       ` Gunther Persoons
  2004-11-12 20:19                                                         ` Ingo Molnar
  2004-11-14 12:56                                                       ` Florian Schmidt
                                                                         ` (2 subsequent siblings)
  5 siblings, 1 reply; 951+ messages in thread
From: Gunther Persoons @ 2004-11-12 19:48 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

Ingo Molnar wrote:

>i have released the -V0.7.25-1 Real-Time Preemption patch, which can be
>downloaded from the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/
>
>this is a fixes-only release that resolves a couple of bugs that slipped
>into -V0.7.25-0:
>
> - lockup/deadlock fix: make debug_direct_keyboard default to 0. It is
>   only a debug helper to be used for development, it was never intended
>   to be enabled. This fix should resolve the bugs reported by Gunther
>   Persoons and Mark H. Johnson.
>
> - fix symbol export problems in rtc.ko, reported by Remi Colinet, based
>   on the patch from K.R. Foley.
>
> - make preempt_wakeup_timing default to 1 if enabled in the .config, as 
>   originally intended.
>
>to create a -V0.7.25-1 tree from scratch, the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
>   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc1.bz2
>   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm3/2.6.10-rc1-mm3.bz2
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc1-mm3-V0.7.25-1
>
>	Ingo
>
>  
>
I cant use my pcmcia wireless network card with this version, i can use 
it with V0.7.25-0. dhcpcd and ifconfig lock when i try to use them. 
config attached.

[-- Attachment #2: config --]
[-- Type: text/plain, Size: 30708 bytes --]

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_STANDALONE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS 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_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
# CONFIG_HPET_EMULATE_RTC is not set
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_SMBIOS is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_BADRAM=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y
# CONFIG_PM_DISK is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set
# CONFIG_AMD76X_PM is not set
CONFIG_ACPI_INITRD=y

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_HZ_1000=y
# CONFIG_HZ_512 is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ=1000

#
# 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_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=m
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_YENTA=m
CONFIG_CARDBUS=y
# CONFIG_I82092 is not set
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_FW_LOADER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_PC_PCMCIA is not set
# CONFIG_PARPORT_OTHER 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

#
# 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_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_CARMEL is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_LBD=y
# CONFIG_CDROM_PKTCDVD 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_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_IDEDISK_STROKE is not set
# CONFIG_BLK_DEV_IDECS is not set
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
CONFIG_IDE_TASKFILE_IO=y

#
# 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_ADMA=y
# 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_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_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_REPORT_LUNS=y
# 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

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID 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 is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_MEGARAID is not set
CONFIG_SCSI_SATA=y
# CONFIG_SCSI_SATA_SVW is not set
CONFIG_SCSI_ATA_PIIX=y
# CONFIG_SCSI_ATA_ITE is not set
# CONFIG_SCSI_SATA_PROMISE is not set
# CONFIG_SCSI_SATA_SX4 is not set
# CONFIG_SCSI_SATA_SIL is not set
# CONFIG_SCSI_SATA_SIS 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_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO 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_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP 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_QLA6322 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

#
# PCMCIA SCSI adapter support
#
# CONFIG_PCMCIA_AHA152X is not set
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_NINJA_SCSI is not set
# CONFIG_PCMCIA_QLOGIC is not set
# CONFIG_PCMCIA_SYM53C500 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

#
# 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

#
# 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

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV 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_PNP 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

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA 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_LAYER7 is not set
# CONFIG_IP_NF_MATCH_CHILDLEVEL is not set
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_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
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_LOCAL is not set
# 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_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y
# CONFIG_IP_NF_RAW 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_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET 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_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 is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
# CONFIG_WAVELAN is not set
# CONFIG_PCMCIA_WAVELAN is not set
# CONFIG_PCMCIA_NETWAVE is not set

#
# Wireless 802.11 Frequency Hopping cards support
#
# CONFIG_PCMCIA_RAYCS is not set

#
# Wireless 802.11b ISA/PCI cards support
#
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set

#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
CONFIG_AIRO_CS=m
# CONFIG_PCMCIA_WL3501 is not set

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
# CONFIG_PRISM54 is not set
CONFIG_NET_WIRELESS=y

#
# PCMCIA network device support
#
# CONFIG_NET_PCMCIA 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

#
# 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 I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
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

#
# 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

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_NR_TTY_DEVICES=63
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_CS 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_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
# CONFIG_QIC02_TAPE 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_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_INTEL_MCH is not set
# 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_GAMMA is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=y
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
# CONFIG_HPET_NOMMAP is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
CONFIG_FB=y
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_CLE266 is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE is not set

#
# Logo configuration
#
CONFIG_LOGO=y
CONFIG_LOGO_WALKEN=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y

#
# Bootsplash configuration
#

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_RAWMIDI=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_MPU401_UART=y
# 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_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_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_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=y
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP 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_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# ALSA USB devices
#
# CONFIG_SND_USB_AUDIO is not set

#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_VXP440 is not set
# CONFIG_SND_PDAUDIOCF is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
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

#
# 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_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
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_HP8200e 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 Human Interface Devices (HID)
#
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_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network adaptors
#
# 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

#
# 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_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_TEST is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISER4_FS=y
# CONFIG_REISER4_FS_SYSCALL is not set
CONFIG_REISER4_LARGE_KEY=y
# CONFIG_REISER4_CHECK is not set
CONFIG_REISER4_USE_EFLUSH=y
# CONFIG_REISER4_COPY_ON_CAPTURE is not set
# CONFIG_REISER4_BADBLOCKS is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
# CONFIG_DEVFS_DEBUG is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_SUPERMOUNT 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_SQUASHFS 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
# CONFIG_LUFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 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 is not set
CONFIG_LOCKD=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT 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

#
# 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_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=y
CONFIG_OPROFILE=y

#
# NeTraverse Win4Lin Support
#
# CONFIG_MKI is not set

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_KGDB_MORE is not set
# CONFIG_FRAME_POINTER is not set
# CONFIG_4KSTACKS is not set
CONFIG_SCHEDSTATS=y

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
# CONFIG_QSORT is not set
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_STD_RESOURCES=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12 14:31                                                       ` Shane Shrybman
  2004-11-12 17:27                                                         ` K.R. Foley
@ 2004-11-12 20:13                                                         ` Ingo Molnar
  2004-11-12 22:15                                                           ` Shane Shrybman
  2004-11-12 23:44                                                           ` Shane Shrybman
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-12 20:13 UTC (permalink / raw)
  To: Shane Shrybman
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Amit Shah


* Shane Shrybman <shrybman@aei.ca> wrote:

> V0.7.25-1 has been stable here with the ivtv driver for 11 hrs. No
> sign of the ide dma time out issue either. Out of curiosity, do we
> know what solved that problem?

could you try the attached patch - does it trigger the DMA timeouts
again? There were 3 changes to the IOAPIC code that could have affected
your dma-timeout problem, this patch reverts all of them.

Mark's suggestion sounds quite plausible too - but the question is, your
timeout problems went away previously by tweaking io_apic.c, so it would
be nice to see that they are still gone even with the old 'broken'
io_apic.c logic. (none of the io_apic.c changes fixes any particular
bug, they are only latency optimizations, so i'd be surprised if they
really impacted your timeout problems.)

if the DMA timeouts are still gone even with this patch applied then i
think it's safe to conclude that Mark's explanation is the correct one,
and that it was starvation of the SCHED_OTHER IDE irq-thread that caused
the timeouts: it _really_ was a timeout. (a workaround would be to make
the timeout longer)

	Ingo

--- linux/arch/i386/kernel/io_apic.c.orig2	
+++ linux/arch/i386/kernel/io_apic.c	
@@ -150,7 +150,7 @@ static void update_io_apic_cache(unsigne
 	}
 }
 
-#define IOAPIC_CACHE
+// #define IOAPIC_CACHE
 /*
  * Some systems need a POST flush or else level-triggered interrupts
  * generate lots of spurious interrupts due to the POST-ed write not
@@ -188,7 +188,7 @@ static void __modify_IO_APIC_irq (unsign
 		/*
 		 * Force POST flush by reading:
 	 	 */
-		reg = *(IO_APIC_BASE(entry->apic)+4);
+		reg = io_apic_read(entry->apic, 0x10 + pin*2);
 #endif
 		if (!entry->next)
 			break;
@@ -1940,7 +1940,7 @@ static unsigned int startup_level_ioapic
  * unacked local APIC is dangerous on SMP as it can prevent the
  * delivery of IPIs and can thus cause deadlocks.)
  */
-#if defined(CONFIG_PREEMPT_HARDIRQS) && defined(CONFIG_SMP)
+#if defined(CONFIG_PREEMPT_HARDIRQS)
 
 static void mask_and_ack_level_ioapic_irq(unsigned int irq)
 {

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12 19:48                                                       ` Gunther Persoons
@ 2004-11-12 20:19                                                         ` Ingo Molnar
  2004-11-13 12:55                                                           ` Gunther Persoons
                                                                             ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-12 20:19 UTC (permalink / raw)
  To: Gunther Persoons; +Cc: linux-kernel


* Gunther Persoons <gunther_persoons@spymac.com> wrote:

> I cant use my pcmcia wireless network card with this version, i can
> use it with V0.7.25-0. dhcpcd and ifconfig lock when i try to use
> them.  config attached.

extremely weird - there simply was no change between -0 and -1 that
could have affected it. If you do this on the -1 kernel:

	echo 0 > /proc/sys/kernel/preempt_wakeup_timing
	echo 1 > /proc/sys/kernel/debug_direct_keyboard

then you'll get precisely the -0 kernel, bit for bit. (plus the symbol
export fix in rtc.ko, which should have zero relevance to your setup.)

[note that debug_direct_keyboard is dangerous.]

so i believe the explanation has to be something else:

 - are you sure the build is correct?

 - are you sure it still works with the -0 kernel, maybe the bug is 
   transient?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12 20:13                                                         ` Ingo Molnar
@ 2004-11-12 22:15                                                           ` Shane Shrybman
  2004-11-12 23:44                                                           ` Shane Shrybman
  1 sibling, 0 replies; 951+ messages in thread
From: Shane Shrybman @ 2004-11-12 22:15 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Amit Shah

On Fri, 2004-11-12 at 15:13, Ingo Molnar wrote:
> * Shane Shrybman <shrybman@aei.ca> wrote:
> 
> > V0.7.25-1 has been stable here with the ivtv driver for 11 hrs. No
> > sign of the ide dma time out issue either. Out of curiosity, do we
> > know what solved that problem?
> 
> could you try the attached patch - does it trigger the DMA timeouts
> again? There were 3 changes to the IOAPIC code that could have affected
> your dma-timeout problem, this patch reverts all of them.
> 

Yes it does trigger the DMA timeouts again. Just the addition of
CONFIG_SMP dep is enough to trigger it. Which isn't surprising since
the hack was to put #if 0 there wasn't it?

> Mark's suggestion sounds quite plausible too - but the question is, your
> timeout problems went away previously by tweaking io_apic.c, so it would
> be nice to see that they are still gone even with the old 'broken'
> io_apic.c logic. (none of the io_apic.c changes fixes any particular
> bug, they are only latency optimizations, so i'd be surprised if they
> really impacted your timeout problems.)
> 
> if the DMA timeouts are still gone even with this patch applied then i
> think it's safe to conclude that Mark's explanation is the correct one,
> and that it was starvation of the SCHED_OTHER IDE irq-thread that caused
> the timeouts: it _really_ was a timeout. (a workaround would be to make
> the timeout longer)
> 
> 	Ingo
> 
> --- linux/arch/i386/kernel/io_apic.c.orig2	
> +++ linux/arch/i386/kernel/io_apic.c	
> @@ -150,7 +150,7 @@ static void update_io_apic_cache(unsigne
>  	}
>  }
>  
> -#define IOAPIC_CACHE
> +// #define IOAPIC_CACHE
>  /*
>   * Some systems need a POST flush or else level-triggered interrupts
>   * generate lots of spurious interrupts due to the POST-ed write not
> @@ -188,7 +188,7 @@ static void __modify_IO_APIC_irq (unsign
>  		/*
>  		 * Force POST flush by reading:
>  	 	 */
> -		reg = *(IO_APIC_BASE(entry->apic)+4);
> +		reg = io_apic_read(entry->apic, 0x10 + pin*2);
>  #endif
>  		if (!entry->next)
>  			break;
> @@ -1940,7 +1940,7 @@ static unsigned int startup_level_ioapic
>   * unacked local APIC is dangerous on SMP as it can prevent the
>   * delivery of IPIs and can thus cause deadlocks.)
>   */
> -#if defined(CONFIG_PREEMPT_HARDIRQS) && defined(CONFIG_SMP)
> +#if defined(CONFIG_PREEMPT_HARDIRQS)
>  
>  static void mask_and_ack_level_ioapic_irq(unsigned int irq)
>  {
> 

shane


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12 20:13                                                         ` Ingo Molnar
  2004-11-12 22:15                                                           ` Shane Shrybman
@ 2004-11-12 23:44                                                           ` Shane Shrybman
  2004-11-14 12:51                                                             ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Shane Shrybman @ 2004-11-12 23:44 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Amit Shah

On Fri, 2004-11-12 at 15:13, Ingo Molnar wrote:
> * Shane Shrybman <shrybman@aei.ca> wrote:
> 
> > V0.7.25-1 has been stable here with the ivtv driver for 11 hrs. No
> > sign of the ide dma time out issue either. Out of curiosity, do we
> > know what solved that problem?
> 
> could you try the attached patch - does it trigger the DMA timeouts
> again? There were 3 changes to the IOAPIC code that could have affected
> your dma-timeout problem, this patch reverts all of them.
> 

Ok, V0.7.25-1 seems to have resolved the DMA timeout problem.

I don't know how useful it is but this patch also seems to have resolved
that problem.

--- linux-2.6.10-rc1mm3-RT3/arch/i386/kernel/io_apic.c	2004-11-11 16:41:37.000000000 -0500
+++ linux-2.6.10-rc1mm3-RT3.T5/arch/i386/kernel/io_apic.c	2004-11-12 17:54:31.000000000 -0500
@@ -156,7 +156,7 @@
  * generate lots of spurious interrupts due to the POST-ed write not
  * reaching the IOAPIC before the IRQ is ACK-ed in the local APIC.
  */
-#define IOAPIC_POSTFLUSH
+//#define IOAPIC_POSTFLUSH
 
 static void __modify_IO_APIC_irq (unsigned int irq, unsigned long enable, unsigned long disable)
 {
@@ -1940,7 +1940,7 @@
  * unacked local APIC is dangerous on SMP as it can prevent the
  * delivery of IPIs and can thus cause deadlocks.)
  */
-#if defined(CONFIG_PREEMPT_HARDIRQS) && defined(CONFIG_SMP)
+#if defined(CONFIG_PREEMPT_HARDIRQS)
 
 static void mask_and_ack_level_ioapic_irq(unsigned int irq)
 {

Regards,

Shane


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12 20:19                                                         ` Ingo Molnar
@ 2004-11-13 12:55                                                           ` Gunther Persoons
  2004-11-13 14:36                                                           ` Gunther Persoons
  2004-11-13 23:12                                                           ` Gunther Persoons
  2 siblings, 0 replies; 951+ messages in thread
From: Gunther Persoons @ 2004-11-13 12:55 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

Ingo Molnar wrote:

>* Gunther Persoons <gunther_persoons@spymac.com> wrote:
>
>  
>
>>I cant use my pcmcia wireless network card with this version, i can
>>use it with V0.7.25-0. dhcpcd and ifconfig lock when i try to use
>>them.  config attached.
>>    
>>
>
>extremely weird - there simply was no change between -0 and -1 that
>could have affected it. If you do this on the -1 kernel:
>
>	echo 0 > /proc/sys/kernel/preempt_wakeup_timing
>	echo 1 > /proc/sys/kernel/debug_direct_keyboard
>
>then you'll get precisely the -0 kernel, bit for bit. (plus the symbol
>export fix in rtc.ko, which should have zero relevance to your setup.)
>
>[note that debug_direct_keyboard is dangerous.]
>
>so i believe the explanation has to be something else:
>
> - are you sure the build is correct?
>
> - are you sure it still works with the -0 kernel, maybe the bug is 
>   transient?
>
>	Ingo
>
>  
>
Removing every software update i did between 25.0 and 25.1 resolved the 
problem, i think there was something with my gentoo init scripts. 
Although 25.0 was working fine with the software updates. I am now going 
to reinstall the updates one by one to see which one caused it.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12 20:19                                                         ` Ingo Molnar
  2004-11-13 12:55                                                           ` Gunther Persoons
@ 2004-11-13 14:36                                                           ` Gunther Persoons
  2004-11-14 12:49                                                             ` Ingo Molnar
  2004-11-13 23:12                                                           ` Gunther Persoons
  2 siblings, 1 reply; 951+ messages in thread
From: Gunther Persoons @ 2004-11-13 14:36 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

Ingo Molnar wrote:

>* Gunther Persoons <gunther_persoons@spymac.com> wrote:
>
>  
>
>>I cant use my pcmcia wireless network card with this version, i can
>>use it with V0.7.25-0. dhcpcd and ifconfig lock when i try to use
>>them.  config attached.
>>    
>>
>
>extremely weird - there simply was no change between -0 and -1 that
>could have affected it. If you do this on the -1 kernel:
>
>	echo 0 > /proc/sys/kernel/preempt_wakeup_timing
>	echo 1 > /proc/sys/kernel/debug_direct_keyboard
>
>then you'll get precisely the -0 kernel, bit for bit. (plus the symbol
>export fix in rtc.ko, which should have zero relevance to your setup.)
>
>[note that debug_direct_keyboard is dangerous.]
>
>so i believe the explanation has to be something else:
>
> - are you sure the build is correct?
>
> - are you sure it still works with the -0 kernel, maybe the bug is 
>   transient?
>
>	Ingo
>
>  
>
As i thought the init scripts were my problem. But i have an other question.
I recently started to use NFS. But with the mainline kernel cpu usage is 
100%, and when i look in top si shows bewteen 40 and 60% cpu usage. With 
your kernel si is 0%, but ksoftriqd/0 shows around 38% cpu usage and  
total cpu usage is around 52%. Is this normal? on my server cpu usage is 
2% but it uses a intel network card. My laptop is using a wireless 
pcmcia card (cisco).

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12 20:19                                                         ` Ingo Molnar
  2004-11-13 12:55                                                           ` Gunther Persoons
  2004-11-13 14:36                                                           ` Gunther Persoons
@ 2004-11-13 23:12                                                           ` Gunther Persoons
  2004-11-14 12:38                                                             ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Gunther Persoons @ 2004-11-13 23:12 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

Ingo Molnar wrote:

>* Gunther Persoons <gunther_persoons@spymac.com> wrote:
>
>  
>
>>I cant use my pcmcia wireless network card with this version, i can
>>use it with V0.7.25-0. dhcpcd and ifconfig lock when i try to use
>>them.  config attached.
>>    
>>
>
>extremely weird - there simply was no change between -0 and -1 that
>could have affected it. If you do this on the -1 kernel:
>
>	echo 0 > /proc/sys/kernel/preempt_wakeup_timing
>	echo 1 > /proc/sys/kernel/debug_direct_keyboard
>
>then you'll get precisely the -0 kernel, bit for bit. (plus the symbol
>export fix in rtc.ko, which should have zero relevance to your setup.)
>
>[note that debug_direct_keyboard is dangerous.]
>
>so i believe the explanation has to be something else:
>
> - are you sure the build is correct?
>
> - are you sure it still works with the -0 kernel, maybe the bug is 
>   transient?
>
>	Ingo
>
>  
>
this bug i got with .26
wget:12388 BUG: lock held at task exit time!
 [c03ec764] {kernel_sem.lock}
.. held by:              wget:12388 [c87d2680, 116]
... acquired at:  __lock_text_start+0x2c/0x63
wget/12388: BUG in __up_mutex at kernel/rt.c:1076
 [<c01395b0>] __up_mutex+0x2a3/0x509 (8)
 [<c037f3b0>] __sched_text_start+0x508/0x64b (36)
 [<c013a637>] up+0xef/0x104 (24)
 [<c037f3b0>] __sched_text_start+0x508/0x64b (12)
 [<c037f3b0>] __sched_text_start+0x508/0x64b (20)
 [<c012480d>] do_exit+0x2d8/0x515 (8)
 [<c0138126>] printk_lock+0x7f/0xc1 (4)
 [<c0381136>] __lock_text_start+0x2c/0x63 (36)
 [<c012480d>] do_exit+0x2d8/0x515 (32)
 [<c012ea47>] get_signal_to_deliver+0x21e/0x379 (16)
 [<c0124ab8>] do_group_exit+0x3f/0xcc (28)
 [<c012ea47>] get_signal_to_deliver+0x21e/0x379 (8)
 [<c012ea73>] get_signal_to_deliver+0x24a/0x379 (24)
 [<c0105f88>] do_signal+0xa4/0x174 (44)
 [<c014725b>] free_hot_page+0x20/0x24 (112)
 [<c0177541>] poll_freewait+0x38/0x40 (12)
 [<c0178254>] sys_poll+0x18b/0x21f (16)
 [<c0177549>] __pollwait+0x0/0xc6 (36)
 [<c010608d>] do_notify_resume+0x35/0x38 (24)
 [<c010620e>] work_notifysig+0x13/0x15 (8)
---------------------------
| preempt count: 00000004 ]
| 4-level deep critical section nesting:
----------------------------------------
.. [<c037eef2>] .... __sched_text_start+0x4a/0x64b
.....[<00000000>] ..   ( <= 0x0)
.. [<c013a5f1>] .... up+0xa9/0x104
.....[<00000000>] ..   ( <= 0x0)
.. [<c0139665>] .... __up_mutex+0x358/0x509
.....[<00000000>] ..   ( <= 0x0)
.. [<c013b1fe>] .... print_traces+0x14/0x44
.....[<00000000>] ..   ( <= 0x0)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-13 23:12                                                           ` Gunther Persoons
@ 2004-11-14 12:38                                                             ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-14 12:38 UTC (permalink / raw)
  To: Gunther Persoons; +Cc: linux-kernel, Karsten Wiese


* Gunther Persoons <gunther_persoons@spymac.com> wrote:

> this bug i got with .26
> wget:12388 BUG: lock held at task exit time!
> [c03ec764] {kernel_sem.lock}
> .. held by:              wget:12388 [c87d2680, 116]
> ... acquired at:  __lock_text_start+0x2c/0x63

i've uploaded .26-1 which has special BKL-debugging code added, which
will (hopefully) pinpoint where the BKL count leaked. (Karsten had
similar problems, with NFS.)

so, could you try .26-1 from the usual place:

    http://redhat.com/~mingo/realtime-preempt/

and make sure you still have CONFIG_RT_DEADLOCK_DETECT enabled. When
this warning message hits next time around it should print some more
info about the place that last acquired the BKL.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-13 14:36                                                           ` Gunther Persoons
@ 2004-11-14 12:49                                                             ` Ingo Molnar
  2004-11-14 14:25                                                               ` Gunther Persoons
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-14 12:49 UTC (permalink / raw)
  To: Gunther Persoons; +Cc: linux-kernel


* Gunther Persoons <gunther_persoons@spymac.com> wrote:

> As i thought the init scripts were my problem. But i have an other
> question. I recently started to use NFS. But with the mainline kernel
> cpu usage is 100%, and when i look in top si shows bewteen 40 and 60%
> cpu usage. With your kernel si is 0%, but ksoftriqd/0 shows around 38%
> cpu usage and total cpu usage is around 52%. Is this normal? on my
> server cpu usage is 2% but it uses a intel network card. My laptop is
> using a wireless pcmcia card (cisco).

normally the RT kernel has higher system overhead (all IRQ traffic goes
to separate thread contexts, involving context-switching, etc.) so a
_reduction_ in system overhead looks a bit strange. Is there a
difference in performance?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-12 23:44                                                           ` Shane Shrybman
@ 2004-11-14 12:51                                                             ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-14 12:51 UTC (permalink / raw)
  To: Shane Shrybman
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Amit Shah


* Shane Shrybman <shrybman@aei.ca> wrote:

> -#define IOAPIC_POSTFLUSH
> +//#define IOAPIC_POSTFLUSH

> -#if defined(CONFIG_PREEMPT_HARDIRQS) && defined(CONFIG_SMP)
> +#if defined(CONFIG_PREEMPT_HARDIRQS)

unfortunately the POST-flush is still needed. Without it i can see lots
of spurious interrupts on SMP systems. (most likely caused by the ACK
reaching the IO-APIC _before_ the mask-the-irq PCI-space write [which
gets delayed in the chipset due to write optimizations], so the IO-APIC
still thinks that the IRQ is enabled and for level-triggered IRQs this
means that another interrupt is sent to the CPU.)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-11 21:51                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1 Ingo Molnar
                                                                         ` (2 preceding siblings ...)
  2004-11-12 19:48                                                       ` Gunther Persoons
@ 2004-11-14 12:56                                                       ` Florian Schmidt
  2004-11-14 13:26                                                         ` K.R. Foley
  2004-11-14 14:15                                                         ` Ingo Molnar
  2004-11-15 14:33                                                       ` Rui Nuno Capela
  2004-11-16 12:54                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-0 Ingo Molnar
  5 siblings, 2 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-14 12:56 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Thu, 11 Nov 2004 22:51:22 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> i have released the -V0.7.25-1 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>     http://redhat.com/~mingo/realtime-preempt/

Hi,

i just build and booted into 26-3 (w/o debugging stuff) and put a little
load on the system (find /'s plus kernel compile plus rtc_wakeup -f 8192).
Got this on the console:

`IRQ 8` [14] is being piggy. need_resched=0, cpu=0

and the machine locked. will build with debugging and try to reproduce.

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-14 12:56                                                       ` Florian Schmidt
@ 2004-11-14 13:26                                                         ` K.R. Foley
  2004-11-14 13:35                                                           ` Florian Schmidt
                                                                             ` (2 more replies)
  2004-11-14 14:15                                                         ` Ingo Molnar
  1 sibling, 3 replies; 951+ messages in thread
From: K.R. Foley @ 2004-11-14 13:26 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

Florian Schmidt wrote:
> On Thu, 11 Nov 2004 22:51:22 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> 
>>i have released the -V0.7.25-1 Real-Time Preemption patch, which can be
>>downloaded from the usual place:
>>
>>    http://redhat.com/~mingo/realtime-preempt/
> 
> 
> Hi,
> 
> i just build and booted into 26-3 (w/o debugging stuff) and put a little
> load on the system (find /'s plus kernel compile plus rtc_wakeup -f 8192).
> Got this on the console:
> 
> `IRQ 8` [14] is being piggy. need_resched=0, cpu=0
> 
> and the machine locked. will build with debugging and try to reproduce.
> 
> flo
> 

Did you get any other messages in the log? This message is harmless as 
far as the machine locking. This gets printed from rtc when a read of 
/dev/rtc is missed before another interrupt arrives.

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-14 13:26                                                         ` K.R. Foley
@ 2004-11-14 13:35                                                           ` Florian Schmidt
  2004-11-14 13:56                                                           ` K.R. Foley
  2004-11-14 14:11                                                           ` Florian Schmidt
  2 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-14 13:35 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sun, 14 Nov 2004 07:26:46 -0600
"K.R. Foley" <kr@cybsft.com> wrote:

> > `IRQ 8` [14] is being piggy. need_resched=0, cpu=0
> > 
> > and the machine locked. will build with debugging and try to reproduce.
> > 
> > flo
> > 
> 
> Did you get any other messages in the log? This message is harmless as 
> far as the machine locking. This gets printed from rtc when a read of 
> /dev/rtc is missed before another interrupt arrives.

I see. I have rebuilt and run the kernel with debugging, but it seems the
console dump is pretty useless when an ncurses app is running on the active
console (1 line at the bottom showed that there was more output, but i
couldn't see it). Will rerun and try to reproduce again without any ncurses
stuff running :)

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-14 13:26                                                         ` K.R. Foley
  2004-11-14 13:35                                                           ` Florian Schmidt
@ 2004-11-14 13:56                                                           ` K.R. Foley
  2004-11-14 14:11                                                           ` Florian Schmidt
  2 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-11-14 13:56 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Florian Schmidt, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

K.R. Foley wrote:
> Florian Schmidt wrote:
> 
>> On Thu, 11 Nov 2004 22:51:22 +0100
>> Ingo Molnar <mingo@elte.hu> wrote:
>>
>>
>>> i have released the -V0.7.25-1 Real-Time Preemption patch, which can be
>>> downloaded from the usual place:
>>>
>>>    http://redhat.com/~mingo/realtime-preempt/
>>
>>
>>
>> Hi,
>>
>> i just build and booted into 26-3 (w/o debugging stuff) and put a little
>> load on the system (find /'s plus kernel compile plus rtc_wakeup -f 
>> 8192).
>> Got this on the console:
>>
>> `IRQ 8` [14] is being piggy. need_resched=0, cpu=0
>>
>> and the machine locked. will build with debugging and try to reproduce.
>>
>> flo
>>
> 
> Did you get any other messages in the log? This message is harmless as 
> far as the machine locking. This gets printed from rtc when a read of 
> /dev/rtc is missed before another interrupt arrives.
> 
> kr

Actually this message should probably be removed, because the only 
process that will every show up as being a piggy anymore will be 'IRQ 
8', right?

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-14 13:26                                                         ` K.R. Foley
  2004-11-14 13:35                                                           ` Florian Schmidt
  2004-11-14 13:56                                                           ` K.R. Foley
@ 2004-11-14 14:11                                                           ` Florian Schmidt
  2 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-14 14:11 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sun, 14 Nov 2004 07:26:46 -0600
"K.R. Foley" <kr@cybsft.com> wrote:

> Did you get any other messages in the log? This message is harmless as 
> far as the machine locking. This gets printed from rtc when a read of 
> /dev/rtc is missed before another interrupt arrives.

Arr, this time it just locked silently. sys-rq keysd were still available
but didn't produce any console output (sys-rq-b still rebooted the machine
though :))

I suppose this doesn't relly make sense w/o a serial console. I will get a
second machine on next friday. Then i can hopefully provide more useful info
than "he my machine locked up"..

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-14 12:56                                                       ` Florian Schmidt
  2004-11-14 13:26                                                         ` K.R. Foley
@ 2004-11-14 14:15                                                         ` Ingo Molnar
  2004-11-15  1:27                                                           ` Florian Schmidt
  2004-11-15 15:15                                                           ` Florian Schmidt
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-14 14:15 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> i just build and booted into 26-3 (w/o debugging stuff) and put a
> little load on the system (find /'s plus kernel compile plus
> rtc_wakeup -f 8192). Got this on the console:
> 
> `IRQ 8` [14] is being piggy. need_resched=0, cpu=0
> 
> and the machine locked. will build with debugging and try to
> reproduce.

hm, i tried and couldnt reproduce this, so i'm curious what your
debugging build yields.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-14 12:49                                                             ` Ingo Molnar
@ 2004-11-14 14:25                                                               ` Gunther Persoons
  0 siblings, 0 replies; 951+ messages in thread
From: Gunther Persoons @ 2004-11-14 14:25 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel

Ingo Molnar wrote:

>* Gunther Persoons <gunther_persoons@spymac.com> wrote:
>
>  
>
>>As i thought the init scripts were my problem. But i have an other
>>question. I recently started to use NFS. But with the mainline kernel
>>cpu usage is 100%, and when i look in top si shows bewteen 40 and 60%
>>cpu usage. With your kernel si is 0%, but ksoftriqd/0 shows around 38%
>>cpu usage and total cpu usage is around 52%. Is this normal? on my
>>server cpu usage is 2% but it uses a intel network card. My laptop is
>>using a wireless pcmcia card (cisco).
>>    
>>
>
>normally the RT kernel has higher system overhead (all IRQ traffic goes
>to separate thread contexts, involving context-switching, etc.) so a
>_reduction_ in system overhead looks a bit strange. Is there a
>difference in performance?
>
>	Ingo
>
>  
>
With the mainline kernel i get speeds around 600-700kb/s and with the RT 
kernel i get speeds around 550kb/s. No other differnces except the cpu 
usage and that the RT kernel feels much more responsive.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-14 14:15                                                         ` Ingo Molnar
@ 2004-11-15  1:27                                                           ` Florian Schmidt
  2004-11-15  2:22                                                             ` K.R. Foley
  2004-11-15 15:15                                                           ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-11-15  1:27 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sun, 14 Nov 2004 15:15:51 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> > i just build and booted into 26-3 (w/o debugging stuff) and put a
> > little load on the system (find /'s plus kernel compile plus
> > rtc_wakeup -f 8192). Got this on the console:
> > 
> > `IRQ 8` [14] is being piggy. need_resched=0, cpu=0
> > 
> > and the machine locked. will build with debugging and try to
> > reproduce.
> 
> hm, i tried and couldnt reproduce this, so i'm curious what your
> debugging build yields.

not mch sadly. I tried booting into it once more and had to wait quite a
while (around 30minutes) until the lock. I got this around 10 minutes before
the lock though:

Nov 15 00:09:23 mango kernel: bug in rtc_read(): called in state S_IDLE!

The system locked up quitly again. no console dump. sys rq kept working (i
could sync, remount ro and reboot). Does sys rq offer diagnosis which would
be useful for you?

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-15  1:27                                                           ` Florian Schmidt
@ 2004-11-15  2:22                                                             ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-11-15  2:22 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

Florian Schmidt wrote:
> On Sun, 14 Nov 2004 15:15:51 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> 
>>>i just build and booted into 26-3 (w/o debugging stuff) and put a
>>>little load on the system (find /'s plus kernel compile plus
>>>rtc_wakeup -f 8192). Got this on the console:
>>>
>>>`IRQ 8` [14] is being piggy. need_resched=0, cpu=0
>>>
>>>and the machine locked. will build with debugging and try to
>>>reproduce.
>>
>>hm, i tried and couldnt reproduce this, so i'm curious what your
>>debugging build yields.
> 
> 
> not mch sadly. I tried booting into it once more and had to wait quite a
> while (around 30minutes) until the lock. I got this around 10 minutes before
> the lock though:
> 
> Nov 15 00:09:23 mango kernel: bug in rtc_read(): called in state S_IDLE!

Still don't think this has anything to do with the lock. This message is 
usually produced by reading the rtc with a program that is running at a 
higher priority than 'IRQ 8'. Did you chrt the 'IRQ 8' thread? Make sure 
the reader priority is at least 1 less than the handler.

> 
> The system locked up quitly again. no console dump. sys rq kept working (i
> could sync, remount ro and reboot). Does sys rq offer diagnosis which would
> be useful for you?

Possibly 't' for trace?

kr
> 
> flo
> 


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-11 21:51                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1 Ingo Molnar
                                                                         ` (3 preceding siblings ...)
  2004-11-14 12:56                                                       ` Florian Schmidt
@ 2004-11-15 14:33                                                       ` Rui Nuno Capela
  2004-11-15 15:40                                                         ` Ingo Molnar
  2004-11-15 16:11                                                         ` Ingo Molnar
  2004-11-16 12:54                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-0 Ingo Molnar
  5 siblings, 2 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-15 14:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, alsa-devel

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]

Ingo Molnar wrote:
>
> i have released the -V0.7.25-1 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
>     http://redhat.com/~mingo/realtime-preempt/
>

Hi,

I've been running RT-0.7.26-3 already on both of my machines (P4/UP laptop
and P4/SMP-HT desktop) and I must say that overall stability seems to be
good.

However I still have some pending complaints ;) These are the ones that
are troubling my confidence:


  1) Almost everytime the P4/SMP box locks up while unloading the ALSA
modules e.g.on shutdown. This has been an issue for quite some time on the
latest RT patches, not exclusive to RT-V0.7.26-3. Probably it
started since the merge into -mm3, but not sure.

  One thing to note is that, when the nmi_watchdog=1 boot parameter is
set, this lockup behavior seem to be avoided.

  This isn't quite an issue on my other P4/UP (laptop), but it segfaults
sometimes too, while rmmod'ing the alsa modules. It doesn't lockup
thought, and the corresponding tracedump can be pasted from syslog (see
attachment). Unfortunately this is the only cross-evidence I could gather,
and hope it helps to a clue, just because...


  2) Serial console (or netconsole, if that matters) aren't showing
anything relevant for debugging; SysRq-T is just silent, only printing a
"Show State" one liner. No traces, no dumps.


  3) USB hotplugging is not working as it should be on my P4/UP laptop
(ohci_hcd), althought it seems to work on the P4/SMP-HT desktop
(uhci_hcd). USB devices are only recognized if and only if already plugged at
boot/init time; plugging in on a later time doesn't get listed by 'lsusb',
but a single 'wakeup' message shows _once_, and only once, on
syslog/dmesg.

  Unplugging and/or plugging in back again, gives you nothing not even
that 'wakeup' message. As reported a few days before, this really seem to
be introduced by -mm3 (and still an issue on -mm4, FWIW).

  I'm just asking for hints here, as one of the main uses of the RT kernel
on my laptop is about using a Tascam US-224 USB Audio/MIDI controller
interface, which is USB 1.1 based and have been quite successful with it,
at least until (and including) -mm2-RT-V0.7.11 .


OK. Just some last resort questions: is there any plans (or recipe) on
merging the RT patch(es) against the 2.6.10(-rc1) vanilla kernel? Or, at
least for my laptop's sake, on top of this late and "well" behaved -mm2 ?

Hope someone knows it better ;)

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


[-- Attachment #2: messages.0-2.6.10-rc1-mm3-RT-V0.7.24 --]
[-- Type: text/plain, Size: 18915 bytes --]

Nov 11 12:39:43 lambda alsa: Shutting down ALSA sound driver (version 1.0.6): 
Nov 11 12:39:46 lambda kernel: usbcore: deregistering driver snd-usb-usx2y
Nov 11 12:39:46 lambda alsa: /etc/rc6.d/K70alsa: line 287:  6663 Segmentation fault      /sbin/rmmod `echo $line | cut -d ' ' -f 1` >/dev/null 2>&1
Nov 11 12:39:46 lambda kernel: BUG: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Nov 11 12:39:46 lambda kernel:  printing eip:
Nov 11 12:39:46 lambda kernel: c012adc5
Nov 11 12:39:46 lambda kernel: *pde = 00000000
Nov 11 12:39:46 lambda kernel: Oops: 0000 [#1]
Nov 11 12:39:46 lambda kernel: PREEMPT 
Nov 11 12:39:46 lambda kernel: Modules linked in: nls_iso8859_15 nls_cp860 vfat fat nls_base realtime commoncap snd_usb_usx2y snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd_ali5451 snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore pcmcia yenta_socket pcmcia_core natsemi crc32 loop subfs evdev ohci_hcd usbcore
Nov 11 12:39:46 lambda kernel: CPU:    0
Nov 11 12:39:46 lambda kernel: EIP:    0060:[__up_mutex+59/353]    Not tainted VLI
Nov 11 12:39:46 lambda kernel: EIP:    0060:[<c012adc5>]    Not tainted VLI
Nov 11 12:39:46 lambda kernel: EFLAGS: 00010083   (2.6.10-rc1-mm3-RT-V0.7.24) 
Nov 11 12:39:46 lambda kernel: EIP is at __up_mutex+0x3b/0x161
Nov 11 12:39:46 lambda kernel: eax: 00000000   ebx: de444000   ecx: 00000064   edx: 00000064
Nov 11 12:39:46 lambda alsa: /etc/rc6.d/K70alsa: line 287:  6690 Segmentation fault      /sbin/rmmod `echo $line | cut -d ' ' -f 1` >/dev/null 2>&1
Nov 11 12:39:46 lambda kernel: esi: df384aa0   edi: e010a58c   ebp: e0062130   esp: de445ee4
Nov 11 12:39:46 lambda kernel: ds: 007b   es: 007b   ss: 0068   preempt: 00000004
Nov 11 12:39:46 lambda kernel: Process rmmod (pid: 6663, threadinfo=de444000 task=d7582550)
Nov 11 12:39:46 lambda kernel: Stack: 00000296 c013b72c 00000286 00000296 c01b0f08 00000000 de444000 c0304a88 
Nov 11 12:39:46 lambda kernel:        e0062120 e0062130 c012b4c0 e010a59c c01b0f08 e010a5b4 c01b0f0a bfffd3e0 
Nov 11 12:39:46 lambda kernel:        de444000 c01b1817 e010a59c 00000000 bfffd3e0 de444000 e010a59c 00000000 
Nov 11 12:39:46 lambda kernel: Call Trace:
Nov 11 12:39:46 lambda kernel:  [kmem_cache_free+74/199] kmem_cache_free+0x4a/0xc7 (8)
Nov 11 12:39:46 lambda kernel:  [<c013b72c>] kmem_cache_free+0x4a/0xc7 (8)
Nov 11 12:39:46 lambda kernel:  [kobject_cleanup+142/144] kobject_cleanup+0x8e/0x90 (12)
Nov 11 12:39:46 lambda kernel:  [<c01b0f08>] kobject_cleanup+0x8e/0x90 (12)
Nov 11 12:39:46 lambda kernel:  [up+53/61] up+0x35/0x3d (24)
Nov 11 12:39:46 lambda kernel:  [<c012b4c0>] up+0x35/0x3d (24)
Nov 11 12:39:46 lambda kernel:  [kobject_cleanup+142/144] kobject_cleanup+0x8e/0x90 (8)
Nov 11 12:39:46 lambda kernel:  [<c01b0f08>] kobject_cleanup+0x8e/0x90 (8)
Nov 11 12:39:46 lambda kernel:  [kobject_release+0/8] kobject_release+0x0/0x8 (8)
Nov 11 12:39:46 lambda kernel:  [<c01b0f0a>] kobject_release+0x0/0x8 (8)
Nov 11 12:39:46 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov 11 12:39:46 lambda kernel:  [<c01b1817>] kref_put+0x51/0xc2 (12)
Nov 11 12:39:46 lambda kernel:  [bus_remove_driver+63/72] bus_remove_driver+0x3f/0x48 (36)
Nov 11 12:39:46 lambda kernel:  [<c01f6f47>] bus_remove_driver+0x3f/0x48 (36)
Nov 11 12:39:46 lambda kernel:  [driver_unregister+11/26] driver_unregister+0xb/0x1a (8)
Nov 11 12:39:46 lambda kernel:  [<c01f72e0>] driver_unregister+0xb/0x1a (8)
Nov 11 12:39:46 lambda kernel:  [pg0+533426599/1069982720] usb_deregister+0x31/0x3f [usbcore] (8)
Nov 11 12:39:46 lambda kernel:  [<e004b1a7>] usb_deregister+0x31/0x3f [usbcore] (8)
Nov 11 12:39:46 lambda kernel:  [sys_delete_module+292/304] sys_delete_module+0x124/0x130 (20)
Nov 11 12:39:46 lambda kernel:  [<c012d368>] sys_delete_module+0x124/0x130 (20)
Nov 11 12:39:46 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176 (32)
Nov 11 12:39:46 lambda kernel:  [<c014499b>] do_munmap+0x11a/0x176 (32)
Nov 11 12:39:46 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 11 12:39:46 lambda kernel:  [<c0144a2f>] sys_munmap+0x38/0x45 (12)
Nov 11 12:39:46 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 11 12:39:46 lambda kernel:  [<c0144a2f>] sys_munmap+0x38/0x45 (24)
Nov 11 12:39:46 lambda kernel:  [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 (12)
Nov 11 12:39:46 lambda kernel:  [<c0103bc1>] sysenter_past_esp+0x52/0x71 (12)
Nov 11 12:39:46 lambda kernel: Code: 10 9c 8f 44 24 08 fa 9c 58 b8 00 e0 ff ff 21 e0 83 40 14 01 83 40 14 01 8b 47 08 e8 f6 81 fe ff 8b 77 08 89 c2 8b 86 38 05 00 00 <8b> 08 0f 18 01 90 8d 9e 38 05 00 00 eb 10 8b 40 0c 39 d0 0f 4c 
Nov 11 12:39:46 lambda kernel:  <6>note: rmmod[6663] exited with preempt_count 3
Nov 11 12:39:46 lambda kernel: BUG: scheduling while atomic: rmmod/0x00000003/6663
Nov 11 12:39:46 lambda kernel: caller is do_exit+0x28d/0x4b6
Nov 11 12:39:46 lambda kernel:  [__schedule+1194/1525] __sched_text_start+0x4aa/0x5f5 (8)
Nov 11 12:39:46 lambda kernel:  [<c02a973a>] __sched_text_start+0x4aa/0x5f5 (8)
Nov 11 12:39:46 lambda kernel:  [exit_notify+1154/2290] exit_notify+0x482/0x8f2 (24)
Nov 11 12:39:46 lambda kernel:  [<c01188be>] exit_notify+0x482/0x8f2 (24)
Nov 11 12:39:46 lambda kernel:  [do_exit+653/1206] do_exit+0x28d/0x4b6 (56)
Nov 11 12:39:46 lambda kernel:  [<c0118fbb>] do_exit+0x28d/0x4b6 (56)
Nov 11 12:39:46 lambda kernel:  [do_divide_error+0/320] do_divide_error+0x0/0x140 (44)
Nov 11 12:39:46 lambda kernel:  [<c0104d79>] do_divide_error+0x0/0x140 (44)
Nov 11 12:39:46 lambda kernel:  [do_page_fault+865/1341] do_page_fault+0x361/0x53d (64)
Nov 11 12:39:46 lambda kernel:  [<c0111344>] do_page_fault+0x361/0x53d (64)
Nov 11 12:39:46 lambda kernel:  [call_usermodehelper+346/364] call_usermodehelper+0x15a/0x16c (72)
Nov 11 12:39:46 lambda kernel:  [<c0125d6a>] call_usermodehelper+0x15a/0x16c (72)
Nov 11 12:39:46 lambda kernel:  [kmem_cache_free+74/199] kmem_cache_free+0x4a/0xc7 (8)
Nov 11 12:39:46 lambda kernel:  [<c013b72c>] kmem_cache_free+0x4a/0xc7 (8)
Nov 11 12:39:46 lambda kernel:  [__kfree_skb+118/263] __kfree_skb+0x76/0x107 (32)
Nov 11 12:39:46 lambda kernel:  [<c025d1dd>] __kfree_skb+0x76/0x107 (32)
Nov 11 12:39:46 lambda kernel:  [__call_usermodehelper+0/72] __call_usermodehelper+0x0/0x48 (16)
Nov 11 12:39:46 lambda kernel:  [<c0125bc8>] __call_usermodehelper+0x0/0x48 (16)
Nov 11 12:39:46 lambda kernel:  [__down_mutex+73/322] __down_mutex+0x49/0x142 (16)
Nov 11 12:39:46 lambda kernel:  [<c02aa833>] __down_mutex+0x49/0x142 (16)
Nov 11 12:39:46 lambda kernel:  [dput+121/657] dput+0x79/0x291 (4)
Nov 11 12:39:46 lambda kernel:  [<c0166519>] dput+0x79/0x291 (4)
Nov 11 12:39:46 lambda kernel:  [kfree+81/237] kfree+0x51/0xed (28)
Nov 11 12:39:46 lambda kernel:  [<c013b85e>] kfree+0x51/0xed (28)
Nov 11 12:39:46 lambda kernel:  [do_page_fault+0/1341] do_page_fault+0x0/0x53d (28)
Nov 11 12:39:46 lambda kernel:  [<c0110fe3>] do_page_fault+0x0/0x53d (28)
Nov 11 12:39:46 lambda kernel:  [error_code+43/48] error_code+0x2b/0x30 (8)
Nov 11 12:39:46 lambda kernel:  [<c0104627>] error_code+0x2b/0x30 (8)
Nov 11 12:39:46 lambda kernel:  [vfs_rename+259/936] vfs_rename+0x103/0x3a8 (32)
Nov 11 12:39:46 lambda kernel:  [<c016007b>] vfs_rename+0x103/0x3a8 (32)
Nov 11 12:39:46 lambda kernel:  [__up_mutex+59/353] __up_mutex+0x3b/0x161 (12)
Nov 11 12:39:46 lambda kernel:  [<c012adc5>] __up_mutex+0x3b/0x161 (12)
Nov 11 12:39:46 lambda kernel:  [kmem_cache_free+74/199] kmem_cache_free+0x4a/0xc7 (16)
Nov 11 12:39:46 lambda kernel:  [<c013b72c>] kmem_cache_free+0x4a/0xc7 (16)
Nov 11 12:39:46 lambda kernel:  [kobject_cleanup+142/144] kobject_cleanup+0x8e/0x90 (12)
Nov 11 12:39:46 lambda kernel:  [<c01b0f08>] kobject_cleanup+0x8e/0x90 (12)
Nov 11 12:39:46 lambda kernel:  [up+53/61] up+0x35/0x3d (24)
Nov 11 12:39:46 lambda kernel:  [<c012b4c0>] up+0x35/0x3d (24)
Nov 11 12:39:46 lambda kernel:  [kobject_cleanup+142/144] kobject_cleanup+0x8e/0x90 (8)
Nov 11 12:39:46 lambda kernel:  [<c01b0f08>] kobject_cleanup+0x8e/0x90 (8)
Nov 11 12:39:46 lambda kernel:  [kobject_release+0/8] kobject_release+0x0/0x8 (8)
Nov 11 12:39:46 lambda kernel:  [<c01b0f0a>] kobject_release+0x0/0x8 (8)
Nov 11 12:39:46 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov 11 12:39:46 lambda kernel:  [<c01b1817>] kref_put+0x51/0xc2 (12)
Nov 11 12:39:46 lambda kernel:  [bus_remove_driver+63/72] bus_remove_driver+0x3f/0x48 (36)
Nov 11 12:39:46 lambda kernel:  [<c01f6f47>] bus_remove_driver+0x3f/0x48 (36)
Nov 11 12:39:46 lambda kernel:  [driver_unregister+11/26] driver_unregister+0xb/0x1a (8)
Nov 11 12:39:46 lambda kernel:  [<c01f72e0>] driver_unregister+0xb/0x1a (8)
Nov 11 12:39:46 lambda kernel:  [pg0+533426599/1069982720] usb_deregister+0x31/0x3f [usbcore] (8)
Nov 11 12:39:46 lambda kernel:  [<e004b1a7>] usb_deregister+0x31/0x3f [usbcore] (8)
Nov 11 12:39:46 lambda kernel:  [sys_delete_module+292/304] sys_delete_module+0x124/0x130 (20)
Nov 11 12:39:46 lambda kernel:  [<c012d368>] sys_delete_module+0x124/0x130 (20)
Nov 11 12:39:46 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176 (32)
Nov 11 12:39:46 lambda kernel:  [<c014499b>] do_munmap+0x11a/0x176 (32)
Nov 11 12:39:46 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 11 12:39:46 lambda kernel:  [<c0144a2f>] sys_munmap+0x38/0x45 (12)
Nov 11 12:39:46 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 11 12:39:46 lambda kernel:  [<c0144a2f>] sys_munmap+0x38/0x45 (24)
Nov 11 12:39:46 lambda kernel:  [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 (12)
Nov 11 12:39:46 lambda kernel:  [<c0103bc1>] sysenter_past_esp+0x52/0x71 (12)
Nov 11 12:39:46 lambda kernel: ALI 5451 0000:00:06.0: Device was removed without properly calling pci_disable_device(). This may need fixing.
Nov 11 12:39:46 lambda kernel: BUG: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Nov 11 12:39:46 lambda kernel:  printing eip:
Nov 11 12:39:46 lambda kernel: c012adc5
Nov 11 12:39:46 lambda kernel: *pde = 00000000
Nov 11 12:39:46 lambda kernel: Oops: 0000 [#2]
Nov 11 12:39:46 lambda kernel: PREEMPT 
Nov 11 12:39:46 lambda kernel: Modules linked in: nls_iso8859_15 nls_cp860 vfat fat nls_base realtime commoncap snd_usb_usx2y snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd_ali5451 snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore pcmcia yenta_socket pcmcia_core natsemi crc32 loop subfs evdev ohci_hcd usbcore
Nov 11 12:39:46 lambda kernel: CPU:    0
Nov 11 12:39:46 lambda kernel: EIP:    0060:[__up_mutex+59/353]    Not tainted VLI
Nov 11 12:39:46 lambda kernel: EIP:    0060:[<c012adc5>]    Not tainted VLI
Nov 11 12:39:46 lambda kernel: EFLAGS: 00010083   (2.6.10-rc1-mm3-RT-V0.7.24) 
Nov 11 12:39:46 lambda kernel: EIP is at __up_mutex+0x3b/0x161
Nov 11 12:39:46 lambda kernel: eax: 00000000   ebx: de444000   ecx: 00000064   edx: 00000064
Nov 11 12:39:46 lambda kernel: esi: df384aa0   edi: e00f4894   ebp: c02fd3b0   esp: de445ef0
Nov 11 12:39:46 lambda kernel: ds: 007b   es: 007b   ss: 0068   preempt: 00000004
Nov 11 12:39:46 lambda kernel: Process rmmod (pid: 6690, threadinfo=de444000 task=d7582550)
Nov 11 12:39:46 lambda kernel: Stack: 00000282 c013b72c 00000286 00000282 c01b0f08 00000000 de444000 c0304a88 
Nov 11 12:39:46 lambda kernel:        c02fd3a0 c02fd3b0 c012b4c0 e00f48a4 c01b0f08 e00f48bc c01b0f0a bfffd3e0 
Nov 11 12:39:46 lambda kernel:        de444000 c01b1817 e00f48a4 00000000 bfffd3e0 de444000 e00f48a4 00000000 
Nov 11 12:39:46 lambda kernel: Call Trace:
Nov 11 12:39:46 lambda kernel:  [kmem_cache_free+74/199] kmem_cache_free+0x4a/0xc7 (8)
Nov 11 12:39:46 lambda kernel:  [<c013b72c>] kmem_cache_free+0x4a/0xc7 (8)
Nov 11 12:39:46 lambda kernel:  [kobject_cleanup+142/144] kobject_cleanup+0x8e/0x90 (12)
Nov 11 12:39:46 lambda kernel:  [<c01b0f08>] kobject_cleanup+0x8e/0x90 (12)
Nov 11 12:39:46 lambda kernel:  [up+53/61] up+0x35/0x3d (24)
Nov 11 12:39:46 lambda kernel:  [<c012b4c0>] up+0x35/0x3d (24)
Nov 11 12:39:46 lambda kernel:  [kobject_cleanup+142/144] kobject_cleanup+0x8e/0x90 (8)
Nov 11 12:39:46 lambda kernel:  [<c01b0f08>] kobject_cleanup+0x8e/0x90 (8)
Nov 11 12:39:46 lambda kernel:  [kobject_release+0/8] kobject_release+0x0/0x8 (8)
Nov 11 12:39:46 lambda kernel:  [<c01b0f0a>] kobject_release+0x0/0x8 (8)
Nov 11 12:39:46 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov 11 12:39:46 lambda kernel:  [<c01b1817>] kref_put+0x51/0xc2 (12)
Nov 11 12:39:46 lambda kernel:  [bus_remove_driver+63/72] bus_remove_driver+0x3f/0x48 (36)
Nov 11 12:39:46 lambda kernel:  [<c01f6f47>] bus_remove_driver+0x3f/0x48 (36)
Nov 11 12:39:46 lambda kernel:  [driver_unregister+11/26] driver_unregister+0xb/0x1a (8)
Nov 11 12:39:46 lambda kernel:  [<c01f72e0>] driver_unregister+0xb/0x1a (8)
Nov 11 12:39:46 lambda kernel:  [pci_unregister_driver+11/19] pci_unregister_driver+0xb/0x13 (8)
Nov 11 12:39:46 lambda kernel:  [<c01b8816>] pci_unregister_driver+0xb/0x13 (8)
Nov 11 12:39:46 lambda kernel:  [sys_delete_module+292/304] sys_delete_module+0x124/0x130 (8)
Nov 11 12:39:46 lambda kernel:  [<c012d368>] sys_delete_module+0x124/0x130 (8)
Nov 11 12:39:46 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176 (32)
Nov 11 12:39:46 lambda kernel:  [<c014499b>] do_munmap+0x11a/0x176 (32)
Nov 11 12:39:46 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 11 12:39:46 lambda kernel:  [<c0144a2f>] sys_munmap+0x38/0x45 (12)
Nov 11 12:39:46 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 11 12:39:46 lambda kernel:  [<c0144a2f>] sys_munmap+0x38/0x45 (24)
Nov 11 12:39:46 lambda kernel:  [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 (12)
Nov 11 12:39:46 lambda kernel:  [<c0103bc1>] sysenter_past_esp+0x52/0x71 (12)
Nov 11 12:39:46 lambda kernel: Code: 10 9c 8f 44 24 08 fa 9c 58 b8 00 e0 ff ff 21 e0 83 40 14 01 83 40 14 01 8b 47 08 e8 f6 81 fe ff 8b 77 08 89 c2 8b 86 38 05 00 00 <8b> 08 0f 18 01 90 8d 9e 38 05 00 00 eb 10 8b 40 0c 39 d0 0f 4c 
Nov 11 12:39:46 lambda kernel:  <6>note: rmmod[6690] exited with preempt_count 3
Nov 11 12:39:46 lambda kernel: BUG: scheduling while atomic: rmmod/0x00000003/6690
Nov 11 12:39:46 lambda kernel: caller is do_exit+0x28d/0x4b6
Nov 11 12:39:46 lambda kernel:  [__schedule+1194/1525] __sched_text_start+0x4aa/0x5f5 (8)
Nov 11 12:39:46 lambda kernel:  [<c02a973a>] __sched_text_start+0x4aa/0x5f5 (8)
Nov 11 12:39:46 lambda kernel:  [exit_notify+1154/2290] exit_notify+0x482/0x8f2 (24)
Nov 11 12:39:46 lambda kernel:  [<c01188be>] exit_notify+0x482/0x8f2 (24)
Nov 11 12:39:46 lambda kernel:  [do_exit+653/1206] do_exit+0x28d/0x4b6 (56)
Nov 11 12:39:46 lambda kernel:  [<c0118fbb>] do_exit+0x28d/0x4b6 (56)
Nov 11 12:39:46 lambda kernel:  [do_divide_error+0/320] do_divide_error+0x0/0x140 (44)
Nov 11 12:39:46 lambda kernel:  [<c0104d79>] do_divide_error+0x0/0x140 (44)
Nov 11 12:39:46 lambda kernel:  [do_page_fault+865/1341] do_page_fault+0x361/0x53d (64)
Nov 11 12:39:46 lambda kernel:  [<c0111344>] do_page_fault+0x361/0x53d (64)
Nov 11 12:39:46 lambda kernel:  [call_usermodehelper+346/364] call_usermodehelper+0x15a/0x16c (72)
Nov 11 12:39:46 lambda kernel:  [<c0125d6a>] call_usermodehelper+0x15a/0x16c (72)
Nov 11 12:39:46 lambda kernel:  [kmem_cache_free+74/199] kmem_cache_free+0x4a/0xc7 (8)
Nov 11 12:39:46 lambda kernel:  [<c013b72c>] kmem_cache_free+0x4a/0xc7 (8)
Nov 11 12:39:46 lambda kernel:  [__kfree_skb+118/263] __kfree_skb+0x76/0x107 (32)
Nov 11 12:39:46 lambda kernel:  [<c025d1dd>] __kfree_skb+0x76/0x107 (32)
Nov 11 12:39:46 lambda kernel:  [__call_usermodehelper+0/72] __call_usermodehelper+0x0/0x48 (16)
Nov 11 12:39:46 lambda kernel:  [<c0125bc8>] __call_usermodehelper+0x0/0x48 (16)
Nov 11 12:39:46 lambda kernel:  [__down_mutex+73/322] __down_mutex+0x49/0x142 (16)
Nov 11 12:39:46 lambda kernel:  [<c02aa833>] __down_mutex+0x49/0x142 (16)
Nov 11 12:39:46 lambda kernel:  [dput+121/657] dput+0x79/0x291 (4)
Nov 11 12:39:46 lambda kernel:  [<c0166519>] dput+0x79/0x291 (4)
Nov 11 12:39:46 lambda kernel:  [kfree+81/237] kfree+0x51/0xed (28)
Nov 11 12:39:46 lambda kernel:  [<c013b85e>] kfree+0x51/0xed (28)
Nov 11 12:39:46 lambda kernel:  [do_page_fault+0/1341] do_page_fault+0x0/0x53d (28)
Nov 11 12:39:46 lambda kernel:  [<c0110fe3>] do_page_fault+0x0/0x53d (28)
Nov 11 12:39:46 lambda kernel:  [error_code+43/48] error_code+0x2b/0x30 (8)
Nov 11 12:39:46 lambda kernel:  [<c0104627>] error_code+0x2b/0x30 (8)
Nov 11 12:39:46 lambda kernel:  [vfs_rename+259/936] vfs_rename+0x103/0x3a8 (32)
Nov 11 12:39:46 lambda kernel:  [<c016007b>] vfs_rename+0x103/0x3a8 (32)
Nov 11 12:39:46 lambda kernel:  [__up_mutex+59/353] __up_mutex+0x3b/0x161 (12)
Nov 11 12:39:46 lambda kernel:  [<c012adc5>] __up_mutex+0x3b/0x161 (12)
Nov 11 12:39:46 lambda kernel:  [kmem_cache_free+74/199] kmem_cache_free+0x4a/0xc7 (16)
Nov 11 12:39:46 lambda kernel:  [<c013b72c>] kmem_cache_free+0x4a/0xc7 (16)
Nov 11 12:39:46 lambda kernel:  [kobject_cleanup+142/144] kobject_cleanup+0x8e/0x90 (12)
Nov 11 12:39:46 lambda kernel:  [<c01b0f08>] kobject_cleanup+0x8e/0x90 (12)
Nov 11 12:39:46 lambda kernel:  [up+53/61] up+0x35/0x3d (24)
Nov 11 12:39:46 lambda kernel:  [<c012b4c0>] up+0x35/0x3d (24)
Nov 11 12:39:46 lambda kernel:  [kobject_cleanup+142/144] kobject_cleanup+0x8e/0x90 (8)
Nov 11 12:39:46 lambda kernel:  [<c01b0f08>] kobject_cleanup+0x8e/0x90 (8)
Nov 11 12:39:46 lambda kernel:  [kobject_release+0/8] kobject_release+0x0/0x8 (8)
Nov 11 12:39:46 lambda kernel:  [<c01b0f0a>] kobject_release+0x0/0x8 (8)
Nov 11 12:39:46 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov 11 12:39:46 lambda kernel:  [<c01b1817>] kref_put+0x51/0xc2 (12)
Nov 11 12:39:46 lambda kernel:  [bus_remove_driver+63/72] bus_remove_driver+0x3f/0x48 (36)
Nov 11 12:39:46 lambda kernel:  [<c01f6f47>] bus_remove_driver+0x3f/0x48 (36)
Nov 11 12:39:46 lambda kernel:  [driver_unregister+11/26] driver_unregister+0xb/0x1a (8)
Nov 11 12:39:46 lambda kernel:  [<c01f72e0>] driver_unregister+0xb/0x1a (8)
Nov 11 12:39:46 lambda kernel:  [pci_unregister_driver+11/19] pci_unregister_driver+0xb/0x13 (8)
Nov 11 12:39:46 lambda kernel:  [<c01b8816>] pci_unregister_driver+0xb/0x13 (8)
Nov 11 12:39:46 lambda kernel:  [sys_delete_module+292/304] sys_delete_module+0x124/0x130 (8)
Nov 11 12:39:46 lambda kernel:  [<c012d368>] sys_delete_module+0x124/0x130 (8)
Nov 11 12:39:46 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176 (32)
Nov 11 12:39:46 lambda kernel:  [<c014499b>] do_munmap+0x11a/0x176 (32)
Nov 11 12:39:46 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 11 12:39:46 lambda kernel:  [<c0144a2f>] sys_munmap+0x38/0x45 (12)
Nov 11 12:39:46 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 11 12:39:46 lambda kernel:  [<c0144a2f>] sys_munmap+0x38/0x45 (24)
Nov 11 12:39:46 lambda kernel:  [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 (12)
Nov 11 12:39:46 lambda kernel:  [<c0103bc1>] sysenter_past_esp+0x52/0x71 (12)
Nov 11 12:39:47 lambda alsa:  succeeded

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-14 14:15                                                         ` Ingo Molnar
  2004-11-15  1:27                                                           ` Florian Schmidt
@ 2004-11-15 15:15                                                           ` Florian Schmidt
  1 sibling, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-15 15:15 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

[-- Attachment #1: Type: text/plain, Size: 8167 bytes --]

On Sun, 14 Nov 2004 15:15:51 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > i just build and booted into 26-3 (w/o debugging stuff) and put a
> > little load on the system (find /'s plus kernel compile plus
> > rtc_wakeup -f 8192). Got this on the console:
> > 
> > `IRQ 8` [14] is being piggy. need_resched=0, cpu=0
> > 
> > and the machine locked. will build with debugging and try to
> > reproduce.
> 
> hm, i tried and couldnt reproduce this, so i'm curious what your
> debugging build yields.

Ok, i found time to boot into it once more. Now i'm pretty certain that the
rtc triggers the lock. As this time the kernel ran fine again for ca. 30
minutes. and then it locked right at the moment of spitting one of the rtc
being piggy messages to the ocnsole (of which i get about 1 per minute or
so, so it still might have been coincidence, but i was busy typing atm and
right in the moment of the piggy message, keyboard stopped working).

The sys-rq-t didn't help so much as i only have 50lines on my vga console.
The only thing i got to see was a list of held locks. I wrote down the
unique ones:

lock                held by       aquired at
atomic_read         bash          read_char
gendev_rel_sem      init          init_hwif_data
serio_lock          IRQ 1         serio_interrupt
&mm->mmap_sem       rtc_wakeup    do_page_fault
sysrq_key_table     IRQ 1         __handle_sysrq

Btw: i do have access to another machine on the internet, but i connect to
the net it via ppp0, thus netconsole won't help, right? Would it maybe be
feasible to add some sort of netconsole support which just dumps prinkt's
over any net interface to any IP with the price of not being able to catch
very early printk's (i'm probably talking out of my ass here. you'll set me
straight :))

Flo

.config attached

And FYI: some latency traces from before the lock:

preemption latency trace v1.0.7 on 2.6.10-rc1-mm3-RT-V0.7.26-4-NORT
-------------------------------------------------------
 latency: 985 us, entries: 19 (19)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: IRQ 0/2, uid:0 nice:0 policy:1 rt_prio:49
    -----------------
 => started at: try_to_wake_up+0x5a/0x110 <c01148da>
 => ended at:   finish_task_switch+0x51/0xc0 <c0114dc1>
=======>
    5 80000000 0.000ms (+0.000ms): trace_start_sched_wakeup (try_to_wake_up)
    5 80000000 0.000ms (+0.000ms): (50) ((98))
    5 80000000 0.000ms (+0.000ms): (2) ((5))
    5 80000000 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
    5 80000000 0.000ms (+0.000ms): preempt_schedule (__do_IRQ)
    5 80000000 0.000ms (+0.000ms): irq_exit (do_IRQ)
    5 80000000 0.000ms (+0.000ms): do_softirq (irq_exit)
    5 80000000 0.000ms (+0.983ms): __do_softirq (do_softirq)
    5 00000000 0.983ms (+0.000ms): preempt_schedule (_mmx_memcpy)
    5 80000000 0.984ms (+0.000ms): __schedule (preempt_schedule)
    5 80000000 0.984ms (+0.000ms): profile_hit (__schedule)
    5 80000000 0.984ms (+0.000ms): sched_clock (__schedule)
    2 80000000 0.984ms (+0.000ms): __switch_to (__schedule)
    2 80000000 0.984ms (+0.000ms): (5) ((2))
    2 80000000 0.984ms (+0.000ms): (98) ((50))
    2 80000000 0.985ms (+0.000ms): finish_task_switch (__schedule)
    2 80000000 0.985ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
    2 80000000 0.985ms (+0.003ms): (2) ((50))
    2 80000000 0.989ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)


preemption latency trace v1.0.7 on 2.6.10-rc1-mm3-RT-V0.7.26-4-NORT
-------------------------------------------------------
 latency: 1035 us, entries: 19 (19)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: IRQ 0/2, uid:0 nice:0 policy:1 rt_prio:49
    -----------------
 => started at: try_to_wake_up+0x5a/0x110 <c01148da>
 => ended at:   finish_task_switch+0x51/0xc0 <c0114dc1>
=======>
    5 80000000 0.000ms (+0.000ms): trace_start_sched_wakeup (try_to_wake_up)
    5 80000000 0.000ms (+0.000ms): (50) ((98))
    5 80000000 0.000ms (+0.000ms): (2) ((5))
    5 80000000 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
    5 80000000 0.000ms (+0.000ms): preempt_schedule (__do_IRQ)
    5 80000000 0.000ms (+0.000ms): irq_exit (do_IRQ)
    5 80000000 0.000ms (+0.000ms): do_softirq (irq_exit)
    5 80000000 0.000ms (+1.033ms): __do_softirq (do_softirq)
    5 00000000 1.033ms (+0.000ms): preempt_schedule (_mmx_memcpy)
    5 80000000 1.034ms (+0.000ms): __schedule (preempt_schedule)
    5 80000000 1.034ms (+0.000ms): profile_hit (__schedule)
    5 80000000 1.034ms (+0.000ms): sched_clock (__schedule)
    2 80000000 1.034ms (+0.000ms): __switch_to (__schedule)
    2 80000000 1.034ms (+0.000ms): (5) ((2))
    2 80000000 1.035ms (+0.000ms): (98) ((50))
    2 80000000 1.035ms (+0.000ms): finish_task_switch (__schedule)
    2 80000000 1.035ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
    2 80000000 1.035ms (+0.003ms): (2) ((50))
    2 80000000 1.038ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)

preemption latency trace v1.0.7 on 2.6.10-rc1-mm3-RT-V0.7.26-4-NORT
-------------------------------------------------------
 latency: 1048 us, entries: 19 (19)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: IRQ 0/2, uid:0 nice:0 policy:1 rt_prio:49
    -----------------
 => started at: try_to_wake_up+0x5a/0x110 <c01148da>
 => ended at:   finish_task_switch+0x51/0xc0 <c0114dc1>
=======>
    5 80000000 0.000ms (+0.000ms): trace_start_sched_wakeup (try_to_wake_up)
    5 80000000 0.000ms (+0.000ms): (50) ((98))
    5 80000000 0.000ms (+0.000ms): (2) ((5))
    5 80000000 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
    5 80000000 0.000ms (+0.000ms): preempt_schedule (__do_IRQ)
    5 80000000 0.000ms (+0.000ms): irq_exit (do_IRQ)
    5 80000000 0.000ms (+0.000ms): do_softirq (irq_exit)
    5 80000000 0.000ms (+1.046ms): __do_softirq (do_softirq)
    5 00000000 1.046ms (+0.000ms): preempt_schedule (_mmx_memcpy)
    5 80000000 1.047ms (+0.000ms): __schedule (preempt_schedule)
    5 80000000 1.047ms (+0.000ms): profile_hit (__schedule)
    5 80000000 1.047ms (+0.000ms): sched_clock (__schedule)
    2 80000000 1.047ms (+0.000ms): __switch_to (__schedule)
    2 80000000 1.047ms (+0.000ms): (5) ((2))
    2 80000000 1.047ms (+0.000ms): (98) ((50))
    2 80000000 1.048ms (+0.000ms): finish_task_switch (__schedule)
    2 80000000 1.048ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
    2 80000000 1.048ms (+0.002ms): (2) ((50))
    2 80000000 1.050ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)


preemption latency trace v1.0.7 on 2.6.10-rc1-mm3-RT-V0.7.26-4-NORT
-------------------------------------------------------
 latency: 56 us, entries: 19 (19)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: IRQ 8/14, uid:0 nice:-10 policy:1 rt_prio:98
    -----------------
 => started at: try_to_wake_up+0x5a/0x110 <c01148da>
 => ended at:   finish_task_switch+0x51/0xc0 <c0114dc1>
=======>
    5 80000000 0.000ms (+0.000ms): trace_start_sched_wakeup (try_to_wake_up)
    5 80000000 0.000ms (+0.000ms): (1) ((98))
    5 80000000 0.000ms (+0.000ms): (14) ((5))
    5 80000000 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
    5 80000000 0.000ms (+0.000ms): preempt_schedule (__do_IRQ)
    5 80000000 0.000ms (+0.000ms): irq_exit (do_IRQ)
    5 80000000 0.000ms (+0.000ms): do_softirq (irq_exit)
    5 80000000 0.000ms (+0.054ms): __do_softirq (do_softirq)
    5 00000000 0.055ms (+0.000ms): preempt_schedule (_mmx_memcpy)
    5 80000000 0.055ms (+0.000ms): __schedule (preempt_schedule)
    5 80000000 0.055ms (+0.000ms): profile_hit (__schedule)
    5 80000000 0.055ms (+0.000ms): sched_clock (__schedule)
   14 80000000 0.055ms (+0.000ms): __switch_to (__schedule)
   14 80000000 0.056ms (+0.000ms): (5) ((14))
   14 80000000 0.056ms (+0.000ms): (98) ((1))
   14 80000000 0.056ms (+0.000ms): finish_task_switch (__schedule)
   14 80000000 0.056ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
   14 80000000 0.056ms (+0.003ms): (14) ((1))
   14 80000000 0.059ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)


[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 26580 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-rc1-mm3-RT-V0.7.26-4
# Mon Nov 15 14:54:38 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION="-NORT"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
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

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# 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_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
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_X86_USE_3DNOW=y
# CONFIG_HPET_TIMER is not set
# 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_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_KERN_PHYS_OFFSET=1
# 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 is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y

#
# 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=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_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 is not set
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 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=y
# 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_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_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_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_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM 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

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
CONFIG_RTC_HISTOGRAM=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_STUB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
# CONFIG_SENSORS_LM87 is not set
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_MEMORY is not set
# CONFIG_SND_DEBUG_DETECT is not set

#
# Generic devices
#
CONFIG_SND_DUMMY=m
# 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

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY 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_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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=m
CONFIG_RXRPC=m

#
# 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=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_WAKEUP_TIMING=y
CONFIG_PREEMPT_TRACE=y
CONFIG_CRITICAL_PREEMPT_TIMING=y
CONFIG_CRITICAL_IRQSOFF_TIMING=y
CONFIG_CRITICAL_TIMING=y
CONFIG_LATENCY_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_RT_DEADLOCK_DETECT=y
CONFIG_DEBUG_KOBJECT=y
CONFIG_DEBUG_INFO=y
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
CONFIG_SECURITY_REALTIME=m
# CONFIG_SECURITY_SELINUX is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-15 14:33                                                       ` Rui Nuno Capela
@ 2004-11-15 15:40                                                         ` Ingo Molnar
  2004-11-15 16:11                                                         ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-15 15:40 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, alsa-devel


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

>   2) Serial console (or netconsole, if that matters) aren't showing
> anything relevant for debugging; SysRq-T is just silent, only printing
> a "Show State" one liner. No traces, no dumps.

next time around could you try SysRq-D first?

> OK. Just some last resort questions: is there any plans (or recipe) on
> merging the RT patch(es) against the 2.6.10(-rc1) vanilla kernel? Or,
> at least for my laptop's sake, on top of this late and "well" behaved
> -mm2 ?

there should be an -rc2-mm1 kernel out within the next day or two, at
which point i'll merge. (-rc1-mm5 has some problems.)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-15 14:33                                                       ` Rui Nuno Capela
  2004-11-15 15:40                                                         ` Ingo Molnar
@ 2004-11-15 16:11                                                         ` Ingo Molnar
  2004-11-15 16:52                                                           ` Rui Nuno Capela
       [not found]                                                           ` <33583.195.245.190.93.1100537554.squirrel@195.245.190.93>
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-15 16:11 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, alsa-devel


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

>   1) Almost everytime the P4/SMP box locks up while unloading the ALSA
> modules e.g.on shutdown. This has been an issue for quite some time on
> the latest RT patches, not exclusive to RT-V0.7.26-3. Probably it
> started since the merge into -mm3, but not sure.

hm, the syslog you sent suggests that it's the 2.6.10-rc1-mm3-RT-V0.7.24
kernel that crashed:

 Nov 11 12:39:46 lambda kernel: EFLAGS: 00010083   (2.6.10-rc1-mm3-RT-V0.7.24)

not -V0.7.26-3. The particular rmmod crash you got:

 Nov 11 12:39:46 lambda kernel:  [<c013b72c>] kmem_cache_free+0x4a/0xc7 (8)
 Nov 11 12:39:46 lambda kernel:  [kobject_cleanup+142/144] kobject_cleanup+0x8e/0x90 (12)
 Nov 11 12:39:46 lambda kernel:  [<c01b0f08>] kobject_cleanup+0x8e/0x90 (12)

seems to be quite related to one of the fixes that -V0.7.25 includes:

 - added upstream fix for kobject related crash, pointed out by Shane
   Shrybman.

so ... unless you got similar crashes with -V0.7.25 or later kernels
(but no syslog traces), please try the latest one (-V0.7.26-4), does
that one crash in rmmod too?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-15 16:11                                                         ` Ingo Molnar
@ 2004-11-15 16:52                                                           ` Rui Nuno Capela
       [not found]                                                           ` <33583.195.245.190.93.1100537554.squirrel@195.245.190.93>
  1 sibling, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-15 16:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, alsa-devel

Hi Ingo,
>
> Rui Nuno Capela wrote:
>
>>   1) Almost everytime the P4/SMP box locks up while unloading the ALSA
>> modules e.g.on shutdown. This has been an issue for quite some time on
>> the latest RT patches, not exclusive to RT-V0.7.26-3. Probably it
>> started since the merge into -mm3, but not sure.
>
> hm, the syslog you sent suggests that it's the 2.6.10-rc1-mm3-RT-V0.7.24
> kernel that crashed:
>
>  Nov 11 12:39:46 lambda kernel: EFLAGS: 00010083
> (2.6.10-rc1-mm3-RT-V0.7.24)
>
> not -V0.7.26-3. The particular rmmod crash you got:
>

Yes, but as I said so, I couldn't get any relevent trace on the P4/SMP
box, where the issue means real trouble -- the system just locks up while
serial console's annoyingly quiet about it.

Did you notice about nmi_watchdog=1? As it seems, '/etc/init.d/alsasound
stop' just runs smoothly then.

The dump I sent is in fact taken from my P4/UP desktop, and I thought it
was somewhat related. Indeed, I cannot see it happenning anymore since
running RT-0.7.25-1.

I will try RT-0.7.26-4 later on.

Seeya.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
       [not found]                                                           ` <33583.195.245.190.93.1100537554.squirrel@195.245.190.93>
@ 2004-11-15 22:35                                                             ` Rui Nuno Capela
  2004-11-16 10:41                                                               ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-15 22:35 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah, alsa-devel

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

meself writes:
>
> Ingo Molnar wrote:
>>
>>>   1) Almost everytime the P4/SMP box locks up while unloading the ALSA
>>> modules e.g.on shutdown. This has been an issue for quite some time on
>>> the latest RT patches, not exclusive to RT-V0.7.26-3. Probably it
>>> started since the merge into -mm3, but not sure.
>>
>> hm, the syslog you sent suggests that it's the
>> 2.6.10-rc1-mm3-RT-V0.7.24 kernel that crashed:
>>
>>  Nov 11 12:39:46 lambda kernel: EFLAGS: 00010083
>> (2.6.10-rc1-mm3-RT-V0.7.24)
>>
>> not -V0.7.26-3. The particular rmmod crash you got:
>>
>
> Yes, but as I said so, I couldn't get any relevent trace on the P4/SMP
> box, where the issue means real trouble -- the system just locks up
> while serial console's annoyingly quiet about it.
>
> I will try RT-0.7.26-4 later on.
>

Already testing with RT-0.7.26-5 now. No good. Same lockup behavior on
alsa shutdown, altought not always, but very frequently. Nothing comes out
via serial console. Not even SysRq is of any help, pretty hard these
lockups are.

Oh, about the nmi_watchdog=1 trick: forget what I've told you before; I
already saw a couple of freezes while its on.

(config.gz file attached).

/me out of ideas.

Byw now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: config-2.6.10-rc1-mm3-RT-V0.7.26-5smp.gz --]
[-- Type: application/x-gzip, Size: 8211 bytes --]

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-15 22:35                                                             ` Rui Nuno Capela
@ 2004-11-16 10:41                                                               ` Ingo Molnar
  2004-11-16 12:05                                                                 ` Rui Nuno Capela
  2004-11-16 13:16                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-2 Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-16 10:41 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, alsa-devel


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> Already testing with RT-0.7.26-5 now. No good. Same lockup behavior on
> alsa shutdown, altought not always, but very frequently. Nothing comes
> out via serial console. Not even SysRq is of any help, pretty hard
> these lockups are.

i'm rebasing to -rc2-mm1 currently, it should be completed today and
we'll see whether those ALSA problems are upstream related.

is it stable if you dont unload the ALSA modules?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1
  2004-11-16 10:41                                                               ` Ingo Molnar
@ 2004-11-16 12:05                                                                 ` Rui Nuno Capela
  2004-11-16 13:16                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-2 Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-16 12:05 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah

Ingo Molnar wrote:
>
> Rui Nuno Capela wrote:
>
>> Already testing with RT-0.7.26-5 now. No good. Same lockup behavior on
>> alsa shutdown, altought not always, but very frequently. Nothing comes
>> out via serial console. Not even SysRq is of any help, pretty hard
>> these lockups are.
>
> i'm rebasing to -rc2-mm1 currently, it should be completed today and
> we'll see whether those ALSA problems are upstream related.
>
> is it stable if you dont unload the ALSA modules?
>

Yes, it looks like the stabliest of the RTs I've tested to date. Trouble
only comes when '/etc/init.d/alsasound stop' is called.

Bye.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-0
  2004-11-11 21:51                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1 Ingo Molnar
                                                                         ` (4 preceding siblings ...)
  2004-11-15 14:33                                                       ` Rui Nuno Capela
@ 2004-11-16 12:54                                                       ` Ingo Molnar
  2004-11-16 13:09                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-1 Ingo Molnar
  5 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-16 12:54 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


i have released the -V0.7.27-0 Real-Time Preemption patch, which can be
downloaded from the usual place:

	http://redhat.com/~mingo/realtime-preempt/

this is a pure merge of -V0.7.26-5 to 2.6.10-rc2-mm1, there are no other
changes.

to create a -V0.7.27-0 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm1/2.6.10-rc2-mm1.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.27-0

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-1
  2004-11-16 12:54                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-0 Ingo Molnar
@ 2004-11-16 13:09                                                         ` Ingo Molnar
  2004-11-16 13:40                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3 Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-16 13:09 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


i have released the -V0.7.27-1 Real-Time Preemption patch, which can be
downloaded from the usual place:

	http://redhat.com/~mingo/realtime-preempt/

this quick update fixes a couple of build bugs.

Changes since a -V0.7.27-0:

 - fix iptables compilation error

 - fix selinux compilation error

to create a -V0.7.27-1 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm1/2.6.10-rc2-mm1.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.27-1

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-2
  2004-11-16 10:41                                                               ` Ingo Molnar
  2004-11-16 12:05                                                                 ` Rui Nuno Capela
@ 2004-11-16 13:16                                                                 ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-16 13:16 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, alsa-devel


* Ingo Molnar <mingo@elte.hu> wrote:

> > Already testing with RT-0.7.26-5 now. No good. Same lockup behavior on
> > alsa shutdown, altought not always, but very frequently. Nothing comes
> > out via serial console. Not even SysRq is of any help, pretty hard
> > these lockups are.
> 
> i'm rebasing to -rc2-mm1 currently, it should be completed today and
> we'll see whether those ALSA problems are upstream related.
> 
> is it stable if you dont unload the ALSA modules?

i just found a potential problem that could cause a near-lockup during
module removal. This code in __module_put_and_exit() could loop for
quite long time:

        while (current->lock_depth != -1)
                unlock_kernel();

since for specifically ALSA's no-BKL purpose i've introduced the notion
of ->lock_depth going below -1. So if we happen to put the module while
->lock_depth is -2, it could take quite some time for it to go down to
zero again ... (and it could cause other problems as well)

i fixed this in the -V0.7.27-2 release, freshly uploaded to the usual
place:

      http://redhat.com/~mingo/realtime-preempt/

do you still see lockups with this patch?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3
  2004-11-16 13:09                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-1 Ingo Molnar
@ 2004-11-16 13:40                                                           ` Ingo Molnar
  2004-11-16 14:20                                                             ` Florian Schmidt
                                                                               ` (3 more replies)
  0 siblings, 4 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-16 13:40 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


i have released the -V0.7.27-3 Real-Time Preemption patch, which can be
downloaded from the usual place:

	http://redhat.com/~mingo/realtime-preempt/

this is another quick update to fix a couple of bugs. Sorry about the
fast pace of updates but these fixes are worth having ASAP:

Changes since a -V0.7.27-1:

 - fix module-put BKL count bug - this could explain/fix the lockups
   reported by Rui Nuno Capela.

 - fixed a netfilter related networking deadlock reported by Mark H. 
   Johnson two weeks ago, it triggered on my testbox today. This (rare)
   bug could potentially explain some of the other lockup reports that
   are still open.

 - fix load average constant +1.0 offset when PREEMPT_RT is enabled. 
   This was an artifact of the IRQ-threading of the timer interrupt.

to create a -V0.7.27-3 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm1/2.6.10-rc2-mm1.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3
  2004-11-16 13:40                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3 Ingo Molnar
@ 2004-11-16 14:20                                                             ` Florian Schmidt
  2004-11-16 15:08                                                               ` Florian Schmidt
  2004-11-16 18:43                                                             ` Marcos D. Marado Torres
                                                                               ` (2 subsequent siblings)
  3 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-11-16 14:20 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Tue, 16 Nov 2004 14:40:27 +0100
Ingo Molnar <mingo@elte.hu> wrote:

 
> i have released the -V0.7.27-3 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
> 	http://redhat.com/~mingo/realtime-preempt/
> 
> this is another quick update to fix a couple of bugs. Sorry about the
> fast pace of updates but these fixes are worth having ASAP:

Hi,

i built a 27-4 kernel and tried to boot into it. It hangs after:

Uncompressing linux.. Ok, booting the kernel

Will try plain 2.6.10-rc2-mm1 and 2.6.10-rc2

.config is here:

http://affenbande.org/~tapas/config

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3
  2004-11-16 14:20                                                             ` Florian Schmidt
@ 2004-11-16 15:08                                                               ` Florian Schmidt
  2004-11-16 15:29                                                                 ` Florian Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-11-16 15:08 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Tue, 16 Nov 2004 15:20:21 +0100
Florian Schmidt <mista.tapas@gmx.net> wrote:

> i built a 27-4 kernel and tried to boot into it. It hangs after:
> 
> Uncompressing linux.. Ok, booting the kernel
> 
> Will try plain 2.6.10-rc2-mm1 and 2.6.10-rc2
> 
> .config is here:
> 
> http://affenbande.org/~tapas/config

Ok, both 2.6.10-rc2 and 2.6.10-rc2-mm1 boot fine.. Rebuilding 27-4 kernel to
see if i can still reproduce above mentioned hang..

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3
  2004-11-16 15:08                                                               ` Florian Schmidt
@ 2004-11-16 15:29                                                                 ` Florian Schmidt
  2004-11-16 15:52                                                                   ` Stefan Schweizer
  0 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-11-16 15:29 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Tue, 16 Nov 2004 16:08:22 +0100
Florian Schmidt <mista.tapas@gmx.net> wrote:

> On Tue, 16 Nov 2004 15:20:21 +0100
> Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > i built a 27-4 kernel and tried to boot into it. It hangs after:
> > 
> > Uncompressing linux.. Ok, booting the kernel
> > 
> > Will try plain 2.6.10-rc2-mm1 and 2.6.10-rc2
> > 
> > .config is here:
> > 
> > http://affenbande.org/~tapas/config
> 
> Ok, both 2.6.10-rc2 and 2.6.10-rc2-mm1 boot fine.. Rebuilding 27-4 kernel to
> see if i can still reproduce above mentioned hang..

ok, this new build still hangs at the same spot.

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3
  2004-11-16 15:29                                                                 ` Florian Schmidt
@ 2004-11-16 15:52                                                                   ` Stefan Schweizer
  0 siblings, 0 replies; 951+ messages in thread
From: Stefan Schweizer @ 2004-11-16 15:52 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Tue, 16 Nov 2004 16:29:24 +0100, Florian Schmidt <mista.tapas@gmx.net> wrote:
> ok, this new build still hangs at the same spot.

same problem here

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3
  2004-11-16 13:40                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3 Ingo Molnar
  2004-11-16 14:20                                                             ` Florian Schmidt
@ 2004-11-16 18:43                                                             ` Marcos D. Marado Torres
  2004-11-16 18:51                                                               ` Lee Revell
  2004-11-16 19:53                                                               ` Ingo Molnar
  2004-11-17  0:36                                                             ` Bill Huey
  2004-11-17 12:42                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 Ingo Molnar
  3 siblings, 2 replies; 951+ messages in thread
From: Marcos D. Marado Torres @ 2004-11-16 18:43 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 16 Nov 2004, Ingo Molnar wrote:

> to create a -V0.7.27-3 tree from scratch, the patching order is:
>
>  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
>  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
>  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm1/2.6.10-rc2-mm1.bz2
>  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3
>

root@Atlantis:/usr/src# wget http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3
- --18:43:08--  http://redhat.com/%7Emingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3
            => `realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3'
Resolving redhat.com... 209.132.177.50
Connecting to redhat.com[209.132.177.50]:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3 [following]
- --18:43:11--  http://www.redhat.com/%7Emingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3
            => `realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3'
Resolving www.redhat.com... 209.132.177.50
Connecting to www.redhat.com[209.132.177.50]:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://people.redhat.com/mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3 [following]
- --18:43:12--  http://people.redhat.com/mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3
            => `realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3'
Resolving people.redhat.com... 66.187.233.237
Connecting to people.redhat.com[66.187.233.237]:80... connected.
HTTP request sent, awaiting response... 404 Not Found
18:43:12 ERROR 404: Not Found.


Mind Booster Noori

- -- 
/* *************************************************************** */
    Marcos Daniel Marado Torres	     AKA	Mind Booster Noori
    http://student.dei.uc.pt/~marado   -	  marado@student.dei.uc.pt
    () Join the ASCII ribbon campaign against html email, Microsoft
    /\ attachments and Software patents.   They endanger the World.
    Sign a petition against patents:  http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFBmkpqmNlq8m+oD34RAv3VAJ0Xk4PVQuKmxbWGS9BKCyTj/b3pUACg7H5W
hvMBsDXBU/3xSOJOI4jU7fA=
=AyKN
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3
  2004-11-16 18:43                                                             ` Marcos D. Marado Torres
@ 2004-11-16 18:51                                                               ` Lee Revell
  2004-11-16 19:53                                                               ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-11-16 18:51 UTC (permalink / raw)
  To: Marcos D. Marado Torres
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Tue, 2004-11-16 at 18:43 +0000, Marcos D. Marado Torres wrote:
> HTTP request sent, awaiting response... 404 Not Found
> 18:43:12 ERROR 404: Not Found.

Usually means a bug was found and Ingo is uploading a new version.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3
  2004-11-16 18:43                                                             ` Marcos D. Marado Torres
  2004-11-16 18:51                                                               ` Lee Revell
@ 2004-11-16 19:53                                                               ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-16 19:53 UTC (permalink / raw)
  To: Marcos D. Marado Torres
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Marcos D. Marado Torres <marado@student.dei.uc.pt> wrote:

> root@Atlantis:/usr/src# wget 
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.27-3

> 18:43:12 ERROR 404: Not Found.

yes. If you get a 404 then a newer patch has been uploaded - check the
home directory for the latest patch. Old patches are in the older/
subdirectory.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3
  2004-11-16 13:40                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3 Ingo Molnar
  2004-11-16 14:20                                                             ` Florian Schmidt
  2004-11-16 18:43                                                             ` Marcos D. Marado Torres
@ 2004-11-17  0:36                                                             ` Bill Huey
  2004-11-17 12:42                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 Ingo Molnar
  3 siblings, 0 replies; 951+ messages in thread
From: Bill Huey @ 2004-11-17  0:36 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

[-- Attachment #1: Type: text/plain, Size: 234 bytes --]

On Tue, Nov 16, 2004 at 02:40:27PM +0100, Ingo Molnar wrote:
> i have released the -V0.7.27-3 Real-Time Preemption patch, which can be
> downloaded from the usual place:

Against some version of V0.7.25... that I just deleted.

bill


[-- Attachment #2: t --]
[-- Type: application/x-troff, Size: 42963 bytes --]

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-16 13:40                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3 Ingo Molnar
                                                                               ` (2 preceding siblings ...)
  2004-11-17  0:36                                                             ` Bill Huey
@ 2004-11-17 12:42                                                             ` Ingo Molnar
  2004-11-17 18:18                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-10 Adam Heath
                                                                                 ` (4 more replies)
  3 siblings, 5 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-17 12:42 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


i have released the -V0.7.28-0 Real-Time Preemption patch, which can be
downloaded from the usual place:

	http://redhat.com/~mingo/realtime-preempt/

this is a fixes & latency-reduction release.

Changes since a -V0.7.27-3:

 - made the UP-ioapic code a bit more conservative again - maybe some of
   the lockups are related?

 - removed the BKL from the sound code in a cleaner way and
   removed the quite fragile 'negative ->lock_depth' code. Much less
   intrusive than i originally thought, and much cleaner as well.

 - more fixes to the wakeup-timing logic, 4 false positives fixed in
   total, mostly related to new-task-wakeup not accurately starting the
   tracer.

 - fixed the mmx-memcpy related latency reported by Florian Schmidt and 
   others. Also turned off the MMX/SSE ops in the RAID code, which 
   can introduce similar latencies.

 - kgdb fix from Bill Huey

 - knfsd shutdown with-BKL-held fix

 - highmem compilation fix

 - profiling related crash fix

 - implemented 'direct-path' rescheduling to further reduce scheduling
   latency: the kernel will now in most cases go from try_to_wakeup()
   into the scheduler directly without re-enabling interrupts ever again
   (and thus not giving irq handlers a window to increase latency). This
   is also the final fix for irq nesting and irq-stack recursion.

 - turn off sync wakeups on PREEMPT_RT -> they are latency generators

to create a -V0.7.28-0 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm1/2.6.10-rc2-mm1.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.28-0

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-10
  2004-11-17 12:42                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 Ingo Molnar
@ 2004-11-17 18:18                                                               ` Adam Heath
  2004-11-18 15:44                                                                 ` Ingo Molnar
  2004-11-18  2:38                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 K.R. Foley
                                                                                 ` (3 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: Adam Heath @ 2004-11-17 18:18 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Wed, 17 Nov 2004, Ingo Molnar wrote:

>
> i have released the -V0.7.28-0 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
> 	http://redhat.com/~mingo/realtime-preempt/
>
> this is a fixes & latency-reduction release.
>
> Changes since a -V0.7.27-3:

Running .26-5.  Been running almost 2 days.  All small latency values.  Then,
just a few minutes ago, got a 133us value:

preemption latency trace v1.0.7 on 2.6.10-rc1-mm3-RT-V0.7.26-5
-------------------------------------------------------
 latency: 133 us, entries: 41 (41)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: IRQ 15/19, uid:0 nice:-10 policy:1 rt_prio:46
    -----------------
 => started at: try_to_wake_up+0x5a/0x110 <c0115f1a>
 => ended at:   finish_task_switch+0x51/0xc0 <c0116401>
=======>
    0 80000000 00000000 [0284618592175289] 0.000ms (+0.000ms): trace_start_sched_wakeup+0x8e/0xc0 <c013623e> (try_to_wake_up+0x5a/0x110 <c0115f1a>)
    0 80000000 00000001 [0284618592175411] 0.000ms (+0.000ms): <00000034> (<0000008c>)
    0 80000000 00000002 [0284618592175481] 0.000ms (+0.000ms): <00000013> (<00000000>)
    0 80000000 00000003 [0284618592175763] 0.000ms (+0.000ms): preempt_schedule+0x11/0x80 <c02bbb81> (try_to_wake_up+0xf6/0x110 <c0115fb6>)
    0 80000000 00000004 [0284618592175975] 0.000ms (+0.000ms): preempt_schedule+0x11/0x80 <c02bbb81> (__do_IRQ+0x13d/0x170 <c013f3cd>)
    0 80000000 00000005 [0284618592176118] 0.000ms (+0.127ms): irq_exit+0xb/0x50 <c013f10b> (do_IRQ+0x53/0x70 <c01080d3>)
    0 80000000 00000006 [0284618592387634] 0.127ms (+0.000ms): do_IRQ+0x0/0x70 <c0108080> (<0000a253>)
    0 80000000 00000007 [0284618592387690] 0.127ms (+0.000ms): do_IRQ+0x0/0x70 <c0108080> (<0000000e>)
    0 80000000 00000008 [0284618592387909] 0.128ms (+0.001ms): mask_and_ack_8259A+0xe/0x110 <c010b98e> (__do_IRQ+0x86/0x170 <c013f316>)
    0 80000000 00000009 [0284618592390653] 0.129ms (+0.000ms): preempt_schedule+0x11/0x80 <c02bbb81> (__do_IRQ+0x86/0x170 <c013f316>)
    0 80000000 0000000a [0284618592390834] 0.129ms (+0.000ms): redirect_hardirq+0xe/0xa0 <c013f15e> (__do_IRQ+0xbe/0x170 <c013f34e>)
    0 80000000 0000000b [0284618592390971] 0.129ms (+0.000ms): wake_up_process+0xb/0x30 <c0115fdb> (redirect_hardirq+0x6e/0xa0 <c013f1be>)
    0 80000000 0000000c [0284618592391058] 0.129ms (+0.000ms): try_to_wake_up+0xe/0x110 <c0115ece> (wake_up_process+0x2b/0x30 <c0115ffb>)
    0 80000000 0000000d [0284618592391145] 0.130ms (+0.000ms): task_rq_lock+0xb/0x30 <c0115a8b> (try_to_wake_up+0x27/0x110 <c0115ee7>)
    0 80000000 0000000e [0284618592391351] 0.130ms (+0.000ms): activate_task+0x11/0xa0 <c0115df1> (try_to_wake_up+0x5a/0x110 <c0115f1a>)
    0 80000000 0000000f [0284618592391455] 0.130ms (+0.000ms): sched_clock+0x14/0x80 <c01103c4> (activate_task+0x1c/0xa0 <c0115dfc>)
    0 80000000 00000010 [0284618592391614] 0.130ms (+0.000ms): recalc_task_prio+0xe/0x190 <c0115c5e> (activate_task+0x32/0xa0 <c0115e12>)
    0 80000000 00000011 [0284618592391773] 0.130ms (+0.000ms): effective_prio+0x8/0x60 <c0115bf8> (recalc_task_prio+0x98/0x190 <c0115ce8>)
    0 80000000 00000012 [0284618592391929] 0.130ms (+0.000ms): enqueue_task+0x12/0x50 <c0115bb2> (activate_task+0x6c/0xa0 <c0115e4c>)
    0 80000000 00000013 [0284618592392059] 0.130ms (+0.000ms): trace_start_sched_wakeup+0xe/0xc0 <c01361be> (try_to_wake_up+0x5a/0x110 <c0115f1a>)
    0 80000000 00000014 [0284618592392333] 0.130ms (+0.000ms): preempt_schedule+0x11/0x80 <c02bbb81> (try_to_wake_up+0x5a/0x110 <c0115f1a>)
    0 80000000 00000015 [0284618592392439] 0.130ms (+0.000ms): <00000034> (<0000008c>)
    0 80000000 00000016 [0284618592392510] 0.130ms (+0.000ms): <00000012> (<00000000>)
    0 80000000 00000017 [0284618592392714] 0.130ms (+0.000ms): preempt_schedule+0x11/0x80 <c02bbb81> (try_to_wake_up+0xf6/0x110 <c0115fb6>)
    0 80000000 00000018 [0284618592392916] 0.131ms (+0.000ms): preempt_schedule+0x11/0x80 <c02bbb81> (__do_IRQ+0x13d/0x170 <c013f3cd>)
    0 80000000 00000019 [0284618592393022] 0.131ms (+0.000ms): irq_exit+0xb/0x50 <c013f10b> (do_IRQ+0x53/0x70 <c01080d3>)
    0 80000000 0000001a [0284618592393709] 0.131ms (+0.000ms): preempt_schedule+0x11/0x80 <c02bbb81> (apm_bios_call_simple+0xd5/0xf0 <c0110ff5>)
    0 80000000 0000001b [0284618592393899] 0.131ms (+0.000ms): apm_do_busy+0xb/0x40 <c01111eb> (cpu_idle+0x4c/0x70 <c0103f9c>)
    0 80000000 0000001c [0284618592393987] 0.131ms (+0.000ms): apm_bios_call_simple+0xe/0xf0 <c0110f2e> (apm_do_busy+0x2e/0x40 <c011120e>)
    0 80000000 0000001d [0284618592394648] 0.132ms (+0.000ms): preempt_schedule+0x11/0x80 <c02bbb81> (apm_bios_call_simple+0xd5/0xf0 <c0110ff5>)
    0 00000000 0000001e [0284618592394819] 0.132ms (+0.000ms): preempt_schedule+0x11/0x80 <c02bbb81> (cpu_idle+0x64/0x70 <c0103fb4>)
    0 80000000 0000001f [0284618592394966] 0.132ms (+0.000ms): __schedule+0xe/0x6b0 <c02bb38e> (preempt_schedule+0x58/0x80 <c02bbbc8>)
    0 80000000 00000020 [0284618592395053] 0.132ms (+0.000ms): profile_hit+0x9/0x50 <c011bec9> (__schedule+0x43/0x6b0 <c02bb3c3>)
    0 80000000 00000021 [0284618592395254] 0.132ms (+0.000ms): sched_clock+0x14/0x80 <c01103c4> (__schedule+0x70/0x6b0 <c02bb3f0>)
   19 80000000 00000022 [0284618592395691] 0.132ms (+0.000ms): __switch_to+0xe/0x190 <c01049ae> (__schedule+0x2fc/0x6b0 <c02bb67c>)
   19 80000000 00000023 [0284618592395824] 0.132ms (+0.000ms): <00000000> (<00000013>)
   19 80000000 00000024 [0284618592395876] 0.132ms (+0.000ms): <0000008c> (<00000034>)
   19 80000000 00000025 [0284618592395941] 0.132ms (+0.000ms): finish_task_switch+0x14/0xc0 <c01163c4> (__schedule+0x345/0x6b0 <c02bb6c5>)
   19 80000000 00000026 [0284618592396082] 0.133ms (+0.000ms): trace_stop_sched_switched+0x14/0x190 <c0136284> (finish_task_switch+0x51/0xc0 <c0116401>)
   19 80000000 00000027 [0284618592396150] 0.133ms (+0.002ms): <00000013> (<00000034>)
   19 80000000 00000028 [0284618592399999] 0.135ms (+0.000ms): trace_stop_sched_switched+0x133/0x190 <c01363a3> (finish_task_switch+0x51/0xc0 <c0116401>)

Note the jump in irq_exit/do_IRQ.

I have .27-11 installed, but hadn't rebooted yet into it.  Will compile .28-0,
and hopefully boot into it today.


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-17 12:42                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 Ingo Molnar
  2004-11-17 18:18                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-10 Adam Heath
@ 2004-11-18  2:38                                                               ` K.R. Foley
  2004-11-18  9:57                                                                 ` Ingo Molnar
  2004-11-18 10:24                                                               ` Christian Meder
                                                                                 ` (2 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-11-18  2:38 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

Ingo Molnar wrote:
> i have released the -V0.7.28-0 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
> 	http://redhat.com/~mingo/realtime-preempt/
> 
> this is a fixes & latency-reduction release.
> 

I know I am late reporting this but I didn't figure it out until late
this afternoon. I had trouble booting this one on my SMP workstation at
the office. It would hang after it had almost finished booting. Anyway
the solution was to disable tracing in /etc/rc.local and then re-enable
it after it has finished booting. I know this happens late in the boot
but it works for me.

echo 0 > /proc/sys/kernel/trace_enabled
#echo 0 > /proc/sys/kernel/preempt_wakeup_timing
#echo 50 > /proc/sys/kernel/preempt_max_latency

To be honest I am not sure which of the above fixes the late boot hang 
and I didn't have time to figure it out either. This doesn't happen on 
my SMP system here.

kr


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-18  2:38                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 K.R. Foley
@ 2004-11-18  9:57                                                                 ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18  9:57 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* K.R. Foley <kr@cybsft.com> wrote:

> I know I am late reporting this but I didn't figure it out until late
> this afternoon. I had trouble booting this one on my SMP workstation
> at the office. It would hang after it had almost finished booting.
> Anyway the solution was to disable tracing in /etc/rc.local and then
> re-enable it after it has finished booting. I know this happens late
> in the boot but it works for me.
> 
> echo 0 > /proc/sys/kernel/trace_enabled
> #echo 0 > /proc/sys/kernel/preempt_wakeup_timing
> #echo 50 > /proc/sys/kernel/preempt_max_latency
> 
> To be honest I am not sure which of the above fixes the late boot hang
> and I didn't have time to figure it out either. This doesn't happen on
> my SMP system here.

there's a generic bug i'm chasing right now that seems to get worse with
tracing enabled. The symptom of the bug is typically a system hang.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-17 12:42                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 Ingo Molnar
  2004-11-17 18:18                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-10 Adam Heath
  2004-11-18  2:38                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 K.R. Foley
@ 2004-11-18 10:24                                                               ` Christian Meder
  2004-11-18 16:11                                                                 ` Ingo Molnar
  2004-11-18 12:35                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1 Ingo Molnar
       [not found]                                                               ` <1100732223.3472.10.camel@localhost>
  4 siblings, 1 reply; 951+ messages in thread
From: Christian Meder @ 2004-11-18 10:24 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

On Wed, 2004-11-17 at 13:42 +0100, Ingo Molnar wrote:
> i have released the -V0.7.28-0 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
> 	http://redhat.com/~mingo/realtime-preempt/
> 
> this is a fixes & latency-reduction release.

Hi,

here's another message log this time on my Dell laptop when removing my
prism wlan pccard running the hostap driver.

BTW I didn't see my previous report about my vdr/router box on lkml so I
hope it got through. Otherwise just tell me and I'll resend it.


			Christian

-- 
Christian Meder, email: chris@onestepahead.de

The Way-Seeking Mind of a tenzo is actualized 
by rolling up your sleeves.

                (Eihei Dogen Zenji)

[-- Attachment #2: kern.log --]
[-- Type: text/x-log, Size: 15555 bytes --]

Nov 18 09:43:02 localhost kernel: wifi0: LinkStatus=4 (Access point out of range)
Nov 18 09:43:02 localhost kernel: wifi0: LinkStatus: BSSID=00:09:5b:67:f0:98
Nov 18 09:43:06 localhost kernel: hostap_cs: CS_EVENT_CARD_REMOVAL
Nov 18 09:43:06 localhost kernel: wifi0: card already removed or not configured during shutdown
Nov 18 09:43:06 localhost kernel: wifi0: Interrupt, but dev not OK
Nov 18 09:43:06 localhost kernel: wifi0: card already removed or not configured during shutdown
Nov 18 09:43:07 localhost kernel: BUG: sleeping function called from invalid context modprobe(22211) at kernel/rt.c:1364
Nov 18 09:43:07 localhost kernel: in_atomic():1 [00000004], irqs_disabled():1
Nov 18 09:43:07 localhost kernel:  [__might_sleep+218/233] __might_sleep+0xda/0xe9 (8)
Nov 18 09:43:07 localhost kernel:  [__queue_work+78/102] __queue_work+0x4e/0x66 (24)
Nov 18 09:43:07 localhost kernel:  [__spin_lock+56/87] __spin_lock+0x38/0x57 (16)
Nov 18 09:43:07 localhost kernel:  [__up_mutex+458/1236] __up_mutex+0x1ca/0x4d4 (4)
Nov 18 09:43:07 localhost kernel:  [__up_mutex+458/1236] __up_mutex+0x1ca/0x4d4 (8)
Nov 18 09:43:07 localhost kernel:  [_spin_lock_irqsave+8/11] _spin_lock_irqsave+0x8/0xb (8)
Nov 18 09:43:07 localhost kernel:  [search_module_extables+18/115] search_module_extables+0x12/0x73 (4)
Nov 18 09:43:07 localhost kernel:  [__up_mutex+458/1236] __up_mutex+0x1ca/0x4d4 (4)
Nov 18 09:43:07 localhost kernel:  [search_exception_tables+33/35] search_exception_tables+0x21/0x23 (16)
Nov 18 09:43:07 localhost kernel:  [fixup_exception+30/104] fixup_exception+0x1e/0x68 (8)
Nov 18 09:43:07 localhost kernel:  [do_page_fault+499/1347] do_page_fault+0x1f3/0x543 (12)
Nov 18 09:43:07 localhost kernel:  [__down_mutex+464/844] __down_mutex+0x1d0/0x34c (148)
Nov 18 09:43:07 localhost kernel:  [dput+39/665] dput+0x27/0x299 (4)
Nov 18 09:43:07 localhost kernel:  [do_page_fault+0/1347] do_page_fault+0x0/0x543 (52)
Nov 18 09:43:07 localhost kernel:  [error_code+43/48] error_code+0x2b/0x30 (8)
Nov 18 09:43:07 localhost kernel:  [__up_mutex+458/1236] __up_mutex+0x1ca/0x4d4 (44)
Nov 18 09:43:07 localhost kernel:  [kobject_cleanup+140/142] kobject_cleanup+0x8c/0x8e (44)
Nov 18 09:43:07 localhost kernel:  [up+238/250] up+0xee/0xfa (24)
Nov 18 09:43:07 localhost kernel:  [kobject_cleanup+140/142] kobject_cleanup+0x8c/0x8e (32)
Nov 18 09:43:07 localhost kernel:  [kobject_release+0/8] kobject_release+0x0/0x8 (8)
Nov 18 09:43:07 localhost kernel:  [kref_put+62/232] kref_put+0x3e/0xe8 (12)
Nov 18 09:43:07 localhost kernel:  [bus_remove_driver+63/72] bus_remove_driver+0x3f/0x48 (36)
Nov 18 09:43:07 localhost kernel:  [driver_unregister+11/26] driver_unregister+0xb/0x1a (8)
Nov 18 09:43:07 localhost kernel:  [pg0+541997089/1068487680] exit_prism2_pccard+0xd/0x25 [hostap_cs] (8)
Nov 18 09:43:07 localhost kernel:  [sys_delete_module+315/361] sys_delete_module+0x13b/0x169 (12)
Nov 18 09:43:07 localhost kernel:  [unmap_vma_list+14/23] unmap_vma_list+0xe/0x17 (20)
Nov 18 09:43:07 localhost kernel:  [do_munmap+272/315] do_munmap+0x110/0x13b (12)
Nov 18 09:43:07 localhost kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 18 09:43:07 localhost kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 18 09:43:07 localhost kernel:  [syscall_call+7/11] syscall_call+0x7/0xb (12)
Nov 18 09:43:07 localhost kernel: ---------------------------
Nov 18 09:43:07 localhost kernel: | preempt count: 00000005 ]
Nov 18 09:43:07 localhost kernel: | 5-level deep critical section nesting:
Nov 18 09:43:07 localhost kernel: ----------------------------------------
Nov 18 09:43:07 localhost kernel: .. [up+168/250] .... up+0xa8/0xfa
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [__up_mutex+1221/1236] .... __up_mutex+0x4c5/0x4d4
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [__up_mutex+311/1236] .... __up_mutex+0x137/0x4d4
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [__up_mutex+439/1236] .... __up_mutex+0x1b7/0x4d4
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [print_traces+13/52] .... print_traces+0xd/0x34
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: 
Nov 18 09:43:07 localhost kernel: BUG: Unable to handle kernel paging request at virtual address 656e7265
Nov 18 09:43:07 localhost kernel:  printing eip:
Nov 18 09:43:07 localhost kernel: c012f1ba
Nov 18 09:43:07 localhost kernel: *pde = 00000000
Nov 18 09:43:07 localhost kernel: Oops: 0000 [#1]
Nov 18 09:43:07 localhost kernel: PREEMPT 
Nov 18 09:43:07 localhost kernel: Modules linked in: hostap_crypt_wep hostap_cs hostap nfs lockd sunrpc lp binfmt_misc 8250_pci 8250_pnp 8250 serial_core evdev snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snd_page_alloc
Nov 18 09:43:07 localhost kernel: CPU:    0
Nov 18 09:43:07 localhost kernel: EIP:    0060:[__up_mutex+458/1236]    Not tainted VLI
Nov 18 09:43:07 localhost kernel: EFLAGS: 00010097   (2.6.10-rc2-mm1-rt-v0.7.28-0) 
Nov 18 09:43:07 localhost kernel: EIP is at __up_mutex+0x1ca/0x4d4
Nov 18 09:43:07 localhost kernel: eax: 00000064   ebx: 00000064   ecx: 656e7265   edx: 00000064
Nov 18 09:43:07 localhost kernel: esi: c044f828   edi: d798f180   ebp: e09ea578   esp: cf890ec4
Nov 18 09:43:07 localhost kernel: ds: 007b   es: 007b   ss: 0068   preempt: 00000005
Nov 18 09:43:07 localhost kernel: Process modprobe (pid: 22211, threadinfo=cf890000 task=d11e0120)
Nov 18 09:43:07 localhost kernel: Stack: 00000246 d11e0120 d11e0120 00000246 cf890000 c0407898 00000246 c14d7400 
Nov 18 09:43:07 localhost kernel:        c01f73f2 00000000 e09ea574 c044f828 c0457980 c0457990 c013024c cf890000 
Nov 18 09:43:07 localhost kernel:        c0457964 00000246 c0407880 d57ee108 cf890000 e09ea5a8 c01f73f2 e09ea5c0 
Nov 18 09:43:07 localhost kernel: Call Trace:
Nov 18 09:43:07 localhost kernel:  [kobject_cleanup+140/142] kobject_cleanup+0x8c/0x8e (36)
Nov 18 09:43:07 localhost kernel:  [up+238/250] up+0xee/0xfa (24)
Nov 18 09:43:07 localhost kernel:  [kobject_cleanup+140/142] kobject_cleanup+0x8c/0x8e (32)
Nov 18 09:43:07 localhost kernel:  [kobject_release+0/8] kobject_release+0x0/0x8 (8)
Nov 18 09:43:07 localhost kernel:  [kref_put+62/232] kref_put+0x3e/0xe8 (12)
Nov 18 09:43:07 localhost kernel:  [bus_remove_driver+63/72] bus_remove_driver+0x3f/0x48 (36)
Nov 18 09:43:07 localhost kernel:  [driver_unregister+11/26] driver_unregister+0xb/0x1a (8)
Nov 18 09:43:07 localhost kernel:  [pg0+541997089/1068487680] exit_prism2_pccard+0xd/0x25 [hostap_cs] (8)
Nov 18 09:43:07 localhost kernel:  [sys_delete_module+315/361] sys_delete_module+0x13b/0x169 (12)
Nov 18 09:43:07 localhost kernel:  [unmap_vma_list+14/23] unmap_vma_list+0xe/0x17 (20)
Nov 18 09:43:07 localhost kernel:  [do_munmap+272/315] do_munmap+0x110/0x13b (12)
Nov 18 09:43:07 localhost kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 18 09:43:07 localhost kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 18 09:43:07 localhost kernel:  [syscall_call+7/11] syscall_call+0x7/0xb (12)
Nov 18 09:43:07 localhost kernel: ---------------------------
Nov 18 09:43:07 localhost kernel: | preempt count: 00000006 ]
Nov 18 09:43:07 localhost kernel: | 6-level deep critical section nesting:
Nov 18 09:43:07 localhost kernel: ----------------------------------------
Nov 18 09:43:07 localhost kernel: .. [task_rq_lock+17/24] .... task_rq_lock+0x11/0x18
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [task_rq_lock+17/24] .... task_rq_lock+0x11/0x18
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [__up_mutex+311/1236] .... __up_mutex+0x137/0x4d4
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [__up_mutex+439/1236] .... __up_mutex+0x1b7/0x4d4
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [die+54/381] .... die+0x36/0x17d
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [print_traces+13/52] .... print_traces+0xd/0x34
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: 
Nov 18 09:43:07 localhost kernel: Code: c0 e8 f5 b8 fe ff 0f 0b 36 04 3d 1d 3a c0 b8 01 00 00 00 e8 23 15 00 00 8b 45 08 e8 ae 79 fe ff 8b 7d 08 8b 8f 48 06 00 00 89 c3 <8b> 11 0f 18 02 90 8d 87 48 06 00 00 39 c1 74 18 89 c6 8b 41 0c 
Nov 18 09:43:07 localhost kernel:  <6>note: modprobe[22211] exited with preempt_count 4
Nov 18 09:43:07 localhost kernel: BUG: scheduling while atomic: modprobe/0x10000004/22211
Nov 18 09:43:07 localhost kernel: caller is __cond_resched+0x39/0x45
Nov 18 09:43:07 localhost kernel:  [__schedule+1439/1519] __sched_text_start+0x59f/0x5ef (8)
Nov 18 09:43:07 localhost kernel:  [__cond_resched+57/69] __cond_resched+0x39/0x45 (72)
Nov 18 09:43:07 localhost kernel:  [cond_resched+28/35] cond_resched+0x1c/0x23 (12)
Nov 18 09:43:07 localhost kernel:  [unmap_vmas+318/359] unmap_vmas+0x13e/0x167 (8)
Nov 18 09:43:07 localhost kernel:  [exit_mmap+79/274] exit_mmap+0x4f/0x112 (60)
Nov 18 09:43:07 localhost kernel:  [mmput+66/320] mmput+0x42/0x140 (40)
Nov 18 09:43:07 localhost kernel:  [do_exit+325/1281] do_exit+0x145/0x501 (24)
Nov 18 09:43:07 localhost kernel:  [do_divide_error+0/246] do_divide_error+0x0/0xf6 (44)
Nov 18 09:43:07 localhost kernel:  [do_page_fault+678/1347] do_page_fault+0x2a6/0x543 (64)
Nov 18 09:43:07 localhost kernel:  [__down_mutex+464/844] __down_mutex+0x1d0/0x34c (148)
Nov 18 09:43:07 localhost kernel:  [dput+39/665] dput+0x27/0x299 (4)
Nov 18 09:43:07 localhost kernel:  [do_page_fault+0/1347] do_page_fault+0x0/0x543 (52)
Nov 18 09:43:07 localhost kernel:  [error_code+43/48] error_code+0x2b/0x30 (8)
Nov 18 09:43:07 localhost kernel:  [__up_mutex+458/1236] __up_mutex+0x1ca/0x4d4 (44)
Nov 18 09:43:07 localhost kernel:  [kobject_cleanup+140/142] kobject_cleanup+0x8c/0x8e (44)
Nov 18 09:43:07 localhost kernel:  [up+238/250] up+0xee/0xfa (24)
Nov 18 09:43:07 localhost kernel:  [kobject_cleanup+140/142] kobject_cleanup+0x8c/0x8e (32)
Nov 18 09:43:07 localhost kernel:  [kobject_release+0/8] kobject_release+0x0/0x8 (8)
Nov 18 09:43:07 localhost kernel:  [kref_put+62/232] kref_put+0x3e/0xe8 (12)
Nov 18 09:43:07 localhost kernel:  [bus_remove_driver+63/72] bus_remove_driver+0x3f/0x48 (36)
Nov 18 09:43:07 localhost kernel:  [driver_unregister+11/26] driver_unregister+0xb/0x1a (8)
Nov 18 09:43:07 localhost kernel:  [pg0+541997089/1068487680] exit_prism2_pccard+0xd/0x25 [hostap_cs] (8)
Nov 18 09:43:07 localhost kernel:  [sys_delete_module+315/361] sys_delete_module+0x13b/0x169 (12)
Nov 18 09:43:07 localhost kernel:  [unmap_vma_list+14/23] unmap_vma_list+0xe/0x17 (20)
Nov 18 09:43:07 localhost kernel:  [do_munmap+272/315] do_munmap+0x110/0x13b (12)
Nov 18 09:43:07 localhost kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 18 09:43:07 localhost kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 18 09:43:07 localhost kernel:  [syscall_call+7/11] syscall_call+0x7/0xb (12)
Nov 18 09:43:07 localhost kernel: ---------------------------
Nov 18 09:43:07 localhost kernel: | preempt count: 10000005 ]
Nov 18 09:43:07 localhost kernel: | 5-level deep critical section nesting:
Nov 18 09:43:07 localhost kernel: ----------------------------------------
Nov 18 09:43:07 localhost kernel: .. [task_rq_lock+17/24] .... task_rq_lock+0x11/0x18
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [task_rq_lock+17/24] .... task_rq_lock+0x11/0x18
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [__up_mutex+311/1236] .... __up_mutex+0x137/0x4d4
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [__up_mutex+439/1236] .... __up_mutex+0x1b7/0x4d4
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [print_traces+13/52] .... print_traces+0xd/0x34
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: 
Nov 18 09:43:07 localhost kernel: BUG: scheduling while atomic: modprobe/0x00000004/22211
Nov 18 09:43:07 localhost kernel: caller is do_exit+0x2a1/0x501
Nov 18 09:43:07 localhost kernel:  [__schedule+1439/1519] __sched_text_start+0x59f/0x5ef (8)
Nov 18 09:43:07 localhost kernel:  [do_exit+673/1281] do_exit+0x2a1/0x501 (72)
Nov 18 09:43:07 localhost kernel:  [do_divide_error+0/246] do_divide_error+0x0/0xf6 (44)
Nov 18 09:43:07 localhost kernel:  [do_page_fault+678/1347] do_page_fault+0x2a6/0x543 (64)
Nov 18 09:43:07 localhost kernel:  [__down_mutex+464/844] __down_mutex+0x1d0/0x34c (148)
Nov 18 09:43:07 localhost kernel:  [dput+39/665] dput+0x27/0x299 (4)
Nov 18 09:43:07 localhost kernel:  [do_page_fault+0/1347] do_page_fault+0x0/0x543 (52)
Nov 18 09:43:07 localhost kernel:  [error_code+43/48] error_code+0x2b/0x30 (8)
Nov 18 09:43:07 localhost kernel:  [__up_mutex+458/1236] __up_mutex+0x1ca/0x4d4 (44)
Nov 18 09:43:07 localhost kernel:  [kobject_cleanup+140/142] kobject_cleanup+0x8c/0x8e (44)
Nov 18 09:43:07 localhost kernel:  [up+238/250] up+0xee/0xfa (24)
Nov 18 09:43:07 localhost kernel:  [kobject_cleanup+140/142] kobject_cleanup+0x8c/0x8e (32)
Nov 18 09:43:07 localhost kernel:  [kobject_release+0/8] kobject_release+0x0/0x8 (8)
Nov 18 09:43:07 localhost kernel:  [kref_put+62/232] kref_put+0x3e/0xe8 (12)
Nov 18 09:43:07 localhost kernel:  [bus_remove_driver+63/72] bus_remove_driver+0x3f/0x48 (36)
Nov 18 09:43:07 localhost kernel:  [driver_unregister+11/26] driver_unregister+0xb/0x1a (8)
Nov 18 09:43:07 localhost kernel:  [pg0+541997089/1068487680] exit_prism2_pccard+0xd/0x25 [hostap_cs] (8)
Nov 18 09:43:07 localhost kernel:  [sys_delete_module+315/361] sys_delete_module+0x13b/0x169 (12)
Nov 18 09:43:07 localhost kernel:  [unmap_vma_list+14/23] unmap_vma_list+0xe/0x17 (20)
Nov 18 09:43:07 localhost kernel:  [do_munmap+272/315] do_munmap+0x110/0x13b (12)
Nov 18 09:43:07 localhost kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 18 09:43:07 localhost kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 18 09:43:07 localhost kernel:  [syscall_call+7/11] syscall_call+0x7/0xb (12)
Nov 18 09:43:07 localhost kernel: ---------------------------
Nov 18 09:43:07 localhost kernel: | preempt count: 00000005 ]
Nov 18 09:43:07 localhost kernel: | 5-level deep critical section nesting:
Nov 18 09:43:07 localhost kernel: ----------------------------------------
Nov 18 09:43:07 localhost kernel: .. [task_rq_lock+17/24] .... task_rq_lock+0x11/0x18
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [task_rq_lock+17/24] .... task_rq_lock+0x11/0x18
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [__up_mutex+311/1236] .... __up_mutex+0x137/0x4d4
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [__up_mutex+439/1236] .... __up_mutex+0x1b7/0x4d4
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: .. [print_traces+13/52] .... print_traces+0xd/0x34
Nov 18 09:43:07 localhost kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 18 09:43:07 localhost kernel: 

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 12:35                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1 Ingo Molnar
@ 2004-11-18 12:23                                                                 ` Florian Schmidt
  2004-11-18 14:46                                                                 ` Rui Nuno Capela
                                                                                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-18 12:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Thu, 18 Nov 2004 13:35:21 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> i have released the -V0.7.28-1 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
> 	http://redhat.com/~mingo/realtime-preempt/
> 
> this should fix the lockup bug reported by Florian Schmidt.

great news! did you find any sleep at all? anyways, built and booted fine.
putting load on the system since 15 minutes. If it locks up again, i'll write
another mail.

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-17 12:42                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 Ingo Molnar
                                                                                 ` (2 preceding siblings ...)
  2004-11-18 10:24                                                               ` Christian Meder
@ 2004-11-18 12:35                                                               ` Ingo Molnar
  2004-11-18 12:23                                                                 ` Florian Schmidt
                                                                                   ` (3 more replies)
       [not found]                                                               ` <1100732223.3472.10.camel@localhost>
  4 siblings, 4 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18 12:35 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


i have released the -V0.7.28-1 Real-Time Preemption patch, which can be
downloaded from the usual place:

	http://redhat.com/~mingo/realtime-preempt/

this should fix the lockup bug reported by Florian Schmidt.

there's a generic PREEMPT bug in the upstream kernel: there exists a
single-instruction race window in __flush_tlb(), if the kernel preempted
exactly there in a lazy-TLB thread and certain other, rare scheduling
and MM properties were true as well (a certain constellation of threads
and lazy-TLB kernel threads occured), and the lazy-TLB task then got
another user TLB to inherit, and switched to a task from which it
inherited that new TLB, thus the wrong cr3 was loaded and inherited by
this next, non-lazy-TLB next task; then (and only then) this scenario
would typically manifest itself in the form of an infinite pagefault
lockup occuring much after the fact, upon the next userspace access (to
the joy of a totally baffled kernel developer). I suspect from the
description you can guess how much fun it was to debug it =B-)

the bug is even more rare in the generic kernel, because there most (but
not all) TLB flush points are in a critical section.

this fix could resolve some of the other 'my box just locked up'
reports.

Changes since a -V0.7.28-0:

 - reverted the UP-ioapic change - it was unrelated to the lockup and it
   is known to cause problems on certain IDE/soundcard combinations.

 - fixed and improved the trace_print_on_crash tracing feature - it was
   highly needed to find the TLB bug ...

to create a -V0.7.28-1 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm1/2.6.10-rc2-mm1.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm1-V0.7.28-1

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 12:35                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1 Ingo Molnar
  2004-11-18 12:23                                                                 ` Florian Schmidt
@ 2004-11-18 14:46                                                                 ` Rui Nuno Capela
  2004-11-18 20:01                                                                   ` Ingo Molnar
                                                                                     ` (3 more replies)
  2004-11-18 15:23                                                                 ` Christian Meder
  2004-11-18 16:46                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 Ingo Molnar
  3 siblings, 4 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-18 14:46 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah

Ingo Molnar wrote:
>
> i have released the -V0.7.28-1 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
> 	http://redhat.com/~mingo/realtime-preempt/
>
> this should fix the lockup bug reported by Florian Schmidt.
>


I'm still seeing this sometimes (not everytime) on my P4/UP laptop while
shutting down ALSA modules. This isn't the same as the lockup I've been
reporting lately (that happens on my P4/SMT desktop) but may be remotely
related.


Nov 18 12:22:21 lambda kernel: BUG: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
Nov 18 12:22:21 lambda kernel:  printing eip:
Nov 18 12:22:21 lambda kernel: c0129a4b
Nov 18 12:22:21 lambda kernel: *pde = 00000000
Nov 18 12:22:21 lambda kernel: Oops: 0000 [#1]
Nov 18 12:22:21 lambda kernel: PREEMPT
Nov 18 12:22:21 lambda kernel: Modules linked in: realtime commoncap
snd_ali5451 snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore
pcmcia yenta_socket pcmcia_core natsemi crc32 loop evdev ohci_hcd usbcore
Nov 18 12:22:21 lambda kernel: CPU:    0
Nov 18 12:22:21 lambda kernel: EIP:    0060:[__up_mutex+59/384]    Not
tainted VLI
Nov 18 12:22:21 lambda kernel: EIP:    0060:[<c0129a4b>]    Not tainted VLI
Nov 18 12:22:21 lambda kernel: EFLAGS: 00010006  
(2.6.10-rc2-mm1-RT-V0.7.28-1)
Nov 18 12:22:21 lambda kernel: EIP is at __up_mutex+0x3b/0x180
Nov 18 12:22:21 lambda kernel: eax: 00000000   ebx: d70c2000   ecx:
de2510d0   edx: 00000063
Nov 18 12:22:21 lambda kernel: esi: de2510d0   edi: e00f2894   ebp:
c02fa090   esp: d70c3ef0
Nov 18 12:22:21 lambda kernel: ds: 007b   es: 007b   ss: 0068   preempt:
00000004
Nov 18 12:22:21 lambda kernel: Process rmmod (pid: 6836,
threadinfo=d70c2000 task=dca7ad70)
Nov 18 12:22:21 lambda kernel: Stack: 00000282 c0139cdc 00000286 00000282
c01ad4cb 00000000 d70c2000 c0301908
Nov 18 12:22:21 lambda kernel:        c02fa080 c02fa090 c012a165 e00f28a4
c01ad4cb e00f28bc c01ad4cd bfffd3f0
Nov 18 12:22:21 lambda kernel:        d70c2000 c01adadf e00f28a4 00000000
bfffd3f0 d70c2000 e00f28a4 00000000
Nov 18 12:22:21 lambda kernel: Call Trace:
Nov 18 12:22:21 lambda kernel:  [kmem_cache_free+74/199]
kmem_cache_free+0x4a/0xc7 (8)
Nov 18 12:22:21 lambda kernel:  [<c0139cdc>] kmem_cache_free+0x4a/0xc7 (8)
Nov 18 12:22:21 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (12)
Nov 18 12:22:21 lambda kernel:  [<c01ad4cb>] kobject_cleanup+0x8e/0x90 (12)
Nov 18 12:22:21 lambda kernel:  [up+53/61] up+0x35/0x3d (24)
Nov 18 12:22:21 lambda kernel:  [<c012a165>] up+0x35/0x3d (24)
Nov 18 12:22:21 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (8)
Nov 18 12:22:21 lambda kernel:  [<c01ad4cb>] kobject_cleanup+0x8e/0x90 (8)
Nov 18 12:22:21 lambda kernel:  [kobject_release+0/8]
kobject_release+0x0/0x8 (8)
Nov 18 12:22:21 lambda kernel:  [<c01ad4cd>] kobject_release+0x0/0x8 (8)
Nov 18 12:22:21 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov 18 12:22:21 lambda kernel:  [<c01adadf>] kref_put+0x51/0xc2 (12)
Nov 18 12:22:21 lambda kernel:  [bus_remove_driver+63/72]
bus_remove_driver+0x3f/0x48 (36)
Nov 18 12:22:21 lambda kernel:  [<c01f3aff>] bus_remove_driver+0x3f/0x48 (36)
Nov 18 12:22:21 lambda kernel:  [driver_unregister+11/26]
driver_unregister+0xb/0x1a (8)
Nov 18 12:22:21 lambda kernel:  [<c01f3e98>] driver_unregister+0xb/0x1a (8)
Nov 18 12:22:21 lambda kernel:  [pci_unregister_driver+11/19]
pci_unregister_driver+0xb/0x13 (8)
Nov 18 12:22:21 lambda kernel:  [<c01b4b10>]
pci_unregister_driver+0xb/0x13 (8)
Nov 18 12:22:21 lambda kernel:  [sys_delete_module+292/304]
sys_delete_module+0x124/0x130 (8)
Nov 18 12:22:21 lambda kernel:  [<c012c044>] sys_delete_module+0x124/0x130
(8)
Nov 18 12:22:21 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176
(32)
Nov 18 12:22:21 lambda kernel:  [<c01431b3>] do_munmap+0x11a/0x176 (32)
Nov 18 12:22:21 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 18 12:22:21 lambda kernel:  [<c0143247>] sys_munmap+0x38/0x45 (12)
Nov 18 12:22:21 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 18 12:22:21 lambda kernel:  [<c0143247>] sys_munmap+0x38/0x45 (24)
Nov 18 12:22:21 lambda kernel:  [sysenter_past_esp+82/113]
sysenter_past_esp+0x52/0x71 (12)
Nov 18 12:22:21 lambda kernel:  [<c01023f1>] sysenter_past_esp+0x52/0x71 (12)
Nov 18 12:22:21 lambda kernel: Code: 10 9c 8f 44 24 08 fa 9c 58 b8 00 e0
ff ff 21 e0 83 40 14 01 83 40 14 01 8b 47 08 e8 50 7f fe ff 8b 77 08 89 c2
8b 86 48 05 00 00 <8b> 08 0f 18 01 90 8d 9e 48 05 00 00 eb 10 8b 40 0c 39
d0 0f 4c
Nov 18 12:22:21 lambda kernel:  <6>note: rmmod[6836] exited with
preempt_count 3
Nov 18 12:22:21 lambda kernel: BUG: scheduling while atomic:
rmmod/0x00000003/6836
Nov 18 12:22:21 lambda kernel: caller is do_exit+0x2a5/0x4ce
Nov 18 12:22:21 lambda kernel:  [__schedule+1155/1484]
__sched_text_start+0x483/0x5cc (8)
Nov 18 12:22:21 lambda kernel:  [<c02a6507>]
__sched_text_start+0x483/0x5cc (8)
Nov 18 12:22:21 lambda kernel:  [exit_notify+1154/2281]
exit_notify+0x482/0x8e9 (24)
Nov 18 12:22:21 lambda kernel:  [<c011743a>] exit_notify+0x482/0x8e9 (24)
Nov 18 12:22:21 lambda kernel:  [do_exit+677/1230] do_exit+0x2a5/0x4ce (56)
Nov 18 12:22:21 lambda kernel:  [<c0117b46>] do_exit+0x2a5/0x4ce (56)
Nov 18 12:22:21 lambda kernel:  [do_divide_error+0/320]
do_divide_error+0x0/0x140 (48)
Nov 18 12:22:21 lambda kernel:  [<c01035a9>] do_divide_error+0x0/0x140 (48)
Nov 18 12:22:21 lambda kernel:  [do_page_fault+865/1341]
do_page_fault+0x361/0x53d (64)
Nov 18 12:22:21 lambda kernel:  [<c010fc18>] do_page_fault+0x361/0x53d (64)
Nov 18 12:22:21 lambda kernel:  [call_usermodehelper+346/364]
call_usermodehelper+0x15a/0x16c (72)
Nov 18 12:22:21 lambda kernel:  [<c012493e>]
call_usermodehelper+0x15a/0x16c (72)
Nov 18 12:22:21 lambda kernel:  [__call_usermodehelper+0/72]
__call_usermodehelper+0x0/0x48 (56)
Nov 18 12:22:21 lambda kernel:  [<c012479c>]
__call_usermodehelper+0x0/0x48 (56)
Nov 18 12:22:21 lambda kernel:  [__down_mutex+73/322]
__down_mutex+0x49/0x142 (16)
Nov 18 12:22:21 lambda kernel:  [<c02a7600>] __down_mutex+0x49/0x142 (16)
Nov 18 12:22:21 lambda kernel:  [dput+121/657] dput+0x79/0x291 (4)
Nov 18 12:22:21 lambda kernel:  [<c0165899>] dput+0x79/0x291 (4)
Nov 18 12:22:21 lambda kernel:  [kfree+81/237] kfree+0x51/0xed (28)
Nov 18 12:22:21 lambda kernel:  [<c0139e0e>] kfree+0x51/0xed (28)
Nov 18 12:22:21 lambda kernel:  [do_page_fault+0/1341]
do_page_fault+0x0/0x53d (28)
Nov 18 12:22:21 lambda kernel:  [<c010f8b7>] do_page_fault+0x0/0x53d (28)
Nov 18 12:22:21 lambda kernel:  [error_code+43/48] error_code+0x2b/0x30 (8)
Nov 18 12:22:21 lambda kernel:  [<c0102e57>] error_code+0x2b/0x30 (8)
Nov 18 12:22:21 lambda kernel:  [locate_fd+56/137] locate_fd+0x38/0x89 (32)
Nov 18 12:22:21 lambda kernel:  [<c016007b>] locate_fd+0x38/0x89 (32)
Nov 18 12:22:21 lambda kernel:  [__up_mutex+59/384] __up_mutex+0x3b/0x180
(12)
Nov 18 12:22:21 lambda kernel:  [<c0129a4b>] __up_mutex+0x3b/0x180 (12)
Nov 18 12:22:21 lambda kernel:  [kmem_cache_free+74/199]
kmem_cache_free+0x4a/0xc7 (16)
Nov 18 12:22:21 lambda kernel:  [<c0139cdc>] kmem_cache_free+0x4a/0xc7 (16)
Nov 18 12:22:21 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (12)
Nov 18 12:22:21 lambda kernel:  [<c01ad4cb>] kobject_cleanup+0x8e/0x90 (12)
Nov 18 12:22:21 lambda kernel:  [up+53/61] up+0x35/0x3d (24)
Nov 18 12:22:21 lambda kernel:  [<c012a165>] up+0x35/0x3d (24)
Nov 18 12:22:21 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (8)
Nov 18 12:22:21 lambda kernel:  [<c01ad4cb>] kobject_cleanup+0x8e/0x90 (8)
Nov 18 12:22:21 lambda kernel:  [kobject_release+0/8]
kobject_release+0x0/0x8 (8)
Nov 18 12:22:21 lambda kernel:  [<c01ad4cd>] kobject_release+0x0/0x8 (8)
Nov 18 12:22:21 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov 18 12:22:21 lambda kernel:  [<c01adadf>] kref_put+0x51/0xc2 (12)
Nov 18 12:22:21 lambda kernel:  [bus_remove_driver+63/72]
bus_remove_driver+0x3f/0x48 (36)
Nov 18 12:22:21 lambda kernel:  [<c01f3aff>] bus_remove_driver+0x3f/0x48 (36)
Nov 18 12:22:21 lambda kernel:  [driver_unregister+11/26]
driver_unregister+0xb/0x1a (8)
Nov 18 12:22:21 lambda kernel:  [<c01f3e98>] driver_unregister+0xb/0x1a (8)
Nov 18 12:22:21 lambda kernel:  [pci_unregister_driver+11/19]
pci_unregister_driver+0xb/0x13 (8)
Nov 18 12:22:21 lambda kernel:  [<c01b4b10>]
pci_unregister_driver+0xb/0x13 (8)
Nov 18 12:22:21 lambda kernel:  [sys_delete_module+292/304]
sys_delete_module+0x124/0x130 (8)
Nov 18 12:22:21 lambda kernel:  [<c012c044>] sys_delete_module+0x124/0x130
(8)
Nov 18 12:22:21 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176
(32)
Nov 18 12:22:21 lambda kernel:  [<c01431b3>] do_munmap+0x11a/0x176 (32)
Nov 18 12:22:21 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 18 12:22:21 lambda kernel:  [<c0143247>] sys_munmap+0x38/0x45 (12)
Nov 18 12:22:21 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 18 12:22:21 lambda kernel:  [<c0143247>] sys_munmap+0x38/0x45 (24)
Nov 18 12:22:21 lambda kernel:  [sysenter_past_esp+82/113]
sysenter_past_esp+0x52/0x71 (12)
Nov 18 12:22:21 lambda kernel:  [<c01023f1>] sysenter_past_esp+0x52/0x71 (12)
Nov 18 12:22:21 lambda kernel: Kernel logging (proc) stopped.
Nov 18 12:22:21 lambda kernel: Kernel log daemon terminating.
Nov 18 12:22:22 lambda exiting on signal 15


Another one, a couple of times later:

Nov 18 13:21:59 lambda alsa: Shutting down ALSA sound driver (version 1.0.7):
Nov 18 13:22:01 lambda kernel: usbcore: deregistering driver snd-usb-usx2y
Nov 18 13:22:01 lambda alsa: /etc/rc0.d/K70alsa: line 287:  5700
Segmentation fault      /sbin/rmmod `echo $line | cut -d ' ' -f 1`
>/dev/null 2>&1
Nov 18 13:22:03 lambda kernel: BUG: Unable to handle kernel paging request
at virtual address f39d2483
Nov 18 13:22:03 lambda kernel:  printing eip:
Nov 18 13:22:03 lambda kernel: c0129a4b
Nov 18 13:22:03 lambda kernel: *pde = 00000000
Nov 18 13:22:03 lambda kernel: Oops: 0000 [#1]
Nov 18 13:22:03 lambda kernel: PREEMPT
Nov 18 13:22:03 lambda kernel: Modules linked in: realtime commoncap
snd_usb_usx2y snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd_ali5451
snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore prism2_cs
p80211 pcmcia pcmcia_core natsemi crc32 loop subfs evdev ohci_hcd usbcore
Nov 18 13:22:03 lambda kernel: CPU:    0
Nov 18 13:22:03 lambda kernel: EIP:    0060:[__up_mutex+59/384]    Not
tainted VLI
Nov 18 13:22:03 lambda kernel: EIP:    0060:[<c0129a4b>]    Not tainted VLI
Nov 18 13:22:03 lambda kernel: EFLAGS: 00010093  
(2.6.10-rc2-mm1-RT-V0.7.28-1)
Nov 18 13:22:03 lambda kernel: EIP is at __up_mutex+0x3b/0x180
Nov 18 13:22:03 lambda kernel: eax: f39d2483   ebx: deb66000   ecx:
deaae1b0   edx: a1a407da
Nov 18 13:22:03 lambda kernel: esi: deaae1b0   edi: e010b58c   ebp:
e00609b0   esp: deb67ee4
Nov 18 13:22:03 lambda kernel: ds: 007b   es: 007b   ss: 0068   preempt:
00000004
Nov 18 13:22:03 lambda kernel: Process rmmod (pid: 5700,
threadinfo=deb66000 task=de5c5450)
Nov 18 13:22:03 lambda kernel: Stack: 00000296 c0139cdc 00000286 00000296
c01ad4cb 00000000 deb66000 c0301908
Nov 18 13:22:03 lambda kernel:        e00609a0 e00609b0 c012a165 e010b59c
c01ad4cb e010b5b4 c01ad4cd bfffd3f0
Nov 18 13:22:03 lambda kernel:        deb66000 c01adadf e010b59c 00000000
bfffd3f0 deb66000 e010b59c 00000000
Nov 18 13:22:03 lambda kernel: Call Trace:
Nov 18 13:22:03 lambda kernel:  [kmem_cache_free+74/199]
kmem_cache_free+0x4a/0xc7 (8)
Nov 18 13:22:03 lambda kernel:  [<c0139cdc>] kmem_cache_free+0x4a/0xc7 (8)
Nov 18 13:22:03 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (12)
Nov 18 13:22:03 lambda kernel:  [<c01ad4cb>] kobject_cleanup+0x8e/0x90 (12)
Nov 18 13:22:03 lambda kernel:  [up+53/61] up+0x35/0x3d (24)
Nov 18 13:22:03 lambda kernel:  [<c012a165>] up+0x35/0x3d (24)
Nov 18 13:22:03 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (8)
Nov 18 13:22:03 lambda kernel:  [<c01ad4cb>] kobject_cleanup+0x8e/0x90 (8)
Nov 18 13:22:03 lambda kernel:  [kobject_release+0/8]
kobject_release+0x0/0x8 (8)
Nov 18 13:22:03 lambda kernel:  [<c01ad4cd>] kobject_release+0x0/0x8 (8)
Nov 18 13:22:03 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov 18 13:22:03 lambda kernel:  [<c01adadf>] kref_put+0x51/0xc2 (12)
Nov 18 13:22:03 lambda kernel:  [bus_remove_driver+63/72]
bus_remove_driver+0x3f/0x48 (36)
Nov 18 13:22:03 lambda kernel:  [<c01f3aff>] bus_remove_driver+0x3f/0x48 (36)
Nov 18 13:22:03 lambda kernel:  [driver_unregister+11/26]
driver_unregister+0xb/0x1a (8)
Nov 18 13:22:03 lambda kernel:  [<c01f3e98>] driver_unregister+0xb/0x1a (8)
Nov 18 13:22:03 lambda kernel:  [pg0+533373460/1069945856]
usb_deregister+0x31/0x3f [usbcore] (8)
Nov 18 13:22:03 lambda kernel:  [<e0047214>] usb_deregister+0x31/0x3f
[usbcore] (8)
Nov 18 13:22:03 lambda kernel:  [sys_delete_module+292/304]
sys_delete_module+0x124/0x130 (20)
Nov 18 13:22:03 lambda kernel:  [<c012c044>] sys_delete_module+0x124/0x130
(20)
Nov 18 13:22:03 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176
(32)
Nov 18 13:22:03 lambda kernel:  [<c01431b3>] do_munmap+0x11a/0x176 (32)
Nov 18 13:22:03 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 18 13:22:03 lambda kernel:  [<c0143247>] sys_munmap+0x38/0x45 (12)
Nov 18 13:22:03 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 18 13:22:03 lambda kernel:  [<c0143247>] sys_munmap+0x38/0x45 (24)
Nov 18 13:22:03 lambda kernel:  [sysenter_past_esp+82/113]
sysenter_past_esp+0x52/0x71 (12)
Nov 18 13:22:03 lambda kernel:  [<c01023f1>] sysenter_past_esp+0x52/0x71 (12)
Nov 18 13:22:03 lambda kernel: Code: 10 9c 8f 44 24 08 fa 9c 58 b8 00 e0
ff ff 21 e0 83 40 14 01 83 40 14 01 8b 47 08 e8 50 7f fe ff 8b 77 08 89 c2
8b 86 48 05 00 00 <8b> 08 0f 18 01 90 8d 9e 48 05 00 00 eb 10 8b 40 0c 39
d0 0f 4c
Nov 18 13:22:03 lambda kernel:  <6>note: rmmod[5700] exited with
preempt_count 3
Nov 18 13:22:03 lambda kernel: BUG: scheduling while atomic:
rmmod/0x00000003/5700
Nov 18 13:22:03 lambda kernel: caller is do_exit+0x2a5/0x4ce
Nov 18 13:22:03 lambda kernel:  [__schedule+1155/1484]
__sched_text_start+0x483/0x5cc (8)
Nov 18 13:22:03 lambda kernel:  [<c02a6507>]
__sched_text_start+0x483/0x5cc (8)
Nov 18 13:22:03 lambda kernel:  [exit_notify+1154/2281]
exit_notify+0x482/0x8e9 (24)
Nov 18 13:22:03 lambda kernel:  [<c011743a>] exit_notify+0x482/0x8e9 (24)
Nov 18 13:22:03 lambda kernel:  [do_exit+677/1230] do_exit+0x2a5/0x4ce (56)
Nov 18 13:22:03 lambda kernel:  [<c0117b46>] do_exit+0x2a5/0x4ce (56)
Nov 18 13:22:03 lambda kernel:  [do_divide_error+0/320]
do_divide_error+0x0/0x140 (48)
Nov 18 13:22:03 lambda kernel:  [<c01035a9>] do_divide_error+0x0/0x140 (48)
Nov 18 13:22:03 lambda kernel:  [do_page_fault+865/1341]
do_page_fault+0x361/0x53d (64)
Nov 18 13:22:03 lambda kernel:  [<c010fc18>] do_page_fault+0x361/0x53d (64)
Nov 18 13:22:03 lambda kernel:  [call_usermodehelper+346/364]
call_usermodehelper+0x15a/0x16c (72)
Nov 18 13:22:03 lambda kernel:  [<c012493e>]
call_usermodehelper+0x15a/0x16c (72)
Nov 18 13:22:03 lambda kernel:  [__schedule+662/1484]
__sched_text_start+0x296/0x5cc (40)
Nov 18 13:22:03 lambda kernel:  [<c02a631a>]
__sched_text_start+0x296/0x5cc (40)
Nov 18 13:22:03 lambda kernel:  [__call_usermodehelper+0/72]
__call_usermodehelper+0x0/0x48 (16)
Nov 18 13:22:03 lambda kernel:  [<c012479c>]
__call_usermodehelper+0x0/0x48 (16)
Nov 18 13:22:03 lambda kernel:  [__down_mutex+73/322]
__down_mutex+0x49/0x142 (16)
Nov 18 13:22:03 lambda kernel:  [<c02a7600>] __down_mutex+0x49/0x142 (16)
Nov 18 13:22:03 lambda kernel:  [dput+121/657] dput+0x79/0x291 (4)
Nov 18 13:22:03 lambda kernel:  [<c0165899>] dput+0x79/0x291 (4)
Nov 18 13:22:03 lambda kernel:  [kfree+81/237] kfree+0x51/0xed (28)
Nov 18 13:22:03 lambda kernel:  [<c0139e0e>] kfree+0x51/0xed (28)
Nov 18 13:22:03 lambda kernel:  [do_page_fault+0/1341]
do_page_fault+0x0/0x53d (28)
Nov 18 13:22:03 lambda kernel:  [<c010f8b7>] do_page_fault+0x0/0x53d (28)
Nov 18 13:22:03 lambda kernel:  [error_code+43/48] error_code+0x2b/0x30 (8)
Nov 18 13:22:03 lambda kernel:  [<c0102e57>] error_code+0x2b/0x30 (8)
Nov 18 13:22:03 lambda kernel:  [locate_fd+56/137] locate_fd+0x38/0x89 (32)
Nov 18 13:22:03 lambda kernel:  [<c016007b>] locate_fd+0x38/0x89 (32)
Nov 18 13:22:03 lambda kernel:  [__up_mutex+59/384] __up_mutex+0x3b/0x180
(12)
Nov 18 13:22:03 lambda kernel:  [<c0129a4b>] __up_mutex+0x3b/0x180 (12)
Nov 18 13:22:03 lambda kernel:  [kmem_cache_free+74/199]
kmem_cache_free+0x4a/0xc7 (16)
Nov 18 13:22:03 lambda kernel:  [<c0139cdc>] kmem_cache_free+0x4a/0xc7 (16)
Nov 18 13:22:03 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (12)
Nov 18 13:22:03 lambda kernel:  [<c01ad4cb>] kobject_cleanup+0x8e/0x90 (12)
Nov 18 13:22:03 lambda kernel:  [up+53/61] up+0x35/0x3d (24)
Nov 18 13:22:03 lambda kernel:  [<c012a165>] up+0x35/0x3d (24)
Nov 18 13:22:03 lambda kernel:  [kobject_cleanup+142/144]
kobject_cleanup+0x8e/0x90 (8)
Nov 18 13:22:03 lambda kernel:  [<c01ad4cb>] kobject_cleanup+0x8e/0x90 (8)
Nov 18 13:22:03 lambda kernel:  [kobject_release+0/8]
kobject_release+0x0/0x8 (8)
Nov 18 13:22:03 lambda kernel:  [<c01ad4cd>] kobject_release+0x0/0x8 (8)
Nov 18 13:22:03 lambda kernel:  [kref_put+81/194] kref_put+0x51/0xc2 (12)
Nov 18 13:22:03 lambda kernel:  [<c01adadf>] kref_put+0x51/0xc2 (12)
Nov 18 13:22:03 lambda kernel:  [bus_remove_driver+63/72]
bus_remove_driver+0x3f/0x48 (36)
Nov 18 13:22:03 lambda kernel:  [<c01f3aff>] bus_remove_driver+0x3f/0x48 (36)
Nov 18 13:22:03 lambda kernel:  [driver_unregister+11/26]
driver_unregister+0xb/0x1a (8)
Nov 18 13:22:03 lambda kernel:  [<c01f3e98>] driver_unregister+0xb/0x1a (8)
Nov 18 13:22:03 lambda kernel:  [pg0+533373460/1069945856]
usb_deregister+0x31/0x3f [usbcore] (8)
Nov 18 13:22:03 lambda kernel:  [<e0047214>] usb_deregister+0x31/0x3f
[usbcore] (8)
Nov 18 13:22:03 lambda kernel:  [sys_delete_module+292/304]
sys_delete_module+0x124/0x130 (20)
Nov 18 13:22:03 lambda kernel:  [<c012c044>] sys_delete_module+0x124/0x130
(20)
Nov 18 13:22:03 lambda kernel:  [do_munmap+282/374] do_munmap+0x11a/0x176
(32)
Nov 18 13:22:03 lambda kernel:  [<c01431b3>] do_munmap+0x11a/0x176 (32)
Nov 18 13:22:03 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (12)
Nov 18 13:22:03 lambda kernel:  [<c0143247>] sys_munmap+0x38/0x45 (12)
Nov 18 13:22:03 lambda kernel:  [sys_munmap+56/69] sys_munmap+0x38/0x45 (24)
Nov 18 13:22:03 lambda kernel:  [<c0143247>] sys_munmap+0x38/0x45 (24)
Nov 18 13:22:03 lambda kernel:  [sysenter_past_esp+82/113]
sysenter_past_esp+0x52/0x71 (12)
Nov 18 13:22:03 lambda kernel:  [<c01023f1>] sysenter_past_esp+0x52/0x71 (12)
Nov 18 13:22:03 lambda kernel: Kernel logging (proc) stopped.
Nov 18 13:22:03 lambda kernel: Kernel log daemon terminating.
Nov 18 13:22:04 lambda exiting on signal 15


Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-18 15:54                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 Ingo Molnar
@ 2004-11-18 15:07                                                                   ` Christian Meder
  2004-11-18 20:42                                                                     ` Ingo Molnar
  2004-11-18 22:33                                                                   ` Christian Meder
  1 sibling, 1 reply; 951+ messages in thread
From: Christian Meder @ 2004-11-18 15:07 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Thu, 2004-11-18 at 16:54 +0100, Ingo Molnar wrote:
> * Christian Meder <chris@onestepahead.de> wrote:
> 
> > after successfully running the last couple of rt patches on my Dell
> > Inspiron laptop I thought I'd give it a try on my combined vdr/router
> > box which is probably more interesting from a rt point of view. This
> > box is bridging wireless/ADSL and working as a digital vdr using the
> > kernel DVB-S drivers.
> > 
> > I got the appended logging messages with the appended config.  Is
> > there anything else I should provide for debugging purposes or are the
> > messages just harmless ?
> 
> the messages mean that i havent converted the bridge code's RCU locking
> to PREEMPT_RT yet. I've done this in the -V0.7.28-2 patch that i've just
> uploaded to:
> 
>         http://redhat.com/~mingo/realtime-preempt/
> 
> does bridging work fine with this patch, and if yes, do you get any
> (other) warning messages?

Thanks, will try soon and report. There was another trace in my log of
the vdr/router box which seemed unrelated to the bridging traces.


				Christian


Nov 17 22:44:41 verena kernel: dvb-ttpci: found av7110-0.
Nov 17 22:44:43 verena kernel: ves1x93: Detected ves1893a rev2
Nov 17 22:44:43 verena kernel: DVB: registering frontend 0 (VES1893)...
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel:
==========================================
Nov 17 22:44:44 verena kernel: [ BUG: lock recursion deadlock detected!
|
Nov 17 22:44:44 verena kernel:
------------------------------------------
Nov 17 22:44:44 verena kernel: already locked:  [c9c8fa10] {&fe->sem}
Nov 17 22:44:44 verena kernel: .. held by:               vdr: 2147
[ca3a6950, 118]
Nov 17 22:44:44 verena kernel: ... acquired at:  dvb_frontend_start
+0x75/0x100
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: ------------------------------
Nov 17 22:44:44 verena kernel: | showing all locks held by: |  (vdr/2147
[ca3a6950, 118]):
Nov 17 22:44:44 verena kernel: ------------------------------
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #001:             [c9c8fa10] {&fe->sem}
Nov 17 22:44:44 verena kernel: ... acquired at:  dvb_frontend_start
+0x75/0x100
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #002:             [c045e444]
{kernel_sem.lock}
Nov 17 22:44:44 verena kernel: ... acquired at:  lock_kernel+0x27/0x50
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: -{current task's
backtrace}----------------->
Nov 17 22:44:44 verena kernel:  [check_deadlock+608/640] check_deadlock
+0x260/0x280 (8)
Nov 17 22:44:44 verena kernel:  [dvb_frontend_ioctl+171/832]
dvb_frontend_ioctl+0xab/0x340 (28)
Nov 17 22:44:44 verena kernel:  [dvb_frontend_ioctl+171/832]
dvb_frontend_ioctl+0xab/0x340 (8)
Nov 17 22:44:44 verena kernel:  [task_blocks_on_lock+243/256]
task_blocks_on_lock+0xf3/0x100 (12)
Nov 17 22:44:44 verena kernel:  [dvb_frontend_ioctl+171/832]
dvb_frontend_ioctl+0xab/0x340 (16)
Nov 17 22:44:44 verena kernel:  [__down_interruptible+534/1072]
__down_interruptible+0x216/0x430 (4)
Nov 17 22:44:44 verena kernel:  [dvb_frontend_ioctl+171/832]
dvb_frontend_ioctl+0xab/0x340 (4)
Nov 17 22:44:44 verena kernel:  [pg0+264556013/1068020736]
av7110_send_fw_cmd+0x4d/0xc0 [dvb_ttpci] (12)
Nov 17 22:44:44 verena kernel:  [up+190/256] up+0xbe/0x100 (24)
Nov 17 22:44:44 verena kernel:  [down_interruptible+173/480]
down_interruptible+0xad/0x1e0 (36)
Nov 17 22:44:44 verena kernel:  [lru_cache_add_active+13/64]
lru_cache_add_active+0xd/0x40 (4)
Nov 17 22:44:44 verena kernel:  [dvb_frontend_ioctl+171/832]
dvb_frontend_ioctl+0xab/0x340 (40)
Nov 17 22:44:44 verena kernel:  [__kmalloc+133/272] __kmalloc+0x85/0x110
(52)
Nov 17 22:44:44 verena kernel:  [dvb_usercopy+132/272] dvb_usercopy
+0x84/0x110 (32)
Nov 17 22:44:44 verena kernel:  [__down+470/800] __down+0x1d6/0x320 (44)
Nov 17 22:44:44 verena kernel:  [lock_kernel+39/80] lock_kernel
+0x27/0x50 (4)
Nov 17 22:44:44 verena kernel:  [__down_mutex+470/864] __down_mutex
+0x1d6/0x360 (12)
Nov 17 22:44:44 verena kernel:  [fget+47/96] fget+0x2f/0x60 (4)
Nov 17 22:44:44 verena kernel:  [__down_mutex+470/864] __down_mutex
+0x1d6/0x360 (4)
Nov 17 22:44:44 verena kernel:  [kmem_cache_free+53/208] kmem_cache_free
+0x35/0xd0 (4)
Nov 17 22:44:44 verena kernel:  [down+173/480] down+0xad/0x1e0 (48)
Nov 17 22:44:44 verena kernel:  [fget+72/96] fget+0x48/0x60 (16)
Nov 17 22:44:44 verena kernel:  [dvb_generic_ioctl+62/80]
dvb_generic_ioctl+0x3e/0x50 (24)
Nov 17 22:44:44 verena kernel:  [dvb_frontend_ioctl+0/832]
dvb_frontend_ioctl+0x0/0x340 (8)
Nov 17 22:44:44 verena kernel:  [sys_ioctl+184/528] sys_ioctl+0xb8/0x210
(12)
Nov 17 22:44:44 verena kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
(36)
Nov 17 22:44:44 verena kernel: ---------------------------
Nov 17 22:44:44 verena kernel: | preempt count: 00000002 ]
Nov 17 22:44:44 verena kernel: | 2-level deep critical section nesting:
Nov 17 22:44:44 verena kernel: ----------------------------------------
Nov 17 22:44:44 verena kernel: .. [__down_interruptible+1057/1072] ....
__down_interruptible+0x421/0x430
Nov 17 22:44:44 verena kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 17 22:44:44 verena kernel: .. [print_traces+13/64] .... print_traces
+0xd/0x40
Nov 17 22:44:44 verena kernel: .....[<00000000>] ..   ( <= 0x0)
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: showing all tasks:
Nov 17 22:44:44 verena kernel: s            init:    1 [c1239370, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s           IRQ 0:    2 [c1238d00,  50]
(not blocked)
Nov 17 22:44:44 verena kernel: s     ksoftirqd/0:    3 [c1238690, 105]
(not blocked)
Nov 17 22:44:44 verena kernel: s       desched/0:    4 [c1238020, 105]
(not blocked)
Nov 17 22:44:44 verena kernel: s        events/0:    5 [cf7db390,  98]
(not blocked)
Nov 17 22:44:44 verena kernel: s         khelper:    6 [cf7dad20, 113]
(not blocked)
Nov 17 22:44:44 verena kernel: s         kthread:   11 [cf7da6b0, 110]
(not blocked)
Nov 17 22:44:44 verena kernel: s          kacpid:   19 [cf7da040, 120]
(not blocked)
Nov 17 22:44:44 verena kernel: s          IRQ 11:   20 [cf64d3b0,  58]
(not blocked)
Nov 17 22:44:44 verena kernel: s       kblockd/0:   91 [cf64cd40, 110]
(not blocked)
Nov 17 22:44:44 verena kernel: s           khubd:  104 [cf64c6d0, 115]
(not blocked)
Nov 17 22:44:44 verena kernel: s         pdflush:  183 [cf64c060, 117]
(not blocked)
Nov 17 22:44:44 verena kernel: s         pdflush:  184 [cf6c53d0, 115]
(not blocked)
Nov 17 22:44:44 verena kernel: s           aio/0:  186 [cf6c46f0, 112]
(not blocked)
Nov 17 22:44:44 verena kernel: s         kswapd0:  185 [cf6c4d60, 125]
(not blocked)
Nov 17 22:44:44 verena kernel: s           IRQ 8:  775 [cf6c4080,  56]
(not blocked)
Nov 17 22:44:44 verena kernel: s          IRQ 12:  785 [c139ed80,  54]
(not blocked)
Nov 17 22:44:44 verena kernel: s           IRQ 7:  804 [c139e710, 112]
(not blocked)
Nov 17 22:44:44 verena kernel: s         kseriod:  779 [c139f3f0, 125]
(not blocked)
Nov 17 22:44:44 verena kernel: s           IRQ 6:  807 [c139e0a0,  51]
(not blocked)
Nov 17 22:44:44 verena kernel: s          IRQ 14:  821 [c13e9450,  52]
(not blocked)
Nov 17 22:44:44 verena kernel: s          IRQ 15:  824 [c13dc0e0,  53]
(not blocked)
Nov 17 22:44:44 verena kernel: s       scsi_eh_0:  837 [c13dcdc0, 117]
blocked on: [c13e1fac] {sem.lock}
Nov 17 22:44:44 verena kernel: .. held by:         scsi_eh_0:  837
[c13dcdc0, 117]
Nov 17 22:44:44 verena kernel: ... acquired at:  scsi_error_handler
+0x50/0x100
Nov 17 22:44:44 verena kernel: s           IRQ 1:  864 [c13cd410,  55]
(not blocked)
Nov 17 22:44:44 verena kernel: s       kjournald:  903 [c13e8770, 115]
(not blocked)
Nov 17 22:44:44 verena kernel: s           IRQ 5: 1074 [c13dc750,  57]
(not blocked)
Nov 17 22:44:44 verena kernel: s          IRQ 10: 1116 [c13e8100,  59]
(not blocked)
Nov 17 22:44:44 verena kernel: s       kjournald: 1153 [cf439470, 120]
(not blocked)
Nov 17 22:44:44 verena kernel: s         portmap: 1320 [ce6ace20, 115]
(not blocked)
Nov 17 22:44:44 verena kernel: s           IRQ 4: 1328 [c13cc0c0, 112]
(not blocked)
Nov 17 22:44:44 verena kernel: s           IRQ 3: 1331 [cf438e00, 112]
(not blocked)
Nov 17 22:44:44 verena kernel: s         syslogd: 1433 [c13ccda0, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s           klogd: 1436 [ce6ac7b0, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s            pppd: 1448 [cdbb2e40, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s           pppoe: 1451 [c13dd430, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s           gnugk: 1484 [c13e8de0, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s           gnugk: 1508 [cd366e60, 120]
(not blocked)
Nov 17 22:44:44 verena kernel: s           gnugk: 1509 [cd3667f0, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s           gnugk: 1510 [cd366180, 120]
(not blocked)
Nov 17 22:44:44 verena kernel: s           gnugk: 1511 [cc5014f0, 120]
(not blocked)
Nov 17 22:44:44 verena kernel: s           inetd: 1489 [cdbb34b0, 122]
(not blocked)
Nov 17 22:44:44 verena kernel: s         jabberd: 1492 [ce6ad490, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s           ip-up: 1502 [cd3674d0, 118]
(not blocked)
Nov 17 22:44:44 verena kernel: s       run-parts: 1504 [cdbb27d0, 118]
(not blocked)
Nov 17 22:44:44 verena kernel: s            exim: 1506 [cdbb2160, 119]
(not blocked)
Nov 17 22:44:44 verena kernel: s            exim: 1507 [cf438120, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s         jabberd: 1516 [cc5001a0, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s         jabberd: 1519 [c13cc730, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s            nfsd: 1907 [cc500e80, 119]
(not blocked)
Nov 17 22:44:44 verena kernel: s            nfsd: 1908 [cc58eea0, 119]
(not blocked)
Nov 17 22:44:44 verena kernel: s            nfsd: 1909 [cc58e830, 119]
(not blocked)
Nov 17 22:44:44 verena kernel: s            nfsd: 1910 [cf438790, 119]
(not blocked)
Nov 17 22:44:44 verena kernel: s            nfsd: 1911 [cc58e1c0, 119]
(not blocked)
Nov 17 22:44:44 verena kernel: s            nfsd: 1912 [cc7a7530, 120]
(not blocked)
Nov 17 22:44:44 verena kernel: s            nfsd: 1913 [cc7a6ec0, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s            nfsd: 1914 [cc7a6850, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s           lockd: 1916 [cc7a61e0, 121]
(not blocked)
Nov 17 22:44:44 verena kernel: s        rpciod/0: 1917 [cc783550, 111]
(not blocked)
Nov 17 22:44:44 verena kernel: s      rpc.mountd: 1920 [cc782ee0, 119]
(not blocked)
Nov 17 22:44:44 verena kernel: s      postmaster: 1962 [cc58f510, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s      postmaster: 1966 [cc7fc890, 121]
(not blocked)
Nov 17 22:44:44 verena kernel: s      postmaster: 1967 [cc7fcf00, 122]
(not blocked)
Nov 17 22:44:44 verena kernel: s            slpd: 1981 [cc7fd570, 120]
(not blocked)
Nov 17 22:44:44 verena kernel: s            sshd: 1987 [cc500810, 120]
(not blocked)
Nov 17 22:44:44 verena kernel: s   vdrconvert.sh: 1996 [cbcd8f20, 135]
(not blocked)
Nov 17 22:44:44 verena kernel: s       rpc.statd: 2004 [cc782870, 117]
(not blocked)
Nov 17 22:44:44 verena kernel: s            Xvfb: 2005 [cbcd9590, 131]
(not blocked)
Nov 17 22:44:44 verena kernel: s             atd: 2018 [cbcd8240, 118]
(not blocked)
Nov 17 22:44:44 verena kernel: s            cron: 2021 [cc782200, 118]
(not blocked)
Nov 17 22:44:44 verena kernel: s           fcron: 2024 [cbee6f40, 118]
(not blocked)
Nov 17 22:44:44 verena kernel: s          apache: 2031 [cbee68d0, 116]
(not blocked)
Nov 17 22:44:44 verena kernel: s             vdr: 2039 [cb1f4f60, 118]
(not blocked)
Nov 17 22:44:44 verena kernel: s           getty: 2040 [cb1f48f0, 117]
(not blocked)
Nov 17 22:44:44 verena kernel: s           getty: 2043 [ce6ac140, 117]
(not blocked)
Nov 17 22:44:44 verena kernel: s           getty: 2044 [cbee75b0, 117]
(not blocked)
Nov 17 22:44:44 verena kernel: s           getty: 2045 [cbcd88b0, 117]
(not blocked)
Nov 17 22:44:44 verena kernel: s           getty: 2046 [cb1f55d0, 117]
(not blocked)
Nov 17 22:44:44 verena kernel: s           lircd: 2059 [cbee6260, 118]
(not blocked)
Nov 17 22:44:44 verena kernel: s     wait2enc.py: 2060 [cb2815f0, 135]
(not blocked)
Nov 17 22:44:44 verena kernel: s          apache: 2063 [cb280f80, 119]
(not blocked)
Nov 17 22:44:44 verena kernel: s          apache: 2064 [cb280910, 120]
(not blocked)
Nov 17 22:44:44 verena kernel: s          apache: 2065 [cb2802a0, 121]
(not blocked)
Nov 17 22:44:44 verena kernel: s          apache: 2066 [caead610, 122]
(not blocked)
Nov 17 22:44:44 verena kernel: s          apache: 2067 [caeacfa0, 123]
(not blocked)
Nov 17 22:44:44 verena kernel: s    vdradmind.pl: 2078 [caeac2c0, 118]
(not blocked)
Nov 17 22:44:44 verena kernel: s          runvdr: 2079 [cb1f4280, 118]
(not blocked)
Nov 17 22:44:44 verena kernel: s         arm_mon: 2119 [ca3a7630, 119]
(not blocked)
Nov 17 22:44:44 verena kernel: s           sleep: 2139 [c9de0fe0, 136]
(not blocked)
Nov 17 22:44:44 verena kernel: s             vdr: 2147 [ca3a6950, 118]
(not blocked)
Nov 17 22:44:44 verena kernel: R             vdr: 2148 [caeac930, 119]
(not blocked)
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: ---------------------------
Nov 17 22:44:44 verena kernel: | showing all locks held: |
Nov 17 22:44:44 verena kernel: ---------------------------
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #001:             [c053ee6c]
{&hwif->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x8e/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #002:             [c053ea90]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #003:             [c053ec64]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #004:             [c053f4b4]
{&hwif->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x8e/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #005:             [c053f0d8]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #006:             [c053f2ac]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #007:             [c053fafc]
{&hwif->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x8e/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #008:             [c053f720]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #009:             [c053f8f4]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #010:             [c0540144]
{&hwif->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x8e/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #011:             [c053fd68]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #012:             [c053ff3c]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #013:             [c054078c]
{&hwif->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x8e/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #014:             [c05403b0]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #015:             [c0540584]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #016:             [c0540dd4]
{&hwif->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x8e/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #017:             [c05409f8]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #018:             [c0540bcc]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #019:             [c054141c]
{&hwif->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x8e/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #020:             [c0541040]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #021:             [c0541214]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #022:             [c0541a64]
{&hwif->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x8e/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #023:             [c0541688]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #024:             [c054185c]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #025:             [c05420ac]
{&hwif->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x8e/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #026:             [c0541cd0]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #027:             [c0541ea4]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #028:             [c05426f4]
{&hwif->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x8e/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #029:             [c0542318]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #030:             [c05424ec]
{&drive->gendev_rel_sem}
Nov 17 22:44:44 verena kernel: .. held by:           swapper:    0
[c044cd80, 140]
Nov 17 22:44:44 verena kernel: ... acquired at:  init_hwif_data
+0x160/0x180
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #031:             [ccd3dcf0]
{&tty->atomic_read}
Nov 17 22:44:44 verena kernel: .. held by:             getty: 2040
[cb1f48f0, 117]
Nov 17 22:44:44 verena kernel: ... acquired at:  read_chan+0x6f1/0x750
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #032:             [cd66acf0]
{&tty->atomic_read}
Nov 17 22:44:44 verena kernel: .. held by:             getty: 2044
[cbee75b0, 117]
Nov 17 22:44:44 verena kernel: ... acquired at:  read_chan+0x6f1/0x750
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #033:             [cda85cf0]
{&tty->atomic_read}
Nov 17 22:44:44 verena kernel: .. held by:             getty: 2045
[cbcd88b0, 117]
Nov 17 22:44:44 verena kernel: ... acquired at:  read_chan+0x6f1/0x750
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #034:             [cdfe6cf0]
{&tty->atomic_read}
Nov 17 22:44:44 verena kernel: .. held by:             getty: 2046
[cb1f55d0, 117]
Nov 17 22:44:44 verena kernel: ... acquired at:  read_chan+0x6f1/0x750
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #035:             [cb22ccf0]
{&tty->atomic_read}
Nov 17 22:44:44 verena kernel: .. held by:             getty: 2043
[ce6ac140, 117]
Nov 17 22:44:44 verena kernel: ... acquired at:  read_chan+0x6f1/0x750
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #036:             [c9c8fa10] {&fe->sem}
Nov 17 22:44:44 verena kernel: .. held by:               vdr: 2147
[ca3a6950, 118]
Nov 17 22:44:44 verena kernel: ... acquired at:  dvb_frontend_start
+0x75/0x100
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: #037:             [c045e444]
{kernel_sem.lock}
Nov 17 22:44:44 verena kernel: .. held by:               vdr: 2147
[ca3a6950, 118]
Nov 17 22:44:44 verena kernel: ... acquired at:  lock_kernel+0x27/0x50
Nov 17 22:44:44 verena kernel:
=============================================
Nov 17 22:44:44 verena kernel: 
Nov 17 22:44:44 verena kernel: [ turning off deadlock detection. Please
report this trace. ]


-- 
Christian Meder, email: chris@onestepahead.de

The Way-Seeking Mind of a tenzo is actualized 
by rolling up your sleeves.

                (Eihei Dogen Zenji)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 12:35                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1 Ingo Molnar
  2004-11-18 12:23                                                                 ` Florian Schmidt
  2004-11-18 14:46                                                                 ` Rui Nuno Capela
@ 2004-11-18 15:23                                                                 ` Christian Meder
  2004-11-18 15:37                                                                   ` Jan Engelhardt
  2004-11-18 20:06                                                                   ` [patch] " Ingo Molnar
  2004-11-18 16:46                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 Ingo Molnar
  3 siblings, 2 replies; 951+ messages in thread
From: Christian Meder @ 2004-11-18 15:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Thu, 2004-11-18 at 13:35 +0100, Ingo Molnar wrote:
> i have released the -V0.7.28-1 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
> 	http://redhat.com/~mingo/realtime-preempt/
> 
> this should fix the lockup bug reported by Florian Schmidt.
> 
> there's a generic PREEMPT bug in the upstream kernel: there exists a
> single-instruction race window in __flush_tlb(), if the kernel preempted
> exactly there in a lazy-TLB thread and certain other, rare scheduling
> and MM properties were true as well (a certain constellation of threads
> and lazy-TLB kernel threads occured), and the lazy-TLB task then got
> another user TLB to inherit, and switched to a task from which it
> inherited that new TLB, thus the wrong cr3 was loaded and inherited by
> this next, non-lazy-TLB next task; then (and only then) this scenario
> would typically manifest itself in the form of an infinite pagefault
> lockup occuring much after the fact, upon the next userspace access (to
> the joy of a totally baffled kernel developer). I suspect from the
> description you can guess how much fun it was to debug it =B-)
> 
> the bug is even more rare in the generic kernel, because there most (but
> not all) TLB flush points are in a critical section.
> 
> this fix could resolve some of the other 'my box just locked up'
> reports.

Hi,

I've got one of those 'my box just locked up'. I can reproduce it with
0.7.25-1, 0.7.28-0 and 0.7.28-1 by starting the Jetty servlet container
with our inhouse java project under a Blackdown 1.4 jdk. Within a minute
the laptop just locks up: no mouse, no ping, console switching sysrq-t
or anything. The peculiar thing is that I was running 0.7.25-1 for two
or three days before and it was rocksolid. It was just when I started to
work with the jvm that things fell apart.

Any chance to get any interesting and helpful data in this setup ?



			Christian


-- 
Christian Meder, email: chris@onestepahead.de

The Way-Seeking Mind of a tenzo is actualized 
by rolling up your sleeves.

                (Eihei Dogen Zenji)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 15:23                                                                 ` Christian Meder
@ 2004-11-18 15:37                                                                   ` Jan Engelhardt
  2004-11-18 20:06                                                                   ` [patch] " Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Jan Engelhardt @ 2004-11-18 15:37 UTC (permalink / raw)
  To: Christian Meder; +Cc: linux-kernel

>I've got one of those 'my box just locked up'. I can reproduce it with
>0.7.25-1, 0.7.28-0 and 0.7.28-1 by starting the Jetty servlet container
>with our inhouse java project under a Blackdown 1.4 jdk. Within a minute
>the laptop just locks up: no mouse, no ping, console switching sysrq-t

Sysrq+T itself might work, it's just a matter to get to the console! If you can
get to a con, I'm sure it does, because hitting the keys generates an interrupt
which will be delivered to the sysrq code if interrupts are not currently
disabled. So even if your box appears totally dead, you'd be surprised when you
hit Sysrq+B.

To get any data, I'd start a vnc server on it, and all graphical apps in it,
and let the machine itself stay on tty10 (or wherever kernel output goes), and
then try hitting Sysrq+T when it hangs.



Jan Engelhardt
-- 
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-10
  2004-11-17 18:18                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-10 Adam Heath
@ 2004-11-18 15:44                                                                 ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18 15:44 UTC (permalink / raw)
  To: Adam Heath
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Adam Heath <adam@doogie.org> wrote:

> Running .26-5.  Been running almost 2 days.  All small latency values. 
> Then, just a few minutes ago, got a 133us value:

this entry has most of the overhead:

>     0 80000000 00000004 [0284618592175975] 0.000ms (+0.000ms): preempt_schedule+0x11/0x80 <c02bbb81> (__do_IRQ+0x13d/0x170 <c013f3cd>)
>     0 80000000 00000005 [0284618592176118] 0.000ms (+0.127ms): irq_exit+0xb/0x50 <c013f10b> (do_IRQ+0x53/0x70 <c01080d3>)
>     0 80000000 00000006 [0284618592387634] 0.127ms (+0.000ms): do_IRQ+0x0/0x70 <c0108080> (<0000a253>)
>     0 80000000 00000007 [0284618592387690] 0.127ms (+0.000ms): do_IRQ+0x0/0x70 <c0108080> (<0000000e>)

this shows that we interrupted some longer critical section - in this
case it seems to be BIOS/APM code.

> Note the jump in irq_exit/do_IRQ.

that jump is a delayed interrupt hitting the BIOS on its way out of APM
idle mode it seems:

>     0 80000000 0000001b [0284618592393899] 0.131ms (+0.000ms): apm_do_busy+0xb/0x40 <c01111eb> (cpu_idle+0x4c/0x70 <c0103f9c>)
>     0 80000000 0000001c [0284618592393987] 0.131ms (+0.000ms): apm_bios_call_simple+0xe/0xf0 <c0110f2e> (apm_do_busy+0x2e/0x40 <c011120e>)

There's nothing to be done about that, except to disable APM. Perhaps
you could try ACPI, maybe that doesnt have such latencies in the BIOS.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
       [not found]                                                               ` <1100732223.3472.10.camel@localhost>
@ 2004-11-18 15:54                                                                 ` Ingo Molnar
  2004-11-18 15:07                                                                   ` Christian Meder
  2004-11-18 22:33                                                                   ` Christian Meder
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18 15:54 UTC (permalink / raw)
  To: Christian Meder
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Christian Meder <chris@onestepahead.de> wrote:

> after successfully running the last couple of rt patches on my Dell
> Inspiron laptop I thought I'd give it a try on my combined vdr/router
> box which is probably more interesting from a rt point of view. This
> box is bridging wireless/ADSL and working as a digital vdr using the
> kernel DVB-S drivers.
> 
> I got the appended logging messages with the appended config.  Is
> there anything else I should provide for debugging purposes or are the
> messages just harmless ?

the messages mean that i havent converted the bridge code's RCU locking
to PREEMPT_RT yet. I've done this in the -V0.7.28-2 patch that i've just
uploaded to:

        http://redhat.com/~mingo/realtime-preempt/

does bridging work fine with this patch, and if yes, do you get any
(other) warning messages?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-18 16:11                                                                 ` Ingo Molnar
@ 2004-11-18 15:58                                                                   ` Christian Meder
  2004-11-18 16:39                                                                   ` Christian Meder
  1 sibling, 0 replies; 951+ messages in thread
From: Christian Meder @ 2004-11-18 15:58 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Thu, 2004-11-18 at 17:11 +0100, Ingo Molnar wrote:
> * Christian Meder <chris@onestepahead.de> wrote:
> 
> > On Wed, 2004-11-17 at 13:42 +0100, Ingo Molnar wrote:
> > > i have released the -V0.7.28-0 Real-Time Preemption patch, which can be
> > > downloaded from the usual place:
> > > 
> > > 	http://redhat.com/~mingo/realtime-preempt/
> > > 
> > > this is a fixes & latency-reduction release.
> > 
> > Hi,
> > 
> > here's another message log this time on my Dell laptop when removing
> > my prism wlan pccard running the hostap driver.
> 
> could you try this with the vanilla 2.6.10-rc2-mm1 kernel too? The crash
> you got is an escallation of a crash within a critical section, but that
> original crash does not seem to be directly related to PREEMPT_RT.

2.6.10-rc2-mm1 would have been my next try anyway cause otherwise I'd be
rather unable to get any work done for my job due to the jvm lockup
problem I described in my other mail ;-) 

> (also, please enable CONFIG_USE_FRAME_POINTER, to make the backtraces
> easier to parse.)

Sure.



				Christian

-- 
Christian Meder, email: chris@onestepahead.de

The Way-Seeking Mind of a tenzo is actualized 
by rolling up your sleeves.

                (Eihei Dogen Zenji)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-18 10:24                                                               ` Christian Meder
@ 2004-11-18 16:11                                                                 ` Ingo Molnar
  2004-11-18 15:58                                                                   ` Christian Meder
  2004-11-18 16:39                                                                   ` Christian Meder
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18 16:11 UTC (permalink / raw)
  To: Christian Meder
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Christian Meder <chris@onestepahead.de> wrote:

> On Wed, 2004-11-17 at 13:42 +0100, Ingo Molnar wrote:
> > i have released the -V0.7.28-0 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> > 
> > 	http://redhat.com/~mingo/realtime-preempt/
> > 
> > this is a fixes & latency-reduction release.
> 
> Hi,
> 
> here's another message log this time on my Dell laptop when removing
> my prism wlan pccard running the hostap driver.

could you try this with the vanilla 2.6.10-rc2-mm1 kernel too? The crash
you got is an escallation of a crash within a critical section, but that
original crash does not seem to be directly related to PREEMPT_RT.

(also, please enable CONFIG_USE_FRAME_POINTER, to make the backtraces
easier to parse.)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-18 16:11                                                                 ` Ingo Molnar
  2004-11-18 15:58                                                                   ` Christian Meder
@ 2004-11-18 16:39                                                                   ` Christian Meder
  2004-11-18 19:58                                                                     ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Christian Meder @ 2004-11-18 16:39 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Thu, 2004-11-18 at 17:11 +0100, Ingo Molnar wrote:
> * Christian Meder <chris@onestepahead.de> wrote:
> 
> > On Wed, 2004-11-17 at 13:42 +0100, Ingo Molnar wrote:
> > > i have released the -V0.7.28-0 Real-Time Preemption patch, which can be
> > > downloaded from the usual place:
> > > 
> > > 	http://redhat.com/~mingo/realtime-preempt/
> > > 
> > > this is a fixes & latency-reduction release.
> > 
> > Hi,
> > 
> > here's another message log this time on my Dell laptop when removing
> > my prism wlan pccard running the hostap driver.
> 
> could you try this with the vanilla 2.6.10-rc2-mm1 kernel too? The crash
> you got is an escallation of a crash within a critical section, but that
> original crash does not seem to be directly related to PREEMPT_RT.

Ok, tried it now. The output from 2.6.10-rc2-mm1 on removal of the prism
pccard is pretty innocuous and everything works fine:

Nov 18 17:29:27 localhost kernel: hostap_cs: CS_EVENT_CARD_REMOVAL
Nov 18 17:29:27 localhost kernel: wifi0: card already removed or not
configured during shutdown
Nov 18 17:29:27 localhost kernel: wifi0: Interrupt, but dev not OK
Nov 18 17:29:27 localhost kernel: hostap_cs: Driver unloaded


				Christian

-- 
Christian Meder, email: chris@onestepahead.de

The Way-Seeking Mind of a tenzo is actualized 
by rolling up your sleeves.

                (Eihei Dogen Zenji)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-18 12:35                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1 Ingo Molnar
                                                                                   ` (2 preceding siblings ...)
  2004-11-18 15:23                                                                 ` Christian Meder
@ 2004-11-18 16:46                                                                 ` Ingo Molnar
  2004-11-18 21:27                                                                   ` Michal Schmidt
                                                                                     ` (4 more replies)
  3 siblings, 5 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18 16:46 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


i have released the -V0.7.29-0 Real-Time Preemption patch, which can be
downloaded from the usual place:

	http://redhat.com/~mingo/realtime-preempt/

this is a pure merge of -V0.7.28-2 to 2.6.10-rc2-mm2. -rc2-mm2 itself is
a fixes-only release.

to create a -V0.7.29-0 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm2/2.6.10-rc2-mm2.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm2-V0.7.29-0

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-18 19:58                                                                     ` Ingo Molnar
@ 2004-11-18 19:51                                                                       ` Adam Heath
  0 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-11-18 19:51 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Christian Meder, linux-kernel

On Thu, 18 Nov 2004, Ingo Molnar wrote:

>
> * Christian Meder <chris@onestepahead.de> wrote:
>
> > > could you try this with the vanilla 2.6.10-rc2-mm1 kernel too? The crash
> > > you got is an escallation of a crash within a critical section, but that
> > > original crash does not seem to be directly related to PREEMPT_RT.
> >
> > Ok, tried it now. The output from 2.6.10-rc2-mm1 on removal of the prism
> > pccard is pretty innocuous and everything works fine:
> >
> > Nov 18 17:29:27 localhost kernel: hostap_cs: CS_EVENT_CARD_REMOVAL
> > Nov 18 17:29:27 localhost kernel: wifi0: card already removed or not
> > configured during shutdown
> > Nov 18 17:29:27 localhost kernel: wifi0: Interrupt, but dev not OK
> > Nov 18 17:29:27 localhost kernel: hostap_cs: Driver unloaded
>
> ok. Could you please retry with the latest kernel and USE_FRAME_POINTERS
> enabled? It wasnt completely clear from your previous log precisely
> which function generated the fault so it would be easier for me to sort
> it out if you could reproduce it once more.

That's CONFIG_FRAME_POINTER, btw.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-18 16:39                                                                   ` Christian Meder
@ 2004-11-18 19:58                                                                     ` Ingo Molnar
  2004-11-18 19:51                                                                       ` Adam Heath
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18 19:58 UTC (permalink / raw)
  To: Christian Meder
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Christian Meder <chris@onestepahead.de> wrote:

> > could you try this with the vanilla 2.6.10-rc2-mm1 kernel too? The crash
> > you got is an escallation of a crash within a critical section, but that
> > original crash does not seem to be directly related to PREEMPT_RT.
> 
> Ok, tried it now. The output from 2.6.10-rc2-mm1 on removal of the prism
> pccard is pretty innocuous and everything works fine:
> 
> Nov 18 17:29:27 localhost kernel: hostap_cs: CS_EVENT_CARD_REMOVAL
> Nov 18 17:29:27 localhost kernel: wifi0: card already removed or not
> configured during shutdown
> Nov 18 17:29:27 localhost kernel: wifi0: Interrupt, but dev not OK
> Nov 18 17:29:27 localhost kernel: hostap_cs: Driver unloaded

ok. Could you please retry with the latest kernel and USE_FRAME_POINTERS
enabled? It wasnt completely clear from your previous log precisely
which function generated the fault so it would be easier for me to sort
it out if you could reproduce it once more.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 14:46                                                                 ` Rui Nuno Capela
@ 2004-11-18 20:01                                                                   ` Ingo Molnar
  2004-11-18 20:49                                                                   ` Ingo Molnar
                                                                                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18 20:01 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> I'm still seeing this sometimes (not everytime) on my P4/UP laptop
> while shutting down ALSA modules. This isn't the same as the lockup
> I've been reporting lately (that happens on my P4/SMT desktop) but may
> be remotely related.

this seems to be quite similar to the module-unload crash Christian
Meder reported, and it seems to be a genuine PREEMPT_RT bug. (or an
upstream bug that the vanilla kernel ignores silently.)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 15:23                                                                 ` Christian Meder
  2004-11-18 15:37                                                                   ` Jan Engelhardt
@ 2004-11-18 20:06                                                                   ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18 20:06 UTC (permalink / raw)
  To: Christian Meder
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Christian Meder <chris@onestepahead.de> wrote:

> I've got one of those 'my box just locked up'. I can reproduce it with
> 0.7.25-1, 0.7.28-0 and 0.7.28-1 by starting the Jetty servlet
> container with our inhouse java project under a Blackdown 1.4 jdk.
> Within a minute the laptop just locks up: no mouse, no ping, console
> switching sysrq-t or anything. The peculiar thing is that I was
> running 0.7.25-1 for two or three days before and it was rocksolid. It
> was just when I started to work with the jvm that things fell apart.
> 
> Any chance to get any interesting and helpful data in this setup ?

best would be to have a reproducer. Can you trigger it over the network,
using a remote session? If yes then you might want to try this: let the
box boot in, switch it to a text console and dont touch the keyboard
after that. Do this over the remote session:

	echo 1 > /proc/sys/kernel/debug_direct_keyboard

this activates a direct interrupt line for the keyboard only. Keep the
box on the text-console, and try to reproduce the hang over the network. 
Once it triggers, try SysRq - does it work? (leds wont work, but normal
keys should work.)

if the keyboard still doesnt work then you could try nmi_watchdog=1 or
nmi_watchdog=2 (the latter on IO-APIC-less systems), and serial logging,
to capture a dump of the hard-lockup.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-18 15:07                                                                   ` Christian Meder
@ 2004-11-18 20:42                                                                     ` Ingo Molnar
  2004-11-18 22:41                                                                       ` Christian Meder
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18 20:42 UTC (permalink / raw)
  To: Christian Meder
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Christian Meder <chris@onestepahead.de> wrote:

> Thanks, will try soon and report. There was another trace in my log of
> the vdr/router box which seemed unrelated to the bridging traces.

does the patch below fix that message?

	Ingo

--- linux/drivers/media/dvb/dvb-core/dvb_frontend.c.orig2	
+++ linux/drivers/media/dvb/dvb-core/dvb_frontend.c	
@@ -658,7 +658,7 @@ static void dvb_frontend_stop (struct dv
 		printk("dvb_frontend_stop: thread PID %d already died\n",
 				fe->thread_pid);
 		/* make sure the mutex was not held by the thread */
-		init_MUTEX (&fe->sem);
+		sema_init_nocheck (&fe->sem, 1);
 		return;
 	}
 
@@ -1127,10 +1127,10 @@ dvb_register_frontend (int (*ioctl) (str
 
 	memset (fe, 0, sizeof (struct dvb_frontend_data));
 
-	init_MUTEX (&fe->sem);
+	sema_init_nocheck (&fe->sem, 1);
 	init_waitqueue_head (&fe->wait_queue);
 	init_waitqueue_head (&fe->events.wait_queue);
-	init_MUTEX (&fe->events.sem);
+	sema_init_nocheck (&fe->events.sem, 1);
 	fe->events.eventw = fe->events.eventr = 0;
 	fe->events.overflow = 0;
 	fe->module = module;

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 14:46                                                                 ` Rui Nuno Capela
  2004-11-18 20:01                                                                   ` Ingo Molnar
@ 2004-11-18 20:49                                                                   ` Ingo Molnar
  2004-11-18 21:05                                                                   ` Ingo Molnar
  2004-11-18 21:50                                                                   ` Lee Revell
  3 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18 20:49 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> I'm still seeing this sometimes (not everytime) on my P4/UP laptop
> while shutting down ALSA modules. This isn't the same as the lockup
> I've been reporting lately (that happens on my P4/SMT desktop) but may
> be remotely related.

could you send me the latest .config of your laptop?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 14:46                                                                 ` Rui Nuno Capela
  2004-11-18 20:01                                                                   ` Ingo Molnar
  2004-11-18 20:49                                                                   ` Ingo Molnar
@ 2004-11-18 21:05                                                                   ` Ingo Molnar
  2004-11-18 22:54                                                                     ` Christian Meder
  2004-11-18 21:50                                                                   ` Lee Revell
  3 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-18 21:05 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Christian Meder


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> I'm still seeing this sometimes (not everytime) on my P4/UP laptop
> while shutting down ALSA modules. This isn't the same as the lockup
> I've been reporting lately (that happens on my P4/SMT desktop) but may
> be remotely related.

could you (and Christian) try the patch below, ontop of a current-ish
tree - does the unload crash still occur? (this is an earlier cleanup
patch from Thomas Gleixner, but it could fix a real PREEMPT_RT bug in
this particular case.)

	Ingo

--- linux/drivers/base/driver.c.orig
+++ linux/drivers/base/driver.c
@@ -79,14 +79,13 @@ void put_driver(struct device_driver * d
  *	since most of the things we have to do deal with the bus
  *	structures.
  *
- *	The one interesting aspect is that we initialize @drv->unload_sem
- *	to a locked state here. It will be unlocked when the driver
- *	reference count reaches 0.
+ *	We init the completion strcut here. When the reference 
+ *	count reaches zero, complete() is called from bus_release().
  */
 int driver_register(struct device_driver * drv)
 {
 	INIT_LIST_HEAD(&drv->devices);
-	init_MUTEX_LOCKED(&drv->unload_sem);
+	init_completion(&drv->unload_done);
 	return bus_add_driver(drv);
 }
 
@@ -97,18 +96,16 @@ int driver_register(struct device_driver
  *
  *	Again, we pass off most of the work to the bus-level call.
  *
- *	Though, once that is done, we attempt to take @drv->unload_sem.
- *	This will block until the driver refcount reaches 0, and it is
- *	released. Only modular drivers will call this function, and we
+ *	Though, once that is done, we wait until the driver refcount 
+ *	reaches 0, and complete() is called in bus_release().
+ *	Only modular drivers will call this function, and we
  *	have to guarantee that it won't complete, letting the driver
  *	unload until all references are gone.
  */
-
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	down(&drv->unload_sem);
-	up(&drv->unload_sem);
+	wait_for_completion(&drv->unload_done);
 }
 
 /**
--- linux/drivers/base/bus.c.orig
+++ linux/drivers/base/bus.c
@@ -65,7 +65,7 @@ static struct sysfs_ops driver_sysfs_ops
 static void driver_release(struct kobject * kobj)
 {
 	struct device_driver * drv = to_driver(kobj);
-	up(&drv->unload_sem);
+	complete(&drv->unload_done);
 }
 
 static struct kobj_type ktype_driver = {
--- linux/include/linux/device.h.orig
+++ linux/include/linux/device.h
@@ -102,7 +102,7 @@ struct device_driver {
 	char			* name;
 	struct bus_type		* bus;
 
-	struct semaphore	unload_sem;
+	struct completion	unload_done;
 	struct kobject		kobj;
 	struct list_head	devices;
 

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-18 16:46                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 Ingo Molnar
@ 2004-11-18 21:27                                                                   ` Michal Schmidt
  2004-11-19 10:05                                                                     ` Ingo Molnar
  2004-11-19 19:05                                                                   ` Peter Zijlstra
                                                                                     ` (3 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: Michal Schmidt @ 2004-11-18 21:27 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

Ingo Molnar wrote:
> i have released the -V0.7.29-0 Real-Time Preemption patch, 

Hi,
is it supposed to work on x86_64? It doesn't compile.
I tried to fix the compilation errors with these 2 one-liners:


diff -Nurp linux-2.6.10-rc2-mm2-RT0.7.29-0/arch/x86_64/kernel/time.c linux-2.6.10-rc2-mm2-RT/arch/x86_64/kernel/time.c
--- linux-2.6.10-rc2-mm2-RT0.7.29-0/arch/x86_64/kernel/time.c 2004-11-18 22:16:10.728832816 +0100
+++ linux-2.6.10-rc2-mm2-RT/arch/x86_64/kernel/time.c 2004-11-18 22:00:57.000000000 +0100
@@ -49,7 +49,7 @@ static void cpufreq_delayed_get(void);

  extern int using_apic_timer;

-DEFINE_RAW_SPINLOCK(rtc_lock);
+DEFINE_SPINLOCK(rtc_lock);
  DEFINE_RAW_SPINLOCK(i8253_lock);

  static int nohpet __initdata = 0;
diff -Nurp linux-2.6.10-rc2-mm2-RT0.7.29-0/include/asm-x86_64/vsyscall.h linux-2.6.10-rc2-mm2-RT/include/asm-x86_64/vsyscall.h
--- linux-2.6.10-rc2-mm2-RT0.7.29-0/include/asm-x86_64/vsyscall.h 2004-11-18 22:16:11.739679144 +0100
+++ linux-2.6.10-rc2-mm2-RT/include/asm-x86_64/vsyscall.h 2004-11-18 21:56:30.000000000 +0100
@@ -52,7 +52,7 @@ extern struct vxtime_data vxtime;
  extern unsigned long wall_jiffies;
  extern struct timezone sys_tz;
  extern int sysctl_vsyscall;
-extern raw_seqlock_t xtime_lock;
+//extern raw_seqlock_t xtime_lock;

  #define ARCH_HAVE_XTIME_LOCK 1


It now compiles. When I try to run it, I get instant reboot
after "BIOS data check successful".

This is not necessarily a new issue. I haven't tried running
realtime-preempt on x86_64 before.

Michal

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 14:46                                                                 ` Rui Nuno Capela
                                                                                     ` (2 preceding siblings ...)
  2004-11-18 21:05                                                                   ` Ingo Molnar
@ 2004-11-18 21:50                                                                   ` Lee Revell
  2004-11-19  9:56                                                                     ` Ingo Molnar
  3 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-11-18 21:50 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, linux-kernel, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah

On Thu, 2004-11-18 at 14:46 +0000, Rui Nuno Capela wrote:
> I'm still seeing this sometimes (not everytime) on my P4/UP laptop while
> shutting down ALSA modules.

Same thing here (BUG on unload ALSA modules) with 0.7.27-10 FWIW.

Lee



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-18 15:54                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 Ingo Molnar
  2004-11-18 15:07                                                                   ` Christian Meder
@ 2004-11-18 22:33                                                                   ` Christian Meder
  1 sibling, 0 replies; 951+ messages in thread
From: Christian Meder @ 2004-11-18 22:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Thu, 2004-11-18 at 16:54 +0100, Ingo Molnar wrote:
> * Christian Meder <chris@onestepahead.de> wrote:
> 
> > after successfully running the last couple of rt patches on my Dell
> > Inspiron laptop I thought I'd give it a try on my combined vdr/router
> > box which is probably more interesting from a rt point of view. This
> > box is bridging wireless/ADSL and working as a digital vdr using the
> > kernel DVB-S drivers.
> > 
> > I got the appended logging messages with the appended config.  Is
> > there anything else I should provide for debugging purposes or are the
> > messages just harmless ?
> 
> the messages mean that i havent converted the bridge code's RCU locking
> to PREEMPT_RT yet. I've done this in the -V0.7.28-2 patch that i've just
> uploaded to:
> 
>         http://redhat.com/~mingo/realtime-preempt/
> 
> does bridging work fine with this patch, and if yes, do you get any
> (other) warning messages?

I'm running 0.7.29 now on the vdr/router box and bridging is working
fine and there are no new warning messages.

Thanks,



				Christian

-- 
Christian Meder, email: chris@onestepahead.de

The Way-Seeking Mind of a tenzo is actualized 
by rolling up your sleeves.

                (Eihei Dogen Zenji)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0
  2004-11-18 20:42                                                                     ` Ingo Molnar
@ 2004-11-18 22:41                                                                       ` Christian Meder
  0 siblings, 0 replies; 951+ messages in thread
From: Christian Meder @ 2004-11-18 22:41 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Thu, 2004-11-18 at 21:42 +0100, Ingo Molnar wrote:
> * Christian Meder <chris@onestepahead.de> wrote:
> 
> > Thanks, will try soon and report. There was another trace in my log of
> > the vdr/router box which seemed unrelated to the bridging traces.
> 
> does the patch below fix that message?

Yesss. This patch applied on top of 0.7.29-0 removes all warning
messages (bridging/dvb) in my vdr/router box.

Thanks,


			Christian

-- 
Christian Meder, email: chris@onestepahead.de

The Way-Seeking Mind of a tenzo is actualized 
by rolling up your sleeves.

                (Eihei Dogen Zenji)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 21:05                                                                   ` Ingo Molnar
@ 2004-11-18 22:54                                                                     ` Christian Meder
  2004-11-19  9:54                                                                       ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Christian Meder @ 2004-11-18 22:54 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Thu, 2004-11-18 at 22:05 +0100, Ingo Molnar wrote:
> * Rui Nuno Capela <rncbc@rncbc.org> wrote:
> 
> > I'm still seeing this sometimes (not everytime) on my P4/UP laptop
> > while shutting down ALSA modules. This isn't the same as the lockup
> > I've been reporting lately (that happens on my P4/SMT desktop) but may
> > be remotely related.
> 
> could you (and Christian) try the patch below, ontop of a current-ish
> tree - does the unload crash still occur? (this is an earlier cleanup
> patch from Thomas Gleixner, but it could fix a real PREEMPT_RT bug in
> this particular case.)

This patch on top of 0.7.29-0 fixes the prism pccard unload crash on my
Dell laptop.

This just leaves me with the mysterious traceless jvm related crash.
I'll do my best to get a trace ;-)

Thanks,


				Christian

-- 
Christian Meder, email: chris@onestepahead.de

The Way-Seeking Mind of a tenzo is actualized 
by rolling up your sleeves.

                (Eihei Dogen Zenji)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 22:54                                                                     ` Christian Meder
@ 2004-11-19  9:54                                                                       ` Ingo Molnar
  2004-11-22  9:31                                                                         ` Christian Meder
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-19  9:54 UTC (permalink / raw)
  To: Christian Meder
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Christian Meder <chris@onestepahead.de> wrote:

> This just leaves me with the mysterious traceless jvm related crash.
> I'll do my best to get a trace ;-)

it would be equally useful to somehow reproduce the lockup with public
software only, and post the precise steps how to reproduce it.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-18 21:50                                                                   ` Lee Revell
@ 2004-11-19  9:56                                                                     ` Ingo Molnar
  2004-11-19 15:44                                                                       ` Shane Shrybman
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-19  9:56 UTC (permalink / raw)
  To: Lee Revell
  Cc: Rui Nuno Capela, linux-kernel, mark_h_johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Lee Revell <rlrevell@joe-job.com> wrote:

> On Thu, 2004-11-18 at 14:46 +0000, Rui Nuno Capela wrote:
> > I'm still seeing this sometimes (not everytime) on my P4/UP laptop while
> > shutting down ALSA modules.
> 
> Same thing here (BUG on unload ALSA modules) with 0.7.27-10 FWIW.

0.7.29-1 fixes a similar module-unload problem reported by Christian
Meder, could you try it?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-18 21:27                                                                   ` Michal Schmidt
@ 2004-11-19 10:05                                                                     ` Ingo Molnar
  2004-11-19 14:11                                                                       ` Steven Rostedt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-19 10:05 UTC (permalink / raw)
  To: Michal Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:

> Ingo Molnar wrote:
> >i have released the -V0.7.29-0 Real-Time Preemption patch, 
> 
> Hi,
> is it supposed to work on x86_64? It doesn't compile.

not at the moment - it needs the timer interrupt threading changes.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-19 10:05                                                                     ` Ingo Molnar
@ 2004-11-19 14:11                                                                       ` Steven Rostedt
  2004-11-19 17:08                                                                         ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2004-11-19 14:11 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

I'm getting a bug print (really a warning) from enable_irq spawned from
the e100 driver. The reason is that enable_irq is being called because
the irq depth is zero.

Looking into this, it is because the e100 uses a shared interrupt.  On
setup (see drivers/net/e100.c: e100_up) it disables the irq that it will
use, and then calls request_irq which calls setup_irq which zeros out
the depth of the irq if it is not shared.  So if the e100 is the first
to be loaded, then you get this message. 

I know that for now this doesn't hurt anything, but besides annoying me
in my print outs (I can't stop panicking when I see it ;-),  is this
really a bug and thus a design flaw of the e100? How else can a shared
irq initialize without turning off the irq before setting itself up?

Should it enable the irq before it requests it, and thus open the race
of a spurious interrupt, or just disable all interrupts?

Thanks,

-- 
Steven Rostedt
Senior Engineer
Kihon Technologies

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-19  9:56                                                                     ` Ingo Molnar
@ 2004-11-19 15:44                                                                       ` Shane Shrybman
  2004-11-20 13:17                                                                         ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Shane Shrybman @ 2004-11-19 15:44 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, Rui Nuno Capela, linux-kernel, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Amit Shah

On Fri, 2004-11-19 at 04:56, Ingo Molnar wrote:

> 0.7.29-1 fixes a similar module-unload problem reported by Christian
> Meder, could you try it?
> 
> 	Ingo
> 

Hi, just tried V0.7.29-1 with the ivtv module and I got this oops:

Attached scsi generic sg2 at scsi0, channel 0, id 2, lun 0,  type 0
IRQ#22 thread RT prio: 38.
BUG: Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
e0ab77f8
*pde = 00000000
Oops: 0002 [#1]
PREEMPT 
Modules linked in: sg msp3400 saa7115 tveeprom ivtv nfsd exportfs lockd sunrpc tuner tvaudio bttv video_buf firmware_class btcx_risc snd_via82xx snd_mpu401_uart i2c_viapro joydev usbhid uhci_hcd usbcore 3c59x mii emu10k1_gp gameport snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore via_agp agpgart dm_mod realtime rtc
CPU:    0
EIP:    0060:[<e0ab77f8>]    Not tainted VLI
EFLAGS: 00210286   (2.6.10-rc22-V29) 
EIP is at buffer_queue+0x38/0x70 [bttv]
eax: de7d4744   ebx: 00000000   ecx: d745c2a0   edx: d745c304
esi: de7d40e8   edi: e0ad34e0   ebp: d2571c34   esp: d2571c24
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process mythbackend (pid: 4071, threadinfo=d2570000 task=d27fb800)
Stack: d2571c34 00200286 00200286 e0ad39dc d2571ec8 e0ab8fb8 de7d4000 d745c2a0 
       e0ac37b4 00000160 000001e0 00000004 00001c3c e0ad34e0 de7d4010 d27fb800 
       d2571c78 c01112d0 00000002 d745c2a0 c01dcf75 de7d4000 c01339a1 00200286 
Call Trace:
 [<c0104093>] show_stack+0x83/0xa0 (28)
 [<c010424c>] show_registers+0x16c/0x1d0 (56)
 [<c0104447>] die+0xf7/0x190 (64)
 [<c0114fb0>] do_page_fault+0x360/0x6b0 (220)
 [<c0103cab>] error_code+0x2b/0x30 (76)
 [<e0ab8fb8>] bttv_do_ioctl+0x538/0x15f0 [bttv] (660)
 [<c0276a4e>] video_usercopy+0x8e/0x160 (168)
 [<e0aba0b4>] bttv_ioctl+0x44/0x70 [bttv] (32)
 [<c01741a1>] sys_ioctl+0xe1/0x280 (44)
 [<c0103245>] sysenter_past_esp+0x52/0x71 (-8124)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c010438f>] .... die+0x3f/0x190
.....[<c0114fb0>] ..   ( <= do_page_fault+0x360/0x6b0)
.. [<c0136f4d>] .... print_traces+0x1d/0x60
.....[<c0104093>] ..   ( <= show_stack+0x83/0xa0)

Code: eb 9a 65 df 8b 45 08 8b 4d 0c 8b 80 ec 00 00 00 8d 51 64 8b 30 c7 41 20 02 00 00 00 8d 86 5c 06 00 00 8b 58 04 89 41 64 89 50 04 <89> 13 89 5a 04 8b 8e 78 06 00 00 85 c9 74 08 8b 5d f8 8b 75 fc 
 BUG: mythbackend/4071, BKL held at task exit time!
BKL acquired at: sys_ioctl+0x5e/0x280
 [c03b1d44] {kernel_sem.lock}
.. held by:       mythbackend: 4071 [d27fb800, 119]
... acquired at:  lock_kernel+0x2f/0x50
BUG: mythbackend/4071, lock held at task exit time!
 [de7d4014] {&q->lock}
.. held by:       mythbackend: 4071 [d27fb800, 119]
... acquired at:  bttv_do_ioctl+0x476/0x15f0 [bttv]
BUG: mythbackend/4071, lock held at task exit time!
 [e0ad39dc] {&btv->s_lock}
.. held by:       mythbackend: 4071 [d27fb800, 119]
... acquired at:  bttv_do_ioctl+0x51b/0x15f0 [bttv]
mythbackend/4071: BUG in __up_mutex at kernel/rt.c:1101
 [<c01040d3>] dump_stack+0x23/0x30 (20)
 [<c01340a2>] __up_mutex+0x302/0x530 (52)
 [<c01351b1>] up+0x101/0x110 (36)
 [<c0342df1>] __schedule+0x6b1/0x750 (72)
 [<c011e797>] do_exit+0x2f7/0x590 (48)
 [<c01044e0>] do_trap+0x0/0x100 (64)
 [<c0114fb0>] do_page_fault+0x360/0x6b0 (220)
 [<c0103cab>] error_code+0x2b/0x30 (76)
 [<e0ab8fb8>] bttv_do_ioctl+0x538/0x15f0 [bttv] (660)
 [<c0276a4e>] video_usercopy+0x8e/0x160 (168)
 [<e0aba0b4>] bttv_ioctl+0x44/0x70 [bttv] (32)
 [<c01741a1>] sys_ioctl+0xe1/0x280 (44)
 [<c0103245>] sysenter_past_esp+0x52/0x71 (-8124)
---------------------------
| preempt count: 00000004 ]
| 4-level deep critical section nesting:
----------------------------------------
.. [<c034278f>] .... __schedule+0x4f/0x750
.....[<c011e797>] ..   ( <= do_exit+0x2f7/0x590)
.. [<c0135161>] .... up+0xb1/0x110
.....[<c0342df1>] ..   ( <= __schedule+0x6b1/0x750)
.. [<c01342b7>] .... __up_mutex+0x517/0x530
.....[<c01351b1>] ..   ( <= up+0x101/0x110)
.. [<c0136f4d>] .... print_traces+0x1d/0x60
.....[<c01040d3>] ..   ( <= dump_stack+0x23/0x30)

Regards,

Shane


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-19 14:11                                                                       ` Steven Rostedt
@ 2004-11-19 17:08                                                                         ` K.R. Foley
  2004-11-21 21:50                                                                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-11-19 17:08 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Ingo Molnar, LKML

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

Steven Rostedt wrote:
> I'm getting a bug print (really a warning) from enable_irq spawned from
> the e100 driver. The reason is that enable_irq is being called because
> the irq depth is zero.
> 
> Looking into this, it is because the e100 uses a shared interrupt.  On
> setup (see drivers/net/e100.c: e100_up) it disables the irq that it will
> use, and then calls request_irq which calls setup_irq which zeros out
> the depth of the irq if it is not shared.  So if the e100 is the first
> to be loaded, then you get this message. 
> 
> I know that for now this doesn't hurt anything, but besides annoying me
> in my print outs (I can't stop panicking when I see it ;-),  is this
> really a bug and thus a design flaw of the e100? How else can a shared
> irq initialize without turning off the irq before setting itself up?
> 
> Should it enable the irq before it requests it, and thus open the race
> of a spurious interrupt, or just disable all interrupts?
> 
> Thanks,
> 

Actually I think it shouldn't call either enable or disable because it 
is shared (or allowed to be shared). After creating a patch myself to 
fix this I realized that it had already been fixed in the newest version 
of the driver on sourceforge. Anyway if you are interested in this fix 
temporarily, here it is.

kr



[-- Attachment #2: e100.patch --]
[-- Type: text/x-patch, Size: 676 bytes --]

--- linux-2.6.10-rc1-mm3.cln/drivers/net/e100.c.orig	2004-11-15 21:09:24.846227425 -0600
+++ linux-2.6.10-rc1-mm3.cln/drivers/net/e100.c	2004-11-15 21:10:10.870474989 -0600
@@ -1680,8 +1680,6 @@
 	if((err = e100_rx_alloc_list(nic)))
 		return err;
 
-	disable_irq(nic->pdev->irq);
-
 	if((err = e100_alloc_cbs(nic)))
 		goto err_rx_clean_list;
 	if((err = e100_hw_init(nic)))
@@ -1693,7 +1691,6 @@
 		nic->netdev->name, nic->netdev)))
 		goto err_no_irq;
 	e100_enable_irq(nic);
-	enable_irq(nic->pdev->irq);
 	netif_wake_queue(nic->netdev);
 	return 0;
 
@@ -1704,7 +1701,6 @@
 err_rx_clean_list:
 	e100_rx_clean_list(nic);
 
-	enable_irq(nic->pdev->irq);
 	return err;
 }
 

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-18 16:46                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 Ingo Molnar
  2004-11-18 21:27                                                                   ` Michal Schmidt
@ 2004-11-19 19:05                                                                   ` Peter Zijlstra
  2004-11-20 13:13                                                                     ` Ingo Molnar
  2004-11-20  3:22                                                                   ` Lee Revell
                                                                                     ` (2 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: Peter Zijlstra @ 2004-11-19 19:05 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

Hi Ingo,

in 29-4 I get a lot of these lines in my log:

drivers/usb/input/hid-core.c: input irq status -71 received

29-0 didn't do that.

Kind regards,

-- 
Peter Zijlstra <a.p.zijlstra@chello.nl>


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-18 16:46                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 Ingo Molnar
  2004-11-18 21:27                                                                   ` Michal Schmidt
  2004-11-19 19:05                                                                   ` Peter Zijlstra
@ 2004-11-20  3:22                                                                   ` Lee Revell
  2004-11-20 11:50                                                                     ` Florian Schmidt
  2004-11-20 12:55                                                                     ` Ingo Molnar
  2004-11-20 20:23                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 K.R. Foley
  2004-11-22  0:54                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2 Ingo Molnar
  4 siblings, 2 replies; 951+ messages in thread
From: Lee Revell @ 2004-11-20  3:22 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Thu, 2004-11-18 at 17:46 +0100, Ingo Molnar wrote:
> i have released the -V0.7.29-0 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
> 	http://redhat.com/~mingo/realtime-preempt/

I tried this with CONFIG_PREEMPT_VOLUNTARY (which should theoretically
work like the earlier VP patches, right?) to test for regressions.  The
boot process hung after initializing my IDE controller.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20  3:22                                                                   ` Lee Revell
@ 2004-11-20 11:50                                                                     ` Florian Schmidt
  2004-11-20 12:59                                                                       ` Ingo Molnar
  2004-11-20 12:55                                                                     ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-11-20 11:50 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Fri, 19 Nov 2004 22:22:42 -0500
Lee Revell <rlrevell@joe-job.com> wrote:

> On Thu, 2004-11-18 at 17:46 +0100, Ingo Molnar wrote:
> > i have released the -V0.7.29-0 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> > 
> > 	http://redhat.com/~mingo/realtime-preempt/
> 
> I tried this with CONFIG_PREEMPT_VOLUNTARY (which should theoretically
> work like the earlier VP patches, right?) to test for regressions.  The
> boot process hung after initializing my IDE controller.

I thought so, too, until ingo set me straight (quote ingo):

here are the different layers of preemption:

 - !PREEMPT
 - PREEMPT_VOLUNTARY
 - PREEMPT
 - PREEMPT_RT

each step forward decreases latencies, at the cost of more runtime 
overhead.

so PREEMPT_VOLUNTARY is not "the" feature anymore, it's "a" feature down
the hierarchy. In fact the focus is mostly on PREEMPT_RT now.

quote end..

So with RP kernels, PREEMPT is what gives best latency when full realtime
preemption is not an option

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20  3:22                                                                   ` Lee Revell
  2004-11-20 11:50                                                                     ` Florian Schmidt
@ 2004-11-20 12:55                                                                     ` Ingo Molnar
  2004-11-20 17:19                                                                       ` Lee Revell
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-20 12:55 UTC (permalink / raw)
  To: Lee Revell
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Lee Revell <rlrevell@joe-job.com> wrote:

> On Thu, 2004-11-18 at 17:46 +0100, Ingo Molnar wrote:
> > i have released the -V0.7.29-0 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> > 
> > 	http://redhat.com/~mingo/realtime-preempt/
> 
> I tried this with CONFIG_PREEMPT_VOLUNTARY (which should theoretically
> work like the earlier VP patches, right?) to test for regressions. 
> The boot process hung after initializing my IDE controller.

which patch did you try? I fixed the 'lower' preemption levels in
-V0.7.29-4, earlier kernels are broken.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 11:50                                                                     ` Florian Schmidt
@ 2004-11-20 12:59                                                                       ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-20 12:59 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> here are the different layers of preemption:
> 
>  - !PREEMPT
>  - PREEMPT_VOLUNTARY
>  - PREEMPT
>  - PREEMPT_RT
> 
> each step forward decreases latencies, at the cost of more runtime
> overhead.

yes, and here is how they show up in the config:

               ( ) No Forced Preemption (Server)
               ( ) Voluntary Kernel Preemption (Desktop)
               ( ) Preemptible Kernel (Low-Latency Desktop)
               (X) Complete Preemption (Real-Time)

measurements are needed to find out how latencies and runtime overhead
vary between these levels.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-19 19:05                                                                   ` Peter Zijlstra
@ 2004-11-20 13:13                                                                     ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-20 13:13 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: LKML

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]


* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> Hi Ingo,
> 
> in 29-4 I get a lot of these lines in my log:
> 
> drivers/usb/input/hid-core.c: input irq status -71 received
> 
> 29-0 didn't do that.

weird. I've attached the diff between -0 and -4 - nothing should affect
USB, except perhaps the manage.c bits. Could you try to revert the
smaller plaintext patch below, does that solve this problem?

	Ingo

--- linux.old/kernel/irq/manage.c	
+++ linux.new/kernel/irq/manage.c	
@@ -509,9 +509,7 @@ static int start_irq_thread(int irq, str
 	 * such a case:
 	 */
 	smp_mb();
-	
-	if (desc->status & IRQ_INPROGRESS)
-		wake_up_process(desc->thread);
+	wake_up_process(desc->thread);
 	
 	return 0;
 }

[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 7203 bytes --]

--- linux.old/Makefile	
+++ linux.new/Makefile	
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 10
-EXTRAVERSION =-rc2-mm2-V0.7.29-0
+EXTRAVERSION =-rc2-mm2-V0.7.29-5
 NAME=Woozy Numbat
 
 # *DOCUMENTATION*
--- linux.old/arch/i386/kernel/io_apic.c	
+++ linux.new/arch/i386/kernel/io_apic.c	
@@ -1956,7 +1956,7 @@ static void end_level_ioapic_irq(unsigne
 		unmask_IO_APIC_irq(irq);
 }
 
-#else /* !CONFIG_PREEMPT_HARDIRQS */
+#else /* !CONFIG_PREEMPT_HARDIRQS || !CONFIG_SMP */
 
 static void mask_and_ack_level_ioapic_irq(unsigned int irq)
 {
--- linux.old/drivers/base/bus.c	
+++ linux.new/drivers/base/bus.c	
@@ -65,7 +65,7 @@ static struct sysfs_ops driver_sysfs_ops
 static void driver_release(struct kobject * kobj)
 {
 	struct device_driver * drv = to_driver(kobj);
-	up(&drv->unload_sem);
+	complete(&drv->unload_done);
 }
 
 static struct kobj_type ktype_driver = {
--- linux.old/drivers/base/driver.c	
+++ linux.new/drivers/base/driver.c	
@@ -79,14 +79,13 @@ void put_driver(struct device_driver * d
  *	since most of the things we have to do deal with the bus
  *	structures.
  *
- *	The one interesting aspect is that we initialize @drv->unload_sem
- *	to a locked state here. It will be unlocked when the driver
- *	reference count reaches 0.
+ *	We init the completion strcut here. When the reference 
+ *	count reaches zero, complete() is called from bus_release().
  */
 int driver_register(struct device_driver * drv)
 {
 	INIT_LIST_HEAD(&drv->devices);
-	init_MUTEX_LOCKED(&drv->unload_sem);
+	init_completion(&drv->unload_done);
 	return bus_add_driver(drv);
 }
 
@@ -97,18 +96,16 @@ int driver_register(struct device_driver
  *
  *	Again, we pass off most of the work to the bus-level call.
  *
- *	Though, once that is done, we attempt to take @drv->unload_sem.
- *	This will block until the driver refcount reaches 0, and it is
- *	released. Only modular drivers will call this function, and we
+ *	Though, once that is done, we wait until the driver refcount 
+ *	reaches 0, and complete() is called in bus_release().
+ *	Only modular drivers will call this function, and we
  *	have to guarantee that it won't complete, letting the driver
  *	unload until all references are gone.
  */
-
 void driver_unregister(struct device_driver * drv)
 {
 	bus_remove_driver(drv);
-	down(&drv->unload_sem);
-	up(&drv->unload_sem);
+	wait_for_completion(&drv->unload_done);
 }
 
 /**
--- linux.old/drivers/media/dvb/dvb-core/dvb_frontend.c	
+++ linux.new/drivers/media/dvb/dvb-core/dvb_frontend.c	
@@ -658,7 +658,7 @@ static void dvb_frontend_stop (struct dv
 		printk("dvb_frontend_stop: thread PID %d already died\n",
 				fe->thread_pid);
 		/* make sure the mutex was not held by the thread */
-		init_MUTEX (&fe->sem);
+		sema_init_nocheck (&fe->sem, 1);
 		return;
 	}
 
@@ -1127,10 +1127,10 @@ dvb_register_frontend (int (*ioctl) (str
 
 	memset (fe, 0, sizeof (struct dvb_frontend_data));
 
-	init_MUTEX (&fe->sem);
+	sema_init_nocheck (&fe->sem, 1);
 	init_waitqueue_head (&fe->wait_queue);
 	init_waitqueue_head (&fe->events.wait_queue);
-	init_MUTEX (&fe->events.sem);
+	sema_init_nocheck (&fe->events.sem, 1);
 	fe->events.eventw = fe->events.eventr = 0;
 	fe->events.overflow = 0;
 	fe->module = module;
--- linux.old/fs/lockd/svc.c	
+++ linux.new/fs/lockd/svc.c	
@@ -49,7 +49,7 @@ static pid_t			nlmsvc_pid;
 int				nlmsvc_grace_period;
 unsigned long			nlmsvc_timeout;
 
-static DECLARE_MUTEX_NOCHECK(lockd_start);
+static DECLARE_WAIT_QUEUE_HEAD(lockd_start);
 static DECLARE_WAIT_QUEUE_HEAD(lockd_exit);
 
 /*
@@ -112,7 +112,7 @@ lockd(struct svc_rqst *rqstp)
 	 * Let our maker know we're running.
 	 */
 	nlmsvc_pid = current->pid;
-	up(&lockd_start);
+	wake_up(&lockd_start);
 
 	daemonize("lockd");
 
@@ -233,6 +233,7 @@ lockd_up(void)
 		printk(KERN_WARNING
 			"lockd_up: no pid, %d users??\n", nlmsvc_users);
 
+
 	error = -ENOMEM;
 	serv = svc_create(&nlmsvc_program, LOCKD_BUFSIZE);
 	if (!serv) {
@@ -261,8 +262,15 @@ lockd_up(void)
 			"lockd_up: create thread failed, error=%d\n", error);
 		goto destroy_and_out;
 	}
-	down(&lockd_start);
-
+	/*
+	 * Wait for the lockd process to start, but since we're holding
+	 * the lockd semaphore, we can't wait around forever ...
+	 */
+	if (wait_event_interruptible_timeout(lockd_start, 
+					     nlmsvc_pid != 0, HZ) <= 0) {
+		printk(KERN_WARNING 
+			"lockd_down: lockd failed to start\n");
+	}
 	/*
 	 * Note: svc_serv structures have an initial use count of 1,
 	 * so we exit through here on both success and failure.
@@ -302,16 +310,12 @@ lockd_down(void)
 	 * Wait for the lockd process to exit, but since we're holding
 	 * the lockd semaphore, we can't wait around forever ...
 	 */
-	clear_thread_flag(TIF_SIGPENDING);
-	interruptible_sleep_on_timeout(&lockd_exit, HZ);
-	if (nlmsvc_pid) {
+	if (wait_event_interruptible_timeout(lockd_exit, 
+					     nlmsvc_pid == 0, HZ) <= 0) {
 		printk(KERN_WARNING 
 			"lockd_down: lockd failed to exit, clearing pid\n");
 		nlmsvc_pid = 0;
 	}
-	spin_lock_irq(&current->sighand->siglock);
-	recalc_sigpending();
-	spin_unlock_irq(&current->sighand->siglock);
 out:
 	up(&nlmsvc_sema);
 }
@@ -428,7 +432,6 @@ module_param_call(nlm_tcpport, param_set
 
 static int __init init_nlm(void)
 {
-	down(&lockd_start); // initialize as locked
 	nlm_sysctl_table = register_sysctl_table(nlm_sysctl_root, 0);
 	return nlm_sysctl_table ? 0 : -ENOMEM;
 }
--- linux.old/include/linux/device.h	
+++ linux.new/include/linux/device.h	
@@ -102,7 +102,7 @@ struct device_driver {
 	char			* name;
 	struct bus_type		* bus;
 
-	struct semaphore	unload_sem;
+	struct completion	unload_done;
 	struct kobject		kobj;
 	struct list_head	devices;
 
--- linux.old/include/linux/preempt.h	
+++ linux.new/include/linux/preempt.h	
@@ -66,6 +66,8 @@ do { \
 #define preempt_enable()		do { } while (0)
 #define preempt_check_resched()		do { } while (0)
 
+#define preempt_schedule_irq()		do { } while (0)
+
 #endif
 
 #endif /* __LINUX_PREEMPT_H */
--- linux.old/kernel/irq/manage.c	
+++ linux.new/kernel/irq/manage.c	
@@ -509,9 +509,7 @@ static int start_irq_thread(int irq, str
 	 * such a case:
 	 */
 	smp_mb();
-	
-	if (desc->status & IRQ_INPROGRESS)
-		wake_up_process(desc->thread);
+	wake_up_process(desc->thread);
 	
 	return 0;
 }
--- linux.old/kernel/rt.c	
+++ linux.new/kernel/rt.c	
@@ -1112,7 +1112,7 @@ static void __up_mutex(struct rt_mutex *
 	 * reschedule then do it here without enabling interrupts
 	 * again (and lengthening latency):
 	 */
-	while (need_resched() && !irqs_disabled_flags(flags) && !preempt_count())
+	if (need_resched() && !irqs_disabled_flags(flags) && !preempt_count())
 		preempt_schedule_irq();
 	local_irq_restore(flags);
 	/* no need to check for preempt here - we just handled it */
--- linux.old/kernel/sched.c	
+++ linux.new/kernel/sched.c	
@@ -1165,7 +1165,7 @@ out:
 	 * reschedule then do it here without enabling interrupts
 	 * again (and lengthening latency):
 	 */
-	while (need_resched() && !irqs_disabled_flags(flags) && !preempt_count())
+	if (need_resched() && !irqs_disabled_flags(flags) && !preempt_count())
 		preempt_schedule_irq();
 	local_irq_restore(flags);
 	/* no need to check for preempt here - we just handled it */

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-19 15:44                                                                       ` Shane Shrybman
@ 2004-11-20 13:17                                                                         ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-20 13:17 UTC (permalink / raw)
  To: Shane Shrybman
  Cc: Lee Revell, Rui Nuno Capela, linux-kernel, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Amit Shah


* Shane Shrybman <shrybman@aei.ca> wrote:

> On Fri, 2004-11-19 at 04:56, Ingo Molnar wrote:
> 
> > 0.7.29-1 fixes a similar module-unload problem reported by Christian
> > Meder, could you try it?
> > 
> > 	Ingo
> > 
> 
> Hi, just tried V0.7.29-1 with the ivtv module and I got this oops:

hm, does vanilla 2.6.10-rc2-mm2 work?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 12:55                                                                     ` Ingo Molnar
@ 2004-11-20 17:19                                                                       ` Lee Revell
  2004-11-20 19:14                                                                         ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-11-20 17:19 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sat, 2004-11-20 at 13:55 +0100, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Thu, 2004-11-18 at 17:46 +0100, Ingo Molnar wrote:
> > > i have released the -V0.7.29-0 Real-Time Preemption patch, which can be
> > > downloaded from the usual place:
> > > 
> > > 	http://redhat.com/~mingo/realtime-preempt/
> > 
> > I tried this with CONFIG_PREEMPT_VOLUNTARY (which should theoretically
> > work like the earlier VP patches, right?) to test for regressions. 
> > The boot process hung after initializing my IDE controller.
> 
> which patch did you try? I fixed the 'lower' preemption levels in
> -V0.7.29-4, earlier kernels are broken.
> 

This was the version I tried.  I will try to provide some more info.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 19:14                                                                         ` Ingo Molnar
@ 2004-11-20 18:35                                                                           ` Lee Revell
  2004-11-20 19:11                                                                             ` Florian Schmidt
  2004-11-20 19:09                                                                           ` Lee Revell
  2004-11-21  0:32                                                                           ` Lee Revell
  2 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-11-20 18:35 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sat, 2004-11-20 at 20:14 +0100, Ingo Molnar wrote:
> i only tried the !PREEMPT version though - does that one work for you? 

Not sure, will test.  My goal was to see if I could get the stability
and low latency of T3 (this is low enough latency for me!) with the new
versions.

> Also, please send me the .config that produces the failing kernel.

Sent (off-list).

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 19:14                                                                         ` Ingo Molnar
  2004-11-20 18:35                                                                           ` Lee Revell
@ 2004-11-20 19:09                                                                           ` Lee Revell
  2004-11-21 12:47                                                                             ` Ingo Molnar
  2004-11-21  0:32                                                                           ` Lee Revell
  2 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-11-20 19:09 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sat, 2004-11-20 at 20:14 +0100, Ingo Molnar wrote:
> i only tried the !PREEMPT version though - does that one work for you? 
> Also, please send me the .config that produces the failing kernel.
> 

OK it allows me to set PREEMPT_NONE, PREEMPT_SOFTIRQS, and
PREEMPT_HARDIRQS.  This should be an illegal combination, right?

Lee 


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 18:35                                                                           ` Lee Revell
@ 2004-11-20 19:11                                                                             ` Florian Schmidt
  2004-11-20 20:40                                                                               ` Florian Schmidt
  2004-11-21 15:12                                                                               ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-20 19:11 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sat, 20 Nov 2004 13:35:44 -0500
Lee Revell <rlrevell@joe-job.com> wrote:

> On Sat, 2004-11-20 at 20:14 +0100, Ingo Molnar wrote:
> > i only tried the !PREEMPT version though - does that one work for you? 
> 
> Not sure, will test.  My goal was to see if I could get the stability
> and low latency of T3 (this is low enough latency for me!) with the new
> versions.
> 
> > Also, please send me the .config that produces the failing kernel.
> 
> Sent (off-list).

Hi,

29-4 with PREEMPT works very good (jackd at 64 frames: 0 xruns (running for
1h now), soundcard irq unthreaded). Opposed to 29-1 PREEMPT_REALTIME which
showed some very weird jackd behaviour (xruns from 10usec to 50msec [!!!]).
rtc_wakeup was showing no large jitter for that kernel though, nor did the
different traces show anything that might have caused the jackd xruns. And
yes, i configured the irq handlers sanely :)

Will build 29-4 PREEMPT_REALTIME now and see how this one behaves.

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 17:19                                                                       ` Lee Revell
@ 2004-11-20 19:14                                                                         ` Ingo Molnar
  2004-11-20 18:35                                                                           ` Lee Revell
                                                                                             ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-20 19:14 UTC (permalink / raw)
  To: Lee Revell
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Lee Revell <rlrevell@joe-job.com> wrote:

> > > > 	http://redhat.com/~mingo/realtime-preempt/
> > > 
> > > I tried this with CONFIG_PREEMPT_VOLUNTARY (which should theoretically
> > > work like the earlier VP patches, right?) to test for regressions. 
> > > The boot process hung after initializing my IDE controller.
> > 
> > which patch did you try? I fixed the 'lower' preemption levels in
> > -V0.7.29-4, earlier kernels are broken.
> > 
> 
> This was the version I tried.  I will try to provide some more info.

i only tried the !PREEMPT version though - does that one work for you? 
Also, please send me the .config that produces the failing kernel.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-18 16:46                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 Ingo Molnar
                                                                                     ` (2 preceding siblings ...)
  2004-11-20  3:22                                                                   ` Lee Revell
@ 2004-11-20 20:23                                                                   ` K.R. Foley
  2004-11-20 20:51                                                                     ` K.R. Foley
  2004-11-22  0:54                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2 Ingo Molnar
  4 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-11-20 20:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

Ingo Molnar wrote:
> i have released the -V0.7.29-0 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 

I have some latency test results from -V0.7.29-4 generated using the rtc 
histograms and realfeel. The test runs were just over an hour under 
heavy load from stress-kernel. One is from a slower 450 UP system and 
one is from a 933 SMP system. I will be doing more testing but these are 
a start.

http://www.cybsft.com/testresults/histograms/up450test1.hist.png

http://www.cybsft.com/testresults/histograms/up450test1.hist.png

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 19:11                                                                             ` Florian Schmidt
@ 2004-11-20 20:40                                                                               ` Florian Schmidt
  2004-11-21 12:45                                                                                 ` Ingo Molnar
                                                                                                   ` (2 more replies)
  2004-11-21 15:12                                                                               ` Ingo Molnar
  1 sibling, 3 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-20 20:40 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Lee Revell, Ingo Molnar, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Sat, 20 Nov 2004 20:11:55 +0100
Florian Schmidt <mista.tapas@gmx.net> wrote:

> 29-4 with PREEMPT works very good (jackd at 64 frames: 0 xruns (running for
> 1h now), soundcard irq unthreaded). Opposed to 29-1 PREEMPT_REALTIME which
> showed some very weird jackd behaviour (xruns from 10usec to 50msec [!!!]).
> rtc_wakeup was showing no large jitter for that kernel though, nor did the
> different traces show anything that might have caused the jackd xruns. And
> yes, i configured the irq handlers sanely :)
> 
> Will build 29-4 PREEMPT_REALTIME now and see how this one behaves.

Pretty much as bad as 29-1. Sadly i have no idea on how to find out what is
causing jackd to act so weird under a PREEMPT_REALTIME kernel. It seems
there is some correlation to activity on X. Hiding and showing windows has a
certain chance of triggering a large xrun.

Hmm, the max jitter rtc_wakeup shows at 1024hz is around 150us. Which seems
a tiny bit large, too, as the rtc histogram shows a max wakeup latency of
16us..

It seems it's not the threaded irq handlers as jackd peformed quite well
under 29-4 PREEMPT with the soundcrd irq handler threaded and at high prio
(which i forgot to mention in my previous mail).

So i don't really know how to go about this. I suppose i just run PREEMPT
kernels instead of PREEMPT_REALTIME. Maybe it's the overhead which is
killing jackd performance with PREEMPT_REALTIME, but i don't believe so
(50ms? nah!).

flo

P.S.: There's so many variables in this PREEMPT/PREEMPT_REALTIME, handlers
threaded/unthreaded. IRQ handler thread priorities. It would probably be
cool if we could create some testing procedure which produces results which
are comparable. Ideally this procedure would be automated. Any takers?

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 20:23                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 K.R. Foley
@ 2004-11-20 20:51                                                                     ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-11-20 20:51 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

K.R. Foley wrote:
> Ingo Molnar wrote:
> 
>> i have released the -V0.7.29-0 Real-Time Preemption patch, which can be
>> downloaded from the usual place:
>>
> 
> I have some latency test results from -V0.7.29-4 generated using the rtc 
> histograms and realfeel. The test runs were just over an hour under 
> heavy load from stress-kernel. One is from a slower 450 UP system and 
> one is from a 933 SMP system. I will be doing more testing but these are 
> a start.
> 
> http://www.cybsft.com/testresults/histograms/up450test1.hist.png
> 
> http://www.cybsft.com/testresults/histograms/up450test1.hist.png

OK. I feel stupid. The above URL should be:
http://www.cybsft.com/testresults/histograms/smp933test1.hist.png

kr



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 19:14                                                                         ` Ingo Molnar
  2004-11-20 18:35                                                                           ` Lee Revell
  2004-11-20 19:09                                                                           ` Lee Revell
@ 2004-11-21  0:32                                                                           ` Lee Revell
  2004-11-24 12:15                                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-1 Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-11-21  0:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sat, 2004-11-20 at 20:14 +0100, Ingo Molnar wrote:
> i only tried the !PREEMPT version though - does that one work for you? 

Yup, !PREEMPT works fine.  Testing PREEMPT next.  So far only
PREEMPT_VOLUNTARY fails to boot.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 20:40                                                                               ` Florian Schmidt
@ 2004-11-21 12:45                                                                                 ` Ingo Molnar
  2004-11-21 14:32                                                                                   ` Ingo Molnar
  2004-11-21 14:49                                                                                   ` Florian Schmidt
  2004-11-21 12:50                                                                                 ` Ingo Molnar
  2004-11-21 12:54                                                                                 ` Ingo Molnar
  2 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-21 12:45 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> > Will build 29-4 PREEMPT_REALTIME now and see how this one behaves.
> 
> Pretty much as bad as 29-1. Sadly i have no idea on how to find out
> what is causing jackd to act so weird under a PREEMPT_REALTIME kernel.
> It seems there is some correlation to activity on X. Hiding and
> showing windows has a certain chance of triggering a large xrun.

do you have chrt-ed the IRQ#0 thread and the soundcard thread as well?

> So i don't really know how to go about this. I suppose i just run
> PREEMPT kernels instead of PREEMPT_REALTIME. Maybe it's the overhead
> which is killing jackd performance with PREEMPT_REALTIME, but i don't
> believe so (50ms? nah!).

agreed, no way can 50msec be related to overhead.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 19:09                                                                           ` Lee Revell
@ 2004-11-21 12:47                                                                             ` Ingo Molnar
  2004-11-21 13:27                                                                               ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-21 12:47 UTC (permalink / raw)
  To: Lee Revell
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Lee Revell <rlrevell@joe-job.com> wrote:

> > i only tried the !PREEMPT version though - does that one work for you? 
> > Also, please send me the .config that produces the failing kernel.
> 
> OK it allows me to set PREEMPT_NONE, PREEMPT_SOFTIRQS, and
> PREEMPT_HARDIRQS.  This should be an illegal combination, right?

in theory it should work just fine.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 20:40                                                                               ` Florian Schmidt
  2004-11-21 12:45                                                                                 ` Ingo Molnar
@ 2004-11-21 12:50                                                                                 ` Ingo Molnar
  2004-11-21 14:50                                                                                   ` Florian Schmidt
  2004-11-21 12:54                                                                                 ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-21 12:50 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> So i don't really know how to go about this. [...]

you could try to use user-triggered tracing to capture a trace of one
such longer delay.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 20:40                                                                               ` Florian Schmidt
  2004-11-21 12:45                                                                                 ` Ingo Molnar
  2004-11-21 12:50                                                                                 ` Ingo Molnar
@ 2004-11-21 12:54                                                                                 ` Ingo Molnar
  2004-11-21 13:43                                                                                   ` Ingo Molnar
  2004-11-21 14:52                                                                                   ` Florian Schmidt
  2 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-21 12:54 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> Hmm, the max jitter rtc_wakeup shows at 1024hz is around 150us. Which
> seems a tiny bit large, too, as the rtc histogram shows a max wakeup
> latency of 16us..

yep, that's a bit too large too. What type of load does it need to
trigger such a 150 usec delay reliably?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-21 12:47                                                                             ` Ingo Molnar
@ 2004-11-21 13:27                                                                               ` Ingo Molnar
  2004-11-21 13:32                                                                                 ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-21 13:27 UTC (permalink / raw)
  To: Lee Revell
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Ingo Molnar <mingo@elte.hu> wrote:

> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > > i only tried the !PREEMPT version though - does that one work for you? 
> > > Also, please send me the .config that produces the failing kernel.
> > 
> > OK it allows me to set PREEMPT_NONE, PREEMPT_SOFTIRQS, and
> > PREEMPT_HARDIRQS.  This should be an illegal combination, right?
> 
> in theory it should work just fine.

hm, in practice it doesnt work - this is that causes the boot-time hang
you saw during PREEMPT_VOLUNTARY. I'll make irq threading depend on
PREEMPT, for the time being.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-21 13:27                                                                               ` Ingo Molnar
@ 2004-11-21 13:32                                                                                 ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-21 13:32 UTC (permalink / raw)
  To: Lee Revell
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Ingo Molnar <mingo@elte.hu> wrote:

> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > * Lee Revell <rlrevell@joe-job.com> wrote:
> > 
> > > > i only tried the !PREEMPT version though - does that one work for you? 
> > > > Also, please send me the .config that produces the failing kernel.
> > > 
> > > OK it allows me to set PREEMPT_NONE, PREEMPT_SOFTIRQS, and
> > > PREEMPT_HARDIRQS.  This should be an illegal combination, right?
> > 
> > in theory it should work just fine.
> 
> hm, in practice it doesnt work - this is that causes the boot-time
> hang you saw during PREEMPT_VOLUNTARY. I'll make irq threading depend
> on PREEMPT, for the time being.

this change is in the -5 kernel i just uploaded.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-21 12:54                                                                                 ` Ingo Molnar
@ 2004-11-21 13:43                                                                                   ` Ingo Molnar
  2004-11-21 15:05                                                                                     ` Florian Schmidt
  2004-11-21 14:52                                                                                   ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-21 13:43 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


> * Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > Hmm, the max jitter rtc_wakeup shows at 1024hz is around 150us. Which
> > seems a tiny bit large, too, as the rtc histogram shows a max wakeup
> > latency of 16us..
> 
> yep, that's a bit too large too. What type of load does it need to
> trigger such a 150 usec delay reliably?

on a 2 GHz UP box the worst-case max jitter i can trigger via rtc_wakeup
is 11 usecs, using the -5 kernel. The workload i used was 40 parallel
copies of LTP plus a few hackbench runs. This is how i started
rtc_wakeup:

 chrt -f 80 -p `pidof 'IRQ 0'`
 chrt -f 98 -p `pidof 'IRQ 8'`

 cd rtc_wakeup
 ./rtc_wakeup -f 1024 -t 100000

i.e. IRQ0 is below IRQ8 and the rtc_wakeup threads, but above every
other IRQ thread. Here's the histogram of a short (~5 minutes) run:

  1 247383
  2 34842
  3 1488
  4 3188
  5 125
  6 1

so this a 6 usecs max delay measured by /dev/rtc. So on your box, if the
max histogram delay was 16 usecs, i'd not expect a worse than ~30 usecs
jitter measured by rtc_wakeup. Can you reproduce the 150 usecs jitter
with the above IRQ setup?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-21 12:45                                                                                 ` Ingo Molnar
@ 2004-11-21 14:32                                                                                   ` Ingo Molnar
  2004-11-21 14:49                                                                                   ` Florian Schmidt
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-21 14:32 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Ingo Molnar <mingo@elte.hu> wrote:

> > So i don't really know how to go about this. I suppose i just run
> > PREEMPT kernels instead of PREEMPT_REALTIME. Maybe it's the overhead
> > which is killing jackd performance with PREEMPT_REALTIME, but i don't
> > believe so (50ms? nah!).
> 
> agreed, no way can 50msec be related to overhead.

there's one exception: if the RT workload is _just_ below 100% CPU
utilization, then PREEMPT_RT's overhead could push it above 100% and
trigger CPU overload, with big delays. What is the maximum CPU usage
during the test, while the system is otherwise idle?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-21 15:18                                                                                 ` Ingo Molnar
@ 2004-11-21 14:44                                                                                   ` Florian Schmidt
  0 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-21 14:44 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sun, 21 Nov 2004 16:18:45 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > i am too seeing constant, periodic xruns coming every 100 millisecs or
> > so. Simply running current Jack CVS via 'jackd -R -p1024 -d alsa'
> > gives tons of periodic xruns. Are you seeing the same?
> 
> but i'm seeing the same with !PREEMPT too - perhaps something broke in
> ALSA?

possible. Especially as i see those large xruns with jackd, but nothing
comparable with rtc_wakeup. OTOH, just PREEMPT seems to work very fine.

I only tested PREEMPT and PREEMPT_RT yet. 

Ah, i use jackd 0.99 from a debian package btw..

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-21 12:45                                                                                 ` Ingo Molnar
  2004-11-21 14:32                                                                                   ` Ingo Molnar
@ 2004-11-21 14:49                                                                                   ` Florian Schmidt
  1 sibling, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-21 14:49 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sun, 21 Nov 2004 13:45:55 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > > Will build 29-4 PREEMPT_REALTIME now and see how this one behaves.
> > 
> > Pretty much as bad as 29-1. Sadly i have no idea on how to find out
> > what is causing jackd to act so weird under a PREEMPT_REALTIME kernel.
> > It seems there is some correlation to activity on X. Hiding and
> > showing windows has a certain chance of triggering a large xrun.
> 
> do you have chrt-ed the IRQ#0 thread and the soundcard thread as well?

yes. I tried the following combinations with PREEMPT_RT:

- IRQ 0 prio 40, IRQ 3 (soundcard) prio 98
- IRQ 0 prio 99, IRQ 3 prio 98

all other IRQ's at prios around 40-50 (default or set explicitly to 40).
What is the recommended setting for IRQ 0? I thought in this typical
thread-wakeup-by-IRQ scenario the scheduler is "shorted" anyways when an IRQ
occurs, so IRQ 0's prio shouldn't really matter.

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-21 12:50                                                                                 ` Ingo Molnar
@ 2004-11-21 14:50                                                                                   ` Florian Schmidt
  0 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-21 14:50 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sun, 21 Nov 2004 13:50:23 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > So i don't really know how to go about this. [...]
> 
> you could try to use user-triggered tracing to capture a trace of one
> such longer delay.

Ok, will do (searching relevant email).

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-21 12:54                                                                                 ` Ingo Molnar
  2004-11-21 13:43                                                                                   ` Ingo Molnar
@ 2004-11-21 14:52                                                                                   ` Florian Schmidt
  1 sibling, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-21 14:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sun, 21 Nov 2004 13:54:39 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > Hmm, the max jitter rtc_wakeup shows at 1024hz is around 150us. Which
> > seems a tiny bit large, too, as the rtc histogram shows a max wakeup
> > latency of 16us..
> 
> yep, that's a bit too large too. What type of load does it need to
> trigger such a 150 usec delay reliably?

I cannot trigger it reliably yet. :(

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-21 13:43                                                                                   ` Ingo Molnar
@ 2004-11-21 15:05                                                                                     ` Florian Schmidt
  0 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-21 15:05 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

On Sun, 21 Nov 2004 14:43:54 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> on a 2 GHz UP box the worst-case max jitter i can trigger via rtc_wakeup
> is 11 usecs, using the -5 kernel. The workload i used was 40 parallel
> copies of LTP plus a few hackbench runs. This is how i started
> rtc_wakeup:
> 
>  chrt -f 80 -p `pidof 'IRQ 0'`
>  chrt -f 98 -p `pidof 'IRQ 8'`
> 
>  cd rtc_wakeup
>  ./rtc_wakeup -f 1024 -t 100000
> 
> i.e. IRQ0 is below IRQ8 and the rtc_wakeup threads, but above every
> other IRQ thread. Here's the histogram of a short (~5 minutes) run:

Ah, ok, this makes sense.. Will try the same. Btw: one more question wrt the
IRQ prios:

Let's assume i have IRQ 0 at 80, my soundcard and the rtc irq both at prio
98 and all others around 40. Now the rtc handler should never get in the way
of the soundcard irq if the rtc is simply not used right? And of course, the
other way around, too. the soundcard irq should not get in the way of the
rtc handler if the soundcard simply is not used and not generating IRQ's?

> 
>   1 247383
>   2 34842
>   3 1488
>   4 3188
>   5 125
>   6 1
> 
> so this a 6 usecs max delay measured by /dev/rtc. So on your box, if the
> max histogram delay was 16 usecs, i'd not expect a worse than ~30 usecs
> jitter measured by rtc_wakeup. Can you reproduce the 150 usecs jitter
> with the above IRQ setup?

not yet.

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-20 19:11                                                                             ` Florian Schmidt
  2004-11-20 20:40                                                                               ` Florian Schmidt
@ 2004-11-21 15:12                                                                               ` Ingo Molnar
  2004-11-21 15:18                                                                                 ` Ingo Molnar
  2004-11-21 15:28                                                                                 ` Florian Schmidt
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-21 15:12 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> [...] Opposed to 29-1 PREEMPT_REALTIME which showed some very weird
> jackd behaviour (xruns from 10usec to 50msec [!!!]). rtc_wakeup was
> showing no large jitter for that kernel though, nor did the different
> traces show anything that might have caused the jackd xruns. And yes,
> i configured the irq handlers sanely :)

i am too seeing constant, periodic xruns coming every 100 millisecs or
so. Simply running current Jack CVS via 'jackd -R -p1024 -d alsa' gives
tons of periodic xruns. Are you seeing the same?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-21 15:12                                                                               ` Ingo Molnar
@ 2004-11-21 15:18                                                                                 ` Ingo Molnar
  2004-11-21 14:44                                                                                   ` Florian Schmidt
  2004-11-21 15:28                                                                                 ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-21 15:18 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Ingo Molnar <mingo@elte.hu> wrote:

> i am too seeing constant, periodic xruns coming every 100 millisecs or
> so. Simply running current Jack CVS via 'jackd -R -p1024 -d alsa'
> gives tons of periodic xruns. Are you seeing the same?

but i'm seeing the same with !PREEMPT too - perhaps something broke in
ALSA?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-21 15:12                                                                               ` Ingo Molnar
  2004-11-21 15:18                                                                                 ` Ingo Molnar
@ 2004-11-21 15:28                                                                                 ` Florian Schmidt
  1 sibling, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-21 15:28 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]

On Sun, 21 Nov 2004 16:12:25 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > [...] Opposed to 29-1 PREEMPT_REALTIME which showed some very weird
> > jackd behaviour (xruns from 10usec to 50msec [!!!]). rtc_wakeup was
> > showing no large jitter for that kernel though, nor did the different
> > traces show anything that might have caused the jackd xruns. And yes,
> > i configured the irq handlers sanely :)
> 
> i am too seeing constant, periodic xruns coming every 100 millisecs or
> so. Simply running current Jack CVS via 'jackd -R -p1024 -d alsa' gives
> tons of periodic xruns. Are you seeing the same?

Nope, i don't see those. 

- my soundcard doesn't allow periodsizes > 512, so i ran with 512 now

- the xruns are very sporadic. My gnome desktop has a little toolbar thingy
which can hide all windows on a click and show em all again on the next
click. I _think_ there _might_ be a correlation to rapidly clicking that
hide/show all windows thing. But i'm not sure at all since it is not really
reproducable.

.config attached (29-4)

Will try 29-5 today (although my time might be limited due to some visitors)

flo


[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 26563 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-rc2-mm2-V0.7.29-4
# Sat Nov 20 21:45:43 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
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

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# 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_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
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_X86_USE_3DNOW=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_SMP is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT_DESKTOP=y
# CONFIG_PREEMPT_RT is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
# CONFIG_SPINLOCK_BKL is not set
CONFIG_PREEMPT_BKL=y
CONFIG_ASM_SEMAPHORES=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_KERN_PHYS_OFFSET=1
# CONFIG_KEXEC is not set

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

#
# 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_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y

#
# 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=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_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 is not set
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 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=y
# 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# 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

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_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_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM 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

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
CONFIG_RTC_HISTOGRAM=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
# CONFIG_I2C_AMD756_S4882 is not set
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_STUB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
# CONFIG_SENSORS_LM63 is not set
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
# CONFIG_SENSORS_LM87 is not set
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_MEMORY is not set
# CONFIG_SND_DEBUG_DETECT is not set

#
# Generic devices
#
CONFIG_SND_DUMMY=m
# 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

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY 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_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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=m
CONFIG_RXRPC=m

#
# 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=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_WAKEUP_TIMING is not set
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_USE_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
CONFIG_SECURITY_REALTIME=m
# CONFIG_SECURITY_SELINUX is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0
  2004-11-19 17:08                                                                         ` K.R. Foley
@ 2004-11-21 21:50                                                                           ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-21 21:50 UTC (permalink / raw)
  To: K.R. Foley; +Cc: Steven Rostedt, LKML


* K.R. Foley <kr@cybsft.com> wrote:

> >Looking into this, it is because the e100 uses a shared interrupt.  On
> >setup (see drivers/net/e100.c: e100_up) it disables the irq that it will
> >use, and then calls request_irq which calls setup_irq which zeros out
> >the depth of the irq if it is not shared.  So if the e100 is the first
> >to be loaded, then you get this message. 

> Actually I think it shouldn't call either enable or disable because it
> is shared (or allowed to be shared). After creating a patch myself to
> fix this I realized that it had already been fixed in the newest
> version of the driver on sourceforge. Anyway if you are interested in
> this fix temporarily, here it is.

i've included this in my tree, will drop it once -mm merges the
sourceforge e100 driver.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-18 16:46                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 Ingo Molnar
                                                                                     ` (3 preceding siblings ...)
  2004-11-20 20:23                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 K.R. Foley
@ 2004-11-22  0:54                                                                   ` Ingo Molnar
  2004-11-22  1:07                                                                     ` Florian Schmidt
                                                                                       ` (2 more replies)
  4 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22  0:54 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


i have released the -V0.7.30-2 Real-Time Preemption patch, which can be
downloaded from the usual place:

	http://redhat.com/~mingo/realtime-preempt/

the biggest change in this release are fixes for priority-inheritance
bugs uncovered by Esben Nielsen pi_test suite. These bugs could explain
some of the jackd-under-load latencies reported.

Changes since -V0.7.29-0:

 - priority inheritance handling fixes:

    - sort the RT wakees at wakeup time, not at block-time: an RT task
      might have gotten boosted while it slept.

    - fix priority-restoration bug at mutex-release time

    - use task_rt() not p->policy to determine whether a task needs 
      PI handling - a SCHED_OTHER task might be boosted to RT prio.

    - fix mutex_setprio() bug: queue now-RT tasks to the active array, 
      otherwise expired SCHED_OTHER tasks will not be properly boosted.

 - went back to the mask-and-delay method of handling hardirqs on 
   UP-IOAPIC as well. Due to APIC prioritization hardirqs can get
   delayed by another, unacked hardirq, so the quick method needs more 
   work before it can be used.

 - added Thomas Gleixner's semaphore -> completion changes for 
   drv->unload_sem. This fixes the module unload crashes reported by 
   Rui Nuno Capela and Shane Shrybman.

 - dvb mutex updates for RT, this fixes the bug reported by Christian 
   Meder.

 - e100 fix from K.R. Foley - this should fix the boot-time e100
   enable_irq warning.

 - NFS lockd mutex RT fixes from Thomas Gleixner - this could fix some
   of the bugs reported by Bill Huey.

 - PREEMPT_VOLUNTARY fixes - this could fix the boot-time hang reported 
   by Lee Revell.

 - wake up irq thread upon creation - this solves the 'irq thread only 
   changes priority after first interrupt arrives' anomaly reported.

to create a -V0.7.30-2 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm2/2.6.10-rc2-mm2.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm2-V0.7.30-2

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22  0:54                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2 Ingo Molnar
@ 2004-11-22  1:07                                                                     ` Florian Schmidt
  2004-11-22  9:46                                                                       ` Ingo Molnar
  2004-11-22  8:44                                                                     ` Eran Mann
  2004-11-23 17:58                                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-11-22  1:07 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

On Mon, 22 Nov 2004 01:54:11 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> i have released the -V0.7.30-2 Real-Time Preemption patch, which can be
> downloaded from the usual place:

> the biggest change in this release are fixes for priority-inheritance
> bugs uncovered by Esben Nielsen pi_test suite. These bugs could explain
> some of the jackd-under-load latencies reported.

It seems these large load related xruns are gone :) At least i wasn't able
to trigger any during my uptime of 52 min. Will report if i ever see  any of
those again.

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22  0:54                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2 Ingo Molnar
  2004-11-22  1:07                                                                     ` Florian Schmidt
@ 2004-11-22  8:44                                                                     ` Eran Mann
  2004-11-22 10:01                                                                       ` Ingo Molnar
  2004-11-23 17:58                                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Eran Mann @ 2004-11-22  8:44 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

Ingo Molnar wrote:
> i have released the -V0.7.30-2 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
> 	http://redhat.com/~mingo/realtime-preempt/

Hi,
I´m seeing latencies of up to ~2000 microseconds. see attached traces
file for a small sample. I think I´m missing something obvious
config-wise but I don´t know what...
The ´load´ during the traces consisted of a kernel build in a
gnome-terminal, and 2 browser windows with a heavy site (Flash ads etc.)
in each. This load causes a >1 ms latency every 5 minutes on average.
After the kernel build ended the rate dropped dramatically to ~2 traces
an hour.
The traces were from V-0.7.29-5 but I´ve seen these latencies in all RT
kernels I tested (2.6.9-mm1-RT-V0.2 was the first). I´ll try V0.7.30-2 next.
The machine is a PIII 733 Mhz, 256MB RAM, IDE disks.
I attached the traces and a partial .config.
Relevant items in /proc/sys/kernel:

/proc/sys/kernel/kernel_preemption :
1
...
/proc/sys/kernel/osrelease :
2.6.10-rc2-mm2-V0.7.29-5
...
/proc/sys/kernel/panic :
0
/proc/sys/kernel/panic_on_oops :
0
/proc/sys/kernel/pid_max :
32768
/proc/sys/kernel/preempt_max_latency :
1737
/proc/sys/kernel/preempt_thresh :
1000
/proc/sys/kernel/preempt_wakeup_timing :
1
...
/proc/sys/kernel/real-root-dev :
0
/proc/sys/kernel/sem :
250     32000   32      128
/proc/sys/kernel/shmall :
2097152
/proc/sys/kernel/shmmax :
33554432
/proc/sys/kernel/shmmni :
4096
/proc/sys/kernel/sysrq :
1
/proc/sys/kernel/tainted :
0
/proc/sys/kernel/threads-max :
4095
/proc/sys/kernel/trace_enabled :
1
/proc/sys/kernel/trace_freerunning :
0
/proc/sys/kernel/trace_print_at_crash :
1
/proc/sys/kernel/trace_user_triggered :
0
/proc/sys/kernel/trace_verbose :
0
/proc/sys/kernel/unknown_nmi_panic :
0

Let me know if some more information is required.
Thank,
      Eran Mann


[-- Attachment #2: config --]
[-- Type: text/plain, Size: 2988 bytes --]

# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
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_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_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=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_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=y
......
CONFIG_HW_RANDOM=m
CONFIG_NVRAM=m
CONFIG_RTC=m
CONFIG_RTC_HISTOGRAM=m
# 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
......
#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
CONFIG_WAKEUP_TIMING=y
CONFIG_CRITICAL_PREEMPT_TIMING=y
CONFIG_CRITICAL_IRQSOFF_TIMING=y
CONFIG_CRITICAL_TIMING=y
CONFIG_LATENCY_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
CONFIG_RT_DEADLOCK_DETECT=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
# CONFIG_KGDB is not set
.....
#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y


[-- Attachment #3: traces --]
[-- Type: text/plain, Size: 14074 bytes --]

Nov 21 19:22:42 eran kernel: (multiload-apple/5506/CPU#0): 1694 us wakeup latency violates 1000 us threshold.
preemption latency trace v1.0.7 on 2.6.10-rc2-mm2-V0.7.29-5
-------------------------------------------------------
 latency: 1694 us, entries: 21 (21)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: multiload-apple/5506, uid:500 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: try_to_wake_up+0x165/0x1d0 <c0117af5>
 => ended at:   finish_task_switch+0x4f/0xc0 <c0117fbf>
=======>
  131 88000006 0.000ms (+0.000ms): __trace_start_sched_wakeup (try_to_wake_up)
  131 88000005 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
  131 88000005 0.000ms (+0.000ms): (115) ((116))
  131 88000005 0.000ms (+0.000ms): (5506) ((131))
  131 88000005 0.001ms (+0.000ms): try_to_wake_up (wake_up_process)
  131 88000005 0.001ms (+0.000ms): (0) ((1))
  131 88000004 0.001ms (+0.000ms): preempt_schedule (try_to_wake_up)
  131 88000004 0.001ms (+0.000ms): wake_up_process (__up_mutex)
  131 88000003 0.002ms (+0.000ms): preempt_schedule (__up_mutex)
  131 88000002 0.002ms (+0.000ms): preempt_schedule (__up_mutex)
  131 08000001 0.002ms (+0.000ms): preempt_schedule (__schedule)
  131 08000001 0.002ms (+0.000ms): sched_clock (__schedule)
  131 88000002 0.003ms (+0.000ms): deactivate_task (__schedule)
  131 88000002 0.003ms (+1.687ms): dequeue_task (deactivate_task)
 5506 80000002 1.691ms (+0.001ms): __switch_to (__schedule)
 5506 80000002 1.692ms (+0.000ms): (131) ((5506))
 5506 80000002 1.693ms (+0.000ms): (116) ((115))
 5506 80000002 1.693ms (+0.000ms): finish_task_switch (__schedule)
 5506 80000001 1.693ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
 5506 80000001 1.693ms (+0.005ms): (5506) ((115))
 5506 80000001 1.699ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
==================
Nov 21 19:30:58 eran kernel: (firefox-bin/14054/CPU#0): 1991 us wakeup latency violates 1000 us threshold.
preemption latency trace v1.0.7 on 2.6.10-rc2-mm2-V0.7.29-5
-------------------------------------------------------
 latency: 1991 us, entries: 21 (21)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: firefox-bin/14054, uid:500 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: try_to_wake_up+0x165/0x1d0 <c0117af5>
 => ended at:   finish_task_switch+0x4f/0xc0 <c0117fbf>
=======>
  131 88000006 0.000ms (+0.000ms): __trace_start_sched_wakeup (try_to_wake_up)
  131 88000005 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
  131 88000005 0.000ms (+0.000ms): (115) ((116))
  131 88000005 0.000ms (+0.000ms): <000036e6> ((131))
  131 88000005 0.000ms (+0.000ms): try_to_wake_up (wake_up_process)
  131 88000005 0.001ms (+0.000ms): (0) ((1))
  131 88000004 0.001ms (+0.000ms): preempt_schedule (try_to_wake_up)
  131 88000004 0.001ms (+0.000ms): wake_up_process (__up_mutex)
  131 88000003 0.001ms (+0.000ms): preempt_schedule (__up_mutex)
  131 88000002 0.002ms (+0.000ms): preempt_schedule (__up_mutex)
  131 08000001 0.002ms (+0.000ms): preempt_schedule (__schedule)
  131 08000001 0.002ms (+0.000ms): sched_clock (__schedule)
  131 88000002 0.003ms (+0.000ms): deactivate_task (__schedule)
  131 88000002 0.003ms (+1.986ms): dequeue_task (deactivate_task)
14054 80000002 1.989ms (+0.000ms): __switch_to (__schedule)
14054 80000002 1.989ms (+0.000ms): (131) (<000036e6>)
14054 80000002 1.989ms (+0.000ms): (116) ((115))
14054 80000002 1.990ms (+0.000ms): finish_task_switch (__schedule)
14054 80000001 1.990ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
14054 80000001 1.990ms (+0.006ms): <000036e6> ((115))
14054 80000001 1.996ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
==================
Nov 21 19:31:44 eran kernel: (IRQ 0/2/CPU#0): 1213 us wakeup latency violates 1000 us threshold.
preemption latency trace v1.0.7 on 2.6.10-rc2-mm2-V0.7.29-5
-------------------------------------------------------
 latency: 1213 us, entries: 23 (23)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: IRQ 0/2, uid:0 nice:0 policy:1 rt_prio:49
    -----------------
 => started at: try_to_wake_up+0x165/0x1d0 <c0117af5>
 => ended at:   finish_task_switch+0x4f/0xc0 <c0117fbf>
=======>
    3 88010003 0.000ms (+0.000ms): __trace_start_sched_wakeup (try_to_wake_up)
    3 88010002 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
    3 88010002 0.000ms (+0.000ms): (50) ((105))
    3 88010002 0.000ms (+0.000ms): (2) ((3))
    3 88010002 0.000ms (+0.000ms): try_to_wake_up (wake_up_process)
    3 88010002 0.001ms (+0.000ms): (0) ((1))
    3 88010001 0.001ms (+0.000ms): preempt_schedule (try_to_wake_up)
    3 88010001 0.001ms (+0.000ms): wake_up_process (redirect_hardirq)
    3 88010000 0.001ms (+0.000ms): preempt_schedule (__do_IRQ)
    3 88010000 0.002ms (+0.000ms): irq_exit (do_IRQ)
    3 88000001 0.002ms (+0.000ms): do_softirq (irq_exit)
    3 88000001 0.002ms (+0.000ms): __do_softirq (do_softirq)
    3 88000000 0.002ms (+0.000ms): preempt_schedule_irq (need_resched)
    3 98000000 0.003ms (+0.000ms): __schedule (preempt_schedule_irq)
    3 98000000 0.003ms (+0.000ms): profile_hit (__schedule)
    3 98000001 0.003ms (+0.000ms): sched_clock (__schedule)
    2 80000002 0.004ms (+1.207ms): __switch_to (__schedule)
    2 80000002 1.212ms (+0.000ms): (3) ((2))
    2 80000002 1.212ms (+0.000ms): (105) ((50))
    2 80000002 1.212ms (+0.000ms): finish_task_switch (__schedule)
    2 80000001 1.212ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
    2 80000001 1.212ms (+0.006ms): (2) ((50))
    2 80000001 1.219ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
==================
Nov 21 19:36:18 eran kernel: (firefox-bin/14054/CPU#0): 1881 us wakeup latency violates 1000 us threshold.
preemption latency trace v1.0.7 on 2.6.10-rc2-mm2-V0.7.29-5
-------------------------------------------------------
 latency: 1881 us, entries: 21 (21)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: firefox-bin/14054, uid:500 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: try_to_wake_up+0x165/0x1d0 <c0117af5>
 => ended at:   finish_task_switch+0x4f/0xc0 <c0117fbf>
=======>
  131 88000006 0.000ms (+0.000ms): __trace_start_sched_wakeup (try_to_wake_up)
  131 88000005 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
  131 88000005 0.000ms (+0.000ms): (115) ((116))
  131 88000005 0.000ms (+0.000ms): <000036e6> ((131))
  131 88000005 0.001ms (+0.000ms): try_to_wake_up (wake_up_process)
  131 88000005 0.001ms (+0.000ms): (0) ((1))
  131 88000004 0.001ms (+0.000ms): preempt_schedule (try_to_wake_up)
  131 88000004 0.001ms (+0.000ms): wake_up_process (__up_mutex)
  131 88000003 0.002ms (+0.000ms): preempt_schedule (__up_mutex)
  131 88000002 0.002ms (+0.000ms): preempt_schedule (__up_mutex)
  131 08000001 0.002ms (+0.000ms): preempt_schedule (__schedule)
  131 08000001 0.002ms (+0.000ms): sched_clock (__schedule)
  131 88000002 0.003ms (+0.000ms): deactivate_task (__schedule)
  131 88000002 0.003ms (+1.875ms): dequeue_task (deactivate_task)
14054 80000002 1.878ms (+0.001ms): __switch_to (__schedule)
14054 80000002 1.880ms (+0.000ms): (131) (<000036e6>)
14054 80000002 1.880ms (+0.000ms): (116) ((115))
14054 80000002 1.880ms (+0.000ms): finish_task_switch (__schedule)
14054 80000001 1.880ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
14054 80000001 1.881ms (+0.008ms): <000036e6> ((115))
14054 80000001 1.890ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
==================
Nov 21 19:37:18 eran kernel: (firefox-bin/14054/CPU#0): 1347 us wakeup latency violates 1000 us threshold.
preemption latency trace v1.0.7 on 2.6.10-rc2-mm2-V0.7.29-5
-------------------------------------------------------
 latency: 1347 us, entries: 21 (21)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: firefox-bin/14054, uid:500 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: try_to_wake_up+0x165/0x1d0 <c0117af5>
 => ended at:   finish_task_switch+0x4f/0xc0 <c0117fbf>
=======>
  131 88000006 0.000ms (+0.000ms): __trace_start_sched_wakeup (try_to_wake_up)
  131 88000005 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
  131 88000005 0.000ms (+0.000ms): (115) ((116))
  131 88000005 0.000ms (+0.000ms): <000036e6> ((131))
  131 88000005 0.000ms (+0.000ms): try_to_wake_up (wake_up_process)
  131 88000005 0.001ms (+0.000ms): (0) ((1))
  131 88000004 0.001ms (+0.000ms): preempt_schedule (try_to_wake_up)
  131 88000004 0.001ms (+0.000ms): wake_up_process (__up_mutex)
  131 88000003 0.001ms (+0.000ms): preempt_schedule (__up_mutex)
  131 88000002 0.002ms (+0.000ms): preempt_schedule (__up_mutex)
  131 08000001 0.002ms (+0.000ms): preempt_schedule (__schedule)
  131 08000001 0.002ms (+0.000ms): sched_clock (__schedule)
  131 88000002 0.003ms (+0.000ms): deactivate_task (__schedule)
  131 88000002 0.003ms (+0.000ms): dequeue_task (deactivate_task)
14054 80000002 0.003ms (+0.000ms): __switch_to (__schedule)
14054 80000002 0.004ms (+0.000ms): (131) (<000036e6>)
14054 80000002 0.004ms (+0.000ms): (116) ((115))
14054 80000002 0.004ms (+0.000ms): finish_task_switch (__schedule)
14054 80000001 0.005ms (+1.342ms): trace_stop_sched_switched (finish_task_switch)
14054 80000001 1.347ms (+0.103ms): <000036e6> ((115))
14054 80000001 1.450ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
==================
Nov 21 19:49:21 eran kernel: (gnome-terminal/5434/CPU#0): 1683 us wakeup latency violates 1000 us threshold.
preemption latency trace v1.0.7 on 2.6.10-rc2-mm2-V0.7.29-5
-------------------------------------------------------
 latency: 1683 us, entries: 21 (21)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: gnome-terminal/5434, uid:500 nice:0 policy:0 rt_prio:0
    -----------------
 => started at: try_to_wake_up+0x165/0x1d0 <c0117af5>
 => ended at:   finish_task_switch+0x4f/0xc0 <c0117fbf>
=======>
  131 88000006 0.000ms (+0.000ms): __trace_start_sched_wakeup (try_to_wake_up)
  131 88000005 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
  131 88000005 0.000ms (+0.000ms): (115) ((116))
  131 88000005 0.001ms (+0.000ms): (5434) ((131))
  131 88000005 0.001ms (+0.000ms): try_to_wake_up (wake_up_process)
  131 88000005 0.001ms (+0.000ms): (0) ((1))
  131 88000004 0.001ms (+0.000ms): preempt_schedule (try_to_wake_up)
  131 88000004 0.001ms (+0.000ms): wake_up_process (__up_mutex)
  131 88000003 0.002ms (+0.000ms): preempt_schedule (__up_mutex)
  131 88000002 0.002ms (+0.000ms): preempt_schedule (__up_mutex)
  131 08000001 0.002ms (+0.000ms): preempt_schedule (__schedule)
  131 08000001 0.002ms (+0.000ms): sched_clock (__schedule)
  131 88000002 0.003ms (+0.000ms): deactivate_task (__schedule)
  131 88000002 0.003ms (+1.676ms): dequeue_task (deactivate_task)
 5434 80000002 1.680ms (+0.001ms): __switch_to (__schedule)
 5434 80000002 1.681ms (+0.000ms): (131) ((5434))
 5434 80000002 1.682ms (+0.000ms): (116) ((115))
 5434 80000002 1.682ms (+0.000ms): finish_task_switch (__schedule)
 5434 80000001 1.682ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
 5434 80000001 1.682ms (+0.006ms): (5434) ((115))
 5434 80000001 1.689ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
==================
Nov 21 19:52:18 eran kernel: (IRQ 0/2/CPU#0): 2009 us wakeup latency violates 1000 us threshold.
preemption latency trace v1.0.7 on 2.6.10-rc2-mm2-V0.7.29-5
-------------------------------------------------------
 latency: 2009 us, entries: 37 (37)   |   [VP:0 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: IRQ 0/2, uid:0 nice:0 policy:1 rt_prio:49
    -----------------
 => started at: try_to_wake_up+0x165/0x1d0 <c0117af5>
 => ended at:   finish_task_switch+0x4f/0xc0 <c0117fbf>
=======>
  783 88010003 0.000ms (+0.000ms): __trace_start_sched_wakeup (try_to_wake_up)
  783 88010002 0.000ms (+0.000ms): preempt_schedule (try_to_wake_up)
  783 88010002 0.000ms (+0.000ms): (50) ((54))
  783 88010002 0.000ms (+0.000ms): (2) ((783))
  783 88010002 0.000ms (+0.000ms): try_to_wake_up (wake_up_process)
  783 88010002 0.001ms (+0.000ms): (0) ((1))
  783 88010001 0.001ms (+0.000ms): preempt_schedule (try_to_wake_up)
  783 88010001 0.001ms (+0.000ms): wake_up_process (redirect_hardirq)
  783 88010000 0.001ms (+0.000ms): preempt_schedule (__do_IRQ)
  783 88010000 0.002ms (+0.000ms): irq_exit (do_IRQ)
  783 88000001 0.002ms (+0.000ms): do_softirq (irq_exit)
  783 88000001 0.002ms (+0.000ms): __do_softirq (do_softirq)
  783 88000001 0.003ms (+0.000ms): wake_up_process (do_softirq)
  783 88000001 0.003ms (+0.000ms): try_to_wake_up (wake_up_process)
  783 88000001 0.003ms (+0.000ms): task_rq_lock (try_to_wake_up)
  783 88000002 0.003ms (+0.000ms): activate_task (try_to_wake_up)
  783 88000002 0.004ms (+0.000ms): sched_clock (activate_task)
  783 88000002 0.004ms (+0.000ms): recalc_task_prio (activate_task)
  783 88000002 0.004ms (+0.000ms): effective_prio (recalc_task_prio)
  783 88000002 0.004ms (+0.000ms): enqueue_task (activate_task)
  783 88000002 0.005ms (+0.000ms): (105) ((54))
  783 88000002 0.005ms (+0.000ms): (3) ((783))
  783 88000002 0.005ms (+0.000ms): try_to_wake_up (wake_up_process)
  783 88000002 0.006ms (+1.999ms): (0) ((1))
  783 88000001 2.005ms (+0.000ms): preempt_schedule (try_to_wake_up)
  783 88000001 2.005ms (+0.000ms): wake_up_process (do_softirq)
  783 88000000 2.006ms (+0.000ms): preempt_schedule_irq (need_resched)
  783 98000000 2.006ms (+0.000ms): __schedule (preempt_schedule_irq)
  783 98000000 2.006ms (+0.000ms): profile_hit (__schedule)
  783 98000001 2.007ms (+0.000ms): sched_clock (__schedule)
    2 80000002 2.007ms (+0.000ms): __switch_to (__schedule)
    2 80000002 2.008ms (+0.000ms): (783) ((2))
    2 80000002 2.008ms (+0.000ms): (54) ((50))
    2 80000002 2.008ms (+0.000ms): finish_task_switch (__schedule)
    2 80000001 2.008ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)
    2 80000001 2.009ms (+0.006ms): (2) ((50))
    2 80000001 2.015ms (+0.000ms): trace_stop_sched_switched (finish_task_switch)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-19  9:54                                                                       ` Ingo Molnar
@ 2004-11-22  9:31                                                                         ` Christian Meder
  2004-11-22  9:44                                                                           ` Bill Huey
  2004-11-22 13:05                                                                           ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Christian Meder @ 2004-11-22  9:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Fri, 2004-11-19 at 10:54 +0100, Ingo Molnar wrote: 
> * Christian Meder <chris@onestepahead.de> wrote:
> 
> > This just leaves me with the mysterious traceless jvm related crash.
> > I'll do my best to get a trace ;-)
> 
> it would be equally useful to somehow reproduce the lockup with public
> software only, and post the precise steps how to reproduce it.

Hi Ingo,

after two evenings of experimenting this is the current status
(everything based on 0.7.29-0, will try 0.7.30-x during the day):

* the lockup can't be triggered from the console or using a remote
session and I really tried to torture the box ;-)
* the real trigger is mouse activity in X
* the other important factor is running the jvm in profiling mode,
running without jvm or with the jvm in non-profiling mode leaves the box
stable
* I couldn't yet figure out the pattern of java program which is
triggering. Not every java program is triggering but at least I found
several public available ones. I wrote some small test programs doing
simple multithreading but they didn't trigger.

So the simplest setup I found til now is the following: 

chris@blue:~$ java -version
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.1-01)
Java HotSpot(TM) Client VM (build Blackdown-1.4.1-01, mixed mode)
chris@blue:~$ JAVA_OPTIONS=-Xrunhprof:cpu=samples,file=crap.log,depth=3 jython 
Jython 2.1 on java1.4.1 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>>

Now moving the mouse around in X will make the box lockup in less than
10 seconds.

I'm not sure if JAVA_OPTIONS is a standard jython feature but at least
it's part of the jython-wrapper script of Debian.



				Christian

-- 
Christian Meder, email: chris@onestepahead.de

The Way-Seeking Mind of a tenzo is actualized 
by rolling up your sleeves.

                (Eihei Dogen Zenji)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-22  9:31                                                                         ` Christian Meder
@ 2004-11-22  9:44                                                                           ` Bill Huey
  2004-11-22 13:19                                                                             ` Ingo Molnar
  2004-11-22 13:05                                                                           ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Bill Huey @ 2004-11-22  9:44 UTC (permalink / raw)
  To: Christian Meder
  Cc: Ingo Molnar, Rui Nuno Capela, linux-kernel, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah

On Mon, Nov 22, 2004 at 10:31:00AM +0100, Christian Meder wrote:
> Hi Ingo,
> 
> after two evenings of experimenting this is the current status
> (everything based on 0.7.29-0, will try 0.7.30-x during the day):
> 
> * the lockup can't be triggered from the console or using a remote
> session and I really tried to torture the box ;-)
> * the real trigger is mouse activity in X
> * the other important factor is running the jvm in profiling mode,
> running without jvm or with the jvm in non-profiling mode leaves the box
> stable
> * I couldn't yet figure out the pattern of java program which is
> triggering. Not every java program is triggering but at least I found
> several public available ones. I wrote some small test programs doing
> simple multithreading but they didn't trigger.
> 
> So the simplest setup I found til now is the following: 
> 
> chris@blue:~$ java -version
> java version "1.4.1"
> Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.1-01)
> Java HotSpot(TM) Client VM (build Blackdown-1.4.1-01, mixed mode)
> chris@blue:~$ JAVA_OPTIONS=-Xrunhprof:cpu=samples,file=crap.log,depth=3 jython 
> Jython 2.1 on java1.4.1 (JIT: null)
> Type "copyright", "credits" or "license" for more information.
> >>>
> 
> Now moving the mouse around in X will make the box lockup in less than
> 10 seconds.

HotSpot is pretty heavy on VM faulting as well as signal handling, SIGUSR1,
during per thread GC safepointing operations to get the current thread
ucontext for GC traversal roots. Debugging the HotSpot VM is nearly impossible
without heavy unit testing and even that isn't going to push through that
almost pure voodoo code easily. I'm a former HotSpot tweeker for the BSDs so
I know a thing or two about that particular VM.

Try a small Java app to see if this triggers the same lock ups. Are you 
pushing it using Swing ?

I'd try pushing an incremental load on it, maybe some rapid object creation
and destruction with increasing number of threads.

Also, CC the Sun/Blackdown folks about this. It could very well be some
kind of NPTL glue problem triggering.

bill


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22  1:07                                                                     ` Florian Schmidt
@ 2004-11-22  9:46                                                                       ` Ingo Molnar
  2004-11-22 10:36                                                                         ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22  9:46 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> On Mon, 22 Nov 2004 01:54:11 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > i have released the -V0.7.30-2 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> 
> > the biggest change in this release are fixes for priority-inheritance
> > bugs uncovered by Esben Nielsen pi_test suite. These bugs could explain
> > some of the jackd-under-load latencies reported.
> 
> It seems these large load related xruns are gone :) At least i wasn't
> able to trigger any during my uptime of 52 min. Will report if i ever
> see any of those again.

great. I now suspect that some of the xrun problems Rui was observing on
-RT kernel could be (positively) affected by these fixes too.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22  8:44                                                                     ` Eran Mann
@ 2004-11-22 10:01                                                                       ` Ingo Molnar
  2004-11-22 13:34                                                                         ` Eran Mann
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22 10:01 UTC (permalink / raw)
  To: Eran Mann; +Cc: linux-kernel


* Eran Mann <emann@mrv.com> wrote:

> Ingo Molnar wrote:
> >i have released the -V0.7.30-2 Real-Time Preemption patch, which can be
> >downloaded from the usual place:
> >
> >	http://redhat.com/~mingo/realtime-preempt/
> 
> Hi,
> I´m seeing latencies of up to ~2000 microseconds. see attached traces
> file for a small sample. I think I´m missing something obvious
> config-wise but I don´t know what...

  131 88000002 0.003ms (+0.000ms): deactivate_task (__schedule)
  131 88000002 0.003ms (+1.687ms): dequeue_task (deactivate_task)
 5506 80000002 1.691ms (+0.001ms): __switch_to (__schedule)

this seems to be hardware-generated. As you can see it from the trace,
the codepath between __schedule()'s deactive_task() and __switch_to()
has all interrupts and preemption disabled. The O(1) scheduler there has
constant overhead and that codepath should at most take ~1 usec.

(there is one exception, if both LATENCY_TRACING and RT_DEADLOCK_DETECT
are enabled in -V0.7.30-2 and later kernels then the overhead within
__schedule is O(nr_running), because the tracer adds entries for every
runnable task. But this is not the case for your trace because then
you'd see those entries in /proc/latency_trace.)

> The ´load´ during the traces consisted of a kernel build in a
> gnome-terminal, and 2 browser windows with a heavy site (Flash ads
> etc.) in each. This load causes a >1 ms latency every 5 minutes on
> average. After the kernel build ended the rate dropped dramatically to
> ~2 traces an hour.

this seems to imply IDE DMA related hardware overhead. Apparently what
happens is that with certain motherboards/chipsets, if IDE DMA happens
then that DMA transfer _completely locks up_ the system bus. Nothing 
happens, and the CPU is stalled in essence until the end of the DMA 
request.

there's nothing the kernel can do about a hardware latency like that,
but you can try to work it around. Mark H. Johnson has reported up to
500 usec latencies that had a similar pattern as yours, and he has
experimented with lesser DMA modes (udma2?) via hdparm. YMMV and be
careful with hdparm settings.

> The traces were from V-0.7.29-5 but I´ve seen these latencies in all
> RT kernels I tested (2.6.9-mm1-RT-V0.2 was the first). I´ll try
> V0.7.30-2 next. The machine is a PIII 733 Mhz, 256MB RAM, IDE disks.

this very strongly implies some sort of hardware overhead. Btw., the
likely reason why this often shows up within __schedule() is that 1)
it's a very common operation, especially on the -RT kernel 2) we do a
TLB flush there, which can be quite memory-intense, so if the system bus
(the memory bus) is locked up, there is a high likelyhood that this
function generates a cachemiss.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22  9:46                                                                       ` Ingo Molnar
@ 2004-11-22 10:36                                                                         ` Rui Nuno Capela
  2004-11-22 13:24                                                                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-22 10:36 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

Ingo Molnar wrote:
>
> * Florian Schmidt wrote:
>
>>
>> > i have released the -V0.7.30-2 Real-Time Preemption patch, which can
>> > be downloaded from the usual place:
>>
>> > the biggest change in this release are fixes for priority-inheritance
>> > bugs uncovered by Esben Nielsen pi_test suite. These bugs could
>> > explain some of the jackd-under-load latencies reported.
>>
>> It seems these large load related xruns are gone :) At least i wasn't
>> able to trigger any during my uptime of 52 min. Will report if i ever
>> see any of those again.
>
> great. I now suspect that some of the xrun problems Rui was observing on
> -RT kernel could be (positively) affected by these fixes too.
>

Just made some test-runs with RT-V0.7.30-2, with my jackd-R + 8*fluidsynth
benchmark on my laptop (P4/UP), and the results don't seem to be eligible
to the hall of fame, at least when compared with RT-0.7.7 as the ones I
last posted here a few weeks ago.

I hate to say this, but the XRUN rate has increased since RT-0.7.7, and
the maximum scheduling delay reported by jackd has also degraded to 1000
usecs (was around 600 usecs).

Please note that this is not unique to latest RT-V0.7.30-2, but also
applies to each one of the previous iterations I've been testing, only not
reported until now. Again, all test conditions were kept the same
(hardware, jackd, alsa), only the kernel has changed (obviously).


OTOH, there's another thing: I don't seem to be able to build an initrd
image under the latest RT kernels. Something related to the loopback
device. When trying to run mkinitrd it stalls, somewhere under this
process:

  mount -t ext2 /root/tmp/initrd.img /root/tmp/initrd.mnt -o loop

This happens on my laptop (P4/UP, Mandrake 10.1c) but not on my desktop
(P4/SMT, SUSE 9.2pro). Speaking of which, the lockups experienced while
unloading the ALSA modules seems to be over, at least as far as I could
try with RT-V0.7.29-4 (probably not enough yet).

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 13:24                                                                           ` Ingo Molnar
@ 2004-11-22 12:56                                                                             ` Rui Nuno Capela
  2004-11-22 15:00                                                                               ` Ingo Molnar
  2004-11-22 13:27                                                                             ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-22 12:56 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

Ingo Molnar wrote:
>
> Rui Nuno Capela wrote:
>
>> > great. I now suspect that some of the xrun problems Rui was observing
>> > on -RT kernel could be (positively) affected by these fixes too.
>> >
>>
>> Just made some test-runs with RT-V0.7.30-2, with my jackd-R +
>> 8*fluidsynth benchmark on my laptop (P4/UP), and the results don't
>> seem to be eligible to the hall of fame, at least when compared with
>> RT-0.7.7 as the ones I last posted here a few weeks ago.
>>
>> I hate to say this, but the XRUN rate has increased since RT-0.7.7,
>> and the maximum scheduling delay reported by jackd has also degraded
>> to 1000 usecs (was around 600 usecs).
>
> well, life would be too easy if two bugs were fixed at once ;) These
> were nodebug runs, right? Could you give me a description of the precise
> commands of how you started jackd and fluidsyth (and their versions) -
> so that i could try to reproduce & debug your setup. It is certainly a
> complex scheduling scenario.
>
> (perhaps with a link to the .sf2 and .mid files you used, if they are
> public - or whether it's fine if i use the VintageDreamsWaves-v2.sf2
> sound-fonts that comes with fluidsynth plus a random .mid file from the
> net?)
>

These are the command-lines of my test suite:

  jackd -R -dalsa -dhw:0 -P20 -r44100 -p64 -n2 -S -P &
  fluidsynth -s -i -a jack -j -o jack.audio.id=fluid1 -o shell.port=9800
ct4mgm.sf2 &
  fluidsynth -s -i -a jack -j -o jack.audio.id=fluid2 -o shell.port=9801
ct4mgm.sf2 &
  .
  .
  .
  fluidsynth -s -i -a jack -j -o jack.audio.id=fluid8 -o shell.port=9807
ct4mgm.sf2 &


Versions are:

  jack 0.99.10cvs
  fluidsynth 1.0.5


>> OTOH, there's another thing: I don't seem to be able to build an
>> initrd image under the latest RT kernels. Something related to the
>> loopback device. When trying to run mkinitrd it stalls, somewhere
>> under this process:
>>
>>   mount -t ext2 /root/tmp/initrd.img /root/tmp/initrd.mnt -o loop
>
> Do you know when this started, roughly?
>

Not sure, but the first time I've noticed it was on RT-0.7.29-2 and that
was purely by chance. Problem is that I've been building the RT kernels
under a non-RT stock kernel, so I can't say how long or when it all
started exactly. I remember however that this is a revisited issue,
thought.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-22  9:31                                                                         ` Christian Meder
  2004-11-22  9:44                                                                           ` Bill Huey
@ 2004-11-22 13:05                                                                           ` Ingo Molnar
  2004-11-22 13:32                                                                             ` Christian Meder
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22 13:05 UTC (permalink / raw)
  To: Christian Meder
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Christian Meder <chris@onestepahead.de> wrote:

> * the other important factor is running the jvm in profiling mode,
> running without jvm or with the jvm in non-profiling mode leaves the
> box stable

ah ... CPU profiling i suspect needs SIGPROF, and that is one of the
things that i had to disable in -RT. But it seems this disabling wasnt
fully correct - could you try the patch i attached, does it change the
symptoms?

> So the simplest setup I found til now is the following: 
> 
> chris@blue:~$ java -version
> java version "1.4.1"
> Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.1-01)
> Java HotSpot(TM) Client VM (build Blackdown-1.4.1-01, mixed mode)
> chris@blue:~$ JAVA_OPTIONS=-Xrunhprof:cpu=samples,file=crap.log,depth=3 jython 
> Jython 2.1 on java1.4.1 (JIT: null)
> Type "copyright", "credits" or "license" for more information.
> >>>
> 
> Now moving the mouse around in X will make the box lockup in less than
> 10 seconds.
> 
> I'm not sure if JAVA_OPTIONS is a standard jython feature but at least
> it's part of the jython-wrapper script of Debian.

on a FC3 box this gives me:

 saturn:~> JAVA_OPTIONS=-Xrunhprof:cpu=samples,file=crap.log,depth=3 jython
 Exception in thread "main" java.lang.NoClassDefFoundError: error:

(i'm getting the same message when purely running 'jython')

i've got:

 saturn:~> java -version
 java version "1.4.2_03"
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
 Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

is my java setup botched perhaps?

	Ingo

--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -2354,12 +2354,12 @@ static inline void account_it_virt(struc
 
 	if (cputime_gt(it_virt, cputime_zero) &&
 	    cputime_gt(cputime, cputime_zero)) {
-#if 0
 		if (cputime_ge(cputime, it_virt)) {
 			it_virt = cputime_add(it_virt, p->it_virt_incr);
+#if 0
 			send_sig(SIGVTALRM, p, 1);
-		}
 #endif
+		}
 		it_virt = cputime_sub(it_virt, cputime);
 		p->it_virt_value = it_virt;
 	}
@@ -2376,12 +2376,12 @@ static void account_it_prof(struct task_
 
 	if (cputime_gt(it_prof, cputime_zero) &&
 	    cputime_gt(cputime, cputime_zero)) {
-#if 0
 		if (cputime_ge(cputime, it_prof)) {
 			it_prof = cputime_add(it_prof, p->it_prof_incr);
+#if 0
 			send_sig(SIGPROF, p, 1);
-		}
 #endif
+		}
 		it_prof = cputime_sub(it_prof, cputime);
 		p->it_prof_value = it_prof;
 	}
@@ -2395,7 +2395,6 @@ static void account_it_prof(struct task_
  */
 static void check_rlimit(struct task_struct *p, cputime_t cputime)
 {
-#if 0
 	cputime_t total, tmp;
 
 	total = cputime_add(p->utime, p->stime);
@@ -2403,14 +2402,19 @@ static void check_rlimit(struct task_str
 	if (unlikely(cputime_gt(total, tmp))) {
 		/* Send SIGXCPU every second. */
 		tmp = cputime_sub(total, cputime);
-		if (cputime_to_secs(tmp) < cputime_to_secs(total))
+		if (cputime_to_secs(tmp) < cputime_to_secs(total)) {
+#if 0
 			send_sig(SIGXCPU, p, 1);
+#endif
+		}
 		/* and SIGKILL when we go over max.. */
 		tmp = jiffies_to_cputime(p->signal->rlim[RLIMIT_CPU].rlim_max);
-		if (cputime_gt(total, tmp))
+		if (cputime_gt(total, tmp)) {
+#if 0
 			send_sig(SIGKILL, p, 1);
-	}
 #endif
+		}
+	}
 }
 
 /*

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-22  9:44                                                                           ` Bill Huey
@ 2004-11-22 13:19                                                                             ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22 13:19 UTC (permalink / raw)
  To: Bill Huey
  Cc: Christian Meder, Rui Nuno Capela, linux-kernel, Lee Revell,
	mark_h_johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Bill Huey <bhuey@lnxw.com> wrote:

> Also, CC the Sun/Blackdown folks about this. It could very well be
> some kind of NPTL glue problem triggering.

i'd suggest to not yet bother any upstream folks at this point, this
could easily be an -RT related bug. Hard kernel lockups are almost
always -RT's fault.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 10:36                                                                         ` Rui Nuno Capela
@ 2004-11-22 13:24                                                                           ` Ingo Molnar
  2004-11-22 12:56                                                                             ` Rui Nuno Capela
  2004-11-22 13:27                                                                             ` Florian Schmidt
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22 13:24 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> > great. I now suspect that some of the xrun problems Rui was observing on
> > -RT kernel could be (positively) affected by these fixes too.
> >
> 
> Just made some test-runs with RT-V0.7.30-2, with my jackd-R +
> 8*fluidsynth benchmark on my laptop (P4/UP), and the results don't
> seem to be eligible to the hall of fame, at least when compared with
> RT-0.7.7 as the ones I last posted here a few weeks ago.
> 
> I hate to say this, but the XRUN rate has increased since RT-0.7.7,
> and the maximum scheduling delay reported by jackd has also degraded
> to 1000 usecs (was around 600 usecs).

well, life would be too easy if two bugs were fixed at once ;) These
were nodebug runs, right? Could you give me a description of the precise
commands of how you started jackd and fluidsyth (and their versions) -
so that i could try to reproduce & debug your setup. It is certainly a
complex scheduling scenario.

(perhaps with a link to the .sf2 and .mid files you used, if they are
public - or whether it's fine if i use the VintageDreamsWaves-v2.sf2
sound-fonts that comes with fluidsynth plus a random .mid file from the
net?)

> OTOH, there's another thing: I don't seem to be able to build an
> initrd image under the latest RT kernels. Something related to the
> loopback device. When trying to run mkinitrd it stalls, somewhere
> under this process:
> 
>   mount -t ext2 /root/tmp/initrd.img /root/tmp/initrd.mnt -o loop

Do you know when this started, roughly?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 13:24                                                                           ` Ingo Molnar
  2004-11-22 12:56                                                                             ` Rui Nuno Capela
@ 2004-11-22 13:27                                                                             ` Florian Schmidt
  2004-11-22 14:18                                                                               ` Rui Nuno Capela
  1 sibling, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-11-22 13:27 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]

On Mon, 22 Nov 2004 14:24:59 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> > Just made some test-runs with RT-V0.7.30-2, with my jackd-R +
> > 8*fluidsynth benchmark on my laptop (P4/UP), and the results don't
> > seem to be eligible to the hall of fame, at least when compared with
> > RT-0.7.7 as the ones I last posted here a few weeks ago.
> > 
> > I hate to say this, but the XRUN rate has increased since RT-0.7.7,
> > and the maximum scheduling delay reported by jackd has also degraded
> > to 1000 usecs (was around 600 usecs).
> 
> well, life would be too easy if two bugs were fixed at once ;) 

Hi,

i just wanted to mention that a good share of jack clients have issues themself, doing all kinds of funky stuff in the RT thread which they shouldn't do. Maybe the RP kernel just exposes this misuse in a greater visible way. I don't know if fluidsynth is one of them. We could only find out by code inspection. 

Another way to test a more complex scenario than just jackd running with an empty graph (assuming that jackd itself isn't to blame) while avoiding the risk of getting bad data due to insane clients would be to code up an example jackd client that does nothing but putting some load onto the jackd graph but in a strictly RT fashion (no blocking stuff whatsoever).

Attached you probably find the most minimal jack client thinkable that does nothing but copy data from its input to its output port. Its only parameter is the time in seconds it will run (default 60). The jack client name is determined by the PID, so it can be started multiple times (jackd requires a unique name for each client).

compile with

g++ -o jack_test jack_test.cc -ljack

This code can easily be adapted to produce more load (just do some math stuff with the data in the process callback).

It seems jackd has a limitation to 14 clients atm (don't ask me why). The 15th kills jackd ;)

Also i wanted to mention that a good share of ALSA drivers have issues, too, and aren't nessecarily suited to low latency audio work. I don't know how to rule these out except for using the ALSA dummy soundcard driver (which might have its own issues, but it's probably simple enough to work reliable. it just doesn't use any hw IRQ's so it's maybe not a good measure for what we want to test) or to use a soundcard with a proven good driver. 

flo

[-- Attachment #2: jack_test.cc --]
[-- Type: text/x-c++src, Size: 1647 bytes --]

#include <jack/jack.h>
#include <iostream>
#include <sstream>
#include <unistd.h>

jack_client_t *client;
jack_port_t *iport;
jack_port_t *oport;

int process(jack_nframes_t frames, void *arg) {
	// std::cout << "process callback" << std::endl;
	jack_default_audio_sample_t *ibuf;
	ibuf = (jack_default_audio_sample_t*)jack_port_get_buffer(iport, frames);

	jack_default_audio_sample_t *obuf;
	obuf = (jack_default_audio_sample_t*)jack_port_get_buffer(oport, frames);

	for (jack_nframes_t frame = 0; frame < frames; frame++) {
		obuf[frame] = ibuf[frame];
	}
        return 1;
}

int main(int argc, char *argv[]) {
	// default = 60 seconds
	unsigned int seconds_to_run = 60;
	if (argc > 1) {
		std::stringstream sec_stream;
		sec_stream << argv[1];
		sec_stream >> seconds_to_run;
	}
	std::cout << "seconds to run: " << seconds_to_run << std::endl;
	
	std::stringstream pid_stream;
	pid_stream << getpid();
	
        std::cout << "client_new" << std::endl;
        client = jack_client_new(pid_stream.str().c_str());

        std::cout << "port_register." << std::endl;
        iport = jack_port_register(client, "in", JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput|JackPortIsTerminal, 0);
	oport = jack_port_register(client, "out", JACK_DEFAULT_AUDIO_TYPE, JackPortIsTerminal|JackPortIsOutput, 0);

        std::cout << "set_process_callback" << std::endl;
        jack_set_process_callback(client, process, 0);

        std::cout << "activate" << std::endl;
        jack_activate(client);

        std::cout << "running" << std::endl;

        // while(1) {sleep(1);};
	sleep(seconds_to_run);

	jack_deactivate(client);
	jack_client_close(client);
}

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-22 13:05                                                                           ` Ingo Molnar
@ 2004-11-22 13:32                                                                             ` Christian Meder
  2004-11-22 14:38                                                                               ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Christian Meder @ 2004-11-22 13:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Mon, 2004-11-22 at 14:05 +0100, Ingo Molnar wrote:
> * Christian Meder <chris@onestepahead.de> wrote:
> 
> > * the other important factor is running the jvm in profiling mode,
> > running without jvm or with the jvm in non-profiling mode leaves the
> > box stable
> 
> ah ... CPU profiling i suspect needs SIGPROF, and that is one of the
> things that i had to disable in -RT. But it seems this disabling wasnt
> fully correct - could you try the patch i attached, does it change the
> symptoms?

I tried it on top of 0.7.29-0 and it seemed to survive a little bit
longer but it doesn't change fundamentally i.e. I've got to wiggle the
mouse for maybe 20 seconds instead of 10 before the kernel locks up.

> 
> > So the simplest setup I found til now is the following: 
> > 
> > chris@blue:~$ java -version
> > java version "1.4.1"
> > Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.1-01)
> > Java HotSpot(TM) Client VM (build Blackdown-1.4.1-01, mixed mode)
> > chris@blue:~$ JAVA_OPTIONS=-Xrunhprof:cpu=samples,file=crap.log,depth=3 jython 
> > Jython 2.1 on java1.4.1 (JIT: null)
> > Type "copyright", "credits" or "license" for more information.
> > >>>
> > 
> > Now moving the mouse around in X will make the box lockup in less than
> > 10 seconds.
> > 
> > I'm not sure if JAVA_OPTIONS is a standard jython feature but at least
> > it's part of the jython-wrapper script of Debian.
> 
> on a FC3 box this gives me:
> 
>  saturn:~> JAVA_OPTIONS=-Xrunhprof:cpu=samples,file=crap.log,depth=3 jython
>  Exception in thread "main" java.lang.NoClassDefFoundError: error:
> 
> (i'm getting the same message when purely running 'jython')
> 
> i've got:
> 
>  saturn:~> java -version
>  java version "1.4.2_03"
>  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
>  Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)
> 
> is my java setup botched perhaps?

I'd rather guess your jython setup is botched. I'm sending you offlist
another simple test case which just involves a simple start of the Jetty
servlet container.


				Christian

-- 
Christian Meder, email: chris@onestepahead.de

The Way-Seeking Mind of a tenzo is actualized 
by rolling up your sleeves.

                (Eihei Dogen Zenji)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 10:01                                                                       ` Ingo Molnar
@ 2004-11-22 13:34                                                                         ` Eran Mann
  2004-11-22 14:42                                                                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Eran Mann @ 2004-11-22 13:34 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Ingo Molnar wrote:
> * Eran Mann <emann@mrv.com> wrote:
>>
>>Hi,
>>I´m seeing latencies of up to ~2000 microseconds. see attached traces
>>file for a small sample. I think I´m missing something obvious
>>config-wise but I don´t know what...
...

> this seems to imply IDE DMA related hardware overhead. Apparently what
> happens is that with certain motherboards/chipsets, if IDE DMA happens
> then that DMA transfer _completely locks up_ the system bus. Nothing 
> happens, and the CPU is stalled in essence until the end of the DMA 
> request.
> 
....
> 	Ingo

Right on.
After hdparm -d0 I see maximum latency of 35 us after a full kernel 
build with a few GUI apps in the background. I´ll try to find a 
reasonable compromise.
-- 
Eran Mann

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 13:27                                                                             ` Florian Schmidt
@ 2004-11-22 14:18                                                                               ` Rui Nuno Capela
  2004-11-22 15:41                                                                                 ` Ingo Molnar
  2004-11-22 15:45                                                                                 ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-22 14:18 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

Florian Schmidt wrote:

> Ingo Molnar wrote:
>
>> > Just made some test-runs with RT-V0.7.30-2, with my jackd-R +
>> > 8*fluidsynth benchmark on my laptop (P4/UP), and the results don't
>> > seem to be eligible to the hall of fame, at least when compared with
>> > RT-0.7.7 as the ones I last posted here a few weeks ago.
>> >
>> > I hate to say this, but the XRUN rate has increased since RT-0.7.7,
>> > and the maximum scheduling delay reported by jackd has also degraded
>> > to 1000 usecs (was around 600 usecs).
>>
>> well, life would be too easy if two bugs were fixed at once ;)
>
> Hi,
>
> i just wanted to mention that a good share of jack clients have issues
> themself, doing all kinds of funky stuff in the RT thread which they
> shouldn't do. Maybe the RP kernel just exposes this misuse in a greater
> visible way. I don't know if fluidsynth is one of them. We could only find
> out by code inspection.
>

Yes, I know all this, and I warned before that this tests were strictly
and specific to the hardware, jackd and fludisynth code which are
intentionally kept the same along the several RT kernels that have been
issued.

Note that I've kept this consistency to my self, and applies /only/ to my
laptop, where the tests are being evaluated. Again, this test-suite of
mine has the sole intention to compare the jackd workload performance
across kernels, in an almost real softsynth scenario. All kernels tested
are built with no debug options, ressembling production ones as far as
possible.

For example, these are the results-du-jour, which serves as a straight
comparison RT-V0.7.30-2, with the previous posted ones from RT-V0.7.7:

                                  RT-V0.7.7 RT-V0.7.30-2
                                  --------- ------------
  XRUN Rate . . . . . . . . . . :     45.6        292.0  /hour
  Delay Rate (>spare time)  . . :     43.2        265.3  /hour
  Delay Rate (>1000 usecs)  . . :      3.6         29.3  /hour
  Delay Maximum . . . . . . . . :   1249         1045    usecs
  Cycle Maximum . . . . . . . . :    946         1127    usecs
  Average DSP Load. . . . . . . :     55.2         60.1  %
  Average CPU System Load . . . :     13.2         15.5  %
  Average CPU User Load . . . . :     41.9         46.2  %
  Average CPU Nice Load . . . . :      0.0          0.0  %
  Average CPU I/O Wait Load . . :      0.1          0.1  %
  Average CPU IRQ Load  . . . . :      0.0          0.0  %
  Average CPU Soft-IRQ Load . . :      0.0          0.0  %
  Average Interrupt Rate  . . . :   1675.4       1673.8  /sec
  Average Context-Switch Rate . :  13940.9      14894.7  /sec

The only thing that has changed here was the kernel image, as everything
else has remained constant.


> Another way to test a more complex scenario than just jackd running with
> an empty graph (assuming that jackd itself isn't to blame) while avoiding
> the risk of getting bad data due to insane clients would be to code up an
> example jackd client that does nothing but putting some load onto the
> jackd graph but in a strictly RT fashion (no blocking stuff whatsoever).
>
> Attached you probably find the most minimal jack client thinkable that
> does nothing but copy data from its input to its output port. Its only
> parameter is the time in seconds it will run (default 60). The jack client
> name is determined by the PID, so it can be started multiple times (jackd
> requires a unique name for each client).
>
> compile with
>
> g++ -o jack_test jack_test.cc -ljack
>
> This code can easily be adapted to produce more load (just do some math
> stuff with the data in the process callback).
>
> It seems jackd has a limitation to 14 clients atm (don't ask me why). The
> 15th kills jackd ;)
>

So true.

> Also i wanted to mention that a good share of ALSA drivers have issues,
> too, and aren't nessecarily suited to low latency audio work. I don't know
> how to rule these out except for using the ALSA dummy soundcard driver
> (which might have its own issues, but it's probably simple enough to work
> reliable. it just doesn't use any hw IRQ's so it's maybe not a good
> measure for what we want to test) or to use a soundcard with a proven good
> driver.
>

Of course, and the "reference" driver used on my tests is no exception
(snd-ali5451). But again, it's been kept the same on all tests, and the
improvement along the progression of the RT kernel development has been
outstanding nevertheless.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1
  2004-11-22 13:32                                                                             ` Christian Meder
@ 2004-11-22 14:38                                                                               ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22 14:38 UTC (permalink / raw)
  To: Christian Meder
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Christian Meder <chris@onestepahead.de> wrote:

> On Mon, 2004-11-22 at 14:05 +0100, Ingo Molnar wrote:
> > * Christian Meder <chris@onestepahead.de> wrote:
> > 
> > > * the other important factor is running the jvm in profiling mode,
> > > running without jvm or with the jvm in non-profiling mode leaves the
> > > box stable
> > 
> > ah ... CPU profiling i suspect needs SIGPROF, and that is one of the
> > things that i had to disable in -RT. But it seems this disabling wasnt
> > fully correct - could you try the patch i attached, does it change the
> > symptoms?
> 
> I tried it on top of 0.7.29-0 and it seemed to survive a little bit
> longer but it doesn't change fundamentally i.e. I've got to wiggle the
> mouse for maybe 20 seconds instead of 10 before the kernel locks up.

do you have serial logging (or working netdump) from that box? If yes
then you could try the debug_direct_keyboard switch still, and when the
lockup happens, do SysRq-P a number of times, and then do a SysRq-D and
a SysRq-T and send me any log output that this might produce.

> > is my java setup botched perhaps?
> 
> I'd rather guess your jython setup is botched. I'm sending you offlist
> another simple test case which just involves a simple start of the
> Jetty servlet container.

ok.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 13:34                                                                         ` Eran Mann
@ 2004-11-22 14:42                                                                           ` Ingo Molnar
  2004-11-23  8:24                                                                             ` Eran Mann
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22 14:42 UTC (permalink / raw)
  To: Eran Mann; +Cc: linux-kernel


* Eran Mann <emann@mrv.com> wrote:

> >>I´m seeing latencies of up to ~2000 microseconds. see attached traces
> >>file for a small sample. I think I´m missing something obvious
> >>config-wise but I don´t know what...
> ...
> 
> >this seems to imply IDE DMA related hardware overhead. Apparently what
> >happens is that with certain motherboards/chipsets, if IDE DMA happens
> >then that DMA transfer _completely locks up_ the system bus. Nothing 
> >happens, and the CPU is stalled in essence until the end of the DMA 
> >request.

> Right on.
> After hdparm -d0 I see maximum latency of 35 us after a full kernel 
> build with a few GUI apps in the background. I´ll try to find a 
> reasonable compromise.

it might make sense to report this to the hw vendor as well, as these
latencies dont occur at _every_ IDE DMA, it might be some sort of
chipset (or BIOS) bug they might want to see resolved as well (if this
isnt a ship-and-forget vendor). 2 msec stalls are not nice to a fair
number of applications.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 12:56                                                                             ` Rui Nuno Capela
@ 2004-11-22 15:00                                                                               ` Ingo Molnar
  2004-11-22 15:10                                                                                 ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22 15:00 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> These are the command-lines of my test suite:
> 
>   jackd -R -dalsa -dhw:0 -P20 -r44100 -p64 -n2 -S -P &
>   fluidsynth -s -i -a jack -j -o jack.audio.id=fluid1 -o shell.port=9800
> ct4mgm.sf2 &
>   fluidsynth -s -i -a jack -j -o jack.audio.id=fluid2 -o shell.port=9801
> ct4mgm.sf2 &

is this enough to generate the xruns in jackd? Shouldnt fluidsynth be
given a MIDI file to play back? (if yes, what is the method i should use
- should i give it on the command line?)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 15:00                                                                               ` Ingo Molnar
@ 2004-11-22 15:10                                                                                 ` Ingo Molnar
  2004-11-22 15:20                                                                                   ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22 15:10 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Ingo Molnar <mingo@elte.hu> wrote:

> >   jackd -R -dalsa -dhw:0 -P20 -r44100 -p64 -n2 -S -P &
> >   fluidsynth -s -i -a jack -j -o jack.audio.id=fluid1 -o shell.port=9800
> > ct4mgm.sf2 &
> >   fluidsynth -s -i -a jack -j -o jack.audio.id=fluid2 -o shell.port=9801
> > ct4mgm.sf2 &
> 
> is this enough to generate the xruns in jackd? Shouldnt fluidsynth be
> given a MIDI file to play back? (if yes, what is the method i should
> use - should i give it on the command line?)

ah, i think i understand: fluidsynth has roughly the same CPU overhead
when it is 'silent' (it's generating small static noise in that case),
compared to when it's playing a MIDI file - so i should be able to see
the xruns if i just run jackd and 8 fluidsynth instances, and then load
the box - correct?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 15:10                                                                                 ` Ingo Molnar
@ 2004-11-22 15:20                                                                                   ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22 15:20 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Ingo Molnar <mingo@elte.hu> wrote:

> ah, i think i understand: fluidsynth has roughly the same CPU overhead
> when it is 'silent' (it's generating small static noise in that case),
> compared to when it's playing a MIDI file - so i should be able to see
> the xruns if i just run jackd and 8 fluidsynth instances, and then
> load the box - correct?

another question: it seems the fluidsynth threads are running as non-RT
threads - they are soft-synthesizing sound that jackd will mix and play. 
Now, can any delay of these fluidsynth threads (they are non-RT tasks
and can get delayed indefinitely) cause an xrun in Jackd, or should it
'only' make the sound more choppy?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 14:18                                                                               ` Rui Nuno Capela
@ 2004-11-22 15:41                                                                                 ` Ingo Molnar
  2004-11-22 15:45                                                                                 ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22 15:41 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> Yes, I know all this, and I warned before that this tests were
> strictly and specific to the hardware, jackd and fludisynth code which
> are intentionally kept the same along the several RT kernels that have
> been issued.

i'm aware of this - and i'm perfectly happy about all the testing that
is done, even if a latency problem in the end it turns out to be some
'side issue', an application or configuration bug. You are doing very
useful QA no matter what the problem turns out to be in the end.

when fixing stuff i tend to go from the simpler testcases to the more
complex ones (it's naturally simpler to validate the simpler ones), but
currently all the simple ones are working fine, so i'm looking at more
complex ones again.

Having said that, (not in small part based on the care you are taking to
keep your test environment consistent) it very much looks like as if the
latency problems you are reporting are related to -RT itself. It could
easily be something else, but as usual, there's only one way to find out
...

anyway, dont worry about presenting me with some problem that in the end
turns out to be something else. As Florian's jackd-xrun report from two
days ago has proven, jackd is still triggering genuine -RT bugs that
none of the simple workloads/apps are triggering. Less than one day
after half a dozen such latency bugs were fixed in the -RT patchset i
have no basis to go and blame Jackd or ALSA for any of the remaining
latency problems =B-)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 14:18                                                                               ` Rui Nuno Capela
  2004-11-22 15:41                                                                                 ` Ingo Molnar
@ 2004-11-22 15:45                                                                                 ` Ingo Molnar
  2004-11-22 16:53                                                                                   ` Rui Nuno Capela
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-22 15:45 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> > It seems jackd has a limitation to 14 clients atm (don't ask me why). The
> > 15th kills jackd ;)
> >
> 
> So true.

is there any fix for that? Loading 14 jack_test clients only uses up
~33% of CPU time on my testbox. Or should it be possible for me to
trigger xruns using so many clients and 33% CPU utilization already? 

Could you perhaps try 14 instances of jack_test on your box, and see
whether you can generate similar xruns as you could generate with
fluidsynth? jack_test should certainly exclude as much jack-client side
complexity as possible.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 15:45                                                                                 ` Ingo Molnar
@ 2004-11-22 16:53                                                                                   ` Rui Nuno Capela
  2004-11-23 13:55                                                                                     ` Ingo Molnar
  2004-11-23 14:46                                                                                     ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-22 16:53 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

> Ingo Molnar
>
> * Rui Nuno Capela <rncbc@rncbc.org> wrote:
>
>> > It seems jackd has a limitation to 14 clients atm (don't ask me why).
>> The
>> > 15th kills jackd ;)
>> >
>>
>> So true.
>
> is there any fix for that? Loading 14 jack_test clients only uses up
> ~33% of CPU time on my testbox. Or should it be possible for me to
> trigger xruns using so many clients and 33% CPU utilization already?
>
> Could you perhaps try 14 instances of jack_test on your box, and see
> whether you can generate similar xruns as you could generate with
> fluidsynth? jack_test should certainly exclude as much jack-client side
> complexity as possible.
>
> 	Ingo
>

OK. I tried 14 instances of jack_test. I even modded Florian's original
source code, to let each client instance have 4 ins and 4 outs, and to
make things a litle bit heavier, all 4 inputs are mixed into each of the 4
outputs.

Saw at least a couple of XRUNs in a 20 (4*5) minute test-run. CPU load
doesn't get above 30% on my laptop (P4/UP 2.533Ghz).

On attach you may find my "4-multiplex" version of jack_test(.cpp), along
with the jack_test3.sh shell script which has been used for my test runs.

There's also a modified version of nmeter(.c) that served the purpose to
log system performance counters (CPU usage, IRQs  and Context Switch
rate).

Bye.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: jack_test3.tar.gz --]
[-- Type: application/x-gzip-compressed, Size: 9298 bytes --]

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 14:42                                                                           ` Ingo Molnar
@ 2004-11-23  8:24                                                                             ` Eran Mann
  0 siblings, 0 replies; 951+ messages in thread
From: Eran Mann @ 2004-11-23  8:24 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Ingo Molnar wrote:
> * Eran Mann <emann@mrv.com> wrote:
> 
>>Right on.
>>After hdparm -d0 I see maximum latency of 35 us after a full kernel 
>>build with a few GUI apps in the background. I´ll try to find a 
>>reasonable compromise.
> 
> it might make sense to report this to the hw vendor as well, as these
> latencies dont occur at _every_ IDE DMA, it might be some sort of
> chipset (or BIOS) bug they might want to see resolved as well (if this
> isnt a ship-and-forget vendor). 2 msec stalls are not nice to a fair
> number of applications.
> 
> 	Ingo

It´s a rather old white-box machine with a noname VIA-based motherboard, 
So I don´t really have whom to report the problem to. On the other hand 
with udma2 I see latencies < 170 us which seems reasonable.
Thanks for the advice.
   Eran.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 16:53                                                                                   ` Rui Nuno Capela
@ 2004-11-23 13:55                                                                                     ` Ingo Molnar
  2004-11-23 13:56                                                                                       ` Ingo Molnar
                                                                                                         ` (2 more replies)
  2004-11-23 14:46                                                                                     ` Ingo Molnar
  1 sibling, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 13:55 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> OK. I tried 14 instances of jack_test. I even modded Florian's
> original source code, to let each client instance have 4 ins and 4
> outs, and to make things a litle bit heavier, all 4 inputs are mixed
> into each of the 4 outputs.
> 
> Saw at least a couple of XRUNs in a 20 (4*5) minute test-run. CPU load
> doesn't get above 30% on my laptop (P4/UP 2.533Ghz).

the max CPU load i get here is 46% (your laptop is faster), but no
xruns. The result of a 5-minute run is:

 ************* SUMMARY RESULT ****************
 Timeout Count . . . . . . . . :(    0)
 XRUN Count  . . . . . . . . . :     0
 Delay Count (>spare time) . . :     0
 Delay Count (>1000 usecs) . . :     0
 Delay Maximum . . . . . . . . :     0   usecs
 Cycle Maximum . . . . . . . . :  1016   usecs
 Average DSP Load. . . . . . . :    46.4 %
 Average CPU System Load . . . :    40.5 %
 Average CPU User Load . . . . :     2.3 %
 Average CPU Nice Load . . . . :     0.0 %
 Average CPU I/O Wait Load . . :     0.0 %
 Average CPU IRQ Load  . . . . :     0.0 %
 Average CPU Soft-IRQ Load . . :     0.0 %
 Average Interrupt Rate  . . . :  2374.1 /sec
 Average Context-Switch Rate . : 19172.8 /sec

i suspect i need to activate some option/define in jackd to get some of
the more advanced stats such as delay-maximum?

the kernel i used was -30-6 and i used the snd-via82xx driver. (I had to
do -n3 instead of -n2 when starting up jackd - otherwise i'd get an
endless stream of very small xruns, apparently a via82xx driver bug?)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 13:55                                                                                     ` Ingo Molnar
@ 2004-11-23 13:56                                                                                       ` Ingo Molnar
  2004-11-23 13:58                                                                                       ` Ingo Molnar
  2004-11-23 14:00                                                                                       ` Rui Nuno Capela
  2 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 13:56 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


> Saw at least a couple of XRUNs in a 20 (4*5) minute test-run. CPU load
> doesn't get above 30% on my laptop (P4/UP 2.533Ghz).

i'm wondering, do you get any xruns (or other bad behavior) if you use
the dummy ALSA driver for the latency test?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 14:46                                                                                     ` Ingo Molnar
@ 2004-11-23 13:57                                                                                       ` Florian Schmidt
  2004-11-23 15:05                                                                                         ` Ingo Molnar
  2004-11-23 15:21                                                                                         ` Ingo Molnar
  2004-11-23 14:53                                                                                       ` Ingo Molnar
  1 sibling, 2 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-23 13:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

On Tue, 23 Nov 2004 15:46:22 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> i tried your new test-client, and i've got a generic question: should a
> jack client be able to generate an xrun via, other than via overloading
> jackd? E.g. i'm wondering about the following behavior: if start up
> jackd in the usual way:

The process() callback in a jackd client is run in a thread created by
libjack. This thread is run with SCHED_FIFO and at the same priority (or
one lower it seems) as the jackd server. Thus a client can only cause an
xrun when it takes a too long time to return from its process callback.

~$ ps  -C jackd -cmL
  PID   LWP CLS PRI TTY          TIME CMD
  975     - -     - ?        00:00:00 jackd
    -   975 TS   19 -        00:00:00 -
    -   976 TS   23 -        00:00:00 -
    -   977 FF  110 -        00:00:00 -
    -   978 FF  100 -        00:00:00 -

~$ ps -C jack_test -cmL
  PID   LWP CLS PRI TTY          TIME CMD
  988     - -     - pts/1    00:00:00 jack_test
    -   988 TS   20 -        00:00:00 -
    -   989 FF   99 -        00:00:00 -

So when you ctrl-z out of jack_test you cause its process() thread to be
suspended, too, thus jackd cannot finish processing its graph.

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 13:55                                                                                     ` Ingo Molnar
  2004-11-23 13:56                                                                                       ` Ingo Molnar
@ 2004-11-23 13:58                                                                                       ` Ingo Molnar
  2004-11-23 14:11                                                                                         ` Ingo Molnar
  2004-11-23 14:00                                                                                       ` Rui Nuno Capela
  2 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 13:58 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Ingo Molnar <mingo@elte.hu> wrote:

> the max CPU load i get here is 46% (your laptop is faster), but no
> xruns. The result of a 5-minute run is:
> 
>  ************* SUMMARY RESULT ****************
>  Timeout Count . . . . . . . . :(    0)
>  XRUN Count  . . . . . . . . . :     0
>  Delay Count (>spare time) . . :     0
>  Delay Count (>1000 usecs) . . :     0
>  Delay Maximum . . . . . . . . :     0   usecs
>  Cycle Maximum . . . . . . . . :  1016   usecs
>  Average DSP Load. . . . . . . :    46.4 %
>  Average CPU System Load . . . :    40.5 %
>  Average CPU User Load . . . . :     2.3 %
>  Average CPU Nice Load . . . . :     0.0 %
>  Average CPU I/O Wait Load . . :     0.0 %
>  Average CPU IRQ Load  . . . . :     0.0 %
>  Average CPU Soft-IRQ Load . . :     0.0 %
>  Average Interrupt Rate  . . . :  2374.1 /sec
>  Average Context-Switch Rate . : 19172.8 /sec

here are the settings i used:

 JACKD_PRIO=20
 JACKD_RATE=44100
 JACKD_PERIOD=64
 JACKD_SECONDS=300
 CLIENT_MAX=14

 jackd 0.99.0

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 13:55                                                                                     ` Ingo Molnar
  2004-11-23 13:56                                                                                       ` Ingo Molnar
  2004-11-23 13:58                                                                                       ` Ingo Molnar
@ 2004-11-23 14:00                                                                                       ` Rui Nuno Capela
  2004-11-23 15:41                                                                                         ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-23 14:00 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

Ingo Molnar wrote:
>
> the max CPU load i get here is 46% (your laptop is faster), but no
> xruns. The result of a 5-minute run is:
>
>  ************* SUMMARY RESULT ****************
>  Timeout Count . . . . . . . . :(    0)
>  XRUN Count  . . . . . . . . . :     0
>  Delay Count (>spare time) . . :     0
>  Delay Count (>1000 usecs) . . :     0
>  Delay Maximum . . . . . . . . :     0   usecs
>  Cycle Maximum . . . . . . . . :  1016   usecs
>  Average DSP Load. . . . . . . :    46.4 %
>  Average CPU System Load . . . :    40.5 %
>  Average CPU User Load . . . . :     2.3 %
>  Average CPU Nice Load . . . . :     0.0 %
>  Average CPU I/O Wait Load . . :     0.0 %
>  Average CPU IRQ Load  . . . . :     0.0 %
>  Average CPU Soft-IRQ Load . . :     0.0 %
>  Average Interrupt Rate  . . . :  2374.1 /sec
>  Average Context-Switch Rate . : 19172.8 /sec
>
> i suspect i need to activate some option/define in jackd to get some of
> the more advanced stats such as delay-maximum?
>

Yes, there's a non-official patch to jackd from Lee Revell's. Without that
you don't get to read the maximum delay from jackd. Sorry. But if you have
the patience to rebuild jack, here comes attached the minimal patch for
just that.

Seeya.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: jack-0.99.10-max_delayed_usecs.patch.gz --]
[-- Type: application/x-gzip-compressed, Size: 1180 bytes --]

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 13:58                                                                                       ` Ingo Molnar
@ 2004-11-23 14:11                                                                                         ` Ingo Molnar
  2004-11-23 14:32                                                                                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 14:11 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


another test on the same system, this time completely idle:

 ************* SUMMARY RESULT ****************
 Timeout Count . . . . . . . . :(    0)
 XRUN Count  . . . . . . . . . :     0
 Delay Count (>spare time) . . :     0
 Delay Count (>1000 usecs) . . :     0
 Delay Maximum . . . . . . . . :     0   usecs
 Cycle Maximum . . . . . . . . :   724   usecs
 Average DSP Load. . . . . . . :    32.1 %
 Average CPU System Load . . . :    30.8 %
 Average CPU User Load . . . . :     1.6 %
 Average CPU Nice Load . . . . :     0.0 %
 Average CPU I/O Wait Load . . :     0.0 %
 Average CPU IRQ Load  . . . . :     0.0 %
 Average CPU Soft-IRQ Load . . :     0.0 %
 Average Interrupt Rate  . . . :  1669.0 /sec
 Average Context-Switch Rate . : 16975.4 /sec
 *********************************************

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 14:11                                                                                         ` Ingo Molnar
@ 2004-11-23 14:32                                                                                           ` Ingo Molnar
  2004-11-23 14:41                                                                                             ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 14:32 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Ingo Molnar <mingo@elte.hu> wrote:

> another test on the same system, this time completely idle:

ah ... used the jack_test.cc client instead of your new jack_test.cpp.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 14:32                                                                                           ` Ingo Molnar
@ 2004-11-23 14:41                                                                                             ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 14:41 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > another test on the same system, this time completely idle:
> 
> ah ... used the jack_test.cc client instead of your new jack_test.cpp.

no big difference in the results though:

 ************* SUMMARY RESULT ****************
 Timeout Count . . . . . . . . :(    0)
 XRUN Count  . . . . . . . . . :     0
 Delay Count (>spare time) . . :     0
 Delay Count (>1000 usecs) . . :     0
 Delay Maximum . . . . . . . . :     0   usecs
 Cycle Maximum . . . . . . . . :   582   usecs
 Average DSP Load. . . . . . . :    30.7 %
 Average CPU System Load . . . :    22.1 %
 Average CPU User Load . . . . :     8.7 %
 Average CPU Nice Load . . . . :     0.0 %
 Average CPU I/O Wait Load . . :     0.1 %
 Average CPU IRQ Load  . . . . :     0.0 %
 Average CPU Soft-IRQ Load . . :     0.0 %
 Average Interrupt Rate  . . . :  1676.5 /sec
 Average Context-Switch Rate . : 17020.5 /sec
 *********************************************

(i turned off some debugging options in the kernel, hence the small
latency improvement.)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 15:21                                                                                         ` Ingo Molnar
@ 2004-11-23 14:41                                                                                           ` Florian Schmidt
  2004-12-01 13:57                                                                                             ` Paul Davis
  0 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-11-23 14:41 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen, Paul Davis

On Tue, 23 Nov 2004 16:21:26 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > ~$ ps -C jack_test -cmL
> >   PID   LWP CLS PRI TTY          TIME CMD
> >   988     - -     - pts/1    00:00:00 jack_test
> >     -   988 TS   20 -        00:00:00 -
> >     -   989 FF   99 -        00:00:00 -
> > 
> > So when you ctrl-z out of jack_test you cause its process() thread to
> > be suspended, too, thus jackd cannot finish processing its graph.
> 
> so in theory any scheduling delay of PID 988 in the above setup (the
> SCHED_OTHER task) should not be able to negatively influence jackd,
> correct? 

correct

> In fact, does in this particular jack_test case PID 988 do
> anything substantial?

Well, it registers the client with jackd, sets up the ports, registers
the process() callback and then simply goes to sleep() for the desired
runtime of the program. All these are non RT ops and should never be
able to cause any xruns.

All the work is done by the process() callback which is called by
libjack in a SCHED_FIFO thread. The process() callback is called once
for each buffer that jackd processes.

I cannot explain the detailed mechanism of how jackd wakes its clients
and communicates with them myself too well, so i'll leave this to Paul
Davis (CC'ed). Care to elaborate, Paul?

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-22 16:53                                                                                   ` Rui Nuno Capela
  2004-11-23 13:55                                                                                     ` Ingo Molnar
@ 2004-11-23 14:46                                                                                     ` Ingo Molnar
  2004-11-23 13:57                                                                                       ` Florian Schmidt
  2004-11-23 14:53                                                                                       ` Ingo Molnar
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 14:46 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> OK. I tried 14 instances of jack_test. I even modded Florian's
> original source code, to let each client instance have 4 ins and 4
> outs, and to make things a litle bit heavier, all 4 inputs are mixed
> into each of the 4 outputs.

i tried your new test-client, and i've got a generic question: should a
jack client be able to generate an xrun via, other than via overloading
jackd? E.g. i'm wondering about the following behavior: if start up
jackd in the usual way:

  jackd -R -P20 -dalsa -dhw:0 -r44100 -p64 -n2 -S -P

and then i start a single test-client (jack_test.cpp):

 # ./jack_test
 seconds to run: 60
 client_new: jack_test-4215
 port_register
 set_process_callback
 activate
 running

and then if i now Ctrl-Z the Jack client, i get an immediate xrun
message from jackd:

  **** alsa_pcm: xrun of at least 2.119 msecs

and when i 'fg' the client again then jackd sees a big delay:

  **** alsa_pcm: xrun of at least 742.064 msecs

corresponding the amount of time i waited between the Ctrl-Z and the 
'fg'.

since the client runs as SCHED_OTHER, doesnt this mean that simple
delays between SCHED_OTHER tasks could cause xruns in jackd too? A
SCHED_OTHER task can be delayed indefinitely at any stage. So shouldnt
the test-clients have RT priority as well, to guarantee xrun-less jackd?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 14:46                                                                                     ` Ingo Molnar
  2004-11-23 13:57                                                                                       ` Florian Schmidt
@ 2004-11-23 14:53                                                                                       ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 14:53 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


> since the client runs as SCHED_OTHER, doesnt this mean that simple
> delays between SCHED_OTHER tasks could cause xruns in jackd too? A
> SCHED_OTHER task can be delayed indefinitely at any stage. So shouldnt
> the test-clients have RT priority as well, to guarantee xrun-less
> jackd?

if SCHED_OTHER is the goal, then the xruns you are seeing in the
fluidsynth test are likely the result of random fluctuations in
scheduling of SCHED_OTHER tasks.

The way to find out whether that's the main source of xruns would be the
following test: start each fluidsynth instance as "nice -19 fluidsynth
..." to renice it to +19. Nice +19 gives the smoothest timeslices to
CPU-bound tasks (such as fluidsynth), and should give the smallest
global fluctuations. (The system must be idle during the test of course,
a nice +19 task is easily preempted.)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 13:57                                                                                       ` Florian Schmidt
@ 2004-11-23 15:05                                                                                         ` Ingo Molnar
  2004-11-23 15:21                                                                                         ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 15:05 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> So when you ctrl-z out of jack_test you cause its process() thread to
> be suspended, too, thus jackd cannot finish processing its graph.

ok, that makes sense. So under what priority does most of the
CPU-intense processing run in the test client? SCHED_OTHER or
SCHED_FIFO?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 13:57                                                                                       ` Florian Schmidt
  2004-11-23 15:05                                                                                         ` Ingo Molnar
@ 2004-11-23 15:21                                                                                         ` Ingo Molnar
  2004-11-23 14:41                                                                                           ` Florian Schmidt
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 15:21 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> ~$ ps -C jack_test -cmL
>   PID   LWP CLS PRI TTY          TIME CMD
>   988     - -     - pts/1    00:00:00 jack_test
>     -   988 TS   20 -        00:00:00 -
>     -   989 FF   99 -        00:00:00 -
> 
> So when you ctrl-z out of jack_test you cause its process() thread to
> be suspended, too, thus jackd cannot finish processing its graph.

so in theory any scheduling delay of PID 988 in the above setup (the
SCHED_OTHER task) should not be able to negatively influence jackd,
correct? In fact, does in this particular jack_test case PID 988 do
anything substantial?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 14:00                                                                                       ` Rui Nuno Capela
@ 2004-11-23 15:41                                                                                         ` Ingo Molnar
  2004-11-23 16:53                                                                                           ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 15:41 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> Yes, there's a non-official patch to jackd from Lee Revell's. Without
> that you don't get to read the maximum delay from jackd. Sorry. But if
> you have the patience to rebuild jack, here comes attached the minimal
> patch for just that.

thx, it applied cleanly to jack-cvs. Here's the 5-minute idle-system
test again:

 ************* SUMMARY RESULT ****************
 Timeout Count . . . . . . . . :(    0)
 XRUN Count  . . . . . . . . . :     0
 Delay Count (>spare time) . . :     0
 Delay Count (>1000 usecs) . . :     0
 Delay Maximum . . . . . . . . :    28   usecs
 Cycle Maximum . . . . . . . . :   414   usecs
 Average DSP Load. . . . . . . :    20.6 %
 Average CPU System Load . . . :    11.6 %
 Average CPU User Load . . . . :     8.6 %
 Average CPU Nice Load . . . . :     0.0 %
 Average CPU I/O Wait Load . . :     0.0 %
 Average CPU IRQ Load  . . . . :     0.0 %
 Average CPU Soft-IRQ Load . . :     0.0 %
 Average Interrupt Rate  . . . :  1671.7 /sec
 Average Context-Switch Rate . : 17003.1 /sec
 *********************************************

but i can reproduce xruns on another, much slower box, using just 3-4
jack_test clients. The xruns dont seem to be justified, they happen at
30-40% CPU utilization already.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 15:41                                                                                         ` Ingo Molnar
@ 2004-11-23 16:53                                                                                           ` Rui Nuno Capela
  2004-11-23 18:00                                                                                             ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-23 16:53 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

Ingo Molnar wrote:
>
> * Rui Nuno Capela wrote:
>
>> Yes, there's a non-official patch to jackd from Lee Revell's. Without
>> that you don't get to read the maximum delay from jackd. Sorry. But if
>> you have the patience to rebuild jack, here comes attached the minimal
>> patch for just that.
>
> thx, it applied cleanly to jack-cvs. Here's the 5-minute idle-system test
> again:
>
>  ************* SUMMARY RESULT ****************
>  Timeout Count . . . . . . . . :(    0)
>  XRUN Count  . . . . . . . . . :     0
>  Delay Count (>spare time) . . :     0
>  Delay Count (>1000 usecs) . . :     0
>  Delay Maximum . . . . . . . . :    28   usecs
>  Cycle Maximum . . . . . . . . :   414   usecs
>  Average DSP Load. . . . . . . :    20.6 %
>  Average CPU System Load . . . :    11.6 %
>  Average CPU User Load . . . . :     8.6 %
>  Average CPU Nice Load . . . . :     0.0 %
>  Average CPU I/O Wait Load . . :     0.0 %
>  Average CPU IRQ Load  . . . . :     0.0 %
>  Average CPU Soft-IRQ Load . . :     0.0 %
>  Average Interrupt Rate  . . . :  1671.7 /sec
>  Average Context-Switch Rate . : 17003.1 /sec
>  *********************************************
>
> but i can reproduce xruns on another, much slower box, using just 3-4
> jack_test clients. The xruns dont seem to be justified, they happen at
> 30-40% CPU utilization already.
>

Now that you're liking, here goes a more contained jackd test-suite (see
attached tarball, jackd_test3.1.tar.gz).

Just launch the provided shell script, from the command line as:

  ./jack_test3_run.sh [secs] [clients] [ports]

where:

  secs    - number of seconds to run jackd workload (default = 300)
  clients - number of test-clients to run (default = 14)
  ports   - number of interface ports per client (default = 4)

As before, each client (jack_test3_client) registers the same number of
input and output ports (default is 4ins x 4outs), where each output is the
audio mix of all inputs.

Note that you can breakup the 14 client barrier, as that limit seems to be
related to the maximum number of client ports jackd can handle by default
(128). The jack_test_run.sh script sets this jackd maximum port limit
number as it sees fit, so any number of clients greater than 14 is
allowed, provided there's enough CPU and/or RAM ;)

Now, with the default workload (14 clients * 4 * 4 ports) I'm reaching 60%
of CPU, and a "fair" number of XRUNs on my P4@2.5G laptop, against the
on-board alsa driver (snd-ali5451), while under RT-V0.7.30-2.

Each test run produces a kernel-timestamped log filename with the complete
captured stdout/err. Consolidated results can be produced by feeding
several of those logfiles into the jack_test3_consolidated.awk script,
just like this:

   cat *.log | awk -f jack_test3_consolidated.awk


Enjoy.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org

[-- Attachment #2: jack_test3.1.tar.gz --]
[-- Type: application/x-gzip-compressed, Size: 10364 bytes --]

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-23 17:58                                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Ingo Molnar
@ 2004-11-23 17:53                                                                       ` K.R. Foley
  2004-11-23 18:01                                                                       ` K.R. Foley
                                                                                         ` (4 subsequent siblings)
  5 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-11-23 17:53 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

Ingo Molnar wrote:
> i have released the -V0.7.30-9 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 

A couple of observations that I would like to share:

1) With all of the tracing compiled in, there is a measurable amount of 
additional latency, even when the tracing is disabled via the proc 
interfaces. So if you want to measure best-case (or worst-case) 
latencies turn off the tracing facilities to do so. For example, using a 
blocking read, the worst case latency from interrupt to read: wo/tracing 
~68 usec, w/tracing ~110 usec. I am attaching two histograms generated 
by the rtc histogram by running a slightly modified version of realfeel.

2) Also there is a big difference in latencies between blocking reads 
and using signals to notify the process that data is available. I am 
also attaching a histogram generated by the rtc histogram by running 
amlat. Part of the numbers in the > 10 msec bucket are into the hundreds 
of msecs.

All of these numbers were generated using a comparable load from 
stress-kernel.

kr





[-- Attachment #2: notraceread.txt --]
[-- Type: text/plain, Size: 475 bytes --]

No tracing using read:
rtc latency histogram of {realfeel/5162, 671921 samples}:
3 221135
4 32396
5 38047
6 62650
7 99079
8 62347
9 47702
10 37572
11 27323
12 16734
13 9889
14 6081
15 3607
16 2214
17 1440
18 784
19 494
20 355
21 269
22 215
23 186
24 163
25 124
26 123
27 93
28 85
29 85
30 90
31 80
32 61
33 72
34 47
35 53
36 49
37 39
38 29
39 26
40 22
41 15
42 19
43 18
44 23
45 15
46 12
47 4
48 10
49 12
50 4
51 4
52 4
53 3
54 2
55 4
56 3
57 2
59 1
60 1
61 1
62 1
67 1
68 2

[-- Attachment #3: traceon.txt --]
[-- Type: text/plain, Size: 3359 bytes --]

Tracing on using read:
Nov 22 19:37:39 porky kernel: rtc latency histogram of {realfeel/6592, 487037 samples}:
Nov 22 19:37:39 porky kernel: 13 10
Nov 22 19:37:39 porky kernel: 14 88142
Nov 22 19:37:39 porky kernel: 15 113256
Nov 22 19:37:39 porky kernel: 16 77884
Nov 22 19:37:39 porky kernel: 17 60492
Nov 22 19:37:39 porky kernel: 18 41451
Nov 22 19:37:39 porky kernel: 19 23587
Nov 22 19:37:39 porky kernel: 20 15409
Nov 22 19:37:39 porky kernel: 21 11975
Nov 22 19:37:39 porky kernel: 22 14672
Nov 22 19:37:39 porky kernel: 23 11843
Nov 22 19:37:39 porky kernel: 24 8318
Nov 22 19:37:39 porky kernel: 25 5595
Nov 22 19:37:39 porky kernel: 26 3546
Nov 22 19:37:39 porky kernel: 27 2057
Nov 22 19:37:39 porky kernel: 28 1192
Nov 22 19:37:39 porky kernel: 29 819
Nov 22 19:37:39 porky kernel: 30 682
Nov 22 19:37:39 porky kernel: 31 665
Nov 22 19:37:39 porky kernel: 32 662
Nov 22 19:37:39 porky kernel: 33 540
Nov 22 19:37:39 porky kernel: 34 494
Nov 22 19:37:39 porky kernel: 35 433
Nov 22 19:37:39 porky kernel: 36 290
Nov 22 19:37:39 porky kernel: 37 227
Nov 22 19:37:39 porky kernel: 38 189
Nov 22 19:37:39 porky kernel: 39 129
Nov 22 19:37:39 porky kernel: 40 110
Nov 22 19:37:39 porky kernel: 41 78
Nov 22 19:37:39 porky kernel: 42 85
Nov 22 19:37:39 porky kernel: 43 102
Nov 22 19:37:39 porky kernel: 44 314
Nov 22 19:37:39 porky kernel: 45 189
Nov 22 19:37:39 porky kernel: 46 137
Nov 22 19:37:39 porky kernel: 47 105
Nov 22 19:37:39 porky kernel: 48 147
Nov 22 19:37:39 porky kernel: 49 101
Nov 22 19:37:39 porky kernel: 50 99
Nov 22 19:37:39 porky kernel: 51 93
Nov 22 19:37:39 porky kernel: 52 61
Nov 22 19:37:39 porky kernel: 53 57
Nov 22 19:37:39 porky kernel: 54 44
Nov 22 19:37:39 porky kernel: 55 50
Nov 22 19:37:39 porky kernel: 56 49
Nov 22 19:37:39 porky kernel: 57 50
Nov 22 19:37:39 porky kernel: 58 48
Nov 22 19:37:39 porky kernel: 59 49
Nov 22 19:37:39 porky kernel: 60 41
Nov 22 19:37:39 porky kernel: 61 31
Nov 22 19:37:39 porky kernel: 62 23
Nov 22 19:37:39 porky kernel: 63 19
Nov 22 19:37:39 porky kernel: 64 23
Nov 22 19:37:39 porky kernel: 65 27
Nov 22 19:37:39 porky kernel: 66 18
Nov 22 19:37:39 porky kernel: 67 17
Nov 22 19:37:39 porky kernel: 68 15
Nov 22 19:37:39 porky kernel: 69 16
Nov 22 19:37:39 porky kernel: 70 17
Nov 22 19:37:39 porky kernel: 71 11
Nov 22 19:37:39 porky kernel: 72 11
Nov 22 19:37:39 porky kernel: 73 19
Nov 22 19:37:40 porky kernel: 74 15
Nov 22 19:37:40 porky kernel: 75 24
Nov 22 19:37:40 porky kernel: 76 26
Nov 22 19:37:40 porky kernel: 77 14
Nov 22 19:37:40 porky kernel: 78 15
Nov 22 19:37:40 porky kernel: 79 17
Nov 22 19:37:40 porky kernel: 80 19
Nov 22 19:37:40 porky kernel: 81 12
Nov 22 19:37:40 porky kernel: 82 4
Nov 22 19:37:40 porky kernel: 83 7
Nov 22 19:37:40 porky kernel: 84 9
Nov 22 19:37:40 porky kernel: 85 8
Nov 22 19:37:40 porky kernel: 86 11
Nov 22 19:37:40 porky kernel: 87 8
Nov 22 19:37:40 porky kernel: 88 4
Nov 22 19:37:40 porky kernel: 89 3
Nov 22 19:37:40 porky kernel: 90 1
Nov 22 19:37:40 porky kernel: 91 5
Nov 22 19:37:40 porky kernel: 92 5
Nov 22 19:37:40 porky kernel: 94 3
Nov 22 19:37:40 porky kernel: 95 1
Nov 22 19:37:40 porky kernel: 96 2
Nov 22 19:37:40 porky kernel: 97 2
Nov 22 19:37:40 porky kernel: 98 2
Nov 22 19:37:40 porky kernel: 99 1
Nov 22 19:37:40 porky kernel: 101 1
Nov 22 19:37:40 porky kernel: 107 2
Nov 22 19:37:40 porky kernel: 110 1

[-- Attachment #4: notracesig.txt --]
[-- Type: text/plain, Size: 772 bytes --]

No tracing using signals:
rtc latency histogram of {amlat/7215, 535020 samples}:
4 1
9 18916
10 125448
11 29422
12 41496
13 22222
14 15344
15 12256
16 10935
17 11157
18 11192
19 11456
20 12994
21 13832
22 14704
23 14330
24 12625
25 11837
26 11839
27 11206
28 10307
29 10057
30 10183
31 13115
32 11438
33 11897
34 11559
35 7817
36 5823
37 4660
38 3944
39 3106
40 2763
41 2424
42 1961
43 1729
44 1348
45 1154
46 984
47 801
48 682
49 537
50 467
51 345
52 288
53 214
54 182
55 162
56 131
57 117
58 135
59 118
60 111
61 120
62 118
63 89
64 103
65 95
66 92
67 85
68 62
69 45
70 61
71 39
72 29
73 40
74 28
75 25
76 25
77 18
78 18
79 11
80 13
81 9
82 13
83 10
84 11
85 5
86 2
87 4
88 2
89 3
90 2
91 5
92 2
93 1
94 2
95 4
96 3
97 2
98 1
99 3
103 1
104 1
108 2
118 1
7860 1
9999 43

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-22  0:54                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2 Ingo Molnar
  2004-11-22  1:07                                                                     ` Florian Schmidt
  2004-11-22  8:44                                                                     ` Eran Mann
@ 2004-11-23 17:58                                                                     ` Ingo Molnar
  2004-11-23 17:53                                                                       ` K.R. Foley
                                                                                         ` (5 more replies)
  2 siblings, 6 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 17:58 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


i have released the -V0.7.30-9 Real-Time Preemption patch, which can be
downloaded from the usual place:

    http://redhat.com/~mingo/realtime-preempt/

this is a fixes-only release.

most importantly it includes a JACK related latency fix. With Florian
Schmidt's great detective work we honed in on a big latency source
within JACK: the use of named pipes (fifos) on journalled filesystems. 

This issue has been empirically identified before (and is mentioned in
the JACK howto) but has never been given high enough prominence. It
turns out that the atime updates done while read()ing or write()ing
named pipes causes the delays - it may under certain circumstances call
out into the journalling code. It may block even on non-journalled
filesystems.

To work this issue around, when PREEMPT_RT is enabled the -30-9 kernel
skips atime updates on named-fifos. (it's pretty pointless anyway.)
Alternative userspace workarounds are to put the fifos on tmpfs/ramfs,
or to mark the filesystem noatime,nodiratime.

those experiencing xruns under JACK should definitely try the -30-9
kernel.

Changes since -V0.7.30-2:

 - named fifo reads/writes are now atomic, whenever possible

 - fixed pi_lock related SMP & CRITICAL_IRQSOFF_TIMING lockups, this 
   could resolve the lockups reported by Mark H. Johnson.

 - fixed one more PI buglet: wake up the new owner _after_ restoring
   the priority of the old owner.

 - made the NMI oopser more robust - it should print out some message 
   in pretty much any locking scenario.

 - added the blocker device used by Esben Nielsen's pi_test suite.

 - added user-triggerable ALSA xrun tracing to the patch: if a 
   sound IO channel has xrun_debug enabled in /proc then 
   user_trace_stop() will be called before printing the xrun message,
   and the current trace will be saved to /proc/latency_trace. This is a
   'one-shot' tracing method for now. I can be activated via:

     echo 1 > /proc/asound/card0/pcm0p/xrun_debug

     echo 1 > /proc/sys/kernel/trace_user_triggered
     echo 1 > /proc/sys/kernel/trace_freerunning
     echo 0 > /proc/sys/kernel/preempt_max_latency
     echo 0 > /proc/sys/kernel/preempt_thresh
     echo 0 > /proc/sys/kernel/preempt_wakeup_timing

     ./gettimeofday 0 1

  gettimeofday.c is attached below. The JACK fifo xrun source was found
  via this tracing facility.

to create a -V0.7.30-9 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm2/2.6.10-rc2-mm2.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm2-V0.7.30-9

	Ingo


-- gettimeofday.c:

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <sys/wait.h>
#include <linux/unistd.h>

int main (int argc, char **argv)
{
	if (argc != 3) {
		printf("usage: gettimeofday <val1> <val2>\n");
		exit(0);
	}
	gettimeofday(atol(argv[1]), atol(argv[2]));

	return 0;
}


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 16:53                                                                                           ` Rui Nuno Capela
@ 2004-11-23 18:00                                                                                             ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 18:00 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Florian Schmidt, linux-kernel, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> Now, with the default workload (14 clients * 4 * 4 ports) I'm reaching
> 60% of CPU, and a "fair" number of XRUNs on my P4@2.5G laptop, against
> the on-board alsa driver (snd-ali5451), while under RT-V0.7.30-2.

it would be very interesting to see how the new -30-9 kernel performs
using your workload (both fluidsynth and jackd_test), whether your xruns
are impacted by the fifo fix, and/or whether there are any other large
xrun sources left.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-23 17:58                                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Ingo Molnar
  2004-11-23 17:53                                                                       ` K.R. Foley
@ 2004-11-23 18:01                                                                       ` K.R. Foley
  2004-11-24  0:28                                                                       ` Florian Schmidt
                                                                                         ` (3 subsequent siblings)
  5 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-11-23 18:01 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

Ingo Molnar wrote:
> i have released the -V0.7.30-9 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 

A couple of observations that I would like to share:


One other thing regarding my last email. The numbers were generated 
using -V0.7.30-3, not -9. Sorry.

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-23 17:58                                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Ingo Molnar
  2004-11-23 17:53                                                                       ` K.R. Foley
  2004-11-23 18:01                                                                       ` K.R. Foley
@ 2004-11-24  0:28                                                                       ` Florian Schmidt
  2004-11-24  3:19                                                                         ` Ingo Molnar
  2004-11-24  0:58                                                                       ` Lee Revell
                                                                                         ` (2 subsequent siblings)
  5 siblings, 1 reply; 951+ messages in thread
From: Florian Schmidt @ 2004-11-24  0:28 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]

On Tue, 23 Nov 2004 18:58:23 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
>  - added user-triggerable ALSA xrun tracing to the patch: if a 
>    sound IO channel has xrun_debug enabled in /proc then 
>    user_trace_stop() will be called before printing the xrun message,
>    and the current trace will be saved to /proc/latency_trace. This is a
>    'one-shot' tracing method for now. I can be activated via:
> 
>      echo 1 > /proc/asound/card0/pcm0p/xrun_debug
> 
>      echo 1 > /proc/sys/kernel/trace_user_triggered
>      echo 1 > /proc/sys/kernel/trace_freerunning
>      echo 0 > /proc/sys/kernel/preempt_max_latency
>      echo 0 > /proc/sys/kernel/preempt_thresh
>      echo 0 > /proc/sys/kernel/preempt_wakeup_timing
> 
>      ./gettimeofday 0 1
> 
>   gettimeofday.c is attached below. The JACK fifo xrun source was found
>   via this tracing facility.

Hi, i have some problem with unresolved symbols loading my alsa sound
card driver with this kernel version. At first i suspected an unclean
build, but then i did make clean bzImage modules and the unresolved
symbols persist (i have wakeup/nonpreemptible/interrupts-off tracing
enabled (see .config)):

snd_pcm: Unknown symbol user_trace_stop
snd_ac97_codec: Unknown symbol snd_interval_refine
snd_ac97_codec: Unknown symbol snd_pcm_hw_rule_add
snd_cs46xx: Unknown symbol snd_ac97_write_cache
snd_cs46xx: Unknown symbol snd_pcm_new
snd_cs46xx: Unknown symbol snd_pcm_lib_preallocate_pages_for_all
snd_cs46xx: Unknown symbol snd_pcm_format_unsigned
snd_cs46xx: Unknown symbol snd_pcm_format_physical_width
snd_cs46xx: Unknown symbol snd_ac97_mixer
snd_cs46xx: Unknown symbol snd_ac97_bus
snd_cs46xx: Unknown symbol snd_pcm_lib_malloc_pages
snd_cs46xx: Unknown symbol snd_pcm_lib_ioctl
snd_cs46xx: Unknown symbol snd_pcm_lib_free_pages
snd_cs46xx: Unknown symbol snd_pcm_set_ops
snd_cs46xx: Unknown symbol snd_pcm_hw_constraint_list
snd_cs46xx: Unknown symbol snd_pcm_format_big_endian
snd_cs46xx: Unknown symbol snd_pcm_lib_preallocate_free_for_all
snd_cs46xx: Unknown symbol snd_pcm_period_elapsed
snd_cs46xx: Unknown symbol snd_ac97_write
snd_cs46xx: Unknown symbol snd_ac97_read
snd_cs46xx: Unknown symbol snd_pcm_format_width


.config attached

flo

[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 26525 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-rc2-mm2-V0.7.30-9
# Wed Nov 24 00:25:10 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
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

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# 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_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
# CONFIG_SMP 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_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_KERN_PHYS_OFFSET=1
# CONFIG_KEXEC is not set

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

#
# 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_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y

#
# 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=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_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 is not set
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 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=y
# 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# 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

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLOGIC_1280_1040 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_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_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM 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

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_RTC_HISTOGRAM is not set
# CONFIG_BLOCKER 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=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
# CONFIG_I2C_AMD756_S4882 is not set
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_STUB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
# CONFIG_SENSORS_LM63 is not set
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
# CONFIG_SENSORS_LM87 is not set
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_MEMORY is not set
# CONFIG_SND_DEBUG_DETECT is not set

#
# Generic devices
#
CONFIG_SND_DUMMY=m
# 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

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY 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_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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=m
CONFIG_RXRPC=m

#
# 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=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
CONFIG_WAKEUP_TIMING=y
CONFIG_CRITICAL_PREEMPT_TIMING=y
CONFIG_CRITICAL_IRQSOFF_TIMING=y
CONFIG_CRITICAL_TIMING=y
CONFIG_LATENCY_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_MCOUNT=y
# CONFIG_RT_DEADLOCK_DETECT is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
CONFIG_SECURITY_REALTIME=m
# CONFIG_SECURITY_SELINUX is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-23 17:58                                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Ingo Molnar
                                                                                         ` (2 preceding siblings ...)
  2004-11-24  0:28                                                                       ` Florian Schmidt
@ 2004-11-24  0:58                                                                       ` Lee Revell
  2004-11-24  3:45                                                                         ` Ingo Molnar
  2004-11-24 10:16                                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-10 Ingo Molnar
  2004-11-24 19:23                                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Fernando Lopez-Lezcano
  5 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-11-24  0:58 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

On Tue, 2004-11-23 at 18:58 +0100, Ingo Molnar wrote:
> i have released the -V0.7.30-9 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>     http://redhat.com/~mingo/realtime-preempt/

I have notices some weird interactivity issues with this.  These are
also present in T3.

The symptom is that CPU bound tasks like kernel compiles will starve I/O
bound tasks like evolution for a _long_ time.  If I have a kernel build
and external modules building at the same time and Evolution goes to
"Update message list...", it can sit and spin with a blank message pane
for a minute or two.  If I suspend the builds, the message list renders
immediately.

It seems like the build process is constantly preempting the Evolution
process, preventing the latter from making much progress.  The build on
the other hand progresses fine.

AIUI I/O bound, interactive tasks like a mail client should get
scheduled in preference to CPU bound tasks like builds.  The scheduler
has heuristics to distinguish the two types of tasks and boosts the
dynamic priority of the former, right?  It seems like exactly the
opposite is happening.

Another possibility is that Evolution really DOES use so many cycles to
generate the message list that it looks like a CPU bound process to the
kernel.  Unfortunately I think this seems most likely.  For example,
evolution still consumes a hell of a lot of CPU at a low nice value.  It
just makes other tasks stall this way.

Do I need to just find a better mail client?

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-24  3:19                                                                         ` Ingo Molnar
@ 2004-11-24  2:48                                                                           ` Florian Schmidt
  0 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-11-24  2:48 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

On Wed, 24 Nov 2004 04:19:08 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > Hi, i have some problem with unresolved symbols loading my alsa sound
> > card driver with this kernel version. At first i suspected an unclean
> > build, but then i did make clean bzImage modules and the unresolved
> > symbols persist (i have wakeup/nonpreemptible/interrupts-off tracing
> > enabled (see .config)):
> > 
> > snd_pcm: Unknown symbol user_trace_stop
> 
> does adding this line to kernel/latency.c resolve it?:
> 
>   EXPORT_SYMBOL(user_trace_stop);

yes, modules load fine now. thanks.

flo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-24  0:28                                                                       ` Florian Schmidt
@ 2004-11-24  3:19                                                                         ` Ingo Molnar
  2004-11-24  2:48                                                                           ` Florian Schmidt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-24  3:19 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Florian Schmidt <mista.tapas@gmx.net> wrote:

> Hi, i have some problem with unresolved symbols loading my alsa sound
> card driver with this kernel version. At first i suspected an unclean
> build, but then i did make clean bzImage modules and the unresolved
> symbols persist (i have wakeup/nonpreemptible/interrupts-off tracing
> enabled (see .config)):
> 
> snd_pcm: Unknown symbol user_trace_stop

does adding this line to kernel/latency.c resolve it?:

  EXPORT_SYMBOL(user_trace_stop);

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-24  0:58                                                                       ` Lee Revell
@ 2004-11-24  3:45                                                                         ` Ingo Molnar
  2004-11-24 13:33                                                                           ` Steven Rostedt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-24  3:45 UTC (permalink / raw)
  To: Lee Revell
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Lee Revell <rlrevell@joe-job.com> wrote:

> On Tue, 2004-11-23 at 18:58 +0100, Ingo Molnar wrote:
> > i have released the -V0.7.30-9 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> > 
> >     http://redhat.com/~mingo/realtime-preempt/
> 
> I have notices some weird interactivity issues with this.  These are
> also present in T3.
> 
> The symptom is that CPU bound tasks like kernel compiles will starve
> I/O bound tasks like evolution for a _long_ time.  If I have a kernel
> build and external modules building at the same time and Evolution
> goes to "Update message list...", it can sit and spin with a blank
> message pane for a minute or two.  If I suspend the builds, the
> message list renders immediately.

could you try the vanilla -rc2-mm2 kernel (with PREEMPT enabled), does
it behave in such a way too? At first sight this could be a property of
the upstream scheduler, but maybe it's special to PREEMPT_RT.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-10
  2004-11-23 17:58                                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Ingo Molnar
                                                                                         ` (3 preceding siblings ...)
  2004-11-24  0:58                                                                       ` Lee Revell
@ 2004-11-24 10:16                                                                       ` Ingo Molnar
  2004-11-24 11:27                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0 Ingo Molnar
  2004-12-03 20:58                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0 Ingo Molnar
  2004-11-24 19:23                                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Fernando Lopez-Lezcano
  5 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-24 10:16 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


i have released the -V0.7.30-10 Real-Time Preemption patch, which can be
downloaded from the usual place:

    http://redhat.com/~mingo/realtime-preempt/

this is a fixes-only release.

the most important fixes are the ones to the priority inheritance logic
(affecting the latency of RT tasks), discovered and reported by Esben
Nielsen. I also found two more PI bugs running the new pi_test2 code
from Esben.

Changes since -V0.7.30-9:

 - PI fixes:

   - the waiter->prio field caused wrong priority settings upon unlock, 
     resulting in PI bugs in the nested-locking case.

   - use rt_task() when determining PI tasks, not p->policy.

   - in the blocking-on-blocked-task nesting case both promote now-RT
     tasks to the pi_waiters list and queue them to the head of the wait
     list, and demote now-non-RT tasks from the pi_waiters list and 
     queue them to the tail of the wait list.

 - PI-debugging blocker device update from Esben Nielsen

 - module build fix: export user_trace_stop symbol, this fixes the error 
   reported by Florian Schmidt

 - tracer fix: in the default !freerunning tracing mode, if the trace
   buffer overflows (this is relatively rare, but can happen) then the
   tracer overwrote kernel memory that leads to lockups/kernel crashes. 
   Maybe this bug was also the source of the truncated trace bug
   reported by Mark H. Johnson?

 - reduce tracing overhead within schedule() when !tracing_enabled.

to create a -V0.7.30-10 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm2/2.6.10-rc2-mm2.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm2-V0.7.30-10

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0
  2004-11-24 10:16                                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-10 Ingo Molnar
@ 2004-11-24 11:27                                                                         ` Ingo Molnar
  2004-11-24 19:43                                                                           ` Gene Heskett
  2004-11-25 10:03                                                                           ` Rui Nuno Capela
  2004-12-03 20:58                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0 Ingo Molnar
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-24 11:27 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


i have released the -V0.7.31-0 Real-Time Preemption patch, which can be
downloaded from the usual place:

    http://redhat.com/~mingo/realtime-preempt/

this is a merge of the -30-10 patch to 2.6.10-rc2-mm3. There are no
other changes.

to create a -V0.7.31-0 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/2.6.10-rc2-mm3.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm3-V0.7.31-0

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-1
  2004-11-21  0:32                                                                           ` Lee Revell
@ 2004-11-24 12:15                                                                             ` Ingo Molnar
  2004-11-24 12:28                                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-2 Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-24 12:15 UTC (permalink / raw)
  To: Lee Revell
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Lee Revell <rlrevell@joe-job.com> wrote:

> > i only tried the !PREEMPT version though - does that one work for you? 
> 
> Yup, !PREEMPT works fine.  Testing PREEMPT next.  So far only
> PREEMPT_VOLUNTARY fails to boot.

found a bug that causes !PREEMPT boot failures. The seqlock type was
wrong for the !RT case, resulting in a subtle bug:
write_seqlock_irqsave() didnt actually disable interrupts. This results
in a deadlock scenario in where the timer interrupt interrupts
update_times (which runs in softirq context). I've uploaded the -31-1
patch with this fix included to the usual place:

    http://redhat.com/~mingo/realtime-preempt/

i'm cycling through the various options, but it's looking good so far,
PREEMPT_NONE, PREEMPT_VOLUNTARY and PREEMPT_DESKTOP all booted up fine.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-2
  2004-11-24 12:15                                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-1 Ingo Molnar
@ 2004-11-24 12:28                                                                               ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-24 12:28 UTC (permalink / raw)
  To: Lee Revell
  Cc: linux-kernel, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah


* Ingo Molnar <mingo@elte.hu> wrote:

> > Yup, !PREEMPT works fine.  Testing PREEMPT next.  So far only
> > PREEMPT_VOLUNTARY fails to boot.
> 
> found a bug that causes !PREEMPT boot failures. The seqlock type was
> wrong for the !RT case, resulting in a subtle bug:
> write_seqlock_irqsave() didnt actually disable interrupts. This
> results in a deadlock scenario in where the timer interrupt interrupts
> update_times (which runs in softirq context). I've uploaded the -31-1
> patch with this fix included to the usual place:
> 
>     http://redhat.com/~mingo/realtime-preempt/
> 
> i'm cycling through the various options, but it's looking good so far,
> PREEMPT_NONE, PREEMPT_VOLUNTARY and PREEMPT_DESKTOP all booted up
> fine.

all variations i tried booted up fine. While fixing the non-RT cases a
bug slipped into the PREEMPT_RT branch of seqlock.h though, i fixed that
in the -31-2 patch i just uploaded.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-24  3:45                                                                         ` Ingo Molnar
@ 2004-11-24 13:33                                                                           ` Steven Rostedt
  2004-11-24 15:23                                                                             ` kernel builds starving evolution process - scheduler issue? (was Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9) Lee Revell
  0 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2004-11-24 13:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Lee Revell, LKML, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

On Wed, 2004-11-24 at 04:45 +0100, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:

> > 
> > The symptom is that CPU bound tasks like kernel compiles will starve
> > I/O bound tasks like evolution for a _long_ time.  If I have a kernel
> > build and external modules building at the same time and Evolution
> > goes to "Update message list...", it can sit and spin with a blank
> > message pane for a minute or two.  If I suspend the builds, the
> > message list renders immediately.
> 
> could you try the vanilla -rc2-mm2 kernel (with PREEMPT enabled), does
> it behave in such a way too? At first sight this could be a property of
> the upstream scheduler, but maybe it's special to PREEMPT_RT.
> 

Have you notice this behavior with other interactive (I/O) tasks, such
as bash.  Evolution is quite a big utility, and might be doing something
in the background. If you see the same behavior with bash then there is
no doubt that the compile is slowing down an I/O intensive task.

Another variable can be memory. Are you running this on something with
adequate memory, or is you harddrive churning like mad and you're
constantly thrashing the swap space?
 
-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* kernel builds starving evolution process - scheduler issue? (was Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9)
  2004-11-24 13:33                                                                           ` Steven Rostedt
@ 2004-11-24 15:23                                                                             ` Lee Revell
  0 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-11-24 15:23 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, LKML, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

On Wed, 2004-11-24 at 08:33 -0500, Steven Rostedt wrote:
> On Wed, 2004-11-24 at 04:45 +0100, Ingo Molnar wrote:
> > * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > > 
> > > The symptom is that CPU bound tasks like kernel compiles will starve
> > > I/O bound tasks like evolution for a _long_ time.  If I have a kernel
> > > build and external modules building at the same time and Evolution
> > > goes to "Update message list...", it can sit and spin with a blank
> > > message pane for a minute or two.  If I suspend the builds, the
> > > message list renders immediately.
> > 
> > could you try the vanilla -rc2-mm2 kernel (with PREEMPT enabled), does
> > it behave in such a way too? At first sight this could be a property of
> > the upstream scheduler, but maybe it's special to PREEMPT_RT.
> > 
> 
> Have you notice this behavior with other interactive (I/O) tasks, such
> as bash.  Evolution is quite a big utility, and might be doing something
> in the background. If you see the same behavior with bash then there is
> no doubt that the compile is slowing down an I/O intensive task.
> 

No.  Only evolution (2.0) exhibits the problem.  But, it looks like
evolution uses a comparable amount of CPU to a kernel build just
updating the message list.  All stracing it shows me is that it spends a
hell of a lot of time polling().  I think this might be a bloat issue.

> Another variable can be memory. Are you running this on something with
> adequate memory, or is you harddrive churning like mad and you're
> constantly thrashing the swap space?
>  

No, I have plenty of RAM (512M).  I am using a 600Mhz C3 so the system
is probably CPU bound.  But, it seems like evolution should make a
little more progress.  I often find myself having to background all
build processes for a few seconds to let the message list render.  Once
the list renders, and I resume the builds, evolution is more or less
usable.  Running gtk-gnutella in the background will also make evolution
horribly slow.

Running the offending, CPU bound processes at a high nice value solves
the problem.  But now I am wasting half my fscking cycles "Updating
message list...".   Grr.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-23 17:58                                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Ingo Molnar
                                                                                         ` (4 preceding siblings ...)
  2004-11-24 10:16                                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-10 Ingo Molnar
@ 2004-11-24 19:23                                                                       ` Fernando Lopez-Lezcano
  2004-11-24 22:17                                                                         ` Ingo Molnar
  5 siblings, 1 reply; 951+ messages in thread
From: Fernando Lopez-Lezcano @ 2004-11-24 19:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen

On Tue, 2004-11-23 at 09:58, Ingo Molnar wrote:
> i have released the -V0.7.30-9 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>     http://redhat.com/~mingo/realtime-preempt/
> 
> this is a fixes-only release.

Using PREEMPT_DESKTOP I see a irq related problem with my network
interface:

cat /proc/interrupts
           CPU0       
  0:     134209    IO-APIC-edge  timer  0/34148
  1:        221    IO-APIC-edge  i8042  0/221
  8:          1    IO-APIC-edge  rtc  0/1
  9:          0   IO-APIC-level  acpi  0/0
 11:          0    IO-APIC-edge  radeon@PCI:1:0:0  0/0
 12:       2215    IO-APIC-edge  i8042  0/2215
 14:        650    IO-APIC-edge  ide0  2/648
 16:     100000   IO-APIC-level  eth0  0/0
 17:         59   IO-APIC-level  libata, libata  0/59
 18:          0   IO-APIC-level  ICE1712  0/0
 20:      15160   IO-APIC-level  libata  0/15160
 21:          0   IO-APIC-level  ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd,
uhci_hcd  0/0
NMI:          0 
LOC:     134034 
ERR:          0
MIS:          0

relevant portion of dmesg:
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack version 2.1 (8192 buckets, 65536 max) - 304 bytes per
conntrack
r8169 Gigabit Ethernet driver 1.6LK loaded
ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 16 (level, low) -> IRQ 16
divert: allocating divert_blk for eth0
eth0: Identified chip type is 'RTL8169s/8110s'.
eth0: RTL8169 at 0xf88b6f00, 00:0c:76:b3:c2:43, IRQ 16
IRQ#16 thread RT prio: 40.
hm: ioapic cache empty for irq 16 (e:00000000/d:00010000) 0001a9c1
r8169: eth0: link up
Bluetooth: Core ver 2.7
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.5
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM ver 1.3
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
IRQ#4 thread RT prio: 39.
parport_pc: Ignoring new-style parameters in presence of obsolete ones
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
lp0: using parport0 (polling).
lp0: console ready
NET: Registered protocol family 10
Disabled Privacy Extensions on device c03d7e80(lo)
IPv6 over IPv4 tunneling driver
divert: not allocating divert_blk for non-ethernet device sit0
eth0: no IPv6 routers present
[drm] Initialized radeon 1.11.0 20020828 on minor 0: 
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
[drm] Loading R200 Microcode
IRQ#11 thread RT prio: 38.
irq 16: nobody cared!
 [<c0104173>] dump_stack+0x23/0x30 (20)
 [<c0147970>] __report_bad_irq+0x30/0xa0 (24)
 [<c0147a80>] note_interrupt+0x70/0xb0 (32)
 [<c01477dc>] do_hardirq+0x13c/0x150 (40)
 [<c0147889>] do_irqd+0x99/0xd0 (32)
 [<c0139fda>] kthread+0xaa/0xb0 (48)
 [<c0101335>] kernel_thread_helper+0x5/0x10 (153083924)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c014777a>] .... do_hardirq+0xda/0x150
.....[<c0147889>] ..   ( <= do_irqd+0x99/0xd0)
.. [<c013c98d>] .... print_traces+0x1d/0x60
.....[<c0104173>] ..   ( <= dump_stack+0x23/0x30)

handlers:
[<f892ce60>] (rtl8169_interrupt+0x0/0x140 [r8169])
Disabling IRQ #16
ACPI: PCI interrupt 0000:00:07.0[A] -> GSI 18 (level, low) -> IRQ 18
IRQ#18 thread RT prio: 37.
hm: ioapic cache empty for irq 18 (e:00000000/d:00010000) 0001a9c9


output of lspci -v for the card:
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169
Gigabit Ethernet (rev 10)
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 702c
	Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 16
	I/O ports at d000 [size=cffa0000]
	Memory at cfffef00 (32-bit, non-prefetchable) [size=256]
	Expansion ROM at 00020000 [disabled]
	Capabilities: [dc] Power Management version 2

-- Fernando



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0
  2004-11-24 11:27                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0 Ingo Molnar
@ 2004-11-24 19:43                                                                           ` Gene Heskett
  2004-11-25 10:03                                                                           ` Rui Nuno Capela
  1 sibling, 0 replies; 951+ messages in thread
From: Gene Heskett @ 2004-11-24 19:43 UTC (permalink / raw)
  To: linux-kernel
  Cc: Ingo Molnar, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah, Esben Nielsen

[-- Attachment #1: Type: text/plain, Size: 2406 bytes --]

On Wednesday 24 November 2004 06:27, Ingo Molnar wrote:
>i have released the -V0.7.31-0 Real-Time Preemption patch, which can
> be downloaded from the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/
>
>this is a merge of the -30-10 patch to 2.6.10-rc2-mm3. There are no
>other changes.
>
>to create a -V0.7.31-0 tree from scratch, the patching order is:

Except by the time I got there, it was 31-3.

>  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
> 
> http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz
>2
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-r
>c2/2.6.10-rc2-mm3/2.6.10-rc2-mm3.bz2
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-r
>c2-mm3-V0.7.31-0
>
> Ingo

It built relatively uneventfully, set at 4 for the preempt behaviour, 
and with a couple of minor additions to the dmesg, booted about the 
same.

The keyboard actually feels snappier in kmail as it tends to hang 
pretty bad while spamassassin is running.  So far, everything I've 
tried has just worked, which is a long ways from the last time I 
tried it Ingo, congratulations & a tip of the hat to you.  Its come a 
heck of a long ways in the last 3 weeks.

Now, since this is based on the rc2-mm3 tree, I note that I've got all 
the irq shareing back in place that was fixed for the most part in 
rc2-plain with the kernel argument 'acpi_skip_timer_override', which 
did not seem to be effective for later than 2.6.10-rc2 builds.

I'm also running the cfq scheduler as that also seems to level the cpu 
hogs quite a bit here, although it did slow down the amanda run last 
night (not on this kernel, but -rc2-bk8) by an hour or so since gzip 
was pretty badly starved by cfq.  That doesn't hurt my feelings as 
the machine now remains usable while amanda is running.  Running the 
anticipatory scheduler, amanda made this 2800XP a real sickly dog.

What else can I report on that you would like to see?  Take a look at 
my attached .config and shoot me a list.

Gawd this is smooth!

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.29% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 32680 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-rc2-mm3-V0.7.31-3
# Wed Nov 24 10:29:07 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=16
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
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

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# 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_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
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_HPET_EMULATE_RTC=y
# 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_X86_UP_APIC=y
# CONFIG_X86_UP_IOAPIC is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
CONFIG_X86_CPUID=y

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_KERN_PHYS_OFFSET=1
# 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_BOOT=y
CONFIG_ACPI_INTERPRETER=y
# CONFIG_ACPI_SLEEP is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
CONFIG_ACPI_VIDEO=y
# CONFIG_ACPI_FAN is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=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=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=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

#
# PC-card bridges
#
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_PNPBIOS_PROC_FS=y
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_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_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y

#
# 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 is not set
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 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_IDEPCI_SHARE_IRQ is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
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=y
# 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 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_SCSI=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# 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

#
# 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 is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP 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_QLA6322 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_DM is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER 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

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET 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_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=m
# 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=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_R8169=m
# CONFIG_R8169_NAPI is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# 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

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1600
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1200
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
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

#
# 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=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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=y
CONFIG_SERIAL_8250_NR_UARTS=2
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_MULTIPORT is not set
# CONFIG_SERIAL_8250_RSA is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
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=y
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=y
# CONFIG_IPMI_SI is not set
# CONFIG_IPMI_WATCHDOG is not set
# CONFIG_IPMI_POWEROFF is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
# CONFIG_NVRAM is not set
CONFIG_RTC=y
CONFIG_RTC_HISTOGRAM=y
CONFIG_BLOCKER=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_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 is not set
# CONFIG_AGP_INTEL_MCH is not set
CONFIG_AGP_NVIDIA=y
# 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_GAMMA is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=y
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS 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

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
CONFIG_I2C_ISA=y
CONFIG_I2C_NFORCE2=y
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=y
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
CONFIG_SENSORS_W83781D=y
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
CONFIG_VIDEO_BT848=m
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_ZR36120 is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m

#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
# CONFIG_FB_RADEON_DEBUG is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE is not set

#
# Logo configuration
#
# CONFIG_LOGO is not set

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
# CONFIG_SND_MTPAV is not set
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m

#
# ISA devices
#
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 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=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
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# 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_OHCI_HCD=y
# CONFIG_USB_UHCI_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_RW_DETECT 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_HP8200e 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=y
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
CONFIG_USB_DABUSB=m
CONFIG_USB_VICAM=m
CONFIG_USB_DSBR=m
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_OV511=m
CONFIG_USB_SE401=m
CONFIG_USB_SN9C102=m
CONFIG_USB_STV680=m

#
# 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

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=y
# CONFIG_USB_SERIAL_CONSOLE is not set
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
CONFIG_USB_SERIAL_PL2303=y
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_TEST is not set

#
# USB ATM/DSL drivers
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
# CONFIG_TMPFS is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS is not set
CONFIG_SMB_FS=y
# CONFIG_SMB_NLS_DEFAULT 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

#
# 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=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=y

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_WAKEUP_TIMING=y
CONFIG_PREEMPT_TRACE=y
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
CONFIG_LATENCY_TIMING=y
# CONFIG_LATENCY_TRACE is not set
CONFIG_RT_DEADLOCK_DETECT=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_USE_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
CONFIG_CRC_CCITT=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-24 22:17                                                                         ` Ingo Molnar
@ 2004-11-24 21:56                                                                           ` Fernando Lopez-Lezcano
  0 siblings, 0 replies; 951+ messages in thread
From: Fernando Lopez-Lezcano @ 2004-11-24 21:56 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen

On Wed, 2004-11-24 at 14:17, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:
> 
> > Using PREEMPT_DESKTOP I see a irq related problem with my network
> > interface:

(I don't think this is only with PREEMPT_DESKTOP, on a previous kernel
_RT was giving the same error)

> > IRQ#11 thread RT prio: 38.
> > irq 16: nobody cared!
> >  [<c0104173>] dump_stack+0x23/0x30 (20)
> >  [<c0147970>] __report_bad_irq+0x30/0xa0 (24)
> >  [<c0147a80>] note_interrupt+0x70/0xb0 (32)
> >  [<c01477dc>] do_hardirq+0x13c/0x150 (40)
> >  [<c0147889>] do_irqd+0x99/0xd0 (32)
> >  [<c0139fda>] kthread+0xaa/0xb0 (48)
> >  [<c0101335>] kernel_thread_helper+0x5/0x10 (153083924)
> 
> does it otherwise get detected and does it work fine afterwards?

Anything network related activity hangs (for example, trying to ping).
Otherwise the machine seems to work. 

Same kernel on my laptop loads the network driver with no problems
(different driver, e100), but has problems with the usb uhci-hcd driver.
This is when the driver is loaded:

USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 9 (level, low) -> IRQ 9
uhci_hcd 0000:00:1d.0: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 9, io base 0x1800
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 9 (level, low) -> IRQ 9
uhci_hcd 0000:00:1d.1: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 9, io base 0x1820
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 9 (level, low) -> IRQ 9
uhci_hcd 0000:00:1d.2: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 9, io base 0x1840
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usb 3-1: new full speed USB device using uhci_hcd and address 2
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
inserting floppy driver for 2.6.9-1.520.1rV0.7.30_9.ll.rhfc2.ccrma
inserting floppy driver for 2.6.9-1.520.1rV0.7.30_9.ll.rhfc2.ccrma
  Vendor: Sony      Model: MSC-U03           Rev: 1.00
  Type:   Direct-Access                      ANSI SCSI revision: 00
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
usb-storage: device scan complete
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
uhci_hcd 0000:00:1d.0: remove, state 1
usb usb1: USB disconnect, address 1
Device not ready. Make sure there is a disc in the drive.
Device not ready. Make sure there is a disc in the drive.
inserting floppy driver for 2.6.9-1.520.1rV0.7.30_9.ll.rhfc2.ccrma
uhci_hcd 0000:00:1d.0: USB bus 1 deregistered
uhci_hcd 0000:00:1d.1: remove, state 1
usb usb2: USB disconnect, address 1
Device not ready. Make sure there is a disc in the drive.
Device not ready. Make sure there is a disc in the drive.
inserting floppy driver for 2.6.9-1.520.1rV0.7.30_9.ll.rhfc2.ccrma

Also, after the driver is loaded I get a "subdevfs not supported in
kernel" message when I try to:
  mount -t usbdevfs usbdevfs /proc/bus/usb
But I do have (I think) the right kernel options for this to work...

And this is when I try to remove it:

uhci_hcd 0000:00:1d.1: USB bus 2 deregistered
uhci_hcd 0000:00:1d.2: remove, state 1
usb usb3: USB disconnect, address 1
usb 3-1: USB disconnect, address 2
rmmod/3999: BUG in do_drain at mm/slab.c:1522
 [<c0104173>] dump_stack+0x23/0x30 (20)
 [<c0151fc9>] do_drain+0xb9/0xc0 (44)
 [<c0151ece>] smp_call_function_all_cpus+0x2e/0x70 (28)
 [<c0151ff1>] drain_cpu_caches+0x21/0x90 (24)
 [<c0152079>] __cache_shrink+0x19/0x160 (36)
 [<c01522cf>] kmem_cache_destroy+0xaf/0x1c0 (28)
 [<e094657b>] scsi_destroy_command_freelist+0x6b/0xa0 [scsi_mod] (28)
 [<e0947917>] scsi_host_dev_release+0x37/0xa0 [scsi_mod] (36)
 [<c0271725>] device_release+0x85/0x90 (32)
 [<c01ef505>] kobject_cleanup+0x95/0xa0 (28)
 [<c01f00f5>] kref_put+0x45/0x100 (40)
 [<c01ef556>] kobject_put+0x26/0x30 (16)
 [<e0adfd18>] usb_stor_release_resources+0x78/0x150 [usb_storage] (24)
 [<e0ae0294>] storage_disconnect+0xa4/0xb1 [usb_storage] (20)
 [<c02ba207>] usb_unbind_interface+0x87/0x90 (28)
 [<c0272e46>] device_release_driver+0x86/0x90 (28)
 [<c0273109>] bus_remove_device+0x89/0xd0 (28)
 [<c0271c14>] device_del+0x74/0xb0 (28)
 [<c02c1fd8>] usb_disable_device+0xb8/0x100 (28)
 [<c02bcb76>] usb_disconnect+0xc6/0x1a0 (40)
 [<c02bcc18>] usb_disconnect+0x168/0x1a0 (40)
 [<c02c50d5>] usb_hcd_pci_remove+0x85/0x1c0 (36)
 [<c01fbec6>] pci_device_remove+0x46/0x50 (16)
 [<c0272e46>] device_release_driver+0x86/0x90 (28)
 [<c0272e7b>] driver_detach+0x2b/0x40 (20)
 [<c02733c1>] bus_remove_driver+0x71/0xc0 (28)
 [<c02739e9>] driver_unregister+0x19/0x30 (16)
 [<c01fc15c>] pci_unregister_driver+0x1c/0x30 (16)
 [<e0ac2147>] uhci_hcd_cleanup+0x17/0x68 [uhci_hcd] (16)
 [<c013eec6>] sys_delete_module+0x146/0x190 (96)
 [<c01032a1>] sysenter_past_esp+0x52/0x71 (-8124)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c0151ec3>] .... smp_call_function_all_cpus+0x23/0x70
.....[<c0151ff1>] ..   ( <= drain_cpu_caches+0x21/0x90)
.. [<c013c98d>] .... print_traces+0x1d/0x60
.....[<c0104173>] ..   ( <= dump_stack+0x23/0x30)

inserting floppy driver for 2.6.9-1.520.1rV0.7.30_9.ll.rhfc2.ccrma
inserting floppy driver for 2.6.9-1.520.1rV0.7.30_9.ll.rhfc2.ccrma
uhci_hcd 0000:00:1d.2: USB bus 3 deregistered
rmmod/3999: BUG in do_drain at mm/slab.c:1522
 [<c0104173>] dump_stack+0x23/0x30 (20)
 [<c0151fc9>] do_drain+0xb9/0xc0 (44)
 [<c0151ece>] smp_call_function_all_cpus+0x2e/0x70 (28)
 [<c0151ff1>] drain_cpu_caches+0x21/0x90 (24)
 [<c0152079>] __cache_shrink+0x19/0x160 (36)
 [<c01522cf>] kmem_cache_destroy+0xaf/0x1c0 (28)
 [<e0ac2154>] uhci_hcd_cleanup+0x24/0x68 [uhci_hcd] (16)
 [<c013eec6>] sys_delete_module+0x146/0x190 (96)
 [<c01032a1>] sysenter_past_esp+0x52/0x71 (-8124)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c0151ec3>] .... smp_call_function_all_cpus+0x23/0x70
.....[<c0151ff1>] ..   ( <= drain_cpu_caches+0x21/0x90)
.. [<c013c98d>] .... print_traces+0x1d/0x60
.....[<c0104173>] ..   ( <= dump_stack+0x23/0x30)

-- Fernando



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-24 19:23                                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Fernando Lopez-Lezcano
@ 2004-11-24 22:17                                                                         ` Ingo Molnar
  2004-11-24 21:56                                                                           ` Fernando Lopez-Lezcano
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-24 22:17 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:

> Using PREEMPT_DESKTOP I see a irq related problem with my network
> interface:

> IRQ#11 thread RT prio: 38.
> irq 16: nobody cared!
>  [<c0104173>] dump_stack+0x23/0x30 (20)
>  [<c0147970>] __report_bad_irq+0x30/0xa0 (24)
>  [<c0147a80>] note_interrupt+0x70/0xb0 (32)
>  [<c01477dc>] do_hardirq+0x13c/0x150 (40)
>  [<c0147889>] do_irqd+0x99/0xd0 (32)
>  [<c0139fda>] kthread+0xaa/0xb0 (48)
>  [<c0101335>] kernel_thread_helper+0x5/0x10 (153083924)

does it otherwise get detected and does it work fine afterwards?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0
  2004-11-24 11:27                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0 Ingo Molnar
  2004-11-24 19:43                                                                           ` Gene Heskett
@ 2004-11-25 10:03                                                                           ` Rui Nuno Capela
  2004-11-25 11:13                                                                             ` Ingo Molnar
  2004-11-25 12:01                                                                             ` Ingo Molnar
  1 sibling, 2 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-25 10:03 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen

Ingo Molnar wrote:
>
> i have released the -V0.7.31-0 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
>     http://redhat.com/~mingo/realtime-preempt/
>
> this is a merge of the -30-10 patch to 2.6.10-rc2-mm3. There are no
> other changes.
>

I have a problem. Better said, one half-of-a-problem :)

I've been testing the RT patches on both of my personal machines, one
laptop (P4/UP) and a desktop (P4/SMT). That you probably already know.

On the P4/UP side everything has evolved smoothly, with the only major
quirk now being the loopback device hanging while on mkinitrd. It's not a
system lockup, only the "mkinitrd" and "mount -o loop" processes gets
stuck (distro is Mandrake 10.1c). OTOH, audio performance when regarding
jackd low-latency has reached such levels never dreamt before. To seal my
confidence on the RT I've committed to be the primary kernel that boots by
default and production. I'm happy here, so let's get to the topic.

On the P4/SMP/HT side, history has tought quite a different tale. It was
already late on the VP era when this was even able to boot to the
login-prompt. Then it suffered from all sorts of lockups and starvations
when able to start jackd. Then happily, all that has been ironed out. One
last thing, at the moment, that "reliably" locks up the machine is
accessing the floppy-disk (dev/fd0). Yes, I still have one here, and it
was just yesterday that I've tried to mount on it and bang! power-off and
a cold-boot follows. Reproducibility? ALWAYS is often enough. Nothing
shows up via serial console.

OTOH, my confidence goes down the drain when I compare the jackd
low-latency performance between the latest RT-V0.7.31-3 kernel and the one
supplied from SUSE 9.2 Pro (2.6.8-24). I have been checking and
double-checking this too far many times with even stressful workloads:
SUSE's non-RT kernel has an edge over the latest RT ones. Jackd XRUN rates
are pretty low and on the same level (e.g. less than 5 per hour with the
default jack_test3.1 test), but SUSE's 2.6.8-24 is consistently on par of
RT-V0.7.31-3, and even better if the RT kernel is built with some
preempt-debugging options set.

Is this black-magic or what? :)

Oh well. But let's get back to reality :) How can I help on fixing this
floppy showstopper? I've tried with almost every debug option set and
nothing is dumped either on syslog or serial console. The only visible
thing is that, once the floppy starts spinning (LED is on) the machine
freezes. Weird.

Nuff said.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0
  2004-11-25 11:13                                                                             ` Ingo Molnar
@ 2004-11-25 10:38                                                                               ` Rui Nuno Capela
  2004-11-25 11:44                                                                                 ` Ingo Molnar
  2004-11-25 11:17                                                                               ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-25 10:38 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen

Hi Ingo,

>
> * Rui Nuno Capela wrote:
>
>> last thing, at the moment, that "reliably" locks up the machine is
>> accessing the floppy-disk (dev/fd0). Yes, I still have one here, and
>> it was just yesterday that I've tried to mount on it and bang!
>> power-off and a cold-boot follows. Reproducibility? ALWAYS is often
>> enough. Nothing shows up via serial console.
>
> will take a look.
>

Thanks, as always ;)


>> [...] Jackd XRUN rates are pretty low and on the same level (e.g. less
>> than 5 per hour with the default jack_test3.1 test), [...]
>
> could you post the jack_test summary outputs?
>

Of course, but only later tonight (12 hours from now?). Sorry.


>> Oh well. But let's get back to reality :) How can I help on fixing
>> this floppy showstopper? I've tried with almost every debug option set
>> and nothing is dumped either on syslog or serial console. The only
>> visible thing is that, once the floppy starts spinning (LED is on) the
>> machine freezes. Weird.
>
> how hard of a freeze is it? I.e. if you log in over the text console,
> and do:
>
> 	chrt -f 99 -p `pidof 'IRQ 1'`
> 	chrt -f 99 -p $$
>
> can you access the sysrq keys after the freeze happens?

The lockup is pretty hard indeed. Complete lockup. No sysrq, not even any
output thru serial console. The only action that has some visible effect
is turning the power/reset switch off :)


> If not, can you access them if you do:
>
> 	echo 1 > /proc/sys/kernel/debug_direct_keyboard
>
> ? And finally, if the above experiments suggest that it's a hard lockup,
> do you have a working NMI watchdog? (i.e. do the NMI counts in
> /proc/interrupt increase on all CPUs?)
>

Yes, nmi_watchdog=1 was set but have to double-check if the NMI counts
does really pump on /proc/interrupts. Will retry and check later, again.

Bye.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0
  2004-11-25 11:44                                                                                 ` Ingo Molnar
@ 2004-11-25 10:47                                                                                   ` Rui Nuno Capela
  0 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-25 10:47 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen

Ingo Molnar
>
> * Rui Nuno Capela wrote:
>
>> > how hard of a freeze is it? I.e. if you log in over the text console,
>> > and do:
>> >
>> > 	chrt -f 99 -p `pidof 'IRQ 1'`
>> > 	chrt -f 99 -p $$
>> >
>> > can you access the sysrq keys after the freeze happens?
>>
>> The lockup is pretty hard indeed. Complete lockup. No sysrq, not even
>> any output thru serial console. The only action that has some visible
>> effect is turning the power/reset switch off :)
>
> note that unless you try the above, or the debug_direct_keyboard switch,
> 'soft' lockups will have the same symptoms: no sysrq, no serial console,
> an apparently hung system. So unless you've done the equivalent already,
> please try my suggestions.
>
> 	Ingo
>

Yes Master :)
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0
  2004-11-25 10:03                                                                           ` Rui Nuno Capela
@ 2004-11-25 11:13                                                                             ` Ingo Molnar
  2004-11-25 10:38                                                                               ` Rui Nuno Capela
  2004-11-25 11:17                                                                               ` Ingo Molnar
  2004-11-25 12:01                                                                             ` Ingo Molnar
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-25 11:13 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> last thing, at the moment, that "reliably" locks up the machine is
> accessing the floppy-disk (dev/fd0). Yes, I still have one here, and
> it was just yesterday that I've tried to mount on it and bang!
> power-off and a cold-boot follows. Reproducibility? ALWAYS is often
> enough. Nothing shows up via serial console.

will take a look.

> [...] Jackd XRUN rates are pretty low and on the same level (e.g. less
> than 5 per hour with the default jack_test3.1 test), [...]

could you post the jack_test summary outputs?

> Oh well. But let's get back to reality :) How can I help on fixing
> this floppy showstopper? I've tried with almost every debug option set
> and nothing is dumped either on syslog or serial console. The only
> visible thing is that, once the floppy starts spinning (LED is on) the
> machine freezes. Weird.

how hard of a freeze is it? I.e. if you log in over the text console,
and do:

	chrt -f 99 -p `pidof 'IRQ 1'`
	chrt -f 99 -p $$

can you access the sysrq keys after the freeze happens? If not, can you 
access them if you do:

	echo 1 > /proc/sys/kernel/debug_direct_keyboard

? And finally, if the above experiments suggest that it's a hard lockup,
do you have a working NMI watchdog? (i.e. do the NMI counts in
/proc/interrupt increase on all CPUs?)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0
  2004-11-25 12:01                                                                             ` Ingo Molnar
@ 2004-11-25 11:14                                                                               ` Rui Nuno Capela
  2004-11-25 12:20                                                                                 ` Ingo Molnar
  2004-11-25 14:33                                                                               ` [patch, 2.6.10-rc2] floppy boot-time detection fix Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-11-25 11:14 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen

Ingo Molnar wrote:
>
>
> the -RT patchset doesnt properly detect my fd0 device, so there's
> definitely something broken in that area. The unpatched -rc2-mm3 kernel
> detects it fine. Might be an effect of IRQ threading - the floppy
> hardware/driver is a fragile beast.
>

But it works flawlessly on my laptop (P4/UP). Could it be SMP/HT related?

-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0
  2004-11-25 11:13                                                                             ` Ingo Molnar
  2004-11-25 10:38                                                                               ` Rui Nuno Capela
@ 2004-11-25 11:17                                                                               ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-25 11:17 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen


* Ingo Molnar <mingo@elte.hu> wrote:

> > [...] Jackd XRUN rates are pretty low and on the same level (e.g. less
> > than 5 per hour with the default jack_test3.1 test), [...]
> 
> could you post the jack_test summary outputs?

also, could you change JACKD_PRIO from 20 to 50? Otherwise normal IRQ
handlers (IDE, etc.) will preempt jackd.

(the test-clients inherit this prio 50 setting, right?)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0
  2004-11-25 10:38                                                                               ` Rui Nuno Capela
@ 2004-11-25 11:44                                                                                 ` Ingo Molnar
  2004-11-25 10:47                                                                                   ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-25 11:44 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> > how hard of a freeze is it? I.e. if you log in over the text console,
> > and do:
> >
> > 	chrt -f 99 -p `pidof 'IRQ 1'`
> > 	chrt -f 99 -p $$
> >
> > can you access the sysrq keys after the freeze happens?
> 
> The lockup is pretty hard indeed. Complete lockup. No sysrq, not even
> any output thru serial console. The only action that has some visible
> effect is turning the power/reset switch off :)

note that unless you try the above, or the debug_direct_keyboard switch,
'soft' lockups will have the same symptoms: no sysrq, no serial console,
an apparently hung system. So unless you've done the equivalent already,
please try my suggestions.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0
  2004-11-25 10:03                                                                           ` Rui Nuno Capela
  2004-11-25 11:13                                                                             ` Ingo Molnar
@ 2004-11-25 12:01                                                                             ` Ingo Molnar
  2004-11-25 11:14                                                                               ` Rui Nuno Capela
  2004-11-25 14:33                                                                               ` [patch, 2.6.10-rc2] floppy boot-time detection fix Ingo Molnar
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-25 12:01 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen



the -RT patchset doesnt properly detect my fd0 device, so there's
definitely something broken in that area. The unpatched -rc2-mm3 kernel
detects it fine. Might be an effect of IRQ threading - the floppy
hardware/driver is a fragile beast.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0
  2004-11-25 11:14                                                                               ` Rui Nuno Capela
@ 2004-11-25 12:20                                                                                 ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-25 12:20 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> Ingo Molnar wrote:
> >
> > the -RT patchset doesnt properly detect my fd0 device, so there's
> > definitely something broken in that area. The unpatched -rc2-mm3 kernel
> > detects it fine. Might be an effect of IRQ threading - the floppy
> > hardware/driver is a fragile beast.
> >
> 
> But it works flawlessly on my laptop (P4/UP). Could it be SMP/HT
> related?

yeah, could be, the failure i'm seeing is on SMP. On SMP if you have
interrupt threads then concurrency is higher. fd0 gets detected fine
when i turn IRQ threading off.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch, 2.6.10-rc2] floppy boot-time detection fix
  2004-11-25 12:01                                                                             ` Ingo Molnar
  2004-11-25 11:14                                                                               ` Rui Nuno Capela
@ 2004-11-25 14:33                                                                               ` Ingo Molnar
  2004-11-25 14:44                                                                                 ` Ingo Molnar
                                                                                                   ` (2 more replies)
  1 sibling, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-25 14:33 UTC (permalink / raw)
  To: Rui Nuno Capela; +Cc: linux-kernel, Andrew Morton, Linus Torvalds


* Ingo Molnar <mingo@elte.hu> wrote:

> the -RT patchset doesnt properly detect my fd0 device, so there's
> definitely something broken in that area. The unpatched -rc2-mm3
> kernel detects it fine. Might be an effect of IRQ threading - the
> floppy hardware/driver is a fragile beast.

found the bug that causes the fd detection failure. It's a generic race
in the upstream floppy driver, which happens to work by chance in the
vanilla kernel but breaks when IRQ and softirq threading is enabled:

when the FDC hardware is initialized, it sometimes generates a floppy
interrupt right away - without being told to. This interrupt can hit the
detection code that executes right after the initialization code, in
particular it can get intermixed with user_reset_fdc() that the
detection code uses. The fd driver is fundamentally single-threaded when
it comes to handling events: an unexpected irq that arrives in the wrong
moment can confuse the reset_fdc() code, which, with softirq and hardirq
threading on, executes in keventd.

in the stock kernel this stale irq doesnt seem to hit the detection code
in the wrong moment, but i think under certain circumstances it may
still happen. One of the typical incarnations of the race was the
following message:

 reset set in interrupt, calling c0258400

and googling for "reset set in interrupt, calling" does turn up a fair
number of bootlogs (most of them 2.4 ones) that show such a detection
failure, so i think upstream wants to have the fix too.

the fix is simple: delay a bit after initialization, to make sure the
stale irq does not interfere with the detection code. It will be safely
ignored, since do_floppy is still NULL. It might look sloppy that i went
for a delay, but delay i think it is better than waiting for the irq to
occur, because i dont think there's a guarantee that fdc initialization
triggers an interrupt, so waiting for it could hang the boot process. A
delay OTOH is totally harmless.

The attached patch implements this fix, which resolves the detection
problem on my testbox.

here's again how a failure looks like:

 Floppy drive(s): fd0 is 1.44M
 reset set in interrupt, calling c0258400
 floppy0: no floppy controllers found

and this is how it works with the fix:

 Floppy drive(s): fd0 is 1.44M
 FDC 0 is a post-1991 82077

i've tested this on vanilla 2.6.10-rc2-mm3 too (to make sure this doesnt
break the floppy driver), and it should work fine in -BK too.

(this does not solve the irq threading related SMP lockup though, i'm
attacking that problem next - now that my fd0 gets detected fine ;-) )

	Ingo

Signed-off-by: Ingo Molnar <mingo@elte.hu>

--- linux/drivers/block/floppy.c.orig
+++ linux/drivers/block/floppy.c
@@ -4504,6 +4578,13 @@ int __init floppy_init(void)
 		floppy_track_buffer = NULL;
 		max_buffer_sectors = 0;
 	}
+	/*
+	 * Small 10 msec delay to let through any interrupt that
+	 * initialization might have triggered, to not
+	 * confuse detection:
+	 */
+	current->state = TASK_UNINTERRUPTIBLE;
+	schedule_timeout(HZ/100 + 1);
 
 	for (i = 0; i < N_FDC; i++) {
 		fdc = i;

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch, 2.6.10-rc2] floppy boot-time detection fix
  2004-11-25 14:33                                                                               ` [patch, 2.6.10-rc2] floppy boot-time detection fix Ingo Molnar
@ 2004-11-25 14:44                                                                                 ` Ingo Molnar
  2004-11-25 14:48                                                                                 ` Ingo Molnar
  2004-11-25 15:00                                                                                 ` Arjan van de Ven
  2 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-25 14:44 UTC (permalink / raw)
  To: Rui Nuno Capela; +Cc: linux-kernel, Andrew Morton, Linus Torvalds


> +	current->state = TASK_UNINTERRUPTIBLE;
> +	schedule_timeout(HZ/100 + 1);

should use msleep() of course:

Signed-off-by: Ingo Molnar <mingo@elte.hu>

--- linux/drivers/block/floppy.c.orig
+++ linux/drivers/block/floppy.c
@@ -4504,6 +4504,12 @@ int __init floppy_init(void)
 		floppy_track_buffer = NULL;
 		max_buffer_sectors = 0;
 	}
+	/*
+	 * Small 10 msec delay to let through any interrupt that
+	 * initialization might have triggered, to not
+	 * confuse detection:
+	 */
+	msleep(10);
 
 	for (i = 0; i < N_FDC; i++) {
 		fdc = i;

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch, 2.6.10-rc2] floppy boot-time detection fix
  2004-11-25 14:33                                                                               ` [patch, 2.6.10-rc2] floppy boot-time detection fix Ingo Molnar
  2004-11-25 14:44                                                                                 ` Ingo Molnar
@ 2004-11-25 14:48                                                                                 ` Ingo Molnar
  2004-11-25 15:27                                                                                   ` Ingo Molnar
  2004-11-25 15:00                                                                                 ` Arjan van de Ven
  2 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-11-25 14:48 UTC (permalink / raw)
  To: Rui Nuno Capela; +Cc: linux-kernel, Andrew Morton, Linus Torvalds


* Ingo Molnar <mingo@elte.hu> wrote:

> (this does not solve the irq threading related SMP lockup though, i'm
> attacking that problem next - now that my fd0 gets detected fine ;-) )

in fact, i cannot reproduce the SMP lockup anymore and the floppy works
just fine. Maybe the stale irq, even if detection went fine,
mis-programmed the controller, which ended up totally locking up upon
the first attempted IO?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch, 2.6.10-rc2] floppy boot-time detection fix
  2004-11-25 14:33                                                                               ` [patch, 2.6.10-rc2] floppy boot-time detection fix Ingo Molnar
  2004-11-25 14:44                                                                                 ` Ingo Molnar
  2004-11-25 14:48                                                                                 ` Ingo Molnar
@ 2004-11-25 15:00                                                                                 ` Arjan van de Ven
  2 siblings, 0 replies; 951+ messages in thread
From: Arjan van de Ven @ 2004-11-25 15:00 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Rui Nuno Capela, linux-kernel, Andrew Morton, Linus Torvalds

On Thu, Nov 25, 2004 at 03:33:37PM +0100, Ingo Molnar wrote:
> --- linux/drivers/block/floppy.c.orig
> +++ linux/drivers/block/floppy.c
> @@ -4504,6 +4578,13 @@ int __init floppy_init(void)
>  		floppy_track_buffer = NULL;
>  		max_buffer_sectors = 0;
>  	}
> +	/*
> +	 * Small 10 msec delay to let through any interrupt that
> +	 * initialization might have triggered, to not
> +	 * confuse detection:
> +	 */
> +	current->state = TASK_UNINTERRUPTIBLE;
> +	schedule_timeout(HZ/100 + 1);


how about using msleep() ?

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch, 2.6.10-rc2] floppy boot-time detection fix
  2004-11-25 14:48                                                                                 ` Ingo Molnar
@ 2004-11-25 15:27                                                                                   ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-25 15:27 UTC (permalink / raw)
  To: Rui Nuno Capela; +Cc: linux-kernel, Andrew Morton, Linus Torvalds


* Ingo Molnar <mingo@elte.hu> wrote:

> > (this does not solve the irq threading related SMP lockup though, i'm
> > attacking that problem next - now that my fd0 gets detected fine ;-) )
> 
> in fact, i cannot reproduce the SMP lockup anymore and the floppy works
> just fine. [...]

it turns out that this was the side-effect of me doing idle=poll.

The reason for the lockup was a bug in the -RT patch, it broke
disable_hlt() which resulted in all CPUs spinning in idle with
interrupts disabled - with an obvious hard lockup as a result.
Fixed it in my tree.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-11-23 14:41                                                                                           ` Florian Schmidt
@ 2004-12-01 13:57                                                                                             ` Paul Davis
  2004-12-01 14:37                                                                                               ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Paul Davis @ 2004-12-01 13:57 UTC (permalink / raw)
  To: Florian Schmidt
  Cc: Ingo Molnar, Rui Nuno Capela, linux-kernel, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah, Esben Nielsen

>On Tue, 23 Nov 2004 16:21:26 +0100
>Ingo Molnar <mingo@elte.hu> wrote:
>
>> 
>> * Florian Schmidt <mista.tapas@gmx.net> wrote:
>> 
>> > ~$ ps -C jack_test -cmL
>> >   PID   LWP CLS PRI TTY          TIME CMD
>> >   988     - -     - pts/1    00:00:00  jack_test
>> >     -   988 TS   20 -        00:00:00 -
>> >     -   989 FF   99 -        00:00:00 -
>> > 
>> > So when you ctrl-z out of jack_test you cause its process() thread to
>> > be suspended, too, thus jackd cannot finish processing its graph.
>> 
>> so in theory any scheduling delay of PID 988 in the above setup (the
>> SCHED_OTHER task) should not be able to negatively influence jackd,
>> correct? 
>
>correct
>
>> In fact, does in this particular jack_test case PID 988 do
>> anything substantial?
>
>Well, it registers the client with jackd, sets up the ports, registers
>the process() callback and then simply goes to sleep() for the desired
>runtime of the program. All these are non RT ops and should never be
>able to cause any xruns.
>
>All the work is done by the process() callback which is called by
>libjack in a SCHED_FIFO thread. The process() callback is called once
>for each buffer that jackd processes.
>
>I cannot explain the detailed mechanism of how jackd wakes its clients
>and communicates with them myself too well, so i'll leave this to Paul
>Davis (CC'ed). Care to elaborate, Paul?

sorry for the delay on this, it ended up in a mail folder that i don't
check very often.

jackd wakes clients by writing a single byte to a FIFO. the first
client is sleeping on the other side of the FIFO. when that client is
done, it writes a single byte to another FIFO. either another client
is sleeping on the other side of that FIFO, or if there are no other
clients, jackd is waiting for the client there.

the "chain" of wakeup FIFOs is rearranged every time the graph
execution order is modified (e.g. by new connections being established
between clients that requires a different execution order).

the chain is executed every time jackd is woken by its "backend"
client, typically the ALSA client that waits on the fd's corresponding
to an audio interface to be readable and/or writable. in other words,
every interrupt from the audio interface.

we know that writes to FIFOs are not really RT-safe, but they are the
closest thing linux has at this time. i have outlined an idea to ingo
that florian and i cooked up one evening on IRC that would provide
true RT-safe IPC mechanisms, but as i recall, he didn't seem to think
that much of it :)

--p

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-12-01 13:57                                                                                             ` Paul Davis
@ 2004-12-01 14:37                                                                                               ` Ingo Molnar
  2004-12-01 14:56                                                                                                 ` Paul Davis
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-12-01 14:37 UTC (permalink / raw)
  To: Paul Davis
  Cc: Florian Schmidt, Rui Nuno Capela, linux-kernel, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah, Esben Nielsen


* Paul Davis <paul@linuxaudiosystems.com> wrote:

> we know that writes to FIFOs are not really RT-safe, [...]

in kernels -V0.7.30-9 or later they are RT-safe when PREEMPT_RT is
enabled.

also, the problem is that jackd uses _named_ fifos, which are tied to
the raw FS and might trigger journalling activities. Normal pipes
(unnamed fifos) would not cause such problems. Would it be possible to
change jackd to use a pair of pipes, instead of a fifo?

> [...] i have outlined an idea to ingo that florian and i cooked up one
> evening on IRC that would provide true RT-safe IPC mechanisms, but as
> i recall, he didn't seem to think that much of it :)

actually, my answer (sent on Nov 1) was:

> futexes are nearly lock-free. [and even those locks are short-held so
> combined with priority-inheritance they should be lockfree in
> essence.] Would futexes suit your purposes?

to which suggestion i got no reply yet :-)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-12-01 14:37                                                                                               ` Ingo Molnar
@ 2004-12-01 14:56                                                                                                 ` Paul Davis
  2004-12-01 15:53                                                                                                   ` Ingo Molnar
  2004-12-01 16:08                                                                                                   ` Esben Nielsen
  0 siblings, 2 replies; 951+ messages in thread
From: Paul Davis @ 2004-12-01 14:56 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Florian Schmidt, Rui Nuno Capela, linux-kernel, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah, Esben Nielsen

>in kernels -V0.7.30-9 or later they are RT-safe when PREEMPT_RT is
>enabled.

thats good to hear.

>also, the problem is that jackd uses _named_ fifos, which are tied to
>the raw FS and might trigger journalling activities. Normal pipes
>(unnamed fifos) would not cause such problems. Would it be possible to
>change jackd to use a pair of pipes, instead of a fifo?

i.e. pipe(2) rather than mkfifo(2) ?

it would be a complete pain because the pipes have to be
"discoverable" across processes. we would have to do fd passing, which
is still really quite ugly in linux (and other *nix systems). it
would quite difficult, though not impossible.

>> [...] i have outlined an idea to ingo that florian and i cooked up one
>> evening on IRC that would provide true RT-safe IPC mechanisms, but as
>> i recall, he didn't seem to think that much of it :)
>
>actually, my answer (sent on Nov 1) was:
>
>> futexes are nearly lock-free. [and even those locks are short-held so
>> combined with priority-inheritance they should be lockfree in
>> essence.] Would futexes suit your purposes?
>
>to which suggestion i got no reply yet :-)

i am still trying to find the time to investigate futexes. they seem
close to the desired object, but have a slightly more general semantic
than i can fit into my head right now;)

--p

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-12-01 14:56                                                                                                 ` Paul Davis
@ 2004-12-01 15:53                                                                                                   ` Ingo Molnar
  2004-12-01 16:05                                                                                                     ` Paul Davis
  2004-12-01 16:16                                                                                                     ` Esben Nielsen
  2004-12-01 16:08                                                                                                   ` Esben Nielsen
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-01 15:53 UTC (permalink / raw)
  To: Paul Davis
  Cc: Florian Schmidt, Rui Nuno Capela, linux-kernel, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah, Esben Nielsen


* Paul Davis <paul@linuxaudiosystems.com> wrote:

> >also, the problem is that jackd uses _named_ fifos, which are tied to
> >the raw FS and might trigger journalling activities. Normal pipes
> >(unnamed fifos) would not cause such problems. Would it be possible to
> >change jackd to use a pair of pipes, instead of a fifo?
> 
> i.e. pipe(2) rather than mkfifo(2) ?
> 
> it would be a complete pain because the pipes have to be
> "discoverable" across processes. we would have to do fd passing, which
> is still really quite ugly in linux (and other *nix systems). it would
> quite difficult, though not impossible.

yeah. And i think mkfifo(2) objects ought to behave atomically as well,
it's an unfortunate side-effect of atime/mtime inode semantics that they
can block.

your point is correct, the best way to have a system-wide namespace for
synchronization objects is ... the filesystem hierarchy. If you create a
unix domain socket then you can distribute your pipe fds, but that's
indeed somewhat painful.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-12-01 15:53                                                                                                   ` Ingo Molnar
@ 2004-12-01 16:05                                                                                                     ` Paul Davis
  2004-12-01 16:16                                                                                                     ` Esben Nielsen
  1 sibling, 0 replies; 951+ messages in thread
From: Paul Davis @ 2004-12-01 16:05 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Florian Schmidt, Rui Nuno Capela, linux-kernel, Lee Revell,
	mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah, Esben Nielsen

>your point is correct, the best way to have a system-wide namespace for
>synchronization objects is ... the filesystem hierarchy. If you create a
>unix domain socket then you can distribute your pipe fds, but that's
>indeed somewhat painful.

this is where Mach ports come in. they were designed to be passed
around from process to process, painlessly, but without any system
wide namespace. you can create ports that can be looked up by anyone,
but not all ports are required meet this condition. this makes it easy
to set up a private communication channel between two processes.

a bit like futexes :)

--p


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-12-01 14:56                                                                                                 ` Paul Davis
  2004-12-01 15:53                                                                                                   ` Ingo Molnar
@ 2004-12-01 16:08                                                                                                   ` Esben Nielsen
  1 sibling, 0 replies; 951+ messages in thread
From: Esben Nielsen @ 2004-12-01 16:08 UTC (permalink / raw)
  To: Paul Davis
  Cc: Ingo Molnar, Florian Schmidt, Rui Nuno Capela, linux-kernel,
	Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


On Wed, 1 Dec 2004, Paul Davis wrote:

> [...]
> >
> >> futexes are nearly lock-free. [and even those locks are short-held so
> >> combined with priority-inheritance they should be lockfree in
> >> essence.] Would futexes suit your purposes?
> >
> >to which suggestion i got no reply yet :-)
> 
> i am still trying to find the time to investigate futexes. they seem
> close to the desired object, but have a slightly more general semantic
> than i can fit into my head right now;)
>

I looked into them just to see if they could be used for user-space
priority inheritance. I saw that it takes (read-)lock on mmap_sem.
Isn't that potentially held for a long time? I don't know how the memory
subsystem works at all but my guess is that any changing of the process's
memory is done with mmpa_sem locked. The only way to prevent that is 1)
mlockall() and 2) stop increasing your heap.

I.e. you can't have one thread running real-time using a futex while
another runs non-real-time allocating memory in the same process.

Am I correct?

Another problem is the hashing of the futex. That inherently has a
non-deterministic timing behaviour. The more applications use futex'es
the slower this hashing gets :-( The slowdown might in practise be very
low because looking up in the global hash table can't take very many us!

Can't it just use a file-descriptor in the system call to look up the
futex instead of the hashing? That is RT-O(1), right? But, ofcourse, then
it is hard having a futex in shared mem.

 
> --p

Esben


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-12-01 15:53                                                                                                   ` Ingo Molnar
  2004-12-01 16:05                                                                                                     ` Paul Davis
@ 2004-12-01 16:16                                                                                                     ` Esben Nielsen
  2004-12-01 21:24                                                                                                       ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Esben Nielsen @ 2004-12-01 16:16 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Paul Davis, Florian Schmidt, Rui Nuno Capela, linux-kernel,
	Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


On Wed, 1 Dec 2004, Ingo Molnar wrote:

> 
> * Paul Davis <paul@linuxaudiosystems.com> wrote:
> 
> > >also, the problem is that jackd uses _named_ fifos, which are tied to
> > >the raw FS and might trigger journalling activities. Normal pipes
> > >(unnamed fifos) would not cause such problems. Would it be possible to
> > >change jackd to use a pair of pipes, instead of a fifo?
> > 
> > i.e. pipe(2) rather than mkfifo(2) ?
> > 
> > it would be a complete pain because the pipes have to be
> > "discoverable" across processes. we would have to do fd passing, which
> > is still really quite ugly in linux (and other *nix systems). it would
> > quite difficult, though not impossible.
> 
> yeah. And i think mkfifo(2) objects ought to behave atomically as well,
> it's an unfortunate side-effect of atime/mtime inode semantics that they
> can block.
> 
> your point is correct, the best way to have a system-wide namespace for
> synchronization objects is ... the filesystem hierarchy. If you create a
> unix domain socket then you can distribute your pipe fds, but that's
> indeed somewhat painful.
> 

Don't worry about setting up the stuff. Once you have the pipe it ought to
be RT in the usage of read/write,  but setting it up is something you is
something you do "under boot", just as allocating memory and other
non-real-time stuff. 


> 	Ingo
> 

Esben


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-12-01 16:16                                                                                                     ` Esben Nielsen
@ 2004-12-01 21:24                                                                                                       ` Ingo Molnar
  2004-12-01 21:40                                                                                                         ` Chris Friesen
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-12-01 21:24 UTC (permalink / raw)
  To: Esben Nielsen
  Cc: Paul Davis, Florian Schmidt, Rui Nuno Capela, linux-kernel,
	Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Esben Nielsen <simlo@phys.au.dk> wrote:

> Don't worry about setting up the stuff. Once you have the pipe it
> ought to be RT in the usage of read/write, but setting it up is
> something you is something you do "under boot", just as allocating
> memory and other non-real-time stuff. 

actually, the main problem with fifos was they were _not_ atomic even in
read/write (i myself fully expected them to be that, but they arent). 
That's the bug/misfeature that i fixed in the latest kernels.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
  2004-12-01 21:24                                                                                                       ` Ingo Molnar
@ 2004-12-01 21:40                                                                                                         ` Chris Friesen
  0 siblings, 0 replies; 951+ messages in thread
From: Chris Friesen @ 2004-12-01 21:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Esben Nielsen, Paul Davis, Florian Schmidt, Rui Nuno Capela,
	linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah

Ingo Molnar wrote:

> actually, the main problem with fifos was they were _not_ atomic even in
> read/write (i myself fully expected them to be that, but they arent). 
> That's the bug/misfeature that i fixed in the latest kernels.

Whoa.  pipes (ie from the pipe() call) don't read/write atomicly? Even if you 
write less than a page?

When was this fixed?

Chris

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-11-24 10:16                                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-10 Ingo Molnar
  2004-11-24 11:27                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0 Ingo Molnar
@ 2004-12-03 20:58                                                                         ` Ingo Molnar
  2004-12-03 21:04                                                                           ` Ingo Molnar
                                                                                             ` (3 more replies)
  1 sibling, 4 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-03 20:58 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


i have released the -V0.7.32-0 Real-Time Preemption patch, which can be
downloaded from the usual place:

	http://redhat.com/~mingo/realtime-preempt/

this is a fixes-mostly release with one new feature:

implemented global RT-task balancing on SMP systems, which improves the
latency of RT tasks on SMP systems. The basic problem was that the 2.6
kernel has per-CPU runqueues. In the current design there is no
guarantee that if an RT task starves another, lower-prio (or same-prio)
RT task in a given local runqueue, that the starved task will ever be
migrated to another CPU: it has to wait for the higher-prio task to
finish. In short, task migration on SMP is fundamentally non-RT and
priority-insensitive. In particular the workloads and latencies reported
by Mark H. Johnson reflect such SMP scheduling artifacts.

the new global RT-task balancing feature solves this problem by tracking
the 'RT overload' situation (when there is more than one RT tasks on a
CPU) and makes other CPUs 'pull' RT tasks (and only RT tasks)
immediately when such a situation occurs.

To give an example, in the following scheduling scenario:

  CPU#0					CPU#1

  task-A SCHED_FIFO prio 30		task-C SCHED_FIFO prio 30 [curr]
  task-B SCHED_FIFO prio 40 [curr]

task-B is the currently executing task on CPU#0, task-C is the currently
executing task on CPU#1. Now on the vanilla 2.6 kernel, if task-C
blocks, there's no guarantee that task-A will be run there - if there's
a SCHED_NORMAL task on CPU#1's runqueue then it will run indefinitely. 
With global RT-balancing task-A will be scheduled on CPU#1 immediately
after task-C leaves it.

furthermore, if in the same scenario, if e.g. a RT-prio 35 task-D is
woken up on CPU#0, the vanilla 2.6 scheduler will not move it to CPU#1,
even though it could preempt the prio 30 task-C there. With global
RT-balancing this will happen and task-C will be preempted immediately
and task-D runs.

on low RT load (the common case) the scheduler behaves like the stock
scheduler - the new logic only kicks in if a CPU runqueue has 2 or more
RT tasks running at once.

anyway, while the feature is stable on my SMP testboxes, this is still a
nontrivial ~200-lines delta in the scheduler so there might be problems. 
UP should not be affected by this.

other changes since -V0.7.32-20:

 - local-APIC shutdown fix: this should solve some of the 'reboot hangs' 
   reports.

 - more tracing fixes - might fix the 'truncated traces' problems.

 - reduce the NMI watchdog frequency from 10 KHz to 1000 Hz.

 - dont report futex reschedules as atomicity violations

to create a -V0.7.32-0 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm2/2.6.10-rc2-mm2.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm2-V0.7.32-0

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-12-03 20:58                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0 Ingo Molnar
@ 2004-12-03 21:04                                                                           ` Ingo Molnar
  2004-12-04 22:32                                                                           ` Rui Nuno Capela
                                                                                             ` (2 subsequent siblings)
  3 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-03 21:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


> to create a -V0.7.32-0 tree from scratch, the patching order is:

that should read:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/2.6.10-rc2-mm3.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm3-V0.7.32-0

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-12-03 20:58                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0 Ingo Molnar
  2004-12-03 21:04                                                                           ` Ingo Molnar
@ 2004-12-04 22:32                                                                           ` Rui Nuno Capela
  2004-12-04 22:46                                                                             ` Ingo Molnar
  2004-12-05  3:05                                                                             ` Gene Heskett
  2004-12-05 23:14                                                                           ` Esben Nielsen
  2004-12-07 13:29                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-4 Ingo Molnar
  3 siblings, 2 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-12-04 22:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen

Ingo Molnar wrote:
>
> i have released the -V0.7.32-0 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>

I have a bug to report, it shows on both of my machines (SMP and UP) now
running RT-V0.7.32-2. It seems to be present also on previous RT releases,
and don't even know if it's upstream.

When one usb-storage flash stick is first time unplugged:

usb 4-6: USB disconnect, address 4
slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free all
objects
 [<c010361f>] dump_stack+0x23/0x25 (20)
 [<c01467d7>] kmem_cache_destroy+0x103/0x1aa (28)
 [<c026e77a>] scsi_destroy_command_freelist+0x97/0xa8 (28)
 [<c026f5b1>] scsi_host_dev_release+0x37/0xe1 (104)
 [<c023c6a9>] device_release+0x7a/0x7c (32)
 [<c01efd90>] kobject_cleanup+0x87/0x89 (28)
 [<c01f07eb>] kref_put+0x52/0xef (40)
 [<c01efdcc>] kobject_put+0x25/0x27 (16)
 [<f8cf1843>] usb_stor_release_resources+0x66/0xca [usb_storage] (16)
 [<f8cf1d93>] storage_disconnect+0x8e/0x9b [usb_storage] (16)
 [<f89ca117>] usb_unbind_interface+0x84/0x86 [usbcore] (28)
 [<c023d915>] device_release_driver+0x75/0x77 (28)
 [<c023db18>] bus_remove_device+0x53/0x82 (20)
 [<c023cae1>] device_del+0x4b/0x9b (20)
 [<f89d142a>] usb_disable_device+0xf5/0x10a [usbcore] (28)
 [<f89cc61c>] usb_disconnect+0xc8/0x164 [usbcore] (40)
 [<f89cd77e>] hub_port_connect_change+0x2ef/0x426 [usbcore] (56)
 [<f89cda7b>] hub_events+0x1c6/0x39d [usbcore] (56)
 [<f89cdc89>] hub_thread+0x37/0x109 [usbcore] (96)
 [<c01009b1>] kernel_thread_helper+0x5/0xb (142893076)


Then, just when the same is plugged in again:

usb 4-6: new high speed USB device using ehci_hcd and address 5
kmem_cache_create: duplicate cache scsi_cmd_cache
BUG at mm/slab.c:1447!
------------[ cut here ]------------
kernel BUG at mm/slab.c:1447!
invalid operand: 0000 [#1]
PREEMPT SMP
Modules linked in: nls_utf8 nls_cp860 vfat fat nls_base usb_storage
ohci1394 ieee1394 ehci_hcd usbhid uhci_hcd intel_mch_agp agpgart evdev
wacom snd_pcm_oss snd_mixer_oss snd_seq_midi snd_seq_midi_event snd_seq
snd_usb_usx2y snd_usb_lib snd_hwdep snd_cs46xx snd_rawmidi snd_seq_device
snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc
realtime commoncap w83781d i2c_sensor i2c_isa i2c_i801 i2c_core sk98lin
subfs dm_mod usbcore
CPU:    1
EIP:    0060:[<c01462e9>]    Not tainted VLI
EFLAGS: 00010286   (2.6.10-rc2-mm3-RT-V0.7.32-2.0smp)
EIP is at kmem_cache_create+0x4df/0x69c
eax: 00000017   ebx: f7cd9710   ecx: c05c5d00   edx: f77b8000
esi: c030973a   edi: c030973a   ebp: f77b9d10   esp: f77b9cd8
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process khubd (pid: 1477, threadinfo=f77b8000 task=f777c2b0)
Stack: c02f2054 c02f63aa 000005a7 00000565 f77b9d00 f7cd10c0 c0000000
ffffff80
       00000001 f7cd1080 00000080 c03418a0 f7000400 f7000428 f77b9d3c
c026e662
       c030972b 00000180 00000080 00002000 00000000 00000000 f7000490
00000000
Call Trace:
 [<c01035f4>] show_stack+0xb4/0xbc (28)
 [<c010378a>] show_registers+0x169/0x1de (56)
 [<c010399c>] die+0x10b/0x191 (68)
 [<c0103e19>] do_invalid_op+0xba/0xc4 (204)
 [<c0103237>] error_code+0x2b/0x30 (116)
 [<c026e662>] scsi_setup_command_freelist+0x94/0x115 (44)
 [<c026f8ca>] scsi_host_alloc+0x26f/0x399 (124)
 [<f8cf173f>] usb_stor_acquire_resources+0x6c/0x10a [usb_storage] (28)
 [<f8cf1c64>] storage_probe+0x1b8/0x259 [usb_storage] (40)
 [<f89ca07a>] usb_probe_interface+0x62/0x7b [usbcore] (28)
 [<c023d723>] driver_probe_device+0x2f/0x70 (24)
 [<c023d7ae>] device_attach+0x4a/0xa5 (40)
 [<c023da89>] bus_add_device+0x4d/0x89 (28)
 [<c023c9a6>] device_add+0xb1/0x137 (40)
 [<f89d1ba6>] usb_set_configuration+0x3ca/0x444 [usbcore] (84)
 [<f89cc822>] usb_new_device+0xa5/0x164 [usbcore] (44)
 [<f89cd6b0>] hub_port_connect_change+0x221/0x426 [usbcore] (56)
 [<f89cda7b>] hub_events+0x1c6/0x39d [usbcore] (56)
 [<f89cdc89>] hub_thread+0x37/0x109 [usbcore] (96)
 [<c01009b1>] kernel_thread_helper+0x5/0xb (142893076)
Code: e8 57 5e fd ff b8 08 4f be c0 e8 c0 d1 fe ff c7 44 24 08 a7 05 00 00
c7 44 24 04 aa 63 2f c0 c7 04 24 54 20 2f c0 e8 31 5e fd ff <0f> 0b a7 05
aa 63 2f c0 eb b9 a1 44 1a 33 c0 c7 44 24 04 d0 00


After this, any USB related operation is doomed, if not the entire system.

Bye.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-12-04 22:32                                                                           ` Rui Nuno Capela
@ 2004-12-04 22:46                                                                             ` Ingo Molnar
  2004-12-04 23:38                                                                               ` Rui Nuno Capela
  2004-12-04 23:55                                                                               ` K.R. Foley
  2004-12-05  3:05                                                                             ` Gene Heskett
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-04 22:46 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen


* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> Ingo Molnar wrote:
> >
> > i have released the -V0.7.32-0 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> >
> 
> I have a bug to report, it shows on both of my machines (SMP and UP)
> now running RT-V0.7.32-2. It seems to be present also on previous RT
> releases, and don't even know if it's upstream.
> 
> When one usb-storage flash stick is first time unplugged:

hm, doesnt seem to be directly related to -RT. Could you try the vanilla
-rc2-mm3 kernel, does it trigger there too?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-12-04 22:46                                                                             ` Ingo Molnar
@ 2004-12-04 23:38                                                                               ` Rui Nuno Capela
  2004-12-04 23:55                                                                               ` K.R. Foley
  1 sibling, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-12-04 23:38 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, mark_h_johnson, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen

Ingo Molnar wrote:
>
> Rui Nuno Capela wrote:
>
>> Ingo Molnar wrote:
>> >
>> > i have released the -V0.7.32-0 Real-Time Preemption patch, which can
>> > be downloaded from the usual place:
>> >
>>
>> I have a bug to report, it shows on both of my machines (SMP and UP)
>> now running RT-V0.7.32-2. It seems to be present also on previous RT
>> releases, and don't even know if it's upstream.
>>
>> When one usb-storage flash stick is first time unplugged:
>
> hm, doesnt seem to be directly related to -RT. Could you try the vanilla
> -rc2-mm3 kernel, does it trigger there too?
>

No, it doesn't. Just tested on 2.6.10-rc2-mm3 (vanilla) and nothing wrong
happens. I can plug and unplug the USB flashram stick, and again, and
again, and everything stays fine.

On 2.6.10-rc2-mm3-RT-V0.7.32-2 I get trouble after the first time I unplug
the thingie. From then on I rather not touch it back again ;)

Take care.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-12-04 22:46                                                                             ` Ingo Molnar
  2004-12-04 23:38                                                                               ` Rui Nuno Capela
@ 2004-12-04 23:55                                                                               ` K.R. Foley
  2004-12-05  3:10                                                                                 ` Gene Heskett
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-12-04 23:55 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, linux-kernel, Lee Revell, mark_h_johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

Ingo Molnar wrote:
> * Rui Nuno Capela <rncbc@rncbc.org> wrote:
> 
> 
>>Ingo Molnar wrote:
>>
>>>i have released the -V0.7.32-0 Real-Time Preemption patch, which can be
>>>downloaded from the usual place:
>>>
>>
>>I have a bug to report, it shows on both of my machines (SMP and UP)
>>now running RT-V0.7.32-2. It seems to be present also on previous RT
>>releases, and don't even know if it's upstream.
>>
>>When one usb-storage flash stick is first time unplugged:
> 
> 
> hm, doesnt seem to be directly related to -RT. Could you try the vanilla
> -rc2-mm3 kernel, does it trigger there too?
> 
> 	Ingo
> 

Gene Heskett reported a very similar problem yesterday with the subject: 
  Re:2.6.10-rc2-mm3-V0.7.31-19

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-12-04 22:32                                                                           ` Rui Nuno Capela
  2004-12-04 22:46                                                                             ` Ingo Molnar
@ 2004-12-05  3:05                                                                             ` Gene Heskett
  1 sibling, 0 replies; 951+ messages in thread
From: Gene Heskett @ 2004-12-05  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Rui Nuno Capela, Ingo Molnar, Lee Revell, mark_h_johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah, Esben Nielsen

On Saturday 04 December 2004 17:32, Rui Nuno Capela wrote:
>Ingo Molnar wrote:
>> i have released the -V0.7.32-0 Real-Time Preemption patch, which
>> can be downloaded from the usual place:

I can confirm essentially this same bug, this rather voluminous output 
took place after I turned off my camera and unplugged the usb cable 
from it.  At that point all other usb stuff was spotty, even the 
mouse till I rebooted.

>I have a bug to report, it shows on both of my machines (SMP and UP)
> now running RT-V0.7.32-2. It seems to be present also on previous
> RT releases, and don't even know if it's upstream.
>
>When one usb-storage flash stick is first time unplugged:
>
>usb 4-6: USB disconnect, address 4
>slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't
> free all objects
> [<c010361f>] dump_stack+0x23/0x25 (20)
> [<c01467d7>] kmem_cache_destroy+0x103/0x1aa (28)
> [<c026e77a>] scsi_destroy_command_freelist+0x97/0xa8 (28)
> [<c026f5b1>] scsi_host_dev_release+0x37/0xe1 (104)
> [<c023c6a9>] device_release+0x7a/0x7c (32)
> [<c01efd90>] kobject_cleanup+0x87/0x89 (28)
> [<c01f07eb>] kref_put+0x52/0xef (40)
> [<c01efdcc>] kobject_put+0x25/0x27 (16)
> [<f8cf1843>] usb_stor_release_resources+0x66/0xca [usb_storage]
> (16) [<f8cf1d93>] storage_disconnect+0x8e/0x9b [usb_storage] (16)
> [<f89ca117>] usb_unbind_interface+0x84/0x86 [usbcore] (28)
> [<c023d915>] device_release_driver+0x75/0x77 (28)
> [<c023db18>] bus_remove_device+0x53/0x82 (20)
> [<c023cae1>] device_del+0x4b/0x9b (20)
> [<f89d142a>] usb_disable_device+0xf5/0x10a [usbcore] (28)
> [<f89cc61c>] usb_disconnect+0xc8/0x164 [usbcore] (40)
> [<f89cd77e>] hub_port_connect_change+0x2ef/0x426 [usbcore] (56)
> [<f89cda7b>] hub_events+0x1c6/0x39d [usbcore] (56)
> [<f89cdc89>] hub_thread+0x37/0x109 [usbcore] (96)
> [<c01009b1>] kernel_thread_helper+0x5/0xb (142893076)
>
>
>Then, just when the same is plugged in again:
>
>usb 4-6: new high speed USB device using ehci_hcd and address 5
>kmem_cache_create: duplicate cache scsi_cmd_cache
>BUG at mm/slab.c:1447!
>------------[ cut here ]------------
>kernel BUG at mm/slab.c:1447!
>invalid operand: 0000 [#1]
>PREEMPT SMP
>Modules linked in: nls_utf8 nls_cp860 vfat fat nls_base usb_storage
>ohci1394 ieee1394 ehci_hcd usbhid uhci_hcd intel_mch_agp agpgart
> evdev wacom snd_pcm_oss snd_mixer_oss snd_seq_midi
> snd_seq_midi_event snd_seq snd_usb_usx2y snd_usb_lib snd_hwdep
> snd_cs46xx snd_rawmidi snd_seq_device snd_intel8x0 snd_ac97_codec
> snd_pcm snd_timer snd soundcore snd_page_alloc realtime commoncap
> w83781d i2c_sensor i2c_isa i2c_i801 i2c_core sk98lin subfs dm_mod
> usbcore
>CPU:    1
>EIP:    0060:[<c01462e9>]    Not tainted VLI
>EFLAGS: 00010286   (2.6.10-rc2-mm3-RT-V0.7.32-2.0smp)
>EIP is at kmem_cache_create+0x4df/0x69c
>eax: 00000017   ebx: f7cd9710   ecx: c05c5d00   edx: f77b8000
>esi: c030973a   edi: c030973a   ebp: f77b9d10   esp: f77b9cd8
>ds: 007b   es: 007b   ss: 0068   preempt: 00000001
>Process khubd (pid: 1477, threadinfo=f77b8000 task=f777c2b0)
>Stack: c02f2054 c02f63aa 000005a7 00000565 f77b9d00 f7cd10c0
> c0000000 ffffff80
>       00000001 f7cd1080 00000080 c03418a0 f7000400 f7000428
> f77b9d3c c026e662
>       c030972b 00000180 00000080 00002000 00000000 00000000
> f7000490 00000000
>Call Trace:
> [<c01035f4>] show_stack+0xb4/0xbc (28)
> [<c010378a>] show_registers+0x169/0x1de (56)
> [<c010399c>] die+0x10b/0x191 (68)
> [<c0103e19>] do_invalid_op+0xba/0xc4 (204)
> [<c0103237>] error_code+0x2b/0x30 (116)
> [<c026e662>] scsi_setup_command_freelist+0x94/0x115 (44)
> [<c026f8ca>] scsi_host_alloc+0x26f/0x399 (124)
> [<f8cf173f>] usb_stor_acquire_resources+0x6c/0x10a [usb_storage]
> (28) [<f8cf1c64>] storage_probe+0x1b8/0x259 [usb_storage] (40)
> [<f89ca07a>] usb_probe_interface+0x62/0x7b [usbcore] (28)
> [<c023d723>] driver_probe_device+0x2f/0x70 (24)
> [<c023d7ae>] device_attach+0x4a/0xa5 (40)
> [<c023da89>] bus_add_device+0x4d/0x89 (28)
> [<c023c9a6>] device_add+0xb1/0x137 (40)
> [<f89d1ba6>] usb_set_configuration+0x3ca/0x444 [usbcore] (84)
> [<f89cc822>] usb_new_device+0xa5/0x164 [usbcore] (44)
> [<f89cd6b0>] hub_port_connect_change+0x221/0x426 [usbcore] (56)
> [<f89cda7b>] hub_events+0x1c6/0x39d [usbcore] (56)
> [<f89cdc89>] hub_thread+0x37/0x109 [usbcore] (96)
> [<c01009b1>] kernel_thread_helper+0x5/0xb (142893076)
>Code: e8 57 5e fd ff b8 08 4f be c0 e8 c0 d1 fe ff c7 44 24 08 a7 05
> 00 00 c7 44 24 04 aa 63 2f c0 c7 04 24 54 20 2f c0 e8 31 5e fd ff
> <0f> 0b a7 05 aa 63 2f c0 eb b9 a1 44 1a 33 c0 c7 44 24 04 d0 00
>
>
>After this, any USB related operation is doomed, if not the entire
> system.
>
>Bye.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.30% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-12-04 23:55                                                                               ` K.R. Foley
@ 2004-12-05  3:10                                                                                 ` Gene Heskett
  0 siblings, 0 replies; 951+ messages in thread
From: Gene Heskett @ 2004-12-05  3:10 UTC (permalink / raw)
  To: linux-kernel
  Cc: K.R. Foley, Ingo Molnar, Rui Nuno Capela, Lee Revell,
	mark_h_johnson, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah, Esben Nielsen

On Saturday 04 December 2004 18:55, K.R. Foley wrote:
>Ingo Molnar wrote:
>> * Rui Nuno Capela <rncbc@rncbc.org> wrote:
>>>Ingo Molnar wrote:
>>>>i have released the -V0.7.32-0 Real-Time Preemption patch, which
>>>> can be downloaded from the usual place:
>>>
>>>I have a bug to report, it shows on both of my machines (SMP and
>>> UP) now running RT-V0.7.32-2. It seems to be present also on
>>> previous RT releases, and don't even know if it's upstream.
>>>
>>>When one usb-storage flash stick is first time unplugged:
>>
>> hm, doesnt seem to be directly related to -RT. Could you try the
>> vanilla -rc2-mm3 kernel, does it trigger there too?
>>
>>  Ingo
>
>Gene Heskett reported a very similar problem yesterday with the
> subject: Re:2.6.10-rc2-mm3-V0.7.31-19

Yes, and I can confirm that it does not do it right now, running
the UP version of 2.6.10-rc3.  I just tried it and this is all
I got in the log:
-----------------
Dec  4 22:06:38 coyote kernel: usb 3-2.2: new full speed USB device using ohci_hcd and address 7
Dec  4 22:06:38 coyote kernel: scsi0 : SCSI emulation for USB Mass Storage devices
Dec  4 22:06:44 coyote kernel:   Vendor: OLYMPUS   Model: C-3020ZOOM(U)     Rev: 1.00
Dec  4 22:06:44 coyote kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Dec  4 22:06:44 coyote kernel: Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
Dec  4 22:06:44 coyote scsi.agent[26069]: disk at /devices/pci0000:00/0000:00:02.1/usb3/3-2/3-2.2/3-2.2:1.0/host0/target0:0:0/0:0:0:0
Dec  4 22:06:44 coyote kernel: SCSI device sda: 128000 512-byte hdwr sectors (66 MB)
Dec  4 22:06:44 coyote kernel: sda: assuming Write Enabled
Dec  4 22:06:44 coyote kernel: sda: assuming drive cache: write through
Dec  4 22:06:44 coyote kernel: SCSI device sda: 128000 512-byte hdwr sectors (66 MB)
Dec  4 22:06:44 coyote kernel: sda: assuming Write Enabled
Dec  4 22:06:44 coyote kernel: sda: assuming drive cache: write through
Dec  4 22:06:44 coyote kernel:  sda: sda1
Dec  4 22:06:44 coyote kernel: Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
Dec  4 22:06:51 coyote kernel: usb 3-2.2: USB disconnect, address 7
-----------------
-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.30% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-12-03 20:58                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0 Ingo Molnar
  2004-12-03 21:04                                                                           ` Ingo Molnar
  2004-12-04 22:32                                                                           ` Rui Nuno Capela
@ 2004-12-05 23:14                                                                           ` Esben Nielsen
  2004-12-06 13:14                                                                             ` Ingo Molnar
  2004-12-07 13:29                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-4 Ingo Molnar
  3 siblings, 1 reply; 951+ messages in thread
From: Esben Nielsen @ 2004-12-05 23:14 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Fri, 3 Dec 2004, Ingo Molnar wrote:

> 
> [...] 
> on low RT load (the common case) 

In the system I deal with on my day job, 50% of the CPU load is from
RT tasks!

In fact, I think that is quite normal for industrial applications. Those
tend to be PLC-like: You run your scan every 10 ms. First you read your
input, then you do your calculations then you set your output. You do
the same thing every time. You can thus safely tick around at a CPU
load close to 100%!!

This is quite opposit to how telecom real-time systems works: Those are
usually event based. I.e. they process things when they occur. The load
can vary a lot depending on how much traffic has to go through the device.

Esben


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-12-05 23:14                                                                           ` Esben Nielsen
@ 2004-12-06 13:14                                                                             ` Ingo Molnar
  2004-12-06 15:01                                                                               ` Esben Nielsen
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-12-06 13:14 UTC (permalink / raw)
  To: Esben Nielsen
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Esben Nielsen <simlo@phys.au.dk> wrote:

> On Fri, 3 Dec 2004, Ingo Molnar wrote:
> 
> > 
> > [...] 
> > on low RT load (the common case) 
> 
> In the system I deal with on my day job, 50% of the CPU load is from
> RT tasks!

i'm not sure what point you are trying to make, but 'low RT load' in
this context means up to a load of 1.0. (i.e. one or less tasks running
on average)

also, this only applies to SMP systems.

thirdly, even if the new balancing code kicks in, the overhead is not
that bad, and it's for a purpose: we rather want an RT task to run on a
free CPU.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-12-06 13:14                                                                             ` Ingo Molnar
@ 2004-12-06 15:01                                                                               ` Esben Nielsen
  2004-12-06 15:27                                                                                 ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Esben Nielsen @ 2004-12-06 15:01 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah

On Mon, 6 Dec 2004, Ingo Molnar wrote:

> 
> * Esben Nielsen <simlo@phys.au.dk> wrote:
> 
> > On Fri, 3 Dec 2004, Ingo Molnar wrote:
> > 
> > > 
> > > [...] 
> > > on low RT load (the common case) 
> > 
> > In the system I deal with on my day job, 50% of the CPU load is from
> > RT tasks!
> 
> i'm not sure what point you are trying to make, but 'low RT load' in
> this context means up to a load of 1.0. (i.e. one or less tasks running
> on average)
>

The point I want to make is that RT tasks is not always of the type
which reacts to some interrupt, does a small job and then goes to
sleep. Sometimes you also want larger jobs done realtime. Forinstance an
application waking up every 10ms, running for 5ms before going to sleep
again. That ofcourse gives you a RT-load <= 1.0.

In more complicated systems you can have a task running every 5ms,
another at every 25ms and another at every 100ms. That gives you a
RT-load of up to 3! And it is a even common case because you try to
syncronize the tasks, i.e. you wake all 3 tasks up at the same time but
then you know that on your typical UP system they will be executed by
priority, i.e. first the 5ms one, then the 25ms one and last the 100ms.

So my point was: Low RT-load might not be the common case on specific
systems. It is on the desktop where you want to run some multimedia
multimedia task(s) and have fast CPU compared to the job you
need done in RT but in embedded devices you do not pick such a big CPU and
you often use a large part on it in you RT control-loops.
 
> also, this only applies to SMP systems.
> 
> thirdly, even if the new balancing code kicks in, the overhead is not
> that bad, and it's for a purpose: we rather want an RT task to run on a
> free CPU.
> 

Good to hear. I was going to ask if the overhead wasn't too big :-)

However, I do have a feeling that it is rather expensive to move tasks
around. If I was going to design a real-time application on a 2 CPU SMP
system, I think I would CPU lock my RT-tasks to make the system more
deterministic. I.e. I would probably "port" the above mentioned
application by putting the 5 ms task on one CPU, the 25ms on the 
other and the 100 ms on the whatever CPU has the less CPU load. Then the
other non-real-time tasks in the system can wander around as they please.

But that is ofcourse not something you can do unless you know the specific
hardware system you will run your application on.  That is not the case
when you make multimedia software for the PC. I.e. in that case moving
RT-tasks around makes perfect sense!


> 	Ingo
> 

Esben


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0
  2004-12-06 15:01                                                                               ` Esben Nielsen
@ 2004-12-06 15:27                                                                                 ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-06 15:27 UTC (permalink / raw)
  To: Esben Nielsen
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah


* Esben Nielsen <simlo@phys.au.dk> wrote:

> So my point was: Low RT-load might not be the common case on specific
> systems. [...]

i did not suggest it was. The reason why i mentioned it was to point out
that _non-RT usage_ does not see any overhead, i.e. ordinary Linux
boxes. (which nevertheless do run RT tasks occasionally.)

of course in the RT-specific it can be common - Mark's test is one such
workload. If it werent widespread i'd not try to solve the problem...

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-4
  2004-12-03 20:58                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0 Ingo Molnar
                                                                                             ` (2 preceding siblings ...)
  2004-12-05 23:14                                                                           ` Esben Nielsen
@ 2004-12-07 13:29                                                                           ` Ingo Molnar
  2004-12-07 14:11                                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 Ingo Molnar
  3 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-12-07 13:29 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


i have released the -V0.7.32-4 Real-Time Preemption patch, which can be
downloaded from the usual place:

    http://redhat.com/~mingo/realtime-preempt/

this is a fixes-only release.

Changes since -V0.7.32-2:

 - fixed a seqlock related xtime_lock lockup scenario - this could 
   explain the SMP lockups reported by Mark H. Johnson.
 
 - fixed a small buglet in the new SMP RT-balancing code, which could 
   lead to bad balancing in certain rare cases.

to create a -V0.7.32-4 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/2.6.10-rc2-mm3.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm3-V0.7.32-4

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-07 13:29                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-4 Ingo Molnar
@ 2004-12-07 14:11                                                                             ` Ingo Molnar
  2004-12-08  4:31                                                                               ` K.R. Foley
                                                                                                 ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-07 14:11 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


i have released the -V0.7.32-6 Real-Time Preemption patch, which can be
downloaded from the usual place:

   http://redhat.com/~mingo/realtime-preempt/

this too is a fixes-only release.

Changes since -V0.7.32-4:

 - fixed a lock_kernel()-re-enables-interrupts bug reported by Daniel 
   Walker. The fix is to allow down() from irqs-off sections (and 
   save/restore irq flags) as long as there's no real contention on the
   semaphore.

 - fixed a /proc/latency_trace formatting bug reported by Mark H. 
   Johnson.

to create a -V0.7.32-6 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/2.6.10-rc2-mm3.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm3-V0.7.32-6

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-07 14:11                                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 Ingo Molnar
@ 2004-12-08  4:31                                                                               ` K.R. Foley
  2004-12-08  8:34                                                                                 ` Ingo Molnar
  2004-12-08 17:13                                                                               ` Steven Rostedt
  2004-12-14 13:28                                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0 Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-12-08  4:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

Ingo Molnar wrote:
> i have released the -V0.7.32-6 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 

Ingo,

Could you explain what the attached trace means. It looks to me like the 
trace starts in try_to_wake_up when we are trying to wake amlat, but 
then before we finish we get a hit on IRQ 8 and run the IRQ handler??? 
Or do I somehow have it backwards? :)

kr

[-- Attachment #2: trace --]
[-- Type: text/plain, Size: 3211 bytes --]

preemption latency trace v1.1.3 on 2.6.10-rc2-mm3-V0.7.32-9
--------------------------------------------------------------------
 latency: 39 us, #42/42 | (M:rt VP:0, KP:1, SP:1 HP:1 #P:2)
    -----------------
    | task: IRQ 8-677 (uid:0 nice:-5 policy:1 rt_prio:99)
    -----------------

                 _------=> CPU#            
                / _-----=> irqs-off        
               | / _----=> hardirq         
               || / _---=> softirq         
               ||| / _--=> preempt-depth   
               |||| /                      
               |||||     delay             
   cmd     pid ||||| time  |   caller      
      \   /    |||||   \   |   /           
   amlat-4973  0-h.3    0µs : __trace_start_sched_wakeup (try_to_wake_up)
   amlat-4973  0-h.3    1µs : _raw_spin_unlock (try_to_wake_up)
   amlat-4973  0-h.2    1µs : preempt_schedule (try_to_wake_up)
   amlat-4973  0        2µs : wake_up_process <IRQ 8-677> (0 1): 
   amlat-4973  0-h.2    2µs : try_to_wake_up (wake_up_process)
   amlat-4973  0-h.2    2µs : _raw_spin_unlock (try_to_wake_up)
   amlat-4973  0-h.1    3µs : preempt_schedule (try_to_wake_up)
   amlat-4973  0-h.1    3µs : wake_up_process (redirect_hardirq)
   amlat-4973  0-h.1    4µs : _raw_spin_unlock (__do_IRQ)
   amlat-4973  0-h..    4µs : preempt_schedule (__do_IRQ)
   amlat-4973  0-h..    4µs : irq_exit (do_IRQ)
   amlat-4973  0-h.1    5µs : do_softirq (irq_exit)
   amlat-4973  0-h.1    5µs : __do_softirq (do_softirq)
   amlat-4973  0-h..    6µs : preempt_schedule_irq (need_resched)
   amlat-4973  0-h..    6µs : __schedule (preempt_schedule_irq)
   amlat-4973  0-h.1    7µs : sched_clock (__schedule)
   amlat-4973  0-h.1    8µs : _raw_spin_lock_irq (__schedule)
   amlat-4973  0-h.1    8µs : _raw_spin_lock_irqsave (__schedule)
   amlat-4973  0-h.2   10µs : pull_rt_tasks (__schedule)
   amlat-4973  0-h.2   10µs : find_next_bit (pull_rt_tasks)
   amlat-4973  0-h.2   11µs+: find_next_bit (pull_rt_tasks)
   amlat-4973  0-..2   13µs : trace_array (__schedule)
   amlat-4973  0       14µs : __schedule <IRQ 8-677> (0 1): 
   amlat-4973  0       14µs+: __schedule <amlat-4973> (1 2): 
   amlat-4973  0       18µs+: __schedule <<unknown-792> (39 3a): 
   amlat-4973  0       21µs : __schedule <<unknown-4> (69 6e): 
   amlat-4973  0       21µs : __schedule <<unknown-4854> (73 78): 
   amlat-4973  0-..2   22µs+: trace_array (__schedule)
   IRQ 8-677   0-..2   31µs : __switch_to (__schedule)
   IRQ 8-677   0       32µs : schedule <amlat-4973> (1 0): 
   IRQ 8-677   0-..2   32µs : finish_task_switch (__schedule)
   IRQ 8-677   0-..2   33µs : smp_send_reschedule_allbutself (finish_task_switch)
   IRQ 8-677   0-..2   33µs : __bitmap_weight (smp_send_reschedule_allbutself)
   IRQ 8-677   0-..2   34µs : __send_IPI_shortcut (smp_send_reschedule_allbutself)
   IRQ 8-677   0-..2   35µs : _raw_spin_unlock (finish_task_switch)
   IRQ 8-677   0-..1   35µs : trace_stop_sched_switched (finish_task_switch)
   IRQ 8-677   0       36µs : finish_task_switch <IRQ 8-677> (0 0): 
   IRQ 8-677   0-..1   36µs+: _raw_spin_lock_irqsave (trace_stop_sched_switched)
   IRQ 8-677   0-..1   43µs : trace_stop_sched_switched (finish_task_switch)


vim:ft=help

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08  4:31                                                                               ` K.R. Foley
@ 2004-12-08  8:34                                                                                 ` Ingo Molnar
  2004-12-08 16:07                                                                                   ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-12-08  8:34 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* K.R. Foley <kr@cybsft.com> wrote:

> Could you explain what the attached trace means. It looks to me like
> the trace starts in try_to_wake_up when we are trying to wake amlat,
> but then before we finish we get a hit on IRQ 8 and run the IRQ
> handler???  Or do I somehow have it backwards? :)

>    amlat-4973  0-h.3    0?s : __trace_start_sched_wakeup (try_to_wake_up)
>    amlat-4973  0-h.3    1?s : _raw_spin_unlock (try_to_wake_up)
>    amlat-4973  0-h.2    1?s : preempt_schedule (try_to_wake_up)
>    amlat-4973  0        2?s : wake_up_process <IRQ 8-677> (0 1): 

this portion shows that amlat-4973 woke up IRQ_8-677. Subsequently the 
scheduler picked it from a list of 5 tasks:

>    amlat-4973  0-..2   13?s : trace_array (__schedule)
>    amlat-4973  0       14?s : __schedule <IRQ 8-677> (0 1): 
>    amlat-4973  0       14?s+: __schedule <amlat-4973> (1 2): 
>    amlat-4973  0       18?s+: __schedule <<unknown-792> (39 3a): 
>    amlat-4973  0       21?s : __schedule <<unknown-4> (69 6e): 
>    amlat-4973  0       21?s : __schedule <<unknown-4854> (73 78): 
>    amlat-4973  0-..2   22?s+: trace_array (__schedule)
>    IRQ 8-677   0-..2   31?s : __switch_to (__schedule)

IRQ_8's RT priority was 1, amlat's priority was 2, so IRQ-8 got
selected. (there were also other, SCHED_NORMAL tasks with pid 792, 4 and
4854 in the queue but they did not get selected) [ Note that in reality
the O(1) scheduler only considered IRQ_8 when picking the next task,
it's the tracer that listed all runnable tasks, to make it easier to
validate scheduler logic. This 'list all runnable tasks at schedule()
time' tracing is only done if both tracing and rw-deadlock detection is
enabled.]

in this trace you can see the new RT global balancing in the works as
well:

>    IRQ 8-677   0       32?s : schedule <amlat-4973> (1 0): 
>    IRQ 8-677   0-..2   32?s : finish_task_switch (__schedule)
>    IRQ 8-677   0-..2   33?s : smp_send_reschedule_allbutself (finish_task_switch)
>    IRQ 8-677   0-..2   33?s : __bitmap_weight (smp_send_reschedule_allbutself)
>    IRQ 8-677   0-..2   34?s : __send_IPI_shortcut (smp_send_reschedule_allbutself)

here the scheduler noticed that a higher-prio RT task (IRQ_8) preempted
a lower-prio but still RT task (amlat), and sent an IPI (inter-processor
interrupt) to another CPU in the system so that amlat can run on the
other CPU.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08  8:34                                                                                 ` Ingo Molnar
@ 2004-12-08 16:07                                                                                   ` K.R. Foley
  2004-12-08 16:18                                                                                     ` Lee Revell
  2004-12-09  2:45                                                                                     ` K.R. Foley
  0 siblings, 2 replies; 951+ messages in thread
From: K.R. Foley @ 2004-12-08 16:07 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>Could you explain what the attached trace means. It looks to me like
>>the trace starts in try_to_wake_up when we are trying to wake amlat,
>>but then before we finish we get a hit on IRQ 8 and run the IRQ
>>handler???  Or do I somehow have it backwards? :)
> 

Thank you. I really did have it backwards. The thing that confused me 
was that trace_start... gets called with the task that we are trying to 
wake up. I didn't follow the trace code far enough to realize that it 
later starts getting task info from current instead of p. :) This all 
makes more sense now.

I am still confused about one thing, unrelated to this. If RT tasks 
never expire and thus are never moved to the expired array??? Does that 
imply that we never switch the active and expired arrays? If so how do 
tasks that do expire get moved back into the active array?

> 
>>   amlat-4973  0-h.3    0?s : __trace_start_sched_wakeup (try_to_wake_up)
>>   amlat-4973  0-h.3    1?s : _raw_spin_unlock (try_to_wake_up)
>>   amlat-4973  0-h.2    1?s : preempt_schedule (try_to_wake_up)
>>   amlat-4973  0        2?s : wake_up_process <IRQ 8-677> (0 1): 
> 
> 
> this portion shows that amlat-4973 woke up IRQ_8-677. Subsequently the 
> scheduler picked it from a list of 5 tasks:
> 
> 
>>   amlat-4973  0-..2   13?s : trace_array (__schedule)
>>   amlat-4973  0       14?s : __schedule <IRQ 8-677> (0 1): 
>>   amlat-4973  0       14?s+: __schedule <amlat-4973> (1 2): 
>>   amlat-4973  0       18?s+: __schedule <<unknown-792> (39 3a): 
>>   amlat-4973  0       21?s : __schedule <<unknown-4> (69 6e): 
>>   amlat-4973  0       21?s : __schedule <<unknown-4854> (73 78): 
>>   amlat-4973  0-..2   22?s+: trace_array (__schedule)
>>   IRQ 8-677   0-..2   31?s : __switch_to (__schedule)
> 
> 
> IRQ_8's RT priority was 1, amlat's priority was 2, so IRQ-8 got
> selected. (there were also other, SCHED_NORMAL tasks with pid 792, 4 and
> 4854 in the queue but they did not get selected) [ Note that in reality
> the O(1) scheduler only considered IRQ_8 when picking the next task,
> it's the tracer that listed all runnable tasks, to make it easier to
> validate scheduler logic. This 'list all runnable tasks at schedule()
> time' tracing is only done if both tracing and rw-deadlock detection is
> enabled.]
> 
> in this trace you can see the new RT global balancing in the works as
> well:
> 
> 
>>   IRQ 8-677   0       32?s : schedule <amlat-4973> (1 0): 
>>   IRQ 8-677   0-..2   32?s : finish_task_switch (__schedule)
>>   IRQ 8-677   0-..2   33?s : smp_send_reschedule_allbutself (finish_task_switch)
>>   IRQ 8-677   0-..2   33?s : __bitmap_weight (smp_send_reschedule_allbutself)
>>   IRQ 8-677   0-..2   34?s : __send_IPI_shortcut (smp_send_reschedule_allbutself)
> 
> 
> here the scheduler noticed that a higher-prio RT task (IRQ_8) preempted
> a lower-prio but still RT task (amlat), and sent an IPI (inter-processor
> interrupt) to another CPU in the system so that amlat can run on the
> other CPU.
> 
> 	Ingo
> 


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08 16:07                                                                                   ` K.R. Foley
@ 2004-12-08 16:18                                                                                     ` Lee Revell
  2004-12-08 16:52                                                                                       ` K.R. Foley
  2004-12-09  2:45                                                                                     ` K.R. Foley
  1 sibling, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-12-08 16:18 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

On Wed, 2004-12-08 at 10:07 -0600, K.R. Foley wrote:
> I am still confused about one thing, unrelated to this. If RT tasks 
> never expire and thus are never moved to the expired array??? Does that 
> imply that we never switch the active and expired arrays? If so how do 
> tasks that do expire get moved back into the active array?

I think that RT tasks use a completely different scheduling mechanism
that bypasses the active/expired array.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08 16:18                                                                                     ` Lee Revell
@ 2004-12-08 16:52                                                                                       ` K.R. Foley
  2004-12-08 16:58                                                                                         ` Lee Revell
  2004-12-09  9:02                                                                                         ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: K.R. Foley @ 2004-12-08 16:52 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

Lee Revell wrote:
> On Wed, 2004-12-08 at 10:07 -0600, K.R. Foley wrote:
> 
>>I am still confused about one thing, unrelated to this. If RT tasks 
>>never expire and thus are never moved to the expired array??? Does that 
>>imply that we never switch the active and expired arrays? If so how do 
>>tasks that do expire get moved back into the active array?
> 
> 
> I think that RT tasks use a completely different scheduling mechanism
> that bypasses the active/expired array.
> 
> Lee
> 
> 
Please don't misunderstand. I am not arguing with you because obviously 
I am not really intimate with this code, but if the above statement is 
true then I am even more confused than I thought. I don't see any such 
distinctions in the scheduler code. In fact it looks to me like the 
whole scheduler is built on the premise of allowing RT tasks to be just 
like other tasks with a few exceptions, one of which is that RT tasks 
never hit the expired task array.

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08 16:52                                                                                       ` K.R. Foley
@ 2004-12-08 16:58                                                                                         ` Lee Revell
  2004-12-09  9:02                                                                                         ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-12-08 16:58 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

On Wed, 2004-12-08 at 10:52 -0600, K.R. Foley wrote:
> Lee Revell wrote:
> > On Wed, 2004-12-08 at 10:07 -0600, K.R. Foley wrote:
> > 
> >>I am still confused about one thing, unrelated to this. If RT tasks 
> >>never expire and thus are never moved to the expired array??? Does that 
> >>imply that we never switch the active and expired arrays? If so how do 
> >>tasks that do expire get moved back into the active array?
> > 
> > 
> > I think that RT tasks use a completely different scheduling mechanism
> > that bypasses the active/expired array.
> > 
> > Lee
> > 
> > 
> Please don't misunderstand. I am not arguing with you because obviously 
> I am not really intimate with this code, but if the above statement is 
> true then I am even more confused than I thought. I don't see any such 
> distinctions in the scheduler code. In fact it looks to me like the 
> whole scheduler is built on the premise of allowing RT tasks to be just 
> like other tasks with a few exceptions, one of which is that RT tasks 
> never hit the expired task array.

No, you are probably right, I am the one who is confused.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-07 14:11                                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 Ingo Molnar
  2004-12-08  4:31                                                                               ` K.R. Foley
@ 2004-12-08 17:13                                                                               ` Steven Rostedt
  2004-12-08 18:14                                                                                 ` Rui Nuno Capela
  2004-12-09  9:06                                                                                 ` Ingo Molnar
  2004-12-14 13:28                                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0 Ingo Molnar
  2 siblings, 2 replies; 951+ messages in thread
From: Steven Rostedt @ 2004-12-08 17:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: LKML, Lee Revell, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

Hi Ingo,

I found a race condition in slab.c, but I'm still trying to figure out
exactly how it's playing out.  This has to do with dynamic loading and
unloading of caches. I have a small test case that simulates the problem
at http://home.stny.rr.com/rostedt/tests/sillycaches.tgz

This was done on:

# uname -r
2.6.10-rc2-mm3-V0.7.32-9

I have a module that creates a cache to allocate objects from. When you
unload the module, it deallocates the objects and then destroys the
cache.  But with your patched kernel I get the following output, and the
system then goes into an unstable state. That is the system will crash
at a latter time. Usually when dealing with caches.

Here's the output:

slab error in kmem_cache_destroy(): cache `silly_stuff': Can't free all objects
 [<c0103953>] dump_stack+0x23/0x30 (20)
 [<c014929f>] kmem_cache_destroy+0xff/0x1a0 (28)
 [<d081e10d>] mkcache_cleanup+0x1d/0x21 [sillymod] (12)
 [<c013a711>] sys_delete_module+0x161/0x1a0 (100)
 [<c0102a00>] syscall_call+0x7/0xb (-8124)
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c01383ed>] .... print_traces+0x1d/0x60
.....[<c0103953>] ..   ( <= dump_stack+0x23/0x30)


I've done some extra testing and found that if I wait between the frees
and the destroying of the cache, everything works fine.  This problem
happens because it seems that the objects in the slab are being freed in
a batch style and they don't get freed on the destroy. I put prints in
to see more information and found that in kmem_cache_destroy, it calls
__cache_shrink, which calls drain_cpu_caches (obvious from code), but
what my prints show, is that when it gets down to drain_array_locked (it
gets in the function) that ac->avail is zero.  I need to read more into
the details of how the slab works, but you can take a look too.

By the way, 2.6.10-rc2-mm3 does not have a problem with this.

Thanks,

-- Steve

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08 17:13                                                                               ` Steven Rostedt
@ 2004-12-08 18:14                                                                                 ` Rui Nuno Capela
  2004-12-08 19:03                                                                                   ` Steven Rostedt
  2004-12-09  9:06                                                                                 ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-12-08 18:14 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

Steven Rostedt wrote:
>
> I found a race condition in slab.c, but I'm still trying to figure out
> exactly how it's playing out.  This has to do with dynamic loading and
> unloading of caches. I have a small test case that simulates the problem
> at http://home.stny.rr.com/rostedt/tests/sillycaches.tgz
>
> This was done on:
>
> # uname -r
> 2.6.10-rc2-mm3-V0.7.32-9
>
> I have a module that creates a cache to allocate objects from. When you
> unload the module, it deallocates the objects and then destroys the
> cache.  But with your patched kernel I get the following output, and the
> system then goes into an unstable state. That is the system will crash
> at a latter time. Usually when dealing with caches.
>
> Here's the output:
>
> slab error in kmem_cache_destroy(): cache `silly_stuff': Can't free all
> objects
>  [<c0103953>] dump_stack+0x23/0x30 (20)
>  [<c014929f>] kmem_cache_destroy+0xff/0x1a0 (28)
>  [<d081e10d>] mkcache_cleanup+0x1d/0x21 [sillymod] (12)
>  [<c013a711>] sys_delete_module+0x161/0x1a0 (100)
>  [<c0102a00>] syscall_call+0x7/0xb (-8124)
> ---------------------------
> | preempt count: 00000001 ]
> | 1-level deep critical section nesting:
> ----------------------------------------
> .. [<c01383ed>] .... print_traces+0x1d/0x60
> .....[<c0103953>] ..   ( <= dump_stack+0x23/0x30)
>
>
> I've done some extra testing and found that if I wait between the frees
> and the destroying of the cache, everything works fine.  This problem
> happens because it seems that the objects in the slab are being freed in
> a batch style and they don't get freed on the destroy. I put prints in
> to see more information and found that in kmem_cache_destroy, it calls
> __cache_shrink, which calls drain_cpu_caches (obvious from code), but
> what my prints show, is that when it gets down to drain_array_locked (it
> gets in the function) that ac->avail is zero.  I need to read more into
> the details of how the slab works, but you can take a look too.
>
> By the way, 2.6.10-rc2-mm3 does not have a problem with this.
>

AFAICS this seems to be exactly the bug I've reported recently, about when
an usb-storage flashram stick is first time unplugged.

Good show Steven :) Hope it helps.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08 18:14                                                                                 ` Rui Nuno Capela
@ 2004-12-08 19:03                                                                                   ` Steven Rostedt
  2004-12-08 21:39                                                                                     ` Rui Nuno Capela
  0 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2004-12-08 19:03 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

On Wed, 2004-12-08 at 18:14 +0000, Rui Nuno Capela wrote:
> Steven Rostedt wrote:
> >
> > I found a race condition in slab.c, but I'm still trying to figure out
> > exactly how it's playing out.  This has to do with dynamic loading and
> > unloading of caches. I have a small test case that simulates the problem
> > at http://home.stny.rr.com/rostedt/tests/sillycaches.tgz
> >
> > This was done on:
> >
> > # uname -r
> > 2.6.10-rc2-mm3-V0.7.32-9
> >

<snip>


Found the culprit!!! I did a diff of 2.6.10-rc2-mm3 to
2.6.10-rc2-mm3-V0.7.32-9 and found this in slab.c:
----------------------------
+#ifndef CONFIG_PREEMPT_RT
+/*
+ * Executes in an IRQ context:
+ */
 static void do_drain(void *arg)
 {         kmem_cache_t *cachep = (kmem_cache_t*)arg;
        struct array_cache *ac;
+       int cpu = smp_processor_id();
         check_irq_off();
-       ac = ac_data(cachep);
+       ac = ac_data(cachep, cpu);
        spin_lock(&cachep->spinlock);
        free_block(cachep, &ac_entry(ac)[0], ac->avail);
        spin_unlock(&cachep->spinlock);
        ac->avail = 0;
 }
+#endif

 static void drain_cpu_caches(kmem_cache_t *cachep)
 {
+#ifndef CONFIG_PREEMPT_RT
        smp_call_function_all_cpus(do_drain, cachep);
+#endif
        check_irq_on();

--------------------------------
(I have CONFIG_PREEMPT_RT defined :-)

I then put in 

 static void drain_cpu_caches(kmem_cache_t *cachep)
 {
 #ifndef CONFIG_PREEMPT_RT
        smp_call_function_all_cpus(do_drain, cachep);
 #endif
        check_irq_on();
        spin_lock_irq(&cachep->spinlock);
+       {
+               struct array_cache *ac;
+               ac = ac_data(cachep, smp_processor_id());
+               free_block(cachep, &ac_entry(ac)[0], ac->avail);
+               ac->avail = 0;
+       }

To see what would happen, and this indeed fixed the problem. At least
didn't cause the problem to appear after a few tests.

Obviously, this is not the right answer, and Ingo, since I don't know
exactly what you are accomplishing with the added cpu changes, I think
you are probably better at writing a patch than I.  

Which brings up another point.

In places like kmem_cache_create you have cpu = _smp_processor_id(); and
way down near the bottom, you use it.  Being a preemptable kernel, can't
that process jump cpus in the time being? So isn't that in itself a race
condition?

Thanks,

-- Steve

Rui,

Try adding the following in slab.c

--- slab.c      2004-12-08 09:27:10.000000000 -0500
+++ slab.c.new  2004-12-08 13:58:40.000000000 -0500
@@ -1533,6 +1533,12 @@
 #ifndef CONFIG_PREEMPT_RT
        smp_call_function_all_cpus(do_drain, cachep);
 #endif
+       {
+               struct array_cache *ac;
+               ac = ac_data(cachep, smp_processor_id());
+               free_block(cachep, &ac_entry(ac)[0], ac->avail);
+               ac->avail = 0;
+       }
        check_irq_on();
        spin_lock_irq(&cachep->spinlock);
        if (cachep->lists.shared)


and see if this fixes your usb problems.  I would say that this is not a
proper fix and especially for a SMP system. But if it fixes your problem
then you know this is the solution.


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08 19:03                                                                                   ` Steven Rostedt
@ 2004-12-08 21:39                                                                                     ` Rui Nuno Capela
  2004-12-08 22:11                                                                                       ` Steven Rostedt
  0 siblings, 1 reply; 951+ messages in thread
From: Rui Nuno Capela @ 2004-12-08 21:39 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

Steven Rostedt wrote:
>> Steven Rostedt wrote:
>> >
>> > I found a race condition in slab.c, but I'm still trying to figure
>> > out exactly how it's playing out.  This has to do with dynamic
>> > loading and unloading of caches. I have a small test case that
>> > simulates the problem at
>> > http://home.stny.rr.com/rostedt/tests/sillycaches.tgz
>> >
>> > This was done on:
>> >
>> > # uname -r
>> > 2.6.10-rc2-mm3-V0.7.32-9
>> >

>
> Rui,
>
> Try adding the following in slab.c
>
> --- slab.c      2004-12-08 09:27:10.000000000 -0500
> +++ slab.c.new  2004-12-08 13:58:40.000000000 -0500
> @@ -1533,6 +1533,12 @@
>  #ifndef CONFIG_PREEMPT_RT
>         smp_call_function_all_cpus(do_drain, cachep);
>  #endif
> +       {
> +               struct array_cache *ac;
> +               ac = ac_data(cachep, smp_processor_id());
> +               free_block(cachep, &ac_entry(ac)[0], ac->avail);
> +               ac->avail = 0;
> +       }
>         check_irq_on();
>         spin_lock_irq(&cachep->spinlock);
>         if (cachep->lists.shared)
>
>
> and see if this fixes your usb problems.  I would say that this is not a
> proper fix and especially for a SMP system. But if it fixes your problem
> then you know this is the solution.
>

Almost there, perhaps not...

It doesn't solve the problem completely, if not at all. What was kind of a
deterministic failure now seems probabilistic: the fault still occur on
unplugging the usb-storage stick, but not everytime as before.

Did try several times, reboot included, and now it fails after unplugging
a second or a third time. Never needed to replug/unplug more than 3 times
for it to show up, however.

Here is one sample, taken on the patched RT-V0.7.32-9:

 usb 4-5: USB disconnect, address 7
 slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free
all objects
  [<c010361f>] dump_stack+0x23/0x25 (20)
  [<c014669f>] kmem_cache_destroy+0x103/0x1aa (28)
  [<c026e61a>] scsi_destroy_command_freelist+0x97/0xa8 (28)
  [<c026f451>] scsi_host_dev_release+0x37/0xe1 (104)
  [<c023c569>] device_release+0x7a/0x7c (32)
  [<c01efc50>] kobject_cleanup+0x87/0x89 (28)
  [<c01f06ab>] kref_put+0x52/0xef (40)
  [<c01efc8c>] kobject_put+0x25/0x27 (16)
  [<f8cf1843>] usb_stor_release_resources+0x66/0xca [usb_storage] (16)
  [<f8cf1d93>] storage_disconnect+0x8e/0x9b [usb_storage] (16)
  [<f89ca117>] usb_unbind_interface+0x84/0x86 [usbcore] (28)
  [<c023d7d5>] device_release_driver+0x75/0x77 (28)
  [<c023d9d8>] bus_remove_device+0x53/0x82 (20)
  [<c023c9a1>] device_del+0x4b/0x9b (20)
  [<f89d142a>] usb_disable_device+0xf5/0x10a [usbcore] (28)
  [<f89cc61c>] usb_disconnect+0xc8/0x164 [usbcore] (40)
  [<f89cd77e>] hub_port_connect_change+0x2ef/0x426 [usbcore] (56)
  [<f89cda7b>] hub_events+0x1c6/0x39d [usbcore] (56)
  [<f89cdc89>] hub_thread+0x37/0x109 [usbcore] (96)
  [<c01009b1>] kernel_thread_helper+0x5/0xb (150118420)

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08 21:39                                                                                     ` Rui Nuno Capela
@ 2004-12-08 22:11                                                                                       ` Steven Rostedt
  2004-12-09  9:32                                                                                         ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2004-12-08 22:11 UTC (permalink / raw)
  To: Rui Nuno Capela
  Cc: Ingo Molnar, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

On Wed, 2004-12-08 at 21:39 +0000, Rui Nuno Capela wrote:
> 
> Almost there, perhaps not...
> 
> It doesn't solve the problem completely, if not at all. What was kind of a
> deterministic failure now seems probabilistic: the fault still occur on
> unplugging the usb-storage stick, but not everytime as before.
> 

OK, so I would say that this is part of a fix, but there are others.
There are lots of changes done to the slab.c file by Ingo.  The change I
made (and that is just a quick patch, it needs real work), was only in a
place that was obvious that there could be problems. 

Are you running an SMP machine? If so, than the patch I gave you is
definitely not enough. 

Ingo really scares me with all the removing of local_irq_disables in the
rt mode. I'm not sure exactly what is going on there, and why they can,
or should be removed. Ingo?

> Did try several times, reboot included, and now it fails after unplugging
> a second or a third time. Never needed to replug/unplug more than 3 times
> for it to show up, however.
> 
> Here is one sample, taken on the patched RT-V0.7.32-9:
> 
>  usb 4-5: USB disconnect, address 7
>  slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free
> all objects
>   [<c010361f>] dump_stack+0x23/0x25 (20)
>   [<c014669f>] kmem_cache_destroy+0x103/0x1aa (28)
>   [<c026e61a>] scsi_destroy_command_freelist+0x97/0xa8 (28)
>   [<c026f451>] scsi_host_dev_release+0x37/0xe1 (104)
>   [<c023c569>] device_release+0x7a/0x7c (32)
>   [<c01efc50>] kobject_cleanup+0x87/0x89 (28)
>   [<c01f06ab>] kref_put+0x52/0xef (40)
>   [<c01efc8c>] kobject_put+0x25/0x27 (16)
>   [<f8cf1843>] usb_stor_release_resources+0x66/0xca [usb_storage] (16)
>   [<f8cf1d93>] storage_disconnect+0x8e/0x9b [usb_storage] (16)
>   [<f89ca117>] usb_unbind_interface+0x84/0x86 [usbcore] (28)
>   [<c023d7d5>] device_release_driver+0x75/0x77 (28)
>   [<c023d9d8>] bus_remove_device+0x53/0x82 (20)
>   [<c023c9a1>] device_del+0x4b/0x9b (20)
>   [<f89d142a>] usb_disable_device+0xf5/0x10a [usbcore] (28)
>   [<f89cc61c>] usb_disconnect+0xc8/0x164 [usbcore] (40)
>   [<f89cd77e>] hub_port_connect_change+0x2ef/0x426 [usbcore] (56)
>   [<f89cda7b>] hub_events+0x1c6/0x39d [usbcore] (56)
>   [<f89cdc89>] hub_thread+0x37/0x109 [usbcore] (96)
>   [<c01009b1>] kernel_thread_helper+0x5/0xb (150118420)
> 

Unfortunately this really doesn't help. The problem occurs earlier than
this. What happened was that there are still slabs out there that need
to be freed that were postponed to a later time and not done with the
kmem_cache_free call.  So this dump only tells you that. The backtrace
unfortunately doesn't give us any more clues.  It's all in the slab.c
code.
(Of course if the driver really did not free the objects then it's not
slab.c's fault, and why Ingo may not have thought it was related to RT)

Tschuess,

-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08 16:07                                                                                   ` K.R. Foley
  2004-12-08 16:18                                                                                     ` Lee Revell
@ 2004-12-09  2:45                                                                                     ` K.R. Foley
  2004-12-09 12:11                                                                                       ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-12-09  2:45 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

K.R. Foley wrote:
<snip>

> 
> I am still confused about one thing, unrelated to this. If RT tasks 
> never expire and thus are never moved to the expired array??? Does that 
> imply that we never switch the active and expired arrays? If so how do 
> tasks that do expire get moved back into the active array?
> 
OK dumb question. I am going out to get my own personal brown paper bag, 
since I seem to be wearing it so often. I forgot tasks get removed from 
the runqueue when they are sleeping, etc. so the active array should 
empty most of the time. However, with more RT tasks and interactive 
tasks being thrown back into the active queue I could see this POSSIBLY 
occasionally starving a few processes???

kr
<snip>

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08 16:52                                                                                       ` K.R. Foley
  2004-12-08 16:58                                                                                         ` Lee Revell
@ 2004-12-09  9:02                                                                                         ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-09  9:02 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* K.R. Foley <kr@cybsft.com> wrote:

> [...] it looks to me like the whole scheduler is built on the premise
> of allowing RT tasks to be just like other tasks with a few
> exceptions, one of which is that RT tasks never hit the expired task
> array.

this is more or less correct, and we are trying to keep RT scheduling
'integrated' into the SCHED_NORMAL scheduler as long as it's practical.

but Lee is correct too in that the scheduling behavior of RT tasks and
SCHED_NORMAL tasks is completely different. But on the implementational
level the distinction is less stark and boils down to a few branches
here and there, while 90% of the scheduling code is shared.

to answer your question: it is true that if there is an RT task active
then we never switch the arrays. That's how RT tasks work: they run
until they want. That's why it needs privileges to use RT scheduling,
and that's why a buggy RT task can lock up the system. The 'array
switching' mechanism is part of the 10% of code that is only used by
non-RT tasks. SCHED_FIFO tasks dont have any timeslices, they run until
they deschedule voluntarily. SCHED_RR tasks have a notion of timeslices
but they only yield to RR tasks on their own priority level, which is
implemented without an array-switch. [the array-switch implements fair
scheduling between different-priority SCHED_NORMAL tasks - this is a
fundamentally harder problem which necessiates more work from the
scheduler.]

(btw., the 'global RT balancing' SMP code i recently added, and the
priority inheritance scheduler code increases the 10% of non-shared
scheduling code to perhaps 15% or so. Not always is it possible to share
code.)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08 17:13                                                                               ` Steven Rostedt
  2004-12-08 18:14                                                                                 ` Rui Nuno Capela
@ 2004-12-09  9:06                                                                                 ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-09  9:06 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: LKML, Lee Revell, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Steven Rostedt <rostedt@goodmis.org> wrote:

> Hi Ingo,
> 
> I found a race condition in slab.c, but I'm still trying to figure out
> exactly how it's playing out.  This has to do with dynamic loading and
> unloading of caches. I have a small test case that simulates the
> problem at http://home.stny.rr.com/rostedt/tests/sillycaches.tgz

good catch! When i converted slab.c to RT i mistakenly thought that SLAB
flushing (draining) is only an SMP optimization (which i thus generously
disabled), but i forgot about module unloading. This could indeed
explain some of the unresolved bugs in the -RT patchset.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-08 22:11                                                                                       ` Steven Rostedt
@ 2004-12-09  9:32                                                                                         ` Ingo Molnar
  2004-12-09 13:13                                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12 Ingo Molnar
  2004-12-09 13:36                                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 Steven Rostedt
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-09  9:32 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed, 2004-12-08 at 21:39 +0000, Rui Nuno Capela wrote:
> > 
> > Almost there, perhaps not...
> > 
> > It doesn't solve the problem completely, if not at all. What was kind of a
> > deterministic failure now seems probabilistic: the fault still occur on
> > unplugging the usb-storage stick, but not everytime as before.
> > 
> 
> OK, so I would say that this is part of a fix, but there are others.
> There are lots of changes done to the slab.c file by Ingo.  The change I
> made (and that is just a quick patch, it needs real work), was only in a
> place that was obvious that there could be problems. 
> 
> Are you running an SMP machine? If so, than the patch I gave you is
> definitely not enough. 

one of Rui's boxes is an SMP system - which would explain why the bug
goes from an 'always crash' to 'spurious crash'. (if Rui's laptop
triggers this problem too then there must be something else going on as
well.)

> Ingo really scares me with all the removing of local_irq_disables in
> the rt mode. I'm not sure exactly what is going on there, and why they
> can, or should be removed. Ingo?

it is done so that the SLAB code can be fully preempted too. The SLAB
code is of central importance to the -RT project, if it's not fully
preemptible then that has a ripple effect on other subsystems (timer,
signal code, file handling, etc.).

So while making it fully preemptible was quite challenging (==dangerous,
scary), i couldnt just keep the SLAB using raw spinlocks, due to the
locking dependencies. (nor did i have any true inner desire to keep it
non-preemptible - the point of PREEMPT_RT is to have everything
preemptible. I want to see how much preemption the Linux kernel can take
=B-) It has held up surprisingly well i have to say.)

to make the SLAB code fully preemptible, there were two main aspects
that i had to fix:

 1) irq context execution
 2) process preemption

in the -RT kernel all IRQ contexts execute in a separate process
context, so the SLAB code is never called from a true IRQ context -
hence problem #1 is solved. As far as #1 is concerned, the
local_irq_disable()s are not needed anymore.

the other aspect is process<->process preemption - which can still occur
in the -RT kernel (and is the whole point of the PREEMPT_RT feature). 
This means that the per-CPU assumptions within slab.c break.

To solve this i've turned the unlocked per-CPU SLAB code to be
controlled by the cachep->spinlock. (on RT only - on non-RT kernels the
SLAB code should be largely unmodified - this is why all that _rt and
_nort API trickery is done.) Since the SLAB code is thus locked by
cachep->spinlock on PREEMPT_RT, other tasks cannot interfere with the
internal data structures.

Finally, there was still the problem of the use of smp_processor_id() -
the non-RT SLAB code (rightfully) assumes that smp_processor_id() is
constant, but this is not true for the RT code - which can be preempted
anytime (still holding the spinlock of course) and can be migrated to
another CPU.

To solve this problem i am saving smp_processor_id() once, before we use
any per-CPU data structure for the first time, and this constant CPU ID
value is cached and used throughout the whole SLAB processing pass.

[ Since in the RT case we lock the cachep exclusively, it's not a
problem if the 'old' CPU's ID is used as an index - as long as the index
is consistent. Most of the time the current CPU's ID will be used so we
preserve most of the performance advantages (==cache-hotness) of per-CPU
SLABs on SMP systems too. (except for the locking, which is serialized
on RT.) ]

SLAB draining was an oversight - it's mainly called when there is VM
pressure (which is not a stricly necessary feature, so i disabled it),
but i forgot about the module-unload case where it's a correctness
feature. Your patch is a good starting point, i'll try to fix it on SMP
too.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-09  2:45                                                                                     ` K.R. Foley
@ 2004-12-09 12:11                                                                                       ` Ingo Molnar
  2004-12-09 14:50                                                                                         ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-12-09 12:11 UTC (permalink / raw)
  To: K.R. Foley
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen


* K.R. Foley <kr@cybsft.com> wrote:

> OK dumb question. I am going out to get my own personal brown paper
> bag, since I seem to be wearing it so often. I forgot tasks get
> removed from the runqueue when they are sleeping, etc. so the active
> array should empty most of the time. However, with more RT tasks and
> interactive tasks being thrown back into the active queue I could see
> this POSSIBLY occasionally starving a few processes???

interactive tasks do get thrown back, but they wont ever preempt RT
tasks. RT tasks themselves can starve any lower-prio process
indefinitely. Interactive tasks can starve other tasks up to a certain
limit, which is defined via STARVATION_LIMIT, at which point we empty
the active array and perform an array switch. (also see
EXPIRED_STARVING())

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-09  9:32                                                                                         ` Ingo Molnar
@ 2004-12-09 13:13                                                                                           ` Ingo Molnar
  2004-12-09 14:23                                                                                             ` Gene Heskett
                                                                                                               ` (2 more replies)
  2004-12-09 13:36                                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 Steven Rostedt
  1 sibling, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-09 13:13 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra


* Ingo Molnar <mingo@elte.hu> wrote:

> SLAB draining was an oversight - it's mainly called when there is VM
> pressure (which is not a stricly necessary feature, so i disabled it),
> but i forgot about the module-unload case where it's a correctness
> feature. Your patch is a good starting point, i'll try to fix it on
> SMP too.

here's the full patch against a recent tree, or download the -32-12
patch from the usual place:

    http://redhat.com/~mingo/realtime-preempt/

Rui, Gene, does this fix the module unload crash you are seeing?

	Ingo

--- linux/mm/slab.c.orig
+++ linux/mm/slab.c
@@ -1509,22 +1509,26 @@ static void smp_call_function_all_cpus(v
 static void drain_array_locked(kmem_cache_t* cachep,
 				struct array_cache *ac, int force);
 
-#ifndef CONFIG_PREEMPT_RT
-/*
- * Executes in an IRQ context:
- */
-static void do_drain(void *arg)
+static void do_drain_cpu(kmem_cache_t *cachep, int cpu)
 {
-	kmem_cache_t *cachep = (kmem_cache_t*)arg;
 	struct array_cache *ac;
-	int cpu = smp_processor_id();
 
 	check_irq_off();
-	ac = ac_data(cachep, cpu);
+
 	spin_lock(&cachep->spinlock);
+	ac = ac_data(cachep, cpu);
 	free_block(cachep, &ac_entry(ac)[0], ac->avail);
-	spin_unlock(&cachep->spinlock);
 	ac->avail = 0;
+	spin_unlock(&cachep->spinlock);
+}
+
+#ifndef CONFIG_PREEMPT_RT
+/*
+ * Executes in an IRQ context:
+ */
+static void do_drain(void *arg)
+{
+	do_drain_cpu((kmem_cache_t*)arg, smp_processor_id());
 }
 #endif
 
@@ -1532,6 +1536,11 @@ static void drain_cpu_caches(kmem_cache_
 {
 #ifndef CONFIG_PREEMPT_RT
 	smp_call_function_all_cpus(do_drain, cachep);
+#else
+	int cpu;
+
+	for_each_online_cpu(cpu)
+		do_drain_cpu(cachep, cpu);
 #endif
 	check_irq_on();
 	spin_lock_irq(&cachep->spinlock);

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-09  9:32                                                                                         ` Ingo Molnar
  2004-12-09 13:13                                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12 Ingo Molnar
@ 2004-12-09 13:36                                                                                           ` Steven Rostedt
  1 sibling, 0 replies; 951+ messages in thread
From: Steven Rostedt @ 2004-12-09 13:36 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

On Thu, 2004-12-09 at 10:32 +0100, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> > Ingo really scares me with all the removing of local_irq_disables in
> > the rt mode. I'm not sure exactly what is going on there, and why they
> > can, or should be removed. Ingo?
> 
> it is done so that the SLAB code can be fully preempted too. The SLAB
> code is of central importance to the -RT project, if it's not fully
> preemptible then that has a ripple effect on other subsystems (timer,
> signal code, file handling, etc.).
> 
> So while making it fully preemptible was quite challenging (==dangerous,
> scary), i couldnt just keep the SLAB using raw spinlocks, due to the
> locking dependencies. (nor did i have any true inner desire to keep it
> non-preemptible - the point of PREEMPT_RT is to have everything
> preemptible. I want to see how much preemption the Linux kernel can take
> =B-) It has held up surprisingly well i have to say.)

<snip>


> 
> 	Ingo


Ingo,

Thanks for the write up. It really clears things up for me. Now I
understand your approach, not only for slabs, but other areas of the
kernel. Once again, thanks for the explanation.

-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-09 13:13                                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12 Ingo Molnar
@ 2004-12-09 14:23                                                                                             ` Gene Heskett
  2004-12-09 14:33                                                                                             ` Steven Rostedt
  2004-12-09 14:43                                                                                             ` Rui Nuno Capela
  2 siblings, 0 replies; 951+ messages in thread
From: Gene Heskett @ 2004-12-09 14:23 UTC (permalink / raw)
  To: linux-kernel
  Cc: Ingo Molnar, Steven Rostedt, Rui Nuno Capela, Lee Revell,
	Mark Johnson, K.R. Foley, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, emann, Peter Zijlstra

On Thursday 09 December 2004 08:13, Ingo Molnar wrote:
>* Ingo Molnar <mingo@elte.hu> wrote:
>> SLAB draining was an oversight - it's mainly called when there is
>> VM pressure (which is not a stricly necessary feature, so i
>> disabled it), but i forgot about the module-unload case where it's
>> a correctness feature. Your patch is a good starting point, i'll
>> try to fix it on SMP too.
>
>here's the full patch against a recent tree, or download the -32-12
>patch from the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/
>
>Rui, Gene, does this fix the module unload crash you are seeing?

I'm still on -9 here Ingo, and I just rmmod'ed eeprom with no ill
effects.  I'd built -10 last night but as kde was trying to build,
didn't reboot.  I just got -12, so I'll do it and reboot to it next.

Or am I the wrong Gene?

>
> Ingo
>
>--- linux/mm/slab.c.orig
>+++ linux/mm/slab.c
>@@ -1509,22 +1509,26 @@ static void smp_call_function_all_cpus(v
> static void drain_array_locked(kmem_cache_t* cachep,
>     struct array_cache *ac, int force);
>
>-#ifndef CONFIG_PREEMPT_RT
>-/*
>- * Executes in an IRQ context:
>- */
>-static void do_drain(void *arg)
>+static void do_drain_cpu(kmem_cache_t *cachep, int cpu)
> {
>-	kmem_cache_t *cachep = (kmem_cache_t*)arg;
> 	struct array_cache *ac;
>-	int cpu = smp_processor_id();
>
> 	check_irq_off();
>-	ac = ac_data(cachep, cpu);
>+
> 	spin_lock(&cachep->spinlock);
>+	ac = ac_data(cachep, cpu);
> 	free_block(cachep, &ac_entry(ac)[0], ac->avail);
>-	spin_unlock(&cachep->spinlock);
> 	ac->avail = 0;
>+	spin_unlock(&cachep->spinlock);
>+}
>+
>+#ifndef CONFIG_PREEMPT_RT
>+/*
>+ * Executes in an IRQ context:
>+ */
>+static void do_drain(void *arg)
>+{
>+	do_drain_cpu((kmem_cache_t*)arg, smp_processor_id());
> }
> #endif
>
>@@ -1532,6 +1536,11 @@ static void drain_cpu_caches(kmem_cache_
> {
> #ifndef CONFIG_PREEMPT_RT
> 	smp_call_function_all_cpus(do_drain, cachep);
>+#else
>+	int cpu;
>+
>+	for_each_online_cpu(cpu)
>+		do_drain_cpu(cachep, cpu);
> #endif
> 	check_irq_on();
> 	spin_lock_irq(&cachep->spinlock);
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.30% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-09 13:13                                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12 Ingo Molnar
  2004-12-09 14:23                                                                                             ` Gene Heskett
@ 2004-12-09 14:33                                                                                             ` Steven Rostedt
  2004-12-09 19:19                                                                                               ` Steven Rostedt
  2004-12-09 14:43                                                                                             ` Rui Nuno Capela
  2 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2004-12-09 14:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra

On Thu, 2004-12-09 at 14:13 +0100, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > SLAB draining was an oversight - it's mainly called when there is VM
> > pressure (which is not a stricly necessary feature, so i disabled it),
> > but i forgot about the module-unload case where it's a correctness
> > feature. Your patch is a good starting point, i'll try to fix it on
> > SMP too.
> 
> here's the full patch against a recent tree, or download the -32-12
> patch from the usual place:
> 
>     http://redhat.com/~mingo/realtime-preempt/

Ingo,

I just tried out your changes with both my sillycaches test as well as
my real modules that had the original problems. They both work fine.

I'll ever reboot my main machine now (SMP) and run your kernel there
too, and see how it works.

Thanks,

-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-09 13:13                                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12 Ingo Molnar
  2004-12-09 14:23                                                                                             ` Gene Heskett
  2004-12-09 14:33                                                                                             ` Steven Rostedt
@ 2004-12-09 14:43                                                                                             ` Rui Nuno Capela
  2 siblings, 0 replies; 951+ messages in thread
From: Rui Nuno Capela @ 2004-12-09 14:43 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Steven Rostedt, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra

Ingo Molnar wrote:
>
>> SLAB draining was an oversight - it's mainly called when there is VM
>> pressure (which is not a stricly necessary feature, so i disabled it),
>> but i forgot about the module-unload case where it's a correctness
>> feature. Your patch is a good starting point, i'll try to fix it on
>> SMP too.
>
> here's the full patch against a recent tree, or download the -32-12
> patch from the usual place:
>
>     http://redhat.com/~mingo/realtime-preempt/
>
> Rui, Gene, does this fix the module unload crash you are seeing?
>

Tested with RT-V0.7.32-12 after some usb-storage plug/unplug bonanza. All
seems to be OK, at least on my laptop (P4/UP).

Cheers.
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
  2004-12-09 12:11                                                                                       ` Ingo Molnar
@ 2004-12-09 14:50                                                                                         ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-12-09 14:50 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>OK dumb question. I am going out to get my own personal brown paper
>>bag, since I seem to be wearing it so often. I forgot tasks get
>>removed from the runqueue when they are sleeping, etc. so the active
>>array should empty most of the time. However, with more RT tasks and
>>interactive tasks being thrown back into the active queue I could see
>>this POSSIBLY occasionally starving a few processes???
> 
> 
> interactive tasks do get thrown back, but they wont ever preempt RT
> tasks. RT tasks themselves can starve any lower-prio process
> indefinitely. Interactive tasks can starve other tasks up to a certain
> limit, which is defined via STARVATION_LIMIT, at which point we empty
> the active array and perform an array switch. (also see
> EXPIRED_STARVING())
> 
> 	Ingo
> 
Understood. BTW, I wouldn't consider some possible starvation of lower 
priority, non-realtime tasks to be incorrect behavior for a realtime 
system. The comments in the above email as well as previous emails were 
not intended as complaints or questions of correctness. They were more 
just thoughts generated while thinking about some of the reports of 
non-realtime tasks being starved.

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-09 14:33                                                                                             ` Steven Rostedt
@ 2004-12-09 19:19                                                                                               ` Steven Rostedt
  2004-12-09 20:33                                                                                                 ` john cooper
  2004-12-09 22:10                                                                                                 ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Steven Rostedt @ 2004-12-09 19:19 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra

On Thu, 2004-12-09 at 09:33 -0500, Steven Rostedt wrote:
> On Thu, 2004-12-09 at 14:13 +0100, Ingo Molnar wrote:
> > * Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > here's the full patch against a recent tree, or download the -32-12
> > patch from the usual place:
> > 
> >     http://redhat.com/~mingo/realtime-preempt/
> 
> Ingo,
> 
> I just tried out your changes with both my sillycaches test as well as
> my real modules that had the original problems. They both work fine.
> 
> I'll ever reboot my main machine now (SMP) and run your kernel there
> too, and see how it works.

Hi Ingo,

I just tried it on my main machine (SMP Dual Athlon MP, with a Gig of
RAM), and I just got the following dump on boot-up.  It never made it to
a prompt.

Freeing unused kernel memory: 216k freed
BUG: sleeping function called from invalid context IRQ 14(814) at
arch/i386/mm/highmem.c:5
in_atomic():0 [00000000], irqs_disabled():1
 [<c011c064>] __might_sleep+0xd4/0xf0 (8)
 [<c011749f>] kmap+0x1f/0x50 (36)
 [<c014ffb8>] bounce_copy_vec+0x28/0x70 (16)
 [<c01500bc>] copy_to_high_bio_irq+0x5c/0x70 (32)
 [<c0150221>] __bounce_end_io_read+0x41/0x50 (28)
 [<c0150258>] bounce_end_io_read+0x28/0x30 (20)
 [<c01686b9>] bio_endio+0x59/0x80 (12)
 [<c025a2bc>] ide_end_request+0x2c/0xc0 (16)
 [<c024bc02>] __end_that_request_first+0x1c2/0x230 (12)
 [<c01386cf>] up_mutex+0xaf/0x100 (16)
 [<c025a197>] __ide_end_request+0x77/0x170 (36)
 [<c025a2f5>] ide_end_request+0x65/0xc0 (36)
 [<c0260810>] task_end_request+0x40/0x80 (36)
 [<c0260941>] task_in_intr+0xf1/0x110 (24)
 [<c0260850>] task_in_intr+0x0/0x110 (20)
 [<c025bda1>] ide_intr+0xe1/0x170 (12)
 [<c0140e3b>] handle_IRQ_event+0x5b/0xd0 (32)
 [<c0141683>] do_hardirq+0xa3/0x100 (48)
 [<c01417f6>] do_irqd+0x116/0x1e0 (36)
 [<c01416e0>] do_irqd+0x0/0x1e0 (44)
 [<c0135e37>] kthread+0xb7/0xc0 (4)
 [<c0135d80>] kthread+0x0/0xc0 (28)
 [<c01012e5>] kernel_thread_helper+0x5/0x10 (16)
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<c01398e7>] .... print_traces+0x17/0x50
.....[<00000000>] ..   ( <= 0x0)


This looks like it was triggered by bounce_copy_vec calling kmap_atomic
which is now just kmap with irqs disabled.  Does this need to change to
__kmap_atomic?  Is this also used to make things more preemptible, and
start removing the local_irq_saves?  I'd like to know so that you don't
need to make the patches yourself and I can handle things like this, but
I need to know what the general ideas are.  Also, am I the only one that
has highmem support enabled, because this looks like this bug would have
been triggered by anyone.

Thanks,

-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-09 19:19                                                                                               ` Steven Rostedt
@ 2004-12-09 20:33                                                                                                 ` john cooper
  2004-12-09 22:19                                                                                                   ` Steven Rostedt
  2004-12-09 22:10                                                                                                 ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: john cooper @ 2004-12-09 20:33 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, Rui Nuno Capela, LKML, Lee Revell, Mark Johnson,
	K.R. Foley, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, emann, Peter Zijlstra, john cooper

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

Steven Rostedt wrote:

> ...Also, am I the only one that
> has highmem support enabled, because this looks like this bug would have
> been triggered by anyone.

I have not encountered this in -12 with CONFIG_HIGHMEM4G
running on an SMP Opteron with 1GB memory.  Details attached.

-john


-- 
john.cooper@timesys.com

[-- Attachment #2: dmesg.gz --]
[-- Type: application/x-gzip, Size: 4170 bytes --]

[-- Attachment #3: dot-config.gz --]
[-- Type: application/x-gzip, Size: 7125 bytes --]

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-09 19:19                                                                                               ` Steven Rostedt
  2004-12-09 20:33                                                                                                 ` john cooper
@ 2004-12-09 22:10                                                                                                 ` Ingo Molnar
  2004-12-10  6:11                                                                                                   ` Steven Rostedt
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-12-09 22:10 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra


* Steven Rostedt <rostedt@goodmis.org> wrote:

> This looks like it was triggered by bounce_copy_vec calling
> kmap_atomic which is now just kmap with irqs disabled.  Does this need
> to change to __kmap_atomic?  Is this also used to make things more
> preemptible, and start removing the local_irq_saves?  I'd like to know
> so that you don't need to make the patches yourself and I can handle
> things like this, but I need to know what the general ideas are. 
> Also, am I the only one that has highmem support enabled, because this
> looks like this bug would have been triggered by anyone.

the fix would be to find the place that disabled interrupts, and to
check that it's safe to change it to local_irq_disable_nort() (or
whatever other variant is used). Usually it's safe.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-09 20:33                                                                                                 ` john cooper
@ 2004-12-09 22:19                                                                                                   ` Steven Rostedt
  2004-12-09 23:10                                                                                                     ` john cooper
  0 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2004-12-09 22:19 UTC (permalink / raw)
  To: john cooper
  Cc: Ingo Molnar, Rui Nuno Capela, LKML, Lee Revell, Mark Johnson,
	K.R. Foley, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, emann, Peter Zijlstra

On Thu, 2004-12-09 at 15:33 -0500, john cooper wrote:
> Steven Rostedt wrote:
> 
> > ...Also, am I the only one that
> > has highmem support enabled, because this looks like this bug would have
> > been triggered by anyone.
> 
> I have not encountered this in -12 with CONFIG_HIGHMEM4G
> running on an SMP Opteron with 1GB memory.  Details attached.

Hi John,

Could you do me a big favor? Put a print in mm/highmem.c bounce_copy_vec
to see if you get into it.  If you don't then it seems that my system is
triggering this and it just so happens that yours does not. Looking at
my dump, it shows that there may have been some contention in the ide
interrupt. 

I let it run for a little longer and the system does eventually get to a
login prompt, but I'm looking into this further.

-- Steve

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-09 22:19                                                                                                   ` Steven Rostedt
@ 2004-12-09 23:10                                                                                                     ` john cooper
  0 siblings, 0 replies; 951+ messages in thread
From: john cooper @ 2004-12-09 23:10 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, Rui Nuno Capela, LKML, Lee Revell, Mark Johnson,
	K.R. Foley, Florian Schmidt, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, emann, Peter Zijlstra

Steven Rostedt wrote:

> Could you do me a big favor? Put a print in mm/highmem.c bounce_copy_vec
> to see if you get into it.  If you don't then it seems that my system is
> triggering this and it just so happens that yours does not.

Did so.  For whatever reason I don't appear to be getting into
bounce_copy_vec() during bootup as you seem to be.

-john


-- 
john.cooper@timesys.com

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-09 22:10                                                                                                 ` Ingo Molnar
@ 2004-12-10  6:11                                                                                                   ` Steven Rostedt
  2004-12-10 11:05                                                                                                     ` Ingo Molnar
  2004-12-10 11:11                                                                                                     ` Ingo Molnar
  0 siblings, 2 replies; 951+ messages in thread
From: Steven Rostedt @ 2004-12-10  6:11 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra

On Thu, 2004-12-09 at 23:10 +0100, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > This looks like it was triggered by bounce_copy_vec calling
> > kmap_atomic which is now just kmap with irqs disabled.  Does this need
> > to change to __kmap_atomic?  Is this also used to make things more
> > preemptible, and start removing the local_irq_saves?  I'd like to know
> > so that you don't need to make the patches yourself and I can handle
> > things like this, but I need to know what the general ideas are. 
> > Also, am I the only one that has highmem support enabled, because this
> > looks like this bug would have been triggered by anyone.
> 
> the fix would be to find the place that disabled interrupts, and to
> check that it's safe to change it to local_irq_disable_nort() (or
> whatever other variant is used). Usually it's safe.

Hi Ingo,

Here's your fix. I haven't seen anything else cause the bug, and since
it uses local_irq_save, I guess the bounce_copy_vec can be called with
interrupts disabled. Since the kmap_atomic (or just kmap) checks for
that, I don't think I need more than what I've done.

Second, my ethernet doesn't work, and it really seems to be some kind of
interrupt trouble.  It sends out ARPs but doesn't see them come back,
and it also doesn't seem to know that it sent them out. I get the
following:

NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status e601.
  diagnostics: net 0ccc media 8880 dma 0000003a fifo 0000
eth0: Interrupt posted but not delivered -- IRQ blocked by another
device?
  Flags; bus-master 1, dirty 33(1) current 33(1)
  Transmit list 00000000 vs. f75012a0.
  0: @f7501200  length 80000043 status 8c010043
  1: @f75012a0  length 8000007a status 0c01007a
  2: @f7501340  length 8000002a status 0001002a
  3: @f75013e0  length 80000098 status 0c010098
  4: @f7501480  length 8000002a status 0001002a
  5: @f7501520  length 8000002a status 0001002a
  6: @f75015c0  length 8000002a status 0001002a
  7: @f7501660  length 8000002a status 0001002a
  8: @f7501700  length 80000043 status 0c010043
  9: @f75017a0  length 80000043 status 0c010043
  10: @f7501840  length 8000004f status 0c01004f
  11: @f75018e0  length 8000004f status 0c01004f
  12: @f7501980  length 80000043 status 0c010043
  13: @f7501a20  length 8000007a status 0c01007a
  14: @f7501ac0  length 80000098 status 0c010098
  15: @f7501b60  length 8000002a status 8001002a 

I have a (from lspci) 
0000:02:08.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M
[Tornado] (rev 78)


I can look into this further to see what the problem is. One funny note,
on the vanilla kernel, my eth0 is at interrupt 177, but on the rt
patched kernel its swapped with the sound card and is at interrupt 169.
Well it's getting too late for me now (its 1am my time (01:00 for you
European folks ;-) , and I need to get up at 6:30 am). Tomorrow, I'll
hack on it some more.

Oh, and here's the highmem patch:

Index: mm/highmem.c
===================================================================
--- mm/highmem.c	(revision 16)
+++ mm/highmem.c	(working copy)
@@ -240,11 +240,11 @@
 	unsigned long flags;
 	unsigned char *vto;
 
-	local_irq_save(flags);
+	local_irq_save_nort(flags);
 	vto = kmap_atomic(to->bv_page, KM_BOUNCE_READ);
 	memcpy(vto + to->bv_offset, vfrom, to->bv_len);
 	kunmap_atomic(vto, KM_BOUNCE_READ);
-	local_irq_restore(flags);
+	local_irq_restore_nort(flags);
 }
 
 #else /* CONFIG_HIGHMEM */



-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-10  6:11                                                                                                   ` Steven Rostedt
@ 2004-12-10 11:05                                                                                                     ` Ingo Molnar
  2004-12-10 11:11                                                                                                     ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-10 11:05 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra


* Steven Rostedt <rostedt@goodmis.org> wrote:

> Hi Ingo,
> 
> Here's your fix. I haven't seen anything else cause the bug, and since
> it uses local_irq_save, I guess the bounce_copy_vec can be called with
> interrupts disabled. Since the kmap_atomic (or just kmap) checks for
> that, I don't think I need more than what I've done.

yeah, it looks good to me too - thx. I've uploaded -32-16 with your fix
included.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-10  6:11                                                                                                   ` Steven Rostedt
  2004-12-10 11:05                                                                                                     ` Ingo Molnar
@ 2004-12-10 11:11                                                                                                     ` Ingo Molnar
  2004-12-10 16:32                                                                                                       ` K.R. Foley
  2004-12-11  2:26                                                                                                       ` Steven Rostedt
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-10 11:11 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra


* Steven Rostedt <rostedt@goodmis.org> wrote:

> Second, my ethernet doesn't work, and it really seems to be some kind
> of interrupt trouble.  It sends out ARPs but doesn't see them come
> back, and it also doesn't seem to know that it sent them out. I get
> the following:
> 
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: transmit timed out, tx_status 00 status e601.
>   diagnostics: net 0ccc media 8880 dma 0000003a fifo 0000
> eth0: Interrupt posted but not delivered -- IRQ blocked by another
> device?
>   Flags; bus-master 1, dirty 33(1) current 33(1)
>   Transmit list 00000000 vs. f75012a0.
>   0: @f7501200  length 80000043 status 8c010043
>   1: @f75012a0  length 8000007a status 0c01007a
>   2: @f7501340  length 8000002a status 0001002a
>   3: @f75013e0  length 80000098 status 0c010098
>   4: @f7501480  length 8000002a status 0001002a
>   5: @f7501520  length 8000002a status 0001002a
>   6: @f75015c0  length 8000002a status 0001002a
>   7: @f7501660  length 8000002a status 0001002a
>   8: @f7501700  length 80000043 status 0c010043
>   9: @f75017a0  length 80000043 status 0c010043
>   10: @f7501840  length 8000004f status 0c01004f
>   11: @f75018e0  length 8000004f status 0c01004f
>   12: @f7501980  length 80000043 status 0c010043
>   13: @f7501a20  length 8000007a status 0c01007a
>   14: @f7501ac0  length 80000098 status 0c010098
>   15: @f7501b60  length 8000002a status 8001002a 
> 
> I have a (from lspci) 
> 0000:02:08.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M
> [Tornado] (rev 78)
> 
> 
> I can look into this further to see what the problem is. One funny
> note, on the vanilla kernel, my eth0 is at interrupt 177, but on the
> rt patched kernel its swapped with the sound card and is at interrupt
> 169. Well it's getting too late for me now (its 1am my time (01:00 for
> you European folks ;-) , and I need to get up at 6:30 am). Tomorrow,
> I'll hack on it some more.

yeah, please check this - you are the first one to report this issue.

A good first step would be to go switch to a non-PREEMPT_RT preemption
model (but to keep the -RT codebase) and see whether the breakage is
related to that. If the breakage goes away with say PREEMPT_DESKTOP then
i'd suggest to enable PREEMPT_HARDIRQS and PREEMPT_SOFTIRQS (but keep
PREEMPT_DESKTOP) - do these alone trigger the breakage? E.g. there was
an obscure timing bug in the floppy driver that only triggered with
PREEMPT_HARDIRQS enabled. So it's not out of question that there's some
other driver bug/race in hiding. The other possibility is some generic
-RT kernel breakage - like the SLAB issue was.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-10 11:11                                                                                                     ` Ingo Molnar
@ 2004-12-10 16:32                                                                                                       ` K.R. Foley
  2004-12-10 18:02                                                                                                         ` Steven Rostedt
  2004-12-11  2:26                                                                                                       ` Steven Rostedt
  1 sibling, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-12-10 16:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Steven Rostedt, Rui Nuno Capela, LKML, Lee Revell, Mark Johnson,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra

Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> 
>>Second, my ethernet doesn't work, and it really seems to be some kind
>>of interrupt trouble.  It sends out ARPs but doesn't see them come
>>back, and it also doesn't seem to know that it sent them out. I get
>>the following:
>>
>>NETDEV WATCHDOG: eth0: transmit timed out
>>eth0: transmit timed out, tx_status 00 status e601.
>>  diagnostics: net 0ccc media 8880 dma 0000003a fifo 0000
>>eth0: Interrupt posted but not delivered -- IRQ blocked by another
>>device?
>>  Flags; bus-master 1, dirty 33(1) current 33(1)
>>  Transmit list 00000000 vs. f75012a0.
>>  0: @f7501200  length 80000043 status 8c010043
>>  1: @f75012a0  length 8000007a status 0c01007a
>>  2: @f7501340  length 8000002a status 0001002a
>>  3: @f75013e0  length 80000098 status 0c010098
>>  4: @f7501480  length 8000002a status 0001002a
>>  5: @f7501520  length 8000002a status 0001002a
>>  6: @f75015c0  length 8000002a status 0001002a
>>  7: @f7501660  length 8000002a status 0001002a
>>  8: @f7501700  length 80000043 status 0c010043
>>  9: @f75017a0  length 80000043 status 0c010043
>>  10: @f7501840  length 8000004f status 0c01004f
>>  11: @f75018e0  length 8000004f status 0c01004f
>>  12: @f7501980  length 80000043 status 0c010043
>>  13: @f7501a20  length 8000007a status 0c01007a
>>  14: @f7501ac0  length 80000098 status 0c010098
>>  15: @f7501b60  length 8000002a status 8001002a 
>>
>>I have a (from lspci) 
>>0000:02:08.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M
>>[Tornado] (rev 78)
>>
>>
>>I can look into this further to see what the problem is. One funny
>>note, on the vanilla kernel, my eth0 is at interrupt 177, but on the
>>rt patched kernel its swapped with the sound card and is at interrupt
>>169. Well it's getting too late for me now (its 1am my time (01:00 for
>>you European folks ;-) , and I need to get up at 6:30 am). Tomorrow,
>>I'll hack on it some more.
> 
> 
> yeah, please check this - you are the first one to report this issue.
> 
> A good first step would be to go switch to a non-PREEMPT_RT preemption
> model (but to keep the -RT codebase) and see whether the breakage is
> related to that. If the breakage goes away with say PREEMPT_DESKTOP then
> i'd suggest to enable PREEMPT_HARDIRQS and PREEMPT_SOFTIRQS (but keep
> PREEMPT_DESKTOP) - do these alone trigger the breakage? E.g. there was
> an obscure timing bug in the floppy driver that only triggered with
> PREEMPT_HARDIRQS enabled. So it's not out of question that there's some
> other driver bug/race in hiding. The other possibility is some generic
> -RT kernel breakage - like the SLAB issue was.
> 
> 	Ingo
> 

I actually have this same card in the system I am sending this from 
currently running 2.6.10-rc2-mm3-V0.7.32-12 #15 SMP.

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-10 16:32                                                                                                       ` K.R. Foley
@ 2004-12-10 18:02                                                                                                         ` Steven Rostedt
  0 siblings, 0 replies; 951+ messages in thread
From: Steven Rostedt @ 2004-12-10 18:02 UTC (permalink / raw)
  To: K.R. Foley
  Cc: Ingo Molnar, Rui Nuno Capela, LKML, Lee Revell, Mark Johnson,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra

On Fri, 2004-12-10 at 10:32 -0600, K.R. Foley wrote:

> >>I have a (from lspci) 
> >>0000:02:08.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M
> >>[Tornado] (rev 78)
> >>
> >>
> 

<snip> 

> I actually have this same card in the system I am sending this from 
> currently running 2.6.10-rc2-mm3-V0.7.32-12 #15 SMP.

I have a dual Athlon MP system with Tyan S2466N4 Motherboard. It looks
more of a problem with the interrupt controller.  I downloaded -17 and
tried that, but now it hangs on starting up cups and the last message
from the kernel is:

lp0: using parport0 (interrupt-driven).

It looks like a pretty bad lock up, since I know exactly when it happens
since the cursor stops blinking.

I'm right now compiling the PREEMPT_DESKTOP kernel to see if that gives
me the same problems.

-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-10 11:11                                                                                                     ` Ingo Molnar
  2004-12-10 16:32                                                                                                       ` K.R. Foley
@ 2004-12-11  2:26                                                                                                       ` Steven Rostedt
  2004-12-11  3:01                                                                                                         ` Steven Rostedt
                                                                                                                           ` (2 more replies)
  1 sibling, 3 replies; 951+ messages in thread
From: Steven Rostedt @ 2004-12-11  2:26 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra

On Fri, 2004-12-10 at 12:11 +0100, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > Second, my ethernet doesn't work, and it really seems to be some kind
> > of interrupt trouble.  It sends out ARPs but doesn't see them come
> > back, and it also doesn't seem to know that it sent them out. I get
> > the following:
> > 

<snip>

> > I'll hack on it some more.
> 
> yeah, please check this - you are the first one to report this issue.

Hi Ingo,  I found the problem! and I now know why John Cooper didn't
have this problem too.  I have CONFIG_PCI_MSI defined. I don't know why,
I must have seen the option a while ago and said to myself "That looks
cool, lets try it". Since I started with the config file of the vanilla
kernel with your rt patches, it was still on. 

Anyways, what is happening is that the io_apic code is mapping irqs to
vectors, and your code didn't account for it. So here's my patch.

Index: arch/i386/kernel/io_apic.c
===================================================================
--- arch/i386/kernel/io_apic.c	(revision 18)
+++ arch/i386/kernel/io_apic.c	(working copy)
@@ -1942,12 +1942,14 @@
 
 static void end_level_ioapic_irq(unsigned int irq)
 {
+#ifndef CONFIG_PCI_MSI
 	if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)) &&
 							irq_desc[irq].action)
+#endif
 		unmask_IO_APIC_irq(irq);
 }
 
-#else /* !CONFIG_PREEMPT_HARDIRQS || !CONFIG_SMP */
+#else /* !CONFIG_PREEMPT_HARDIRQS */
 
 static void mask_and_ack_level_ioapic_irq(unsigned int irq)
 {
@@ -2035,7 +2037,11 @@
 {
 	int irq = vector_to_irq(vector);
 
-	end_level_ioapic_irq(irq);
+#if defined(CONFIG_PREEMPT_HARDIRQS)
+	if (!(irq_desc[vector].status & (IRQ_DISABLED | IRQ_INPROGRESS)) &&
+							irq_desc[vector].action)
+#endif
+		end_level_ioapic_irq(irq);
 }
 
 static void enable_level_ioapic_vector(unsigned int vector)



--------------------

I also removed the comment "!CONFIG_SMP" since it really wasn't correct.
So I can get back to looking at other things.  This also may explain why
my system would hang with my usb printer attached (the usb interrupts
were vectored too).  I'll plug my printer back in and see if it works
now. I'll let you know if I have any more problems.

Thanks,

-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-11  2:26                                                                                                       ` Steven Rostedt
@ 2004-12-11  3:01                                                                                                         ` Steven Rostedt
  2004-12-11  7:37                                                                                                         ` Fernando Lopez-Lezcano
  2004-12-11  9:57                                                                                                         ` Ingo Molnar
  2 siblings, 0 replies; 951+ messages in thread
From: Steven Rostedt @ 2004-12-11  3:01 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra

On Fri, 2004-12-10 at 21:26 -0500, Steven Rostedt wrote:

> Hi Ingo,  I found the problem! and I now know why John Cooper didn't
                                                    ^^^^^^^^^^^
                                            Sorry, I meant K.R.Foley, 
                                          Since he's the one with the
                                          same ethernet card as me.

> have this problem too.  I have CONFIG_PCI_MSI defined. I don't know why,
> I must have seen the option a while ago and said to myself "That looks
> cool, lets try it". Since I started with the config file of the vanilla
> kernel with your rt patches, it was still on. 


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-11  2:26                                                                                                       ` Steven Rostedt
  2004-12-11  3:01                                                                                                         ` Steven Rostedt
@ 2004-12-11  7:37                                                                                                         ` Fernando Lopez-Lezcano
  2004-12-11 12:30                                                                                                           ` Steven Rostedt
  2004-12-11  9:57                                                                                                         ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Fernando Lopez-Lezcano @ 2004-12-11  7:37 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, Rui Nuno Capela, LKML, Lee Revell, Mark Johnson,
	K.R. Foley, Florian Schmidt, Michal Schmidt, emann,
	Peter Zijlstra

On Fri, 2004-12-10 at 18:26, Steven Rostedt wrote:
> On Fri, 2004-12-10 at 12:11 +0100, Ingo Molnar wrote:
> > * Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > > Second, my ethernet doesn't work, and it really seems to be some kind
> > > of interrupt trouble.  It sends out ARPs but doesn't see them come
> > > back, and it also doesn't seem to know that it sent them out. I get
> > > the following:
> > > 
> 
> <snip>
> 
> > > I'll hack on it some more.
> > 
> > yeah, please check this - you are the first one to report this issue.
> 
> Hi Ingo,  I found the problem! and I now know why John Cooper didn't
> have this problem too.  I have CONFIG_PCI_MSI defined. I don't know why,
> I must have seen the option a while ago and said to myself "That looks
> cool, lets try it". Since I started with the config file of the vanilla
> kernel with your rt patches, it was still on. 
> 
> Anyways, what is happening is that the io_apic code is mapping irqs to
> vectors, and your code didn't account for it. So here's my patch.

Can't wait to try the patch, I don't have CONFI_PCI_MSI defined in the
configurations I use. I've had problems with a network card (R8169
driver) for a while (I think I reported it), the interrupts were being
ignored. Hopefully the same problem...

-- Fernando



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-11  2:26                                                                                                       ` Steven Rostedt
  2004-12-11  3:01                                                                                                         ` Steven Rostedt
  2004-12-11  7:37                                                                                                         ` Fernando Lopez-Lezcano
@ 2004-12-11  9:57                                                                                                         ` Ingo Molnar
  2 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-11  9:57 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Rui Nuno Capela, LKML, Lee Revell, Mark Johnson, K.R. Foley,
	Florian Schmidt, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	emann, Peter Zijlstra


* Steven Rostedt <rostedt@goodmis.org> wrote:

> Anyways, what is happening is that the io_apic code is mapping irqs to
> vectors, and your code didn't account for it. So here's my patch.

ah .. thanks, great debugging!

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-11  7:37                                                                                                         ` Fernando Lopez-Lezcano
@ 2004-12-11 12:30                                                                                                           ` Steven Rostedt
  2004-12-13 23:34                                                                                                             ` Fernando Lopez-Lezcano
  0 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2004-12-11 12:30 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Ingo Molnar, Rui Nuno Capela, LKML, Lee Revell, Mark Johnson,
	K.R. Foley, Florian Schmidt, Michal Schmidt, emann,
	Peter Zijlstra

On Fri, 2004-12-10 at 23:37 -0800, Fernando Lopez-Lezcano wrote:

> Can't wait to try the patch, I don't have CONFI_PCI_MSI defined in the
> configurations I use. I've had problems with a network card (R8169
> driver) for a while (I think I reported it), the interrupts were being
> ignored. Hopefully the same problem...

Hi Fernando,

You may have the same problem but the patch I sent won't solve it.  My
patch only is a problem if you have CONFIG_PCI_MSI defined. But I'm sure
there exists other instances that threading hardirqs might not work
properly with other configurations. Send me your .config, and if I get
time I'll take a look. (also your /proc/cpuinfo might help).

Before you send this, make sure that it is the hardirqs that's the
problem. Switch to PREEMPT_DESKTOP and make sure hardirqs are not
threaded.  If the problem goes away, then this may be your problem. If
it does not, I'm afraid that it's something else, and you don't need to
send me anything.

-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-11 12:30                                                                                                           ` Steven Rostedt
@ 2004-12-13 23:34                                                                                                             ` Fernando Lopez-Lezcano
  2004-12-15  9:51                                                                                                               ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Fernando Lopez-Lezcano @ 2004-12-13 23:34 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, Rui Nuno Capela, LKML, Lee Revell, Mark Johnson,
	K.R. Foley, Florian Schmidt, Michal Schmidt, emann,
	Peter Zijlstra

On Sat, 2004-12-11 at 04:30, Steven Rostedt wrote:
> On Fri, 2004-12-10 at 23:37 -0800, Fernando Lopez-Lezcano wrote:
> > Can't wait to try the patch, I don't have CONFI_PCI_MSI defined in the
> > configurations I use. I've had problems with a network card (R8169
> > driver) for a while (I think I reported it), the interrupts were being
> > ignored. Hopefully the same problem...
>
> You may have the same problem but the patch I sent won't solve it.  My
> patch only is a problem if you have CONFIG_PCI_MSI defined. But I'm sure
> there exists other instances that threading hardirqs might not work
> properly with other configurations. Send me your .config, and if I get
> time I'll take a look. (also your /proc/cpuinfo might help).
> 
> Before you send this, make sure that it is the hardirqs that's the
> problem. Switch to PREEMPT_DESKTOP and make sure hardirqs are not
> threaded.

[The following is all done booting into 0.7.32-19, interrupt scheduling
and priorities unchanged from the defaults]

I'm using PREEMPT_DESKTOP. I don't know how to force the kernel to not
thread hardirqs. What I did (maybe the same thing?) is to boot single
user, then turn off /proc/sys/kernel/hardirq_preempt, and then start the
network. It works (the network). And then I tried the same thing with
hardirq_preempt=1 and still worked when booting single user... :-(

So, these are the interrupts after booting single user:
           CPU0       
  0:      36426    IO-APIC-edge  timer  0/35956
  1:        143    IO-APIC-edge  i8042  0/143
  4:          0    IO-APIC-edge  KGDB-stub  0/0
  8:          1    IO-APIC-edge  rtc  0/1
  9:          0   IO-APIC-level  acpi  0/0
 12:        100    IO-APIC-edge  i8042  0/100
 14:         26    IO-APIC-edge  ide0  1/24
 17:         59   IO-APIC-level  libata, libata  0/59
 20:       1462   IO-APIC-level  libata  0/1462
 21:          0   IO-APIC-level  ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd,
uhci_hcd  0/0
NMI:       7544 
LOC:      36254 
ERR:          0
MIS:          0

Here's the extra one I have after I start the network

 16:          7   IO-APIC-level  eth0  0/7

(network works). I then telinit 3, no changes in interrupts (except for
the count numbers), network continues working. 

I then telinit 5 and the network dies. This is the added interrupt:

 11:          0    IO-APIC-edge  radeon@PCI:1:0:0  0/0

I tried repeating the whole thing but going through all the services in
the transition from level 3 to level 5 one by one, and nothing happened
to the network so it must be X. I then rebooted into single user,
started the network and loaded the radeon kernel module alone and the
network was not affected. 

So, this is what I get in dmesg when I go into level 5:

NET: Registered protocol family 10
Disabled Privacy Extensions on device c03e0ec0(lo)
IPv6 over IPv4 tunneling driver
divert: not allocating divert_blk for non-ethernet device sit0
eth0: no IPv6 routers present
[drm] Initialized radeon 1.11.0 20020828 on minor 0:
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
[drm] Loading R200 Microcode
irq 16: nobody cared!
 [<c01041e3>] dump_stack+0x23/0x30 (20)
 [<c014d480>] __report_bad_irq+0x30/0xa0 (24)
 [<c014d590>] note_interrupt+0x70/0xb0 (32)
 [<c014d30c>] do_hardirq+0x13c/0x150 (40)
 [<c014d399>] do_irqd+0x79/0xb0 (32)
 [<c013bf7a>] kthread+0xaa/0xb0 (48)
 [<c0101335>] kernel_thread_helper+0x5/0x10 (153411604)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c014d2aa>] .... do_hardirq+0xda/0x150
.....[<c014d399>] ..   ( <= do_irqd+0x79/0xb0)
.. [<c014045d>] .... print_traces+0x1d/0x60
.....[<c01041e3>] ..   ( <= dump_stack+0x23/0x30)
 
handlers:
[<f88e3f00>] (rtl8169_interrupt+0x0/0x1a0 [r8169])
Disabling IRQ #16

Anything else I could test?

> If the problem goes away, then this may be your problem. If
> it does not, I'm afraid that it's something else, and you don't need to
> send me anything.

Let me know if you still want the .config...
-- Fernando



^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-07 14:11                                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 Ingo Molnar
  2004-12-08  4:31                                                                               ` K.R. Foley
  2004-12-08 17:13                                                                               ` Steven Rostedt
@ 2004-12-14 13:28                                                                               ` Ingo Molnar
  2004-12-14 19:34                                                                                 ` Steven Rostedt
                                                                                                   ` (4 more replies)
  2 siblings, 5 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-14 13:28 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, Steven Rostedt


i have released the -V0.7.33-0 Real-Time Preemption patch, which can be
downloaded from the usual place:

  http://redhat.com/~mingo/realtime-preempt/

this is mainly a port from -rc2-mm3 to -rc3-mm1. Changes:

- due to 2.6.10 release work the -mm kernel now is in fixes-mostly mode,
  but there's one interesting new feature: -rc3-mm1 introduced the
  ->unlocked_ioctl method which is now an official way to do BKL-less
  ioctls. I changed the ALSA ->ioctl_bkl changes in -RT to use this
  facility. The ALSA/sound guys might be interested in these bits. Thus
  another chunk of -RT could go upstream.

- IO-APIC/MSI fix from Steven Rostedt.

- fixed a tracer bug which would produce a kernel warning and an empty
  /proc/latency_trace if the trace buffer overflows.

to create a -V0.7.33-0 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc3.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc3/2.6.10-rc3-mm1/2.6.10-rc3-mm1.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc3-mm1-V0.7.33-0

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 13:28                                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0 Ingo Molnar
@ 2004-12-14 19:34                                                                                 ` Steven Rostedt
  2004-12-14 20:08                                                                                   ` Lee Revell
  2004-12-14 20:07                                                                                 ` Fernando Lopez-Lezcano
                                                                                                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2004-12-14 19:34 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: LKML, Lee Revell, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano

[RFC]

Ingo,

Any thought about adding a one shot timer for the system? 

I know there's been talk about this in the mainline (actually going on
right now in the dynamic Hz thread), but I figured that this would
especially be good for a RT system and not be worried about the HZ
settings.  

An example would be to have the timer interrupt be implemented as a one
shot timer, and be able to register actions to times with it.  The jiffy
calculations could just be an event that is registered to go off once
every HZ.  The timer interrupt would then just have to look at all the
events that have expired (using something like the TSC to determine what
expires), execute their registered actions, and if need be, the action
could add itself back on the event queue (the jiffy timer would do
this), and then the timer would set itself to go off at the next event.
I believe something like this was done by the utime patch (now with the
KURT project).

This way the RT processes would not need to depend on the HZ settings.

I'd be willing to implement this, since I'm doing it regardless for a
client of mine. But I would like to know your input on this.

Thanks,

-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 13:28                                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0 Ingo Molnar
  2004-12-14 19:34                                                                                 ` Steven Rostedt
@ 2004-12-14 20:07                                                                                 ` Fernando Lopez-Lezcano
  2004-12-14 20:35                                                                                   ` Ingo Molnar
  2004-12-14 23:21                                                                                 ` Fernando Lopez-Lezcano
                                                                                                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: Fernando Lopez-Lezcano @ 2004-12-14 20:07 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Steven Rostedt, Fernando Pablo Lopez-Lezcano

On Tue, 2004-12-14 at 05:28, Ingo Molnar wrote:
> i have released the -V0.7.33-0 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> this is mainly a port from -rc2-mm3 to -rc3-mm1. Changes:
> 
> - due to 2.6.10 release work the -mm kernel now is in fixes-mostly mode,
>   but there's one interesting new feature: -rc3-mm1 introduced the
>   ->unlocked_ioctl method which is now an official way to do BKL-less
>   ioctls. I changed the ALSA ->ioctl_bkl changes in -RT to use this
>   facility. The ALSA/sound guys might be interested in these bits. Thus
>   another chunk of -RT could go upstream.

If I build a cvs version of alsa without those patches, will it work on
top of the 0.7.33 kernel? Or do I have to try to isolate the patches and
apply them to current alsa cvs?

-- Fernando



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 19:34                                                                                 ` Steven Rostedt
@ 2004-12-14 20:08                                                                                   ` Lee Revell
  2004-12-14 20:45                                                                                     ` Steven Rostedt
  0 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-12-14 20:08 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, LKML, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano

On Tue, 2004-12-14 at 14:34 -0500, Steven Rostedt wrote:
> [RFC]
> 
> Ingo,
> 
> Any thought about adding a one shot timer for the system? 
> 

Isn't this what George Anzinger is working on?

http://sourceforge.net/projects/high-res-timers/

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 20:07                                                                                 ` Fernando Lopez-Lezcano
@ 2004-12-14 20:35                                                                                   ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-14 20:35 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Steven Rostedt


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:

> If I build a cvs version of alsa without those patches, will it work
> on top of the 0.7.33 kernel? Or do I have to try to isolate the
> patches and apply them to current alsa cvs?

these are the modified files:

 linux/sound/core/oss/pcm_oss.c.orig
 linux/sound/core/oss/mixer_oss.c.orig
 linux/sound/core/pcm_lib.c.orig
 linux/sound/core/control.c.orig
 linux/sound/core/seq/oss/seq_oss.c.orig
 linux/sound/core/seq/seq_clientmgr.c.orig
 linux/sound/core/hwdep.c.orig
 linux/sound/core/pcm_native.c.orig
 linux/sound/core/timer.c.orig
 linux/sound/core/info.c.orig
 linux/sound/core/rawmidi.c.orig

cvs alsa should work just fine, but to get optimal results you might
want to try to apply the above changes (all linux/sound/ changes) to
alsa-cvs.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 20:08                                                                                   ` Lee Revell
@ 2004-12-14 20:45                                                                                     ` Steven Rostedt
  2004-12-14 21:18                                                                                       ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2004-12-14 20:45 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, LKML, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, george

On Tue, 2004-12-14 at 15:08 -0500, Lee Revell wrote:
> On Tue, 2004-12-14 at 14:34 -0500, Steven Rostedt wrote:
> > [RFC]
> > 
> > Ingo,
> > 
> > Any thought about adding a one shot timer for the system? 
> > 
> 
> Isn't this what George Anzinger is working on?
> 
> http://sourceforge.net/projects/high-res-timers/
> 
> Lee
> 

A quick look at this looks like this is what I was looking for. I'd need
to review the code in a more detailed aspect but first glance, Yes, this
is what I want.

Now, since High Res-timers and RT seem to go together, what are the
plans for merging these?  If this is indeed what I need, then I'll be
doing it to myself, but if these can merge in the public domain, then I
would say, all the better.

-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 20:45                                                                                     ` Steven Rostedt
@ 2004-12-14 21:18                                                                                       ` Ingo Molnar
  2004-12-14 21:47                                                                                         ` Lee Revell
                                                                                                           ` (2 more replies)
  0 siblings, 3 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-14 21:18 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Lee Revell, LKML, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, George Anzinger


* Steven Rostedt <rostedt@goodmis.org> wrote:

> > > [RFC]
> > > 
> > > Ingo,
> > > 
> > > Any thought about adding a one shot timer for the system? 
> > > 
> > 
> > Isn't this what George Anzinger is working on?
> > 
> > http://sourceforge.net/projects/high-res-timers/
> > 
> > Lee
> > 
> 
> A quick look at this looks like this is what I was looking for. I'd
> need to review the code in a more detailed aspect but first glance,
> Yes, this is what I want.
> 
> Now, since High Res-timers and RT seem to go together, what are the
> plans for merging these?  If this is indeed what I need, then I'll be
> doing it to myself, [...]

i've been thinking about it on and off. If you would/could try it that
would certainly help. RT for Linux is a dance of many small steps.

the two projects are obviously complementary and i have no intention to
reinvent the wheel in any way. Best would be to bring hires timers up to
upstream-mergable state (independently of the -RT patch) and ask Andrew
to include it in -mm, then i'd port -RT to it automatically.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 21:18                                                                                       ` Ingo Molnar
@ 2004-12-14 21:47                                                                                         ` Lee Revell
  2004-12-14 21:51                                                                                           ` Ingo Molnar
  2004-12-14 21:52                                                                                         ` George Anzinger
  2004-12-14 22:13                                                                                         ` Lee Revell
  2 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-12-14 21:47 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Steven Rostedt, LKML, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, George Anzinger

On Tue, 2004-12-14 at 22:18 +0100, Ingo Molnar wrote:
> i've been thinking about it on and off. If you would/could try it that
> would certainly help. RT for Linux is a dance of many small steps.
> 
> the two projects are obviously complementary and i have no intention to
> reinvent the wheel in any way. Best would be to bring hires timers up to
> upstream-mergable state (independently of the -RT patch) and ask Andrew
> to include it in -mm, then i'd port -RT to it automatically.

OK, I'll give this a shot.  It would certainly help on my underpowered
EPIA system, where my tests show 2.1% residency for the timer ISR with
HZ=1000.  On a system like this I would expect the difference to be
perceptible with a regular desktop workload.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 21:47                                                                                         ` Lee Revell
@ 2004-12-14 21:51                                                                                           ` Ingo Molnar
  2004-12-14 21:57                                                                                             ` Lee Revell
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-12-14 21:51 UTC (permalink / raw)
  To: Lee Revell
  Cc: Steven Rostedt, LKML, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, George Anzinger


* Lee Revell <rlrevell@joe-job.com> wrote:

> On Tue, 2004-12-14 at 22:18 +0100, Ingo Molnar wrote:
> > i've been thinking about it on and off. If you would/could try it that
> > would certainly help. RT for Linux is a dance of many small steps.
> > 
> > the two projects are obviously complementary and i have no intention to
> > reinvent the wheel in any way. Best would be to bring hires timers up to
> > upstream-mergable state (independently of the -RT patch) and ask Andrew
> > to include it in -mm, then i'd port -RT to it automatically.
> 
> OK, I'll give this a shot.  It would certainly help on my underpowered
> EPIA system, where my tests show 2.1% residency for the timer ISR with
> HZ=1000.  On a system like this I would expect the difference to be
> perceptible with a regular desktop workload.

a warning: it's probably quite complex merging work - while the two
projects work on different conceptual issues, they touch the same code.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 21:18                                                                                       ` Ingo Molnar
  2004-12-14 21:47                                                                                         ` Lee Revell
@ 2004-12-14 21:52                                                                                         ` George Anzinger
  2004-12-14 21:59                                                                                           ` Steven Rostedt
  2004-12-14 22:28                                                                                           ` Ingo Molnar
  2004-12-14 22:13                                                                                         ` Lee Revell
  2 siblings, 2 replies; 951+ messages in thread
From: George Anzinger @ 2004-12-14 21:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Steven Rostedt, Lee Revell, LKML, Rui Nuno Capela, Mark Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano

Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> 
>>>>[RFC]
>>>>
>>>>Ingo,
>>>>
>>>>Any thought about adding a one shot timer for the system? 
>>>>
>>>
>>>Isn't this what George Anzinger is working on?
>>>
>>>http://sourceforge.net/projects/high-res-timers/
>>>
>>>Lee
>>>
>>
>>A quick look at this looks like this is what I was looking for. I'd
>>need to review the code in a more detailed aspect but first glance,
>>Yes, this is what I want.
>>
>>Now, since High Res-timers and RT seem to go together, what are the
>>plans for merging these?  If this is indeed what I need, then I'll be
>>doing it to myself, [...]
> 
> 
> i've been thinking about it on and off. If you would/could try it that
> would certainly help. RT for Linux is a dance of many small steps.
> 
> the two projects are obviously complementary and i have no intention to
> reinvent the wheel in any way. Best would be to bring hires timers up to
> upstream-mergable state (independently of the -RT patch) and ask Andrew
> to include it in -mm, then i'd port -RT to it automatically.

Well, I guess I am just backward :)  I plan to port it to the current RT today 
or tomorrow (if all goes well).  I will then work on the changes needed to get 
it into -mm.  Guess I will be supporting two versions for a bit...


-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 21:51                                                                                           ` Ingo Molnar
@ 2004-12-14 21:57                                                                                             ` Lee Revell
  0 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-12-14 21:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Steven Rostedt, LKML, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, George Anzinger

On Tue, 2004-12-14 at 22:51 +0100, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Tue, 2004-12-14 at 22:18 +0100, Ingo Molnar wrote:
> > > i've been thinking about it on and off. If you would/could try it that
> > > would certainly help. RT for Linux is a dance of many small steps.
> > > 
> > > the two projects are obviously complementary and i have no intention to
> > > reinvent the wheel in any way. Best would be to bring hires timers up to
> > > upstream-mergable state (independently of the -RT patch) and ask Andrew
> > > to include it in -mm, then i'd port -RT to it automatically.
> > 
> > OK, I'll give this a shot.  It would certainly help on my underpowered
> > EPIA system, where my tests show 2.1% residency for the timer ISR with
> > HZ=1000.  On a system like this I would expect the difference to be
> > perceptible with a regular desktop workload.
> 
> a warning: it's probably quite complex merging work - while the two
> projects work on different conceptual issues, they touch the same code.
> 

Yeah, I expected this, I'll wait for George to update it.  I am testing
with 2.6.9 vanilla for the time being.  

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 21:52                                                                                         ` George Anzinger
@ 2004-12-14 21:59                                                                                           ` Steven Rostedt
  2004-12-14 22:28                                                                                           ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Steven Rostedt @ 2004-12-14 21:59 UTC (permalink / raw)
  To: george
  Cc: Ingo Molnar, Lee Revell, LKML, Rui Nuno Capela, Mark Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano

On Tue, 2004-12-14 at 13:52 -0800, George Anzinger wrote:
> Ingo Molnar wrote:

...

> >>Now, since High Res-timers and RT seem to go together, what are the
> >>plans for merging these?  If this is indeed what I need, then I'll be
> >>doing it to myself, [...]
> > 
> > 
> > i've been thinking about it on and off. If you would/could try it that
> > would certainly help. RT for Linux is a dance of many small steps.
> > 
> > the two projects are obviously complementary and i have no intention to
> > reinvent the wheel in any way. Best would be to bring hires timers up to
> > upstream-mergable state (independently of the -RT patch) and ask Andrew
> > to include it in -mm, then i'd port -RT to it automatically.
> 
> Well, I guess I am just backward :)  I plan to port it to the current RT today 
> or tomorrow (if all goes well).  I will then work on the changes needed to get 
> it into -mm.  Guess I will be supporting two versions for a bit...
> 

I need what you've been working on, so I'm available to help get the two
together. Since you two (Ingo and George) are the creators of these,
I'll let you fight it out at how to go about this. If it ends up being
two patches for you George, then I would be glad to help maintain the
RT/HigRes one.

-- Steve


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 21:18                                                                                       ` Ingo Molnar
  2004-12-14 21:47                                                                                         ` Lee Revell
  2004-12-14 21:52                                                                                         ` George Anzinger
@ 2004-12-14 22:13                                                                                         ` Lee Revell
  2004-12-14 22:31                                                                                           ` Ingo Molnar
  2 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-12-14 22:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Steven Rostedt, LKML, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, George Anzinger

On Tue, 2004-12-14 at 22:18 +0100, Ingo Molnar wrote:
> the two projects are obviously complementary and i have no intention to
> reinvent the wheel in any way. Best would be to bring hires timers up to
> upstream-mergable state (independently of the -RT patch) and ask Andrew
> to include it in -mm, then i'd port -RT to it automatically.

Among other things I think Paul Davis mentioned that George's high res
timer patch would make it possible for JACK to send MIDI clock.  This
would be a huge improvement.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 21:52                                                                                         ` George Anzinger
  2004-12-14 21:59                                                                                           ` Steven Rostedt
@ 2004-12-14 22:28                                                                                           ` Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-14 22:28 UTC (permalink / raw)
  To: George Anzinger
  Cc: Steven Rostedt, Lee Revell, LKML, Rui Nuno Capela, Mark Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano


* George Anzinger <george@mvista.com> wrote:

> >the two projects are obviously complementary and i have no intention to
> >reinvent the wheel in any way. Best would be to bring hires timers up to
> >upstream-mergable state (independently of the -RT patch) and ask Andrew
> >to include it in -mm, then i'd port -RT to it automatically.
> 
> Well, I guess I am just backward :) I plan to port it to the current
> RT today or tomorrow (if all goes well).  I will then work on the
> changes needed to get it into -mm.  Guess I will be supporting two
> versions for a bit...

very good - i can carry it along in -RT, and your VST bits are certainly
an immediate bonus feature for the non-hard-RT (=laptop, desktop, audio)
folks too.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 22:13                                                                                         ` Lee Revell
@ 2004-12-14 22:31                                                                                           ` Ingo Molnar
  2004-12-14 22:47                                                                                             ` Lee Revell
  2004-12-15  2:38                                                                                             ` Gene Heskett
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-14 22:31 UTC (permalink / raw)
  To: Lee Revell
  Cc: Steven Rostedt, LKML, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, George Anzinger


* Lee Revell <rlrevell@joe-job.com> wrote:

> On Tue, 2004-12-14 at 22:18 +0100, Ingo Molnar wrote:
> > the two projects are obviously complementary and i have no intention to
> > reinvent the wheel in any way. Best would be to bring hires timers up to
> > upstream-mergable state (independently of the -RT patch) and ask Andrew
> > to include it in -mm, then i'd port -RT to it automatically.
> 
> Among other things I think Paul Davis mentioned that George's high res
> timer patch would make it possible for JACK to send MIDI clock.  This
> would be a huge improvement.

<clueless question> roughly what latency/accuracy requirements does the
MIDI clock have, and why is it an advantage if Linux generates it? What
generates it otherwise - external MIDI hardware? Or was the problem
mainly not latency/accuracy but that Linux couldnt generate a
finegrained enough clock?

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 22:31                                                                                           ` Ingo Molnar
@ 2004-12-14 22:47                                                                                             ` Lee Revell
  2004-12-14 22:57                                                                                               ` Paul Davis
  2004-12-14 23:18                                                                                               ` linux-os
  2004-12-15  2:38                                                                                             ` Gene Heskett
  1 sibling, 2 replies; 951+ messages in thread
From: Lee Revell @ 2004-12-14 22:47 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Steven Rostedt, LKML, Rui Nuno Capela, Mark Johnson, K.R. Foley,
	Bill Huey, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, George Anzinger, Paul Davis

On Tue, 2004-12-14 at 23:31 +0100, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Tue, 2004-12-14 at 22:18 +0100, Ingo Molnar wrote:
> > > the two projects are obviously complementary and i have no intention to
> > > reinvent the wheel in any way. Best would be to bring hires timers up to
> > > upstream-mergable state (independently of the -RT patch) and ask Andrew
> > > to include it in -mm, then i'd port -RT to it automatically.
> > 
> > Among other things I think Paul Davis mentioned that George's high res
> > timer patch would make it possible for JACK to send MIDI clock.  This
> > would be a huge improvement.
> 
> <clueless question> roughly what latency/accuracy requirements does the
> MIDI clock have, and why is it an advantage if Linux generates it? What
> generates it otherwise - external MIDI hardware? Or was the problem
> mainly not latency/accuracy but that Linux couldnt generate a
> finegrained enough clock?

Being able to send or receive MIDI clock is a common feature for
hardware and software samplers, sequencers, etc.  It just allows more
flexibility in your setup.  I think currently Linux can receive MIDI
clock better than it can send.

To answer the last question I think the clock was not fine grained
enough.  But as far as timing requirements I don't actually know the
details.  Paul?

Lee




^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 22:47                                                                                             ` Lee Revell
@ 2004-12-14 22:57                                                                                               ` Paul Davis
  2004-12-15  9:32                                                                                                 ` Ingo Molnar
  2004-12-14 23:18                                                                                               ` linux-os
  1 sibling, 1 reply; 951+ messages in thread
From: Paul Davis @ 2004-12-14 22:57 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, Steven Rostedt, LKML, Rui Nuno Capela, Mark Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, George Anzinger

>> > On Tue, 2004-12-14 at 22:18 +0100, Ingo Molnar wrote:
>> > > the two projects are obviously complementary and i have no intention to
>> > > reinvent the wheel in any way. Best would be to bring hires timers up to
>> > > upstream-mergable state (independently of the -RT patch) and ask Andrew
>> > > to include it in -mm, then i'd port -RT to it automatically.
>> > 
>> > Among other things I think Paul Davis mentioned that George's high res
>> > timer patch would make it possible for JACK to send MIDI clock.  This
>> > would be a huge improvement.
>> 
>> <clueless question> roughly what latency/accuracy requirements does the
>> MIDI clock have, and why is it an advantage if Linux generates it? What
>> generates it otherwise - external MIDI hardware? Or was the problem
>> mainly not latency/accuracy but that Linux couldnt generate a
>> finegrained enough clock?

the latter. to send MIDI Clock or MIDI Timecode requires an interrupt
source that is not locked to jiffie-ish intervals or power-of-2
related intervals. For example, MTC requires sending 2 bytes roughly
every 0.8msec. Sending them every msec isn't good enough, in general.

my understanding of the HRT patch is that it allows the timer to be
reprogrammed to elapse with nanosecond resolution. i don't understand
why linus has been so reluctant to move linux in this direction, other
than it being hard to fit into the existing fixed interval timer
framework.

--p

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 22:47                                                                                             ` Lee Revell
  2004-12-14 22:57                                                                                               ` Paul Davis
@ 2004-12-14 23:18                                                                                               ` linux-os
  2004-12-15  1:53                                                                                                 ` Paul Davis
  2004-12-15  2:49                                                                                                 ` Gene Heskett
  1 sibling, 2 replies; 951+ messages in thread
From: linux-os @ 2004-12-14 23:18 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, Steven Rostedt, LKML, Rui Nuno Capela, Mark Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, George Anzinger,
	Paul Davis

On Tue, 14 Dec 2004, Lee Revell wrote:

> On Tue, 2004-12-14 at 23:31 +0100, Ingo Molnar wrote:
>> * Lee Revell <rlrevell@joe-job.com> wrote:
>>
>>> On Tue, 2004-12-14 at 22:18 +0100, Ingo Molnar wrote:
>>>> the two projects are obviously complementary and i have no intention to
>>>> reinvent the wheel in any way. Best would be to bring hires timers up to
>>>> upstream-mergable state (independently of the -RT patch) and ask Andrew
>>>> to include it in -mm, then i'd port -RT to it automatically.
>>>
>>> Among other things I think Paul Davis mentioned that George's high res
>>> timer patch would make it possible for JACK to send MIDI clock.  This
>>> would be a huge improvement.
>>
>> <clueless question> roughly what latency/accuracy requirements does the
>> MIDI clock have, and why is it an advantage if Linux generates it? What
>> generates it otherwise - external MIDI hardware? Or was the problem
>> mainly not latency/accuracy but that Linux couldnt generate a
>> finegrained enough clock?
>
> Being able to send or receive MIDI clock is a common feature for
> hardware and software samplers, sequencers, etc.  It just allows more
> flexibility in your setup.  I think currently Linux can receive MIDI
> clock better than it can send.
>
> To answer the last question I think the clock was not fine grained
> enough.  But as far as timing requirements I don't actually know the
> details.  Paul?
>
> Lee
>

When I use Cakewalk Home-Studio to record Music from my MIDI piano,
I notice that the clock-resolution shown is several orders of
magnitude better than anything a PC can generate! I haven't got
a clue where this information comes from. It is in seconds, starting
at 1 (not zero, don't know why) and has resolution of microseconds
with no missing codes. This is on a M$ PC.

This generates a highly-accurate "time ruler". One can back-up
through this time and resolve samples that appear synchronous
but can be displaced in time with apparent resolution much
better than the 38,400 baud-rate of MIDI. I don't know how
they do it, but this is the MIDI "sample-clock". It has to
be virtual because there isn't any hardware on a PC that can
duplicate it.

It is likely that they use a software PLL with some periodic
updates from a timer-tick, but it sure looks impressive to
see "real-time" with such resolution on a PC.

I'm pretty sure that if Cakewalk decided to port Home Studio
to Linux, they would be able to do it with no technical hurdles.
Its just that, for Music, most use Apple and cheapskates like
me use PCs running M$.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by John Ashcroft.
                  98.36% of all statistics are fiction.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 13:28                                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0 Ingo Molnar
  2004-12-14 19:34                                                                                 ` Steven Rostedt
  2004-12-14 20:07                                                                                 ` Fernando Lopez-Lezcano
@ 2004-12-14 23:21                                                                                 ` Fernando Lopez-Lezcano
  2004-12-15  0:43                                                                                   ` Florian Schmidt
                                                                                                     ` (2 more replies)
  2004-12-15 20:52                                                                                 ` Magnus Määttä
  2005-01-04  6:40                                                                                 ` Bill Huey
  4 siblings, 3 replies; 951+ messages in thread
From: Fernando Lopez-Lezcano @ 2004-12-14 23:21 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Steven Rostedt, Fernando Pablo Lopez-Lezcano

On Tue, 2004-12-14 at 05:28, Ingo Molnar wrote:
> i have released the -V0.7.33-0 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> this is mainly a port from -rc2-mm3 to -rc3-mm1. Changes:
> 
> - due to 2.6.10 release work the -mm kernel now is in fixes-mostly mode,
>   but there's one interesting new feature: -rc3-mm1 introduced the
>   ->unlocked_ioctl method which is now an official way to do BKL-less
>   ioctls. I changed the ALSA ->ioctl_bkl changes in -RT to use this
>   facility. The ALSA/sound guys might be interested in these bits. Thus
>   another chunk of -RT could go upstream.
> 
> - IO-APIC/MSI fix from Steven Rostedt.
> 
> - fixed a tracer bug which would produce a kernel warning and an empty
>   /proc/latency_trace if the trace buffer overflows.

I don't know which change did it, but I have network connectivity in my
athlon64 test box with 0.7.33-0! Woohoo! [*]
Thanks...
-- Fernando

[*] as reported before: going up to runlevel 5 killed the network, up to
leve 3 everything was fine, I was guessing probably due to some problem
with X and the radeon driver. 



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 23:21                                                                                 ` Fernando Lopez-Lezcano
@ 2004-12-15  0:43                                                                                   ` Florian Schmidt
  2004-12-15  1:09                                                                                   ` Lee Revell
  2004-12-17  0:45                                                                                   ` Fernando Lopez-Lezcano
  2 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2004-12-15  0:43 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Thomas Gleixner, Steven Rostedt, Fernando Pablo Lopez-Lezcano

On 14 Dec 2004 15:21:56 -0800
Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:

> I don't know which change did it, but I have network connectivity in my
> athlon64 test box with 0.7.33-0! Woohoo! [*]
> Thanks...
> -- Fernando
> 

I thought i'd just chime in. 33-0 runs excellent here (i have no
debugging or timing enabled, but xrun performance is really good (i have
seen none but app caused ones (only mild load though, will push it a bit
harder though tomorrow))..

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 23:21                                                                                 ` Fernando Lopez-Lezcano
  2004-12-15  0:43                                                                                   ` Florian Schmidt
@ 2004-12-15  1:09                                                                                   ` Lee Revell
  2004-12-15  2:04                                                                                     ` Fernando Lopez-Lezcano
  2004-12-17  0:45                                                                                   ` Fernando Lopez-Lezcano
  2 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2004-12-15  1:09 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Steven Rostedt

On Tue, 2004-12-14 at 15:21 -0800, Fernando Lopez-Lezcano wrote:
> I don't know which change did it, but I have network connectivity in my
> athlon64 test box with 0.7.33-0! Woohoo! [*]

Wait, this works on x84-64 now?  There was a recent report on LAU that
it didn't compile.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 23:18                                                                                               ` linux-os
@ 2004-12-15  1:53                                                                                                 ` Paul Davis
  2004-12-15  2:49                                                                                                 ` Gene Heskett
  1 sibling, 0 replies; 951+ messages in thread
From: Paul Davis @ 2004-12-15  1:53 UTC (permalink / raw)
  To: linux-os
  Cc: Lee Revell, Ingo Molnar, Steven Rostedt, LKML, Rui Nuno Capela,
	Mark Johnson, K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, George Anzinger

>When I use Cakewalk Home-Studio to record Music from my MIDI piano,
>I notice that the clock-resolution shown is several orders of
>magnitude better than anything a PC can generate! I haven't got

incoming timing is a solved problem. the problem is scheduling
outgoing data, which requires an interrupt source of some kind.

>a clue where this information comes from. It is in seconds, starting

they almost certainly use either the sample clock of the audio
interface interpolated/estimated using a DLL (Delay Locked Loop).

>I'm pretty sure that if Cakewalk decided to port Home Studio
>to Linux, they would be able to do it with no technical hurdles.
>Its just that, for Music, most use Apple and cheapskates like
>me use PCs running M$.

Real cheapskates would use Linux with Rosegarden, Ardour et al :)

--p

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-15  1:09                                                                                   ` Lee Revell
@ 2004-12-15  2:04                                                                                     ` Fernando Lopez-Lezcano
  2004-12-15  9:09                                                                                       ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Fernando Lopez-Lezcano @ 2004-12-15  2:04 UTC (permalink / raw)
  To: Lee Revell
  Cc: Ingo Molnar, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Steven Rostedt

On Tue, 2004-12-14 at 17:09, Lee Revell wrote:
> On Tue, 2004-12-14 at 15:21 -0800, Fernando Lopez-Lezcano wrote:
> > I don't know which change did it, but I have network connectivity in my
> > athlon64 test box with 0.7.33-0! Woohoo! [*]
> 
> Wait, this works on x84-64 now?  There was a recent report on LAU that
> it didn't compile.

The machine has an athlon64 but it is running 32 bit fc2. I have not
tried to build (yet) on 64 bit fcx.

-- Fernando



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 22:31                                                                                           ` Ingo Molnar
  2004-12-14 22:47                                                                                             ` Lee Revell
@ 2004-12-15  2:38                                                                                             ` Gene Heskett
  2004-12-15 15:24                                                                                               ` K.R. Foley
  1 sibling, 1 reply; 951+ messages in thread
From: Gene Heskett @ 2004-12-15  2:38 UTC (permalink / raw)
  To: linux-kernel; +Cc: Ingo Molnar

On Tuesday 14 December 2004 17:31, Ingo Molnar wrote:
>* Lee Revell <rlrevell@joe-job.com> wrote:
>> On Tue, 2004-12-14 at 22:18 +0100, Ingo Molnar wrote:
>> > the two projects are obviously complementary and i have no
>> > intention to reinvent the wheel in any way. Best would be to
>> > bring hires timers up to upstream-mergable state (independently
>> > of the -RT patch) and ask Andrew to include it in -mm, then i'd
>> > port -RT to it automatically.
>>
>> Among other things I think Paul Davis mentioned that George's high
>> res timer patch would make it possible for JACK to send MIDI
>> clock.  This would be a huge improvement.
>
><clueless question> roughly what latency/accuracy requirements does
> the MIDI clock have, and why is it an advantage if Linux generates
> it? What generates it otherwise - external MIDI hardware? Or was
> the problem mainly not latency/accuracy but that Linux couldnt
> generate a finegrained enough clock?
>
> Ingo

I'm not sure of the exact reasons, Ingo.  But the midi clock is a
bit of an odd man out in the normal progression of baud rates,
its 31,250 baud, in case you didn't already know that.
  
A lot of systems resort to a hardware timer driving a seriel shift
register as I doubt if one could guarantee writing to a single
bit port with an interval error of much more than 5% bit to bit,
and cumulatively less than that for the overall byte.  It can be
done though, we have a program for the coco's that run on a .89
mhz clock that can actually drive the seriel port well enough to
run a midi keyboard plugged into it. I've run it, and it has
enough spare time that I can steer some instruments to a second
homemade midi pack plugged into its expansion interface at the
same time & no descernable squiggles in the beat of the music.

Did you see my comment about the later versions seeming to slow
seti a wee bit?  Other than that, I'm in love with this, the
whole system just plain feels better.  The only thing on my wish
list right now is to be able to shut tvtime up, it grows the
system log about a megabyte a minute with its missed read reports.
Or is it tvtime that needs help?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.30% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 23:18                                                                                               ` linux-os
  2004-12-15  1:53                                                                                                 ` Paul Davis
@ 2004-12-15  2:49                                                                                                 ` Gene Heskett
  1 sibling, 0 replies; 951+ messages in thread
From: Gene Heskett @ 2004-12-15  2:49 UTC (permalink / raw)
  To: linux-kernel, linux-os
  Cc: Lee Revell, Ingo Molnar, Steven Rostedt, Rui Nuno Capela,
	Mark Johnson, K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, George Anzinger,
	Paul Davis

On Tuesday 14 December 2004 18:18, linux-os wrote:
>On Tue, 14 Dec 2004, Lee Revell wrote:

>>> <clueless question> roughly what latency/accuracy requirements
>> Lee
>
>When I use Cakewalk Home-Studio to record Music from my MIDI piano,
>I notice that the clock-resolution shown is several orders of
>magnitude better than anything a PC can generate! I haven't got
>a clue where this information comes from. It is in seconds, starting
>at 1 (not zero, don't know why) and has resolution of microseconds
>with no missing codes. This is on a M$ PC.
>
>This generates a highly-accurate "time ruler". One can back-up
>through this time and resolve samples that appear synchronous
>but can be displaced in time with apparent resolution much
>better than the 38,400 baud-rate of MIDI. I don't know how
>they do it, but this is the MIDI "sample-clock". It has to
>be virtual because there isn't any hardware on a PC that can
>duplicate it.

Midi's baud rate isn't 38,400, its 31,250.  Check your
references.  It should be in any keyboards manual.

>It is likely that they use a software PLL with some periodic
>updates from a timer-tick, but it sure looks impressive to
>see "real-time" with such resolution on a PC.

Well, it is pretty slow for a non multiuser os equipt with todays
hardware.

>I'm pretty sure that if Cakewalk decided to port Home Studio
>to Linux, they would be able to do it with no technical hurdles.
>Its just that, for Music, most use Apple and cheapskates like
>me use PCs running M$.
>
>Cheers,
>Dick Johnson
>Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
>  Notice : All mail here is now cached for review by John Ashcroft.

I don't want to bring politics into this group it has no place
here.  None, nada.   But, since you mentioned it, screw Ashcroft
and the camel that ride in on him.  He has done more to bring true
democracy to its knees in 4 years than all others before him in
our 230 years.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.30% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-15  2:04                                                                                     ` Fernando Lopez-Lezcano
@ 2004-12-15  9:09                                                                                       ` Ingo Molnar
  2004-12-15 10:17                                                                                         ` Andrew Walrond
  2004-12-15 16:51                                                                                         ` Lee Revell
  0 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-15  9:09 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Lee Revell, linux-kernel, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Steven Rostedt


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:

> On Tue, 2004-12-14 at 17:09, Lee Revell wrote:
> > On Tue, 2004-12-14 at 15:21 -0800, Fernando Lopez-Lezcano wrote:
> > > I don't know which change did it, but I have network connectivity in my
> > > athlon64 test box with 0.7.33-0! Woohoo! [*]
> > 
> > Wait, this works on x84-64 now?  There was a recent report on LAU that
> > it didn't compile.
> 
> The machine has an athlon64 but it is running 32 bit fc2. I have not
> tried to build (yet) on 64 bit fcx.

x64 wont work for now, it needs some work to make threaded timer IRQs
work.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 22:57                                                                                               ` Paul Davis
@ 2004-12-15  9:32                                                                                                 ` Ingo Molnar
  2004-12-15 16:23                                                                                                   ` Lee Revell
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2004-12-15  9:32 UTC (permalink / raw)
  To: Paul Davis
  Cc: Lee Revell, Steven Rostedt, LKML, Rui Nuno Capela, Mark Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, George Anzinger


* Paul Davis <paul@linuxaudiosystems.com> wrote:

> the latter. to send MIDI Clock or MIDI Timecode requires an interrupt
> source that is not locked to jiffie-ish intervals or power-of-2
> related intervals. For example, MTC requires sending 2 bytes roughly
> every 0.8msec. Sending them every msec isn't good enough, in general.

yeah, i can understand that - 20% slower music is bad, even to kernel
hackers ;-)

> my understanding of the HRT patch is that it allows the timer to be
> reprogrammed to elapse with nanosecond resolution. i don't understand
> why linus has been so reluctant to move linux in this direction, other
> than it being hard to fit into the existing fixed interval timer
> framework.

i dont think there's any particular type of feeling from Linus towards
HRT - it's always the quality of the patch (and the underlying
fundamental issues) that controls, plus 'demand'. So integrating this
stuff is not a matter of will, it's a matter of having good enough code.

the current 'fixed interval timer framework' is one reason that makes
Linux scale so well on big networked boxes, which can easily have
millions of timers running (per CPU). Sub-jiffy solutions i've seen so
far tended to concentrate on making sub-jiffies work, while keeping
fixed interval timers only as a side-effect. That's not how usage
demands it - right now fixed interval timers are king in terms of usage
(and will be king even if we had HRT integrated), so subjiffy timers
must be very precisely engineered to not hurt fixed interval timers.
Plus if we touch the timer code then maybe it could be made more
deterministic (cascading isnt quite deterministic right now) - which
further complicates things. It's not a simple and clear-cut task for
sure.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12
  2004-12-13 23:34                                                                                                             ` Fernando Lopez-Lezcano
@ 2004-12-15  9:51                                                                                                               ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-12-15  9:51 UTC (permalink / raw)
  To: Fernando Lopez-Lezcano
  Cc: Steven Rostedt, Rui Nuno Capela, LKML, Lee Revell, Mark Johnson,
	K.R. Foley, Florian Schmidt, Michal Schmidt, emann,
	Peter Zijlstra


* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:

> [The following is all done booting into 0.7.32-19, interrupt
> scheduling and priorities unchanged from the defaults]
> 
> I'm using PREEMPT_DESKTOP. I don't know how to force the kernel to not
> thread hardirqs. [...]

this is now moot for your case, but here's how you can disable hardirq
threading: you can disable CONFIG_PREEMPT_HARDIRQS in the .config, or
you can disable it via the hardirq-preempt=0 boot-time kernel flag.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-15  9:09                                                                                       ` Ingo Molnar
@ 2004-12-15 10:17                                                                                         ` Andrew Walrond
  2004-12-15 16:51                                                                                         ` Lee Revell
  1 sibling, 0 replies; 951+ messages in thread
From: Andrew Walrond @ 2004-12-15 10:17 UTC (permalink / raw)
  To: linux-kernel
  Cc: Ingo Molnar, Fernando Lopez-Lezcano, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Thomas Gleixner, Steven Rostedt

On Wednesday 15 Dec 2004 09:09, Ingo Molnar wrote:
>
> x64 wont work for now, it needs some work to make threaded timer IRQs
> work.
>

Don't leave it too long; I'm pretty sure I'm not the only x64 user wanting to 
test your -RT stuff.

I'm beginning to develop 32bit-envy ;)

Andrew Walrond

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-15  2:38                                                                                             ` Gene Heskett
@ 2004-12-15 15:24                                                                                               ` K.R. Foley
  2004-12-15 16:34                                                                                                 ` Gene Heskett
  0 siblings, 1 reply; 951+ messages in thread
From: K.R. Foley @ 2004-12-15 15:24 UTC (permalink / raw)
  To: gene.heskett; +Cc: linux-kernel, Ingo Molnar

Gene Heskett wrote:
> On Tuesday 14 December 2004 17:31, Ingo Molnar wrote:
> 
>>* Lee Revell <rlrevell@joe-job.com> wrote:
>>
>>>On Tue, 2004-12-14 at 22:18 +0100, Ingo Molnar wrote:
>>>
>>>>the two projects are obviously complementary and i have no
>>>>intention to reinvent the wheel in any way. Best would be to
>>>>bring hires timers up to upstream-mergable state (independently
>>>>of the -RT patch) and ask Andrew to include it in -mm, then i'd
>>>>port -RT to it automatically.
>>>
>>>Among other things I think Paul Davis mentioned that George's high
>>>res timer patch would make it possible for JACK to send MIDI
>>>clock.  This would be a huge improvement.
>>
>><clueless question> roughly what latency/accuracy requirements does
>>the MIDI clock have, and why is it an advantage if Linux generates
>>it? What generates it otherwise - external MIDI hardware? Or was
>>the problem mainly not latency/accuracy but that Linux couldnt
>>generate a finegrained enough clock?
>>
>>Ingo
> 
> 
> I'm not sure of the exact reasons, Ingo.  But the midi clock is a
> bit of an odd man out in the normal progression of baud rates,
> its 31,250 baud, in case you didn't already know that.
>   
> A lot of systems resort to a hardware timer driving a seriel shift
> register as I doubt if one could guarantee writing to a single
> bit port with an interval error of much more than 5% bit to bit,
> and cumulatively less than that for the overall byte.  It can be
> done though, we have a program for the coco's that run on a .89
> mhz clock that can actually drive the seriel port well enough to
> run a midi keyboard plugged into it. I've run it, and it has
> enough spare time that I can steer some instruments to a second
> homemade midi pack plugged into its expansion interface at the
> same time & no descernable squiggles in the beat of the music.
> 
> Did you see my comment about the later versions seeming to slow
> seti a wee bit?  Other than that, I'm in love with this, the
> whole system just plain feels better.  The only thing on my wish
> list right now is to be able to shut tvtime up, it grows the
> system log about a megabyte a minute with its missed read reports.
> Or is it tvtime that needs help?
> 

Are you referring to the "Read missed before next interrupt" messages? 
If so, you can disable this by disabling the rtc histogram under:
Device Drivers --> Character devices --> Real Time Clock Histogram Support.

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-15  9:32                                                                                                 ` Ingo Molnar
@ 2004-12-15 16:23                                                                                                   ` Lee Revell
  0 siblings, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-12-15 16:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Paul Davis, Steven Rostedt, LKML, Rui Nuno Capela, Mark Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, George Anzinger

On Wed, 2004-12-15 at 10:32 +0100, Ingo Molnar wrote:
> * Paul Davis <paul@linuxaudiosystems.com> wrote:
> 
> > the latter. to send MIDI Clock or MIDI Timecode requires an interrupt
> > source that is not locked to jiffie-ish intervals or power-of-2
> > related intervals. For example, MTC requires sending 2 bytes roughly
> > every 0.8msec. Sending them every msec isn't good enough, in general.
> 
> yeah, i can understand that - 20% slower music is bad, even to kernel
> hackers ;-)

It's a bit worse than that.  If there is excessive jitter in your MIDI
clock/MTC then your other devices will fail to lock on to it at all - it
does not degrade gracefully.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-15 15:24                                                                                               ` K.R. Foley
@ 2004-12-15 16:34                                                                                                 ` Gene Heskett
  2004-12-15 16:38                                                                                                   ` K.R. Foley
  0 siblings, 1 reply; 951+ messages in thread
From: Gene Heskett @ 2004-12-15 16:34 UTC (permalink / raw)
  To: linux-kernel; +Cc: K.R. Foley, Ingo Molnar

On Wednesday 15 December 2004 10:24, K.R. Foley wrote:
>Gene Heskett wrote:
>> Did you see my comment about the later versions seeming to slow
>> seti a wee bit?  Other than that, I'm in love with this, the
>> whole system just plain feels better.  The only thing on my wish
>> list right now is to be able to shut tvtime up, it grows the
>> system log about a megabyte a minute with its missed read reports.
>> Or is it tvtime that needs help?
>
>Are you referring to the "Read missed before next interrupt"
> messages? If so, you can disable this by disabling the rtc
> histogram under: Device Drivers --> Character devices --> Real Time
> Clock Histogram Support.

Ok, thats building now.  Silly Q:  Can that be turned back on with a
setting in /proc or /sys?

>kr

Thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.30% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-15 16:34                                                                                                 ` Gene Heskett
@ 2004-12-15 16:38                                                                                                   ` K.R. Foley
  0 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2004-12-15 16:38 UTC (permalink / raw)
  To: gene.heskett; +Cc: linux-kernel, Ingo Molnar

Gene Heskett wrote:
> On Wednesday 15 December 2004 10:24, K.R. Foley wrote:
> 
>>Gene Heskett wrote:
>>
>>>Did you see my comment about the later versions seeming to slow
>>>seti a wee bit?  Other than that, I'm in love with this, the
>>>whole system just plain feels better.  The only thing on my wish
>>>list right now is to be able to shut tvtime up, it grows the
>>>system log about a megabyte a minute with its missed read reports.
>>>Or is it tvtime that needs help?
>>
>>Are you referring to the "Read missed before next interrupt"
>>messages? If so, you can disable this by disabling the rtc
>>histogram under: Device Drivers --> Character devices --> Real Time
>>Clock Histogram Support.
> 
> 
> Ok, thats building now.  Silly Q:  Can that be turned back on with a
> setting in /proc or /sys?
> 

Not currently.

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-15  9:09                                                                                       ` Ingo Molnar
  2004-12-15 10:17                                                                                         ` Andrew Walrond
@ 2004-12-15 16:51                                                                                         ` Lee Revell
  1 sibling, 0 replies; 951+ messages in thread
From: Lee Revell @ 2004-12-15 16:51 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Fernando Lopez-Lezcano, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Bill Huey, Adam Heath,
	Florian Schmidt, Thomas Gleixner, Steven Rostedt

On Wed, 2004-12-15 at 10:09 +0100, Ingo Molnar wrote:
> x64 wont work for now, it needs some work to make threaded timer IRQs
> work.

But the timer IRQ can only be threaded with PREEMPT_RT, right?  Seems
like PREEMPT_DESKTOP should work.  Older VP patches worked on x64 (S7,
T3) IIRC.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 13:28                                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0 Ingo Molnar
                                                                                                   ` (2 preceding siblings ...)
  2004-12-14 23:21                                                                                 ` Fernando Lopez-Lezcano
@ 2004-12-15 20:52                                                                                 ` Magnus Määttä
  2005-01-04  6:40                                                                                 ` Bill Huey
  4 siblings, 0 replies; 951+ messages in thread
From: Magnus Määttä @ 2004-12-15 20:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt

Hi Ingo,

On Tuesday 14 December 2004 14.28, Ingo Molnar wrote:
> i have released the -V0.7.33-0 Real-Time Preemption patch, which
> can be downloaded from the usual place:
>
>   http://redhat.com/~mingo/realtime-preempt/
>
> this is mainly a port from -rc2-mm3 to -rc3-mm1. Changes:
>
> - due to 2.6.10 release work the -mm kernel now is in fixes-mostly
> mode, but there's one interesting new feature: -rc3-mm1 introduced
> the ->unlocked_ioctl method which is now an official way to do
> BKL-less ioctls. I changed the ALSA ->ioctl_bkl changes in -RT to
> use this facility. The ALSA/sound guys might be interested in these
> bits. Thus another chunk of -RT could go upstream.
>
> - IO-APIC/MSI fix from Steven Rostedt.
>
> - fixed a tracer bug which would produce a kernel warning and an
> empty /proc/latency_trace if the trace buffer overflows.

I got this deadlock with V0.7.33-2:

==========================================
[ BUG: lock recursion deadlock detected! |
------------------------------------------
already locked:  [c04d63e0] {rtc_task_lock}
.. held by:             IRQ 8:  305 [df45c030,  52]
... acquired at:  rtc_interrupt+0x137/0x230

------------------------------
| showing all locks held by: |  (IRQ 8/305 [df45c030,  52]):
------------------------------

#001:             [c04d63e0] {rtc_task_lock}
... acquired at:  rtc_interrupt+0x137/0x230

#002:             [df4f16f8] {&timer->lock}
... acquired at:  _snd_timer_stop+0x8f/0x180

-{current task's backtrace}----------------->
 [<c0104273>] dump_stack+0x23/0x30 (20)
 [<c013d011>] check_deadlock+0x141/0x2d0 (48)
 [<c013dc1a>] task_blocks_on_lock+0x7a/0x100 (36)
 [<c041a847>] __down_mutex+0x237/0x440 (88)
 [<c013f86b>] __spin_lock+0x4b/0x60 (24)
 [<c013f8dd>] _spin_lock_irq+0x1d/0x20 (16)
 [<c02b60d9>] rtc_control+0x29/0x80 (32)
 [<c034efef>] rtctimer_stop+0x2f/0x70 (28)
 [<c034c8fc>] snd_timer_interrupt+0x2fc/0x380 (64)
 [<c034f057>] rtctimer_interrupt+0x27/0x40 (20)
 [<c02b4f08>] rtc_interrupt+0x158/0x230 (32)
 [<c014f40a>] handle_IRQ_event+0x6a/0xf0 (52)
 [<c014fdcb>] do_hardirq+0xab/0x130 (40)
 [<c014fec0>] do_irqd+0x70/0xb0 (32)
 [<c013bcc6>] kthread+0xa6/0xf0 (48)
 [<c0101365>] kernel_thread_helper+0x5/0x10 (548970516)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [<c041a94a>] .... __down_mutex+0x33a/0x440
.....[<c013f86b>] ..   ( <= __spin_lock+0x4b/0x60)
.. [<c01435bb>] .... print_traces+0x1b/0x50
.....[<c0104273>] ..   ( <= dump_stack+0x23/0x30)


showing all tasks:
s            init:    1 [c1467970, 116] (not blocked)
s           IRQ 0:    2 [c1467320,  50] (not blocked)
s     ksoftirqd/0:    3 [c1466cd0, 105] (not blocked)
s       desched/0:    4 [c1466680, 105] (not blocked)
s        events/0:    5 [c1466030,  98] (not blocked)
s         khelper:    6 [df687970, 111] (not blocked)
s         kthread:   11 [df687320, 110] (not blocked)
s          kacpid:   20 [df686cd0, 110] (not blocked)
s           IRQ 9:   21 [df686680,  51] (not blocked)
s       kblockd/0:  117 [c15d4680, 110] (not blocked)
s           khubd:  125 [c15e9320, 115] (not blocked)
s         pdflush:  226 [c15e8680, 117] (not blocked)
s         pdflush:  227 [c15e9970, 116] (not blocked)
s         kswapd0:  228 [c15d4030, 117] (not blocked)
s           aio/0:  229 [df686030, 112] (not blocked)
s           IRQ 8:  305 [df45c030,  52] (not blocked)
s         kseriod:  309 [df45c680, 117] (not blocked)
s          IRQ 12:  315 [df45ccd0,  53] (not blocked)
s          IRQ 14:  405 [df45d320,  54] (not blocked)
s          IRQ 15:  407 [df46b970,  55] (not blocked)
s        khpsbpkt:  420 [df46b320, 115] blocked on: [c04ddfc4] {khpsbpkt_sig.lock}
.. held by:          khpsbpkt:  420 [df46b320, 115]
... acquired at:  dma_trm_tasklet+0x89/0x1a0
s          IRQ 10:  430 [c15d5970,  56] (not blocked)
s     knodemgrd_0:  431 [c15e8cd0, 116] blocked on: [df49bba8] {&hi->reset_sem}
.. held by:       knodemgrd_0:  431 [c15e8cd0, 116]
... acquired at:  highlevel_host_reset+0x4b/0x60
s          IRQ 11:  433 [df45d970,  57] (not blocked)
s           IRQ 1:  451 [c15e8030,  58] (not blocked)
s        krxtimod:  481 [c15fd970, 118] (not blocked)
s          krxiod:  482 [c15d4cd0, 117] (not blocked)
s         krxsecd:  483 [c15fd320, 117] (not blocked)
s       kafstimod:  487 [c15d5320, 120] (not blocked)
s      kafsasyncd:  488 [df46a680, 120] (not blocked)
s      reiserfs/0:  489 [df46acd0, 111] (not blocked)
s           udevd:  580 [de854030, 113] (not blocked)
s           IRQ 6: 4119 [dde00030,  59] (not blocked)
s       ipw2200/0: 4284 [dde01320, 110] (not blocked)
s       syslog-ng: 7503 [dcb30cd0, 115] (not blocked)
s             gpm: 7629 [dcb26cd0, 117] (not blocked)
s         portmap: 8374 [c15fc680, 116] (not blocked)
s        rpciod/0: 8386 [deefb970, 111] (not blocked)
s           lockd: 8387 [dde00cd0, 117] (not blocked)
s            sshd: 8439 [ddbbc680, 120] (not blocked)
s            cron: 8481 [ddbbc030, 116] (not blocked)
s           login: 8502 [c15fccd0, 117] (not blocked)
s          agetty: 8503 [ddb8e680, 116] (not blocked)
s          agetty: 8504 [ddbbd970, 116] (not blocked)
s          agetty: 8505 [deefa680, 116] (not blocked)
s          agetty: 8506 [dcb31320, 116] (not blocked)
s          agetty: 8507 [ddbbccd0, 116] (not blocked)
s            bash: 8588 [de855970, 117] (not blocked)
s             kdm: 8653 [deefb320, 116] (not blocked)
?               X: 8656 [deefacd0, 116] (not blocked)
s             kdm: 8657 [c15fc030, 117] (not blocked)
s        startkde: 8681 [ddbbd320, 118] (not blocked)
s         kdeinit: 8714 [dde01970, 116] (not blocked)
s         kdeinit: 8717 [de854680, 115] (not blocked)
s         kdeinit: 8719 [dcb26030, 116] (not blocked)
s         kdeinit: 8722 [df46a030, 116] (not blocked)
s         kdeinit: 8731 [de855320, 116] (not blocked)
s         kdeinit: 8735 [ddb8f970, 115] (not blocked)
s        kwrapper: 8736 [dde00680, 116] (not blocked)
s         kdeinit: 8738 [ddb8ecd0, 116] (not blocked)
s         kdeinit: 8739 [deefa030, 116] (not blocked)
s         kdeinit: 8741 [dcb30030, 115] (not blocked)
s         kdeinit: 8743 [dcb27320, 115] (not blocked)
s         kdeinit: 8745 [dcb30680, 116] (not blocked)
s         kdeinit: 8746 [dcb27970, 116] (not blocked)
s         kdeinit: 8748 [dcb26680, 115] (not blocked)
s         kdeinit: 8752 [ddb8f320, 115] (not blocked)
s          korgac: 8753 [dcb31970, 116] (not blocked)
s         kalarmd: 8755 [d7398cd0, 119] (not blocked)
s         kdeinit: 8756 [ddb8e030, 116] (not blocked)
s            bash: 8757 [de854cd0, 117] (not blocked)
s         firefox: 8765 [d7399320, 117] (not blocked)
s     firefox-bin: 8778 [d7399970, 115] (not blocked)
s     firefox-bin: 8782 [d5c53970, 116] (not blocked)
s     firefox-bin: 8784 [d7398680, 116] (not blocked)
X         netstat: 8790 [d5c52cd0, 118] (not blocked)
s             ssh: 8811 [d5c53320, 117] (not blocked)
s            bash: 8812 [d5c52680, 117] (not blocked)
s            bash: 8820 [d5c52030, 117] (not blocked)
s            bash: 8828 [d7398030, 117] (not blocked)
s            bash: 8836 [d3161970, 117] (not blocked)
s            bash: 8844 [d3160cd0, 116] (not blocked)
s            bash: 8852 [d3161320, 116] (not blocked)
s            bash: 8860 [d3160680, 116] (not blocked)
s            bash: 8868 [d3160030, 116] (not blocked)
s             ssh: 8876 [d328d320, 117] (not blocked)
s             ssh: 8877 [d328c030, 117] (not blocked)
s            bash: 8880 [d328c680, 119] (not blocked)
s           jackd: 8881 [d328ccd0, 120] (not blocked)
s           jackd: 8882 [d328d970, 116] (not blocked)
s           jackd: 8883 [d1f6f970,   0] (not blocked)
s           jackd: 8884 [d1f6f320,   9] (not blocked)
s          qsynth: 8887 [d1f6ecd0, 116] (not blocked)
s          qsynth: 8888 [c8095970,  10] (not blocked)
?          qsynth: 8889 [c8095320, 116] (not blocked)
s       ksnapshot: 8890 [d1f6e030, 116] (not blocked)
s         ladccad: 8908 [c8094cd0, 116] (not blocked)
s         ladccad: 8910 [c8094680,  10] (not blocked)
s         ladccad: 8911 [d1f6e680, 116] (not blocked)
s         ladccad: 8912 [c5769970, 116] (not blocked)
s         ladccad: 8919 [c5769320, 116] (not blocked)
s         ladccad: 8920 [c5768cd0, 123] (not blocked)
s         ladccad: 8909 [c8094030, 120] (not blocked)
D      rosegarden: 8923 [c5768030, 116] blocked on: [c3f12418] {&q->lock}
.. held by:                 X: 8656 [deefacd0, 116]
... acquired at:  __wake_up+0x51/0x60
R rosegardenseque: 8924 [c5768680, 116] (not blocked)
s rosegardenseque: 8925 [c30af970, 115] (not blocked)
s rosegardenseque: 8926 [c30af320,  10] (not blocked)

---------------------------
| showing all locks held: |
---------------------------

#001:             [c062af2c] {&hwif->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x9d/0x180

#002:             [c062ab50] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#003:             [c062ad24] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#004:             [c062b574] {&hwif->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x9d/0x180

#005:             [c062b198] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#006:             [c062b36c] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#007:             [c062bbbc] {&hwif->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x9d/0x180

#008:             [c062b7e0] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#009:             [c062b9b4] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#010:             [c062c204] {&hwif->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x9d/0x180

#011:             [c062be28] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#012:             [c062bffc] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#013:             [c062c84c] {&hwif->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x9d/0x180

#014:             [c062c470] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#015:             [c062c644] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#016:             [c062ce94] {&hwif->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x9d/0x180

#017:             [c062cab8] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#018:             [c062cc8c] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#019:             [c062d4dc] {&hwif->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x9d/0x180

#020:             [c062d100] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#021:             [c062d2d4] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#022:             [c062db24] {&hwif->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x9d/0x180

#023:             [c062d748] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#024:             [c062d91c] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#025:             [c062e16c] {&hwif->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x9d/0x180

#026:             [c062dd90] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#027:             [c062df64] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#028:             [c062e7b4] {&hwif->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x9d/0x180

#029:             [c062e3d8] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#030:             [c062e5ac] {&drive->gendev_rel_sem}
.. held by:              init:    1 [c1467970, 116]
... acquired at:  init_hwif_data+0x16f/0x180

#031:             [ded6fcf0] {&tty->atomic_read}
.. held by:            agetty: 8503 [ddb8e680, 116]
... acquired at:  read_chan+0x477/0x7c0

#032:             [dedb9cf0] {&tty->atomic_read}
.. held by:            agetty: 8505 [deefa680, 116]
... acquired at:  read_chan+0x477/0x7c0

#033:             [dd710cf0] {&tty->atomic_read}
.. held by:            agetty: 8506 [dcb31320, 116]
... acquired at:  read_chan+0x477/0x7c0

#034:             [dca2acf0] {&tty->atomic_read}
.. held by:            agetty: 8507 [ddbbccd0, 116]
... acquired at:  read_chan+0x477/0x7c0

#035:             [dd3bfcf0] {&tty->atomic_read}
.. held by:            agetty: 8504 [ddbbd970, 116]
... acquired at:  read_chan+0x477/0x7c0

#036:             [c1773cf0] {&tty->atomic_read}
.. held by:              bash: 8588 [de855970, 117]
... acquired at:  read_chan+0x477/0x7c0

#037:             [d35decf0] {&tty->atomic_read}
.. held by:              bash: 8868 [d3160030, 116]
... acquired at:  read_chan+0x477/0x7c0

#038:             [d30c4cf0] {&tty->atomic_read}
.. held by:              bash: 8860 [d3160680, 116]
... acquired at:  read_chan+0x477/0x7c0

#039:             [d306fcf0] {&tty->atomic_read}
.. held by:              bash: 8852 [d3161320, 116]
... acquired at:  read_chan+0x477/0x7c0

#040:             [d3ba3cf0] {&tty->atomic_read}
.. held by:              bash: 8844 [d3160cd0, 116]
... acquired at:  read_chan+0x477/0x7c0

#041:             [c3f12418] {&q->lock}
.. held by:                 X: 8656 [deefacd0, 116]
... acquired at:  __wake_up+0x51/0x60

#042:             [c3f135d8] {&sk->sk_callback_lock}
.. held by:        rosegarden: 8923 [c5768030, 116]
... acquired at:  sock_def_readable+0x25/0xb0

#043:             [d125631c] {&q->lock}
.. held by:            qsynth: 8889 [c8095320, 116]
... acquired at:  __wake_up+0x51/0x60

#044:             [c04d63e0] {rtc_task_lock}
.. held by:             IRQ 8:  305 [df45c030,  52]
... acquired at:  rtc_interrupt+0x137/0x230

#045:             [df4f16f8] {&timer->lock}
.. held by:             IRQ 8:  305 [df45c030,  52]
... acquired at:  _snd_timer_stop+0x8f/0x180
=============================================

[ turning off deadlock detection. Please report this trace. ]


Regards,
Magnus Määttä

-- 
Pushing 40 is exercise enough.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 23:21                                                                                 ` Fernando Lopez-Lezcano
  2004-12-15  0:43                                                                                   ` Florian Schmidt
  2004-12-15  1:09                                                                                   ` Lee Revell
@ 2004-12-17  0:45                                                                                   ` Fernando Lopez-Lezcano
  2 siblings, 0 replies; 951+ messages in thread
From: Fernando Lopez-Lezcano @ 2004-12-17  0:45 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Steven Rostedt, Fernando Pablo Lopez-Lezcano

On Tue, 2004-12-14 at 15:21, Fernando Lopez-Lezcano wrote:
> On Tue, 2004-12-14 at 05:28, Ingo Molnar wrote:
> > i have released the -V0.7.33-0 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> > 
> >   http://redhat.com/~mingo/realtime-preempt/
> > 
> > this is mainly a port from -rc2-mm3 to -rc3-mm1. Changes:
> > 
> > - due to 2.6.10 release work the -mm kernel now is in fixes-mostly mode,
> >   but there's one interesting new feature: -rc3-mm1 introduced the
> >   ->unlocked_ioctl method which is now an official way to do BKL-less
> >   ioctls. I changed the ALSA ->ioctl_bkl changes in -RT to use this
> >   facility. The ALSA/sound guys might be interested in these bits. Thus
> >   another chunk of -RT could go upstream.
> > 
> > - IO-APIC/MSI fix from Steven Rostedt.
> > 
> > - fixed a tracer bug which would produce a kernel warning and an empty
> >   /proc/latency_trace if the trace buffer overflows.
> 
> I don't know which change did it, but I have network connectivity in my
> athlon64 test box with 0.7.33-0! Woohoo! [*]

But I'm still having problems with a dual athlon mp machine while trying
to boot 0.7.33-04 (same as before - this has not booted for quite a
while with the realtime patches). This is what I see:

pnp: 00:02: ioport range 0xe400-0xe4fe could not be reserved
BUG: scheduling while atomic: swapper/0x10000000/1
caller is preempt_schedule_irq+0x34/0x50
 [<c021053c3>] dump_stack+0x23/-x30 (20)
 [<c037438c>] __schedule+0xd5c/0xdb0 (124)
 [<c037432b>] preempt_schedul_irq+0x34/0x50 (12)
 [<c010432b>] need_resched+0x20/0x29 (-7416)
---------------------------
| preempt count: 10000001 ]
| 1-level deep critical section nesting:
---------------------------------------
.. [<c01472ed>] .... print_traces+0x1d/0x60
.....[<c01053c3>] .. ( <= dump_stack+0x23/0x30)

BUG at kernel/latency.c:1292!
--------------------[ cut here ]---------------------
kernel BUG at kernel/latency.c:1292!
invalid operand: 0000 [#1]
PREEMPT_SMP

=================
Booting with:
hardirq_preempt=0
softirq_preempt=0

ide1 at 0x170-0x177,0x376 on irq 15
BUG: scheduling while atomic: swapper/0x10000000/1
caller is preempt_schedule_irq+0x34/0x50
 [<>] dump_stack=0x23/0x30 (20)
 [<>] __schedule+0x5dc/0xdb0 (124)
 [<>] preempt_sched_irq+0x34/0x50 (12)
 [<>] need_resched+0x20/0x29 (-7376)
---------------------------
| preempt count: 10000001 ]
| 1-level deep critical section nesting:
---------------------------------------
.. [<c01472ed>] .... print_traces+0x1d/0x60
.....[<c01053c3>] .. ( <= dump_stack+0x23/0x30)

BUG at kernel/latency.c:1292!
--------------------[ cut here ]---------------------
kernel BUG at kernel/latency.c:1292!
invalid operand: 0000 [#1]
PREEMPT_SMP

=============
Booting with:
acpi=off

usbcore: registered new driver hub
BUG scheduling while atomic: swapper......
....
kernel BUG at kernel/latency.c:1292!
invalid operand: 0000 [#1]
PREEMPT_SMP

========
hardirq_preempt=0
softirq_preempt=0
acpi=off

usbcore: registered new driver hub
BUG scheduling while atomic: swapper......
....
kernel BUG at kernel/latency.c:1292!
invalid operand: 0000 [#1]
PREEMPT_SMP

=============
Booting with:
hardirq_preempt=0
softirq_preempt=0
kernel_preempt=0
acpi=off

Same........
Suggestions?
-- Fernando



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0
  2004-12-14 13:28                                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0 Ingo Molnar
                                                                                                   ` (3 preceding siblings ...)
  2004-12-15 20:52                                                                                 ` Magnus Määttä
@ 2005-01-04  6:40                                                                                 ` Bill Huey
  2005-01-04  9:45                                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00 Ingo Molnar
  4 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2005-01-04  6:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt

On Tue, Dec 14, 2004 at 02:28:34PM +0100, Ingo Molnar wrote:
> to create a -V0.7.33-0 tree from scratch, the patching order is:
> 
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2

>   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc3.bz2
>   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc3/2.6.10-rc3-mm1/2.6.10-rc3-mm1.bz2

>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc3-mm1-V0.7.33-0

Forward port of this patch to 2.6.10-mm1 here:
	http://people.lynuxworks.com/~bhuey/realtime/Ingo_forward_port-mm1-V0.7.33-04

Obviously, you'll need to patch a plain 2.6.10 with -mm1 from Andrew Morton,
but folks should be able to do this by now. ;)

You'll have to apply Ingo's patch so that it gets rejects and then apply
this patch on top of it so that it resolves those issues. It's a bit
sloppy, but this'll at least be somewhat workable until Ingo comes back
and pounds us with patches. :)

bill



^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00
  2005-01-04  6:40                                                                                 ` Bill Huey
@ 2005-01-04  9:45                                                                                   ` Ingo Molnar
  2005-01-04 10:48                                                                                     ` Bill Huey
                                                                                                       ` (4 more replies)
  0 siblings, 5 replies; 951+ messages in thread
From: Ingo Molnar @ 2005-01-04  9:45 UTC (permalink / raw)
  To: Bill Huey
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, Steven Rostedt


* Bill Huey <bhuey@lnxw.com> wrote:

> You'll have to apply Ingo's patch so that it gets rejects and then
> apply this patch on top of it so that it resolves those issues. It's a
> bit sloppy, but this'll at least be somewhat workable until Ingo comes
> back and pounds us with patches. :)

i've uploaded my port:

    http://redhat.com/~mingo/realtime-preempt/

this is mainly a straight port from 2.6.10-rc3-mm1 to 2.6.10-mm1, plus i
picked up a post-2.6.10-mm1 audio-driver buildsystem fix-patch. Please
(re-)report any new or old regressions.

to create a -V0.7.34-00 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
  http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10/2.6.10-mm1/2.6.10-mm1.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-mm1-V0.7.34-00

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00
  2005-01-04  9:45                                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00 Ingo Molnar
@ 2005-01-04 10:48                                                                                     ` Bill Huey
  2005-01-04 10:52                                                                                       ` Ingo Molnar
  2005-01-04 10:55                                                                                     ` Felipe Alfaro Solana
                                                                                                       ` (3 subsequent siblings)
  4 siblings, 1 reply; 951+ messages in thread
From: Bill Huey @ 2005-01-04 10:48 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt

On Tue, Jan 04, 2005 at 10:45:18AM +0100, Ingo Molnar wrote:
> this is mainly a straight port from 2.6.10-rc3-mm1 to 2.6.10-mm1, plus i
> picked up a post-2.6.10-mm1 audio-driver buildsystem fix-patch. Please
> (re-)report any new or old regressions.

Build failure.

  LD      arch/i386/kernel/cpu/mcheck/built-in.o
  kernel/time.c: In function `sys_gettimeofday':
  kernel/time.c:164: error: parse error before ')' token
  distcc[2235] ERROR: compile kernel/time.c on localhost failed
  make[1]: *** [kernel/time.o] Error 1
  make[1]: *** Waiting for unfinished jobs....
    CC      mm/truncate.o

bill


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00
  2005-01-04 10:48                                                                                     ` Bill Huey
@ 2005-01-04 10:52                                                                                       ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2005-01-04 10:52 UTC (permalink / raw)
  To: Bill Huey
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, Steven Rostedt


* Bill Huey <bhuey@lnxw.com> wrote:

> On Tue, Jan 04, 2005 at 10:45:18AM +0100, Ingo Molnar wrote:
> > this is mainly a straight port from 2.6.10-rc3-mm1 to 2.6.10-mm1, plus i
> > picked up a post-2.6.10-mm1 audio-driver buildsystem fix-patch. Please
> > (re-)report any new or old regressions.
> 
> Build failure.

does -01 work better? There was some leftover debugging stuff that got
generated into the patch by mistake.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00
  2005-01-04  9:45                                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00 Ingo Molnar
  2005-01-04 10:48                                                                                     ` Bill Huey
@ 2005-01-04 10:55                                                                                     ` Felipe Alfaro Solana
  2005-01-06 18:45                                                                                     ` Florian Schmidt
                                                                                                       ` (2 subsequent siblings)
  4 siblings, 0 replies; 951+ messages in thread
From: Felipe Alfaro Solana @ 2005-01-04 10:55 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, K.R. Foley, Rui Nuno Capela, Mark_H_Johnson,
	Adam Heath, Steven Rostedt, linux-kernel, Florian Schmidt,
	Fernando Pablo Lopez-Lezcano, Bill Huey, Lee Revell

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

On 4 Jan 2005, at 10:45, Ingo Molnar wrote:

>
> * Bill Huey <bhuey@lnxw.com> wrote:
>
>> You'll have to apply Ingo's patch so that it gets rejects and then
>> apply this patch on top of it so that it resolves those issues. It's a
>> bit sloppy, but this'll at least be somewhat workable until Ingo comes
>> back and pounds us with patches. :)
>
> i've uploaded my port:
>
>     http://redhat.com/~mingo/realtime-preempt/
>
> this is mainly a straight port from 2.6.10-rc3-mm1 to 2.6.10-mm1, plus  
> i
> picked up a post-2.6.10-mm1 audio-driver buildsystem fix-patch. Please
> (re-)report any new or old regressions.
>
> to create a -V0.7.34-00 tree from scratch, the patching order is:
>
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
>    
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10/ 
> 2.6.10-mm1/2.6.10-mm1.bz2
>    
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-mm1- 
> V0.7.34-00
>

   AS [M]  arch/i386/crypto/aes-i586-asm.o
   CC [M]  arch/i386/crypto/aes.o
   LD [M]  arch/i386/crypto/aes-i586.o
   CC      kernel/sched.o
   CC      kernel/fork.o
   CC      kernel/exec_domain.o
   CC      kernel/panic.o
   CC      kernel/printk.o
   CC      kernel/profile.o
   CC      kernel/exit.o
   CC      kernel/itimer.o
   CC      kernel/time.o
kernel/time.c: In function `sys_gettimeofday':
kernel/time.c:164: error: syntax error before ')' token
make[3]: *** [kernel/time.o] Error 1
make[2]: *** [kernel] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.70899 (%build)


[-- Attachment #2: fix.patch --]
[-- Type: application/octet-stream, Size: 483 bytes --]

--- linux-2.6.10-mm1-V0.7.34-00/kernel/time.c.old	2005-01-04 11:46:32.000000000 +0100
+++ linux-2.6.10-mm1-V0.7.34-00/kernel/time.c	2005-01-04 11:50:21.000000000 +0100
@@ -161,7 +161,7 @@
 " sti; cli; mov %ax,%ss; mov %ss,%ax; mov %ax,%ss; "
 " cli; mov %ax,%ss; "
 " cli; mov %ax,%ss; cli; "
-" mov %ax,%ss; mov %ax,%ss; sti; sti; sti; sti");
+" mov %ax,%ss; mov %ax,%ss; sti; sti; sti; sti";
 #ifdef CONFIG_LATENCY_TRACE
 	if (!tv && ((long)tz == 1))
 		return user_trace_start();

[-- Attachment #3: Type: text/plain, Size: 1 bytes --]



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00
  2005-01-04  9:45                                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00 Ingo Molnar
  2005-01-04 10:48                                                                                     ` Bill Huey
  2005-01-04 10:55                                                                                     ` Felipe Alfaro Solana
@ 2005-01-06 18:45                                                                                     ` Florian Schmidt
  2005-01-07 19:26                                                                                     ` Tom Rini
  2005-01-15 13:34                                                                                     ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00 Ingo Molnar
  4 siblings, 0 replies; 951+ messages in thread
From: Florian Schmidt @ 2005-01-06 18:45 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, Steven Rostedt

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

On Tue, 4 Jan 2005 10:45:18 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Bill Huey <bhuey@lnxw.com> wrote:
> 
> > You'll have to apply Ingo's patch so that it gets rejects and then
> > apply this patch on top of it so that it resolves those issues. It's a
> > bit sloppy, but this'll at least be somewhat workable until Ingo comes
> > back and pounds us with patches. :)
> 
> i've uploaded my port:
> 
>     http://redhat.com/~mingo/realtime-preempt/
> 
> this is mainly a straight port from 2.6.10-rc3-mm1 to 2.6.10-mm1, plus i
> picked up a post-2.6.10-mm1 audio-driver buildsystem fix-patch. Please
> (re-)report any new or old regressions.
> 
> to create a -V0.7.34-00 tree from scratch, the patching order is:
> 
>   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
>   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10/2.6.10-mm1/2.6.10-mm1.bz2
>   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-mm1-V0.7.34-00

Hi,

something is wrong with 34-01 and ALSA:

make modules_install gives me:

if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.6.10-mm1-V0.7.34-01; fi
WARNING: /lib/modules/2.6.10-mm1-V0.7.34-01/kernel/sound/pci/ac97/snd-ac97-codec.ko needs unknown symbol snd_ac97_restore_status
WARNING: /lib/modules/2.6.10-mm1-V0.7.34-01/kernel/sound/pci/ac97/snd-ac97-codec.ko needs unknown symbol snd_ac97_restore_iec958

and consequently after booting into the kernel modprobe'ing the alsa
modules fails:

~/tmp/src/linux-2.6.10-realtime-preempt-2.6.10-mm1-V0.7.34-01$ sudo modprobe snd_cs46xx
WARNING: Error inserting snd_ac97_codec (/lib/modules/2.6.10-mm1-V0.7.34-01/kernel/sound/pci/ac97/snd-ac97-codec.ko): Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting snd_cs46xx (/lib/modules/2.6.10-mm1-V0.7.34-01/kernel/sound/pci/cs46xx/snd-cs46xx.ko): Unknown symbol in module, or unknown parameter (see dmesg)

from dmesg:

snd_ac97_codec: Unknown symbol snd_ac97_restore_status
snd_ac97_codec: Unknown symbol snd_ac97_restore_iec958
snd_cs46xx: Unknown symbol snd_ac97_write_cache
snd_cs46xx: Unknown symbol snd_ac97_mixer
snd_cs46xx: Unknown symbol snd_ac97_bus
snd_cs46xx: Unknown symbol snd_ac97_write
snd_cs46xx: Unknown symbol snd_ac97_read

.config attached

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/

[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 26763 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-mm1-V0.7.34-01
# Tue Jan  4 17:14:42 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_HOTPLUG is not set
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
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

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# 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 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# 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_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
# CONFIG_SMP 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_X86_UP_APIC is not set
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_KERN_PHYS_OFFSET=1
# CONFIG_KEXEC is not set

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set
CONFIG_ACPI_BLACKLIST_YEAR=0

#
# 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_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# 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_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y

#
# 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=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_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 is not set
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 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=y
# 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_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# 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

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=m
# 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_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_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_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# 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

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
# CONFIG_CLS_U32_MARK is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_KGDBOE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_ETHERTAP is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 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_B44 is not set
# CONFIG_FORCEDETH 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 is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE 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_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE 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=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW 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_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_RTC_HISTOGRAM is not set
# CONFIG_BLOCKER 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=m
# 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 is not set
# CONFIG_AGP_INTEL_MCH is not set
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set
# CONFIG_I2C_ALGO_SGI is not set

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
# CONFIG_I2C_AMD756_S4882 is not set
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_STUB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
# CONFIG_SENSORS_ADM1026 is not set
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
# CONFIG_SENSORS_LM63 is not set
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
# CONFIG_SENSORS_LM87 is not set
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_MEMORY is not set
# CONFIG_SND_DEBUG_DETECT is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_DUMMY=m
# 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

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_ICE1712=m
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
# CONFIG_USB is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY 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_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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=m
CONFIG_RXRPC=m

#
# 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=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 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=y
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_WAKEUP_TIMING is not set
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
# CONFIG_RT_DEADLOCK_DETECT is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_USE_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
# CONFIG_KGDB is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_SECLVL is not set
CONFIG_SECURITY_REALTIME=m
# CONFIG_SECURITY_SELINUX is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00
  2005-01-04  9:45                                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00 Ingo Molnar
                                                                                                       ` (2 preceding siblings ...)
  2005-01-06 18:45                                                                                     ` Florian Schmidt
@ 2005-01-07 19:26                                                                                     ` Tom Rini
  2005-01-07 19:36                                                                                       ` Lee Revell
  2005-01-26  8:09                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04 Ingo Molnar
  2005-01-15 13:34                                                                                     ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00 Ingo Molnar
  4 siblings, 2 replies; 951+ messages in thread
From: Tom Rini @ 2005-01-07 19:26 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Bill Huey, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt

On Tue, Jan 04, 2005 at 10:45:18AM +0100, Ingo Molnar wrote:
> 
> * Bill Huey <bhuey@lnxw.com> wrote:
> 
> > You'll have to apply Ingo's patch so that it gets rejects and then
> > apply this patch on top of it so that it resolves those issues. It's a
> > bit sloppy, but this'll at least be somewhat workable until Ingo comes
> > back and pounds us with patches. :)
> 
> i've uploaded my port:
> 
>     http://redhat.com/~mingo/realtime-preempt/
> 
> this is mainly a straight port from 2.6.10-rc3-mm1 to 2.6.10-mm1, plus i
> picked up a post-2.6.10-mm1 audio-driver buildsystem fix-patch. Please
> (re-)report any new or old regressions.

Here's a handful of little things to fix issues in the patch for when
you try and use the patchset on an architecture that doesn't (yet) work.

- cycles_t is defined in <asm/timex.h>, but that wasn't part of
  <linux/irq.h> previously (breaks ppc32, I _think_).
- debug_direct_keyboard & such only exist on GENERIC_HARDIRQ arches (and
  I would guess make sense on ones you have a console & !USB keyboard
  on).
- The stubs for init_hardirqs / early_init_hardirqs were in a
  conflicting state (as seen on ppc32, which is GENERIC_HARDIRQ, but not
  yet supported).  I think this gets them down to what was intended.

Signed-off-by: Tom Rini <trini@kernel.crashing.org>

--- linux-2.6.10.orig/include/linux/irq.h
+++ linux-2.6.10/include/linux/irq.h
@@ -21,6 +21,7 @@
 
 #include <asm/irq.h>
 #include <asm/ptrace.h>
+#include <asm/timex.h>
 
 /*
  * IRQ line status.
@@ -100,11 +101,14 @@ extern void report_bad_irq(unsigned int 
 extern int can_request_irq(unsigned int irq, unsigned long irqflags);
 
 extern void early_init_hardirqs(void);
-extern void init_hardirqs(void);
 extern void init_irq_proc(void);
 extern cycles_t irq_timestamp(unsigned int irq);
 #else
 static inline void early_init_hardirqs(void) { }
+#endif
+#if defined(CONFIG_GENERIC_HARDIRQS) && defined(CONFIG_PREEMPT_HARDIRQS)
+extern void init_hardirqs(void);
+#else
 static inline void init_hardirqs(void) { }
 #endif
 
--- linux-2.6.10.orig/include/linux/sched.h
+++ linux-2.6.10/include/linux/sched.h
@@ -47,7 +47,9 @@ extern void direct_timer_interrupt(struc
 extern struct semaphore kernel_sem;
 #endif
 
+#ifdef CONFIG_GENERIC_HARDIRQS
 extern int debug_direct_keyboard;
+#endif
 
 #ifdef CONFIG_RT_DEADLOCK_DETECT
   extern void deadlock_trace_off(void);
--- linux-2.6.10.orig/kernel/irq/manage.c
+++ linux-2.6.10/kernel/irq/manage.c
@@ -527,10 +527,6 @@ void __init init_hardirqs(void)
 
 #else
 
-void __init init_hardirqs(void)
-{
-}
-
 static int start_irq_thread(int irq, struct irq_desc *desc)
 {
 	return 0;
@@ -545,5 +541,3 @@ void __init early_init_hardirqs(void)
 	for (i = 0; i < NR_IRQS; i++)
 		init_waitqueue_head(&irq_desc[i].wait_for_handler);
 }
-
-
--- linux-2.6.10.orig/kernel/sched.c
+++ linux-2.6.10/kernel/sched.c
@@ -5409,8 +5409,10 @@ void __might_sleep(char *file, int line)
 
 	if ((in_atomic() || irqs_disabled()) &&
 	    system_state == SYSTEM_RUNNING) {
+#ifdef CONFIG_GENERIC_HARDIRQS
 		if (debug_direct_keyboard && hardirq_count())
 			return;
+#endif
 		if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy)
 			return;
 		prev_jiffy = jiffies;
--- linux-2.6.10.orig/kernel/sysctl.c
+++ linux-2.6.10/kernel/sysctl.c
@@ -391,6 +391,7 @@ static ctl_table kern_table[] = {
 		.proc_handler	= &proc_dointvec,
 	},
 #endif
+#ifdef CONFIG_GENERIC_HARDIRQS
 	{
 		.ctl_name	= KERN_PANIC,
 		.procname	= "debug_direct_keyboard",
@@ -399,6 +400,7 @@ static ctl_table kern_table[] = {
 		.mode		= 0644,
 		.proc_handler	= &proc_dointvec,
 	},
+#endif
 	{
 		.ctl_name	= KERN_CORE_USES_PID,
 		.procname	= "core_uses_pid",
--- linux-2.6.10.orig/include/linux/rt_lock.h
+++ linux-2.6.10/include/linux/rt_lock.h
@@ -3,7 +3,6 @@
 
 #include <linux/config.h>
 #include <linux/list.h>
-#include <asm/atomic.h>
 
 /*
  * These are the basic SMP spinlocks, allowing only a single CPU anywhere.
@@ -26,6 +25,8 @@ typedef struct {
 # define RAW_SPIN_LOCK_UNLOCKED (raw_spinlock_t) __RAW_SPIN_LOCK_UNLOCKED
 #endif
 
+#include <asm/atomic.h>
+
 /*
  * Read-write spinlocks, allowing multiple readers
  * but only one writer.
--- linux-2.6.10.orig/include/linux/rt_lock.h
+++ linux-2.6.10/include/linux/rt_lock.h
@@ -25,8 +25,6 @@ typedef struct {
 # define RAW_SPIN_LOCK_UNLOCKED (raw_spinlock_t) __RAW_SPIN_LOCK_UNLOCKED
 #endif
 
-#include <asm/atomic.h>
-
 /*
  * Read-write spinlocks, allowing multiple readers
  * but only one writer.
@@ -173,6 +171,7 @@ typedef struct {
 
 
 #ifdef CONFIG_PREEMPT_RT
+#include <asm/atomic.h>
 
 /*
  * semaphores - an RT-mutex plus the semaphore count:

-- 
Tom Rini
http://gate.crashing.org/~trini/

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00
  2005-01-07 19:26                                                                                     ` Tom Rini
@ 2005-01-07 19:36                                                                                       ` Lee Revell
  2005-01-26  8:09                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04 Ingo Molnar
  1 sibling, 0 replies; 951+ messages in thread
From: Lee Revell @ 2005-01-07 19:36 UTC (permalink / raw)
  To: Tom Rini
  Cc: Ingo Molnar, Bill Huey, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt

On Fri, 2005-01-07 at 12:26 -0700, Tom Rini wrote:
> Here's a handful of little things to fix issues in the patch for when
> you try and use the patchset on an architecture that doesn't (yet) work.

Speaking of which, I guess no one ever stepped up & fixed the patch for
x86_64?  AFAICT it should not be too hard to get PREEMPT_DESKTOP
working, as the previous VP patch sets worked, then the timer interrupt
threading changes broke it.  But you can't thread the timer irq with
PREEMPT_DESKTOP anyway.

Unfortunately I can only offer moral support as I don't have the
hardware...

Lee 


^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00
  2005-01-04  9:45                                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00 Ingo Molnar
                                                                                                       ` (3 preceding siblings ...)
  2005-01-07 19:26                                                                                     ` Tom Rini
@ 2005-01-15 13:34                                                                                     ` Ingo Molnar
  2005-01-15 15:16                                                                                       ` K.R. Foley
                                                                                                         ` (3 more replies)
  4 siblings, 4 replies; 951+ messages in thread
From: Ingo Molnar @ 2005-01-15 13:34 UTC (permalink / raw)
  To: linux-kernel
  Cc: Lee Revell, Rui Nuno Capela, Mark_H_Johnson, K.R. Foley,
	Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, Steven Rostedt, Bill Huey


i have released the -V0.7.35-00 Real-Time Preemption patch, which can be
downloaded from the usual place:

  http://redhat.com/~mingo/realtime-preempt/

The two dozen split out latency patches (including PREEMPT_BKL) that
were in -mm are in BK now, so i've rebased the -RT patchset to
2.6.11-rc1. It would be nice to check for regressions (or the lack of
them), to make sure everything latency-related has been properly merged
upstream from -mm. (so that a new splitup cycle can start.)

to create a -V0.7.34-00 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.11-rc1.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.11-rc1-V0.7.35-00

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00
  2005-01-15 13:34                                                                                     ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00 Ingo Molnar
@ 2005-01-15 15:16                                                                                       ` K.R. Foley
  2005-01-15 19:29                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-01 Gene Heskett
                                                                                                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2005-01-15 15:16 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, Steven Rostedt, Bill Huey

Ingo Molnar wrote:
> i have released the -V0.7.35-00 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> The two dozen split out latency patches (including PREEMPT_BKL) that
> were in -mm are in BK now, so i've rebased the -RT patchset to
> 2.6.11-rc1. It would be nice to check for regressions (or the lack of
> them), to make sure everything latency-related has been properly merged
> upstream from -mm. (so that a new splitup cycle can start.)
> 

I've not done much testing with it yet but I do have it built and 
running on my slower SMP system. Working on my UP sytem now.

kr

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-01
  2005-01-15 13:34                                                                                     ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00 Ingo Molnar
  2005-01-15 15:16                                                                                       ` K.R. Foley
@ 2005-01-15 19:29                                                                                       ` Gene Heskett
  2005-01-21 20:34                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00 K.R. Foley
  2005-01-22 12:29                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00 Ingo Molnar
  3 siblings, 0 replies; 951+ messages in thread
From: Gene Heskett @ 2005-01-15 19:29 UTC (permalink / raw)
  To: linux-kernel
  Cc: Ingo Molnar, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, Steven Rostedt, Bill Huey

On Saturday 15 January 2005 08:34, Ingo Molnar wrote:
>i have released the -V0.7.35-00 Real-Time Preemption patch, which
> can be downloaded from the usual place:
>
>  http://redhat.com/~mingo/realtime-preempt/
>
By the time I got there is was 35-01 :-)

I have 1 squawk and one question.

The squawk is the extra "-RT" in the Makefiles Extra-Version, I made 
it 3 times and failed to boot to it with my script before that light 
came on.

And, what happened to drivers/ieee1394/amdtp?  Its not even in the 
xconfig choices now.  And I use it with my Sony Digital8 camera.

Also, and this is a more general squawk, I have to unload all those 
ieee1394 stuffs, turn on the camera, and then reload it all before 
the camera is recognized and usable.  Ditto if I have it working, 
then turn the camera off, before I can access the camera again I have 
to  rmmod all that stuff and reload it again. This is probably 
something that can be done with hotplug, but the last time I played 
with that it was lockup the whole machine disaster.

This was true with 2.6.11-rc1, but I haven't checked that stuff yet 
after getting this to boot just now.

>The two dozen split out latency patches (including PREEMPT_BKL) that
>were in -mm are in BK now, so i've rebased the -RT patchset to
>2.6.11-rc1. It would be nice to check for regressions (or the lack
> of them), to make sure everything latency-related has been properly
> merged upstream from -mm. (so that a new splitup cycle can start.)
>
>to create a -V0.7.34-00 tree from scratch, the patching order is:
>
>  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
> 
> http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.11-rc1.bz
>2
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.11-r
>c1-V0.7.35-00
>
> Ingo
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.32% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00
  2005-01-15 13:34                                                                                     ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00 Ingo Molnar
  2005-01-15 15:16                                                                                       ` K.R. Foley
  2005-01-15 19:29                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-01 Gene Heskett
@ 2005-01-21 20:34                                                                                       ` K.R. Foley
  2005-01-22 12:29                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00 Ingo Molnar
  3 siblings, 0 replies; 951+ messages in thread
From: K.R. Foley @ 2005-01-21 20:34 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	Adam Heath, Florian Schmidt, Thomas Gleixner,
	Fernando Pablo Lopez-Lezcano, Steven Rostedt, Bill Huey

Ingo Molnar wrote:
> i have released the -V0.7.35-00 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> The two dozen split out latency patches (including PREEMPT_BKL) that
> were in -mm are in BK now, so i've rebased the -RT patchset to
> 2.6.11-rc1. It would be nice to check for regressions (or the lack of
> them), to make sure everything latency-related has been properly merged
> upstream from -mm. (so that a new splitup cycle can start.)
> 

Ingo,

I just thought I would mention something that I have been experiencing 
with the last few versions of your patches on my workstation at the 
office. On my 2.6 dual xeon, if I have CONFIG_MICROCODE=m
I have had a heck of a time getting the -V0.7.35-02,03 kernels to boot. 
After disabling CONFIG_MICROCODE -V0.7.35-03 boots fine now. I tried 
this after finding the following in my log after a successful boot of 
-V0.7.35-01.

kr


Jan 21 11:53:50 swdev14 kernel: IA-32 Microcode Update Driver: v1.14 
<tigran@veritas.com>
Jan 21 11:53:50 swdev14 kernel: BUG: sleeping function called from 
invalid context hotplug(3795) at kernel/rt.c:1443
Jan 21 11:53:50 swdev14 kernel: BUG: scheduling while atomic: 
hotplug/0x00010000/3796
Jan 21 11:53:50 swdev14 smartd[4274]: smartd version 5.33 
[i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Jan 21 11:53:51 swdev14 kernel: in_atomic():1 [00010000], irqs_disabled():1
Jan 21 11:53:51 swdev14 smartd[4274]: Home page is 
http://smartmontools.sourceforge.net/
Jan 21 11:53:51 swdev14 kernel:  [<c010366a>] <6>microcode: CPU3 updated 
from revision 0x0 to 0x38, date = 06042003
Jan 21 11:53:51 swdev14 smartd[4274]: Opened configuration file 
/etc/smartd.conf
Jan 21 11:53:51 swdev14 kernel: dump_stack+0x23/0x25 (20)
Jan 21 11:53:51 swdev14 smartd[4274]: Configuration file 
/etc/smartd.conf parsed.
Jan 21 11:53:51 swdev14 kernel:  [<c01180fa>] 
__might_sleep+0xd8/0xf3caller is schedule+0x38/0x12f
Jan 21 11:53:51 swdev14 smartd[4274]: Device: /dev/hda, opened
Jan 21 11:53:51 swdev14 kernel:  (36)
Jan 21 11:53:51 swdev14 kernel:  [<c0133bd0>]  [<c010366a>] 
__spin_lock+0x34/0x50 (24)
Jan 21 11:53:51 swdev14 kernel:  [<c0133c66>] 
_spin_lock_irqsave+0x1d/0x21dump_stack+0x23/0x25 (20)
Jan 21 11:53:51 swdev14 kernel:  [<c02a2376>] __schedule+0xa86/0xd95 (16)
Jan 21 11:53:51 swdev14 smartd[4274]: Device: /dev/hda, found in smartd 
database.
Jan 21 11:53:51 swdev14 kernel:  [<e08c872f>]  (120)
Jan 21 11:53:51 swdev14 kernel:  [<c02a26bd>] do_update_one+0x4e/0xb7 
[microcode] (44)
Jan 21 11:53:51 swdev14 smartd[4274]: Device: /dev/hda, is SMART 
capable. Adding to "monitor" list.
Jan 21 11:53:51 swdev14 kernel:  [<c010e6d0>] 
schedule+0x38/0x12fsmp_call_function_interrupt+0x45/0x65 (24)
Jan 21 11:53:51 swdev14 smartd[4274]: Monitoring 1 ATA and 0 SCSI devices
Jan 21 11:53:51 swdev14 kernel:  [<c01031ec>] 
call_function_interrupt+0x1c/0x24 (36)
Jan 21 11:53:51 swdev14 kernel:  [<c02a38f2>] __down_mutex+0x2aa/0x35a (176)
Jan 21 11:53:51 swdev14 kernel:  [<c0167f5f>]  (88)
Jan 21 11:53:51 swdev14 kernel: sys_fstat64+0x37/0x3d [<c0133be2>]  (100)
Jan 21 11:53:51 swdev14 smartd[4276]: smartd has fork()ed into 
background mode. New PID=4276.
Jan 21 11:53:51 swdev14 smartd: smartd startup succeeded
Jan 21 11:53:51 swdev14 kernel: __spin_lock+0x46/0x50 (24)
Jan 21 11:53:51 swdev14 kernel:  [<c0133c66>] 
_spin_lock_irqsave+0x1d/0x21 [<c0102804>] syscall_call+0x7/0xb (16)
Jan 21 11:53:51 swdev14 kernel:  [<e08c872f>]  (-8124)
Jan 21 11:53:51 swdev14 kernel: do_update_one+0x4e/0xb7 [microcode] (44)
Jan 21 11:53:51 swdev14 kernel:  [<c010e6d0>] ---------------------------
Jan 21 11:53:51 swdev14 kernel: smp_call_function_interrupt+0x45/0x65 (24)
Jan 21 11:53:52 swdev14 kernel:  [<c01031ec>] 
call_function_interrupt+0x1c/0x24| preempt count: 00010001 ]
Jan 21 11:53:52 swdev14 kernel: | 1-level deep critical section nesting:
Jan 21 11:53:52 swdev14 kernel: ----------------------------------------
Jan 21 11:53:52 swdev14 kernel: .. [<c0136ebd>] ....  (124)
Jan 21 11:53:52 swdev14 kernel: print_traces+0x1b/0x52
Jan 21 11:53:52 swdev14 kernel: .....[<c010366a>] ..   ( <= 
dump_stack+0x23/0x25)
Jan 21 11:53:52 swdev14 kernel:  [<c01333f5>] up_mutex+0x89/0x100
Jan 21 11:53:52 swdev14 sshd:  succeeded
Jan 21 11:53:52 swdev14 kernel:  (40)
Jan 21 11:53:52 swdev14 kernel:  [<c014eadc>] <3>BUG: scheduling while 
atomic: hotplug/0x00010000/3795
Jan 21 11:53:52 swdev14 kernel: caller is schedule+0x38/0x12f
Jan 21 11:53:52 swdev14 kernel: do_no_page+0x197/0x3b6 (64)
Jan 21 11:53:52 swdev14 kernel:  [<c014ef6e>] 
handle_mm_fault+0x15a/0x191 [<c010366a>] dump_stack+0x23/0x25 (48)
Jan 21 11:53:52 swdev14 kernel:  [<c0112291>]  (20)
Jan 21 11:53:52 swdev14 kernel: do_page_fault+0x1fc/0x61b (216)
Jan 21 11:53:52 swdev14 kernel:  [<c0103293>] error_code+0x2b/0x30 
[<c02a2376>] __schedule+0xa86/0xd95 (-518059332)
Jan 21 11:53:52 swdev14 kernel: ---------------------------
Jan 21 11:53:52 swdev14 kernel: | preempt count: 00010001 ]
Jan 21 11:53:52 swdev14 xinetd: xinetd startup succeeded
Jan 21 11:53:52 swdev14 kernel: | 1-level deep critical section nesting:
Jan 21 11:53:52 swdev14 kernel: ----------------------------------------
Jan 21 11:53:52 swdev14 kernel: .. [<c0136ebd>] ....  (120)
Jan 21 11:53:52 swdev14 ntpdate[4310]: can't find host wizard
Jan 21 11:53:52 swdev14 kernel: print_traces+0x1b/0x52
Jan 21 11:53:52 swdev14 kernel: .....[<c010366a>] ..   ( <= 
dump_stack+0x23/0x25)
Jan 21 11:53:52 swdev14 kernel:  [<c02a26bd>] schedule+0x38/0x12f
Jan 21 11:53:52 swdev14 kernel:  (36)
Jan 21 11:53:52 swdev14 kernel:  [<c02a38f2>] __down_mutex+0x2aa/0x35a (88)
Jan 21 11:53:52 swdev14 kernel:  [<c0133be2>] __spin_lock+0x46/0x50 (24)
Jan 21 11:53:52 swdev14 kernel:  [<c0133c66>] 
_spin_lock_irqsave+0x1d/0x21 (16)
Jan 21 11:53:52 swdev14 kernel:  [<e08c872f>] do_update_one+0x4e/0xb7 
[microcode] (44)
Jan 21 11:53:52 swdev14 kernel:  [<c010e6d0>] 
smp_call_function_interrupt+0x45/0x65 (24)
Jan 21 11:53:52 swdev14 kernel:  [<c01031ec>] 
call_function_interrupt+0x1c/0x24 (176)
Jan 21 11:53:52 swdev14 kernel:  [<c0167f5f>] sys_fstat64+0x37/0x3d (100)
Jan 21 11:53:52 swdev14 kernel:  [<c0102804>] syscall_call+0x7/0xb (-8124)
Jan 21 11:53:52 swdev14 kernel: ---------------------------
Jan 21 11:53:52 swdev14 kernel: | preempt count: 00010001 ]
Jan 21 11:53:52 swdev14 kernel: | 1-level deep critical section nesting:
Jan 21 11:53:52 swdev14 kernel: ----------------------------------------
Jan 21 11:53:52 swdev14 kernel: .. [<c0136ebd>] .... print_traces+0x1b/0x52
Jan 21 11:53:52 swdev14 kernel: .....[<c010366a>] ..   ( <= 
dump_stack+0x23/0x25)


^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
  2005-01-15 13:34                                                                                     ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00 Ingo Molnar
                                                                                                         ` (2 preceding siblings ...)
  2005-01-21 20:34                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00 K.R. Foley
@ 2005-01-22 12:29                                                                                       ` Ingo Molnar
  2005-01-22 21:22                                                                                         ` Gene Heskett
  2005-02-01 20:14                                                                                         ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02 Ingo Molnar
  3 siblings, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2005-01-22 12:29 UTC (permalink / raw)
  To: linux-kernel


i have released the -V0.7.36-00 Real-Time Preemption patch, which can be
downloaded from the usual place:

  http://redhat.com/~mingo/realtime-preempt/
 
this is mainly a merge to 2.6.11-rc2.

There was alot of merging to be done due to Thomas Gleixner's
spinlock/rwlock cleanups making it into upstream and due to the upstream
spinlock changes, and there were some networking related conflicts as
well, so these areas might introduce new regressions.

the patch includes a fix that should resolve the microcode-update
related boot-time crash reported by K.R. Foley. It also includes a
verify_mm_writelocked() fix from Daniel Walker.

to create a -V0.7.36-00 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.11-rc2.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.11-rc2-V0.7.36-00

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
  2005-01-22 12:29                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00 Ingo Molnar
@ 2005-01-22 21:22                                                                                         ` Gene Heskett
  2005-01-23  9:27                                                                                           ` andyliu
  2005-01-24  8:02                                                                                           ` Ingo Molnar
  2005-02-01 20:14                                                                                         ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02 Ingo Molnar
  1 sibling, 2 replies; 951+ messages in thread
From: Gene Heskett @ 2005-01-22 21:22 UTC (permalink / raw)
  To: linux-kernel; +Cc: Ingo Molnar

On Saturday 22 January 2005 07:29, Ingo Molnar wrote:
>i have released the -V0.7.36-00 Real-Time Preemption patch, which
> can be downloaded from the usual place:
>
>  http://redhat.com/~mingo/realtime-preempt/
>
>this is mainly a merge to 2.6.11-rc2.

Humm, by the time I went after the patch it was up to -02.

And I'm getting a couple of error exits:
-------------------
net/sched/sch_generic.c: In function `qdisc_restart':
net/sched/sch_generic.c:128: error: label `requeue' used but not 
defined
  CC      drivers/pci/setup-bus.o
make[2]: *** [net/sched/sch_generic.o] Error 1
make[1]: *** [net/sched] Error 2
make[1]: *** Waiting for unfinished jobs....
-------------------

And
-------------------
  LD      net/sunrpc/built-in.o
make: *** [net] Error 2
make: *** Waiting for unfinished jobs....
-------------------
So obviously I'm not running it. :-)

One other item I don't think is related, in the last version (35-01) I 
had svn'd a new ieee1396 sub-directory from that ieee1394.org site 
into the drivers tree, and since it was less than a week old and 
worked right well, I just copied it over into the new kernel tree & 
reran the configs after renameing the existing ieee1394 to 
ieee1394-orig.

>There was alot of merging to be done due to Thomas Gleixner's
>spinlock/rwlock cleanups making it into upstream and due to the
> upstream spinlock changes, and there were some networking related
> conflicts as well, so these areas might introduce new regressions.
>
>the patch includes a fix that should resolve the microcode-update
>related boot-time crash reported by K.R. Foley. It also includes a
>verify_mm_writelocked() fix from Daniel Walker.
>
>to create a -V0.7.36-00 tree from scratch, the patching order is:
>
>  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
> 
> http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.11-rc2.bz
>2
> http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.11-r
>c2-V0.7.36-00
>
> Ingo

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.32% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
  2005-01-22 21:22                                                                                         ` Gene Heskett
@ 2005-01-23  9:27                                                                                           ` andyliu
  2005-01-23 11:31                                                                                             ` Ingo Molnar
  2005-01-24  8:02                                                                                           ` Ingo Molnar
  1 sibling, 1 reply; 951+ messages in thread
From: andyliu @ 2005-01-23  9:27 UTC (permalink / raw)
  To: mingo; +Cc: linux-kernel

hi , ingo

i am trying to understand your patch,but the patch file is so long and complex.
i am wondering is there some documents about your patch?

:)

thanks very much for your patch and your work.


On Sat, 22 Jan 2005 16:22:24 -0500, Gene Heskett
<gene.heskett@verizon.net> wrote:
> On Saturday 22 January 2005 07:29, Ingo Molnar wrote:
> >i have released the -V0.7.36-00 Real-Time Preemption patch, which
> > can be downloaded from the usual place:
> >
> >  http://redhat.com/~mingo/realtime-preempt/
> >
> >this is mainly a merge to 2.6.11-rc2.
> 
> Humm, by the time I went after the patch it was up to -02.
> 
> And I'm getting a couple of error exits:
> -------------------
> net/sched/sch_generic.c: In function `qdisc_restart':
> net/sched/sch_generic.c:128: error: label `requeue' used but not
> defined
>   CC      drivers/pci/setup-bus.o
> make[2]: *** [net/sched/sch_generic.o] Error 1
> make[1]: *** [net/sched] Error 2
> make[1]: *** Waiting for unfinished jobs....
> -------------------
> 
> And
> -------------------
>   LD      net/sunrpc/built-in.o
> make: *** [net] Error 2
> make: *** Waiting for unfinished jobs....
> -------------------
> So obviously I'm not running it. :-)
> 
> One other item I don't think is related, in the last version (35-01) I
> had svn'd a new ieee1396 sub-directory from that ieee1394.org site
> into the drivers tree, and since it was less than a week old and
> worked right well, I just copied it over into the new kernel tree &
> reran the configs after renameing the existing ieee1394 to
> ieee1394-orig.
> 
> >There was alot of merging to be done due to Thomas Gleixner's
> >spinlock/rwlock cleanups making it into upstream and due to the
> > upstream spinlock changes, and there were some networking related
> > conflicts as well, so these areas might introduce new regressions.
> >
> >the patch includes a fix that should resolve the microcode-update
> >related boot-time crash reported by K.R. Foley. It also includes a
> >verify_mm_writelocked() fix from Daniel Walker.
> >
> >to create a -V0.7.36-00 tree from scratch, the patching order is:
> >
> >  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
> >
> > http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.11-rc2.bz
> >2
> > http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.11-r
> >c2-V0.7.36-00
> >
> > Ingo
> 
> --
> Cheers, Gene
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> 99.32% setiathome rank, not too shabby for a WV hillbilly
> Yahoo.com attorneys please note, additions to this message
> by Gene Heskett are:
> Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
Yours andyliu

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
  2005-01-23  9:27                                                                                           ` andyliu
@ 2005-01-23 11:31                                                                                             ` Ingo Molnar
  2005-01-23 14:40                                                                                               ` Gene Heskett
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2005-01-23 11:31 UTC (permalink / raw)
  To: andyliu; +Cc: linux-kernel


* andyliu <liudeyan@gmail.com> wrote:

> hi , ingo
> 
> i am trying to understand your patch,but the patch file is so long and
> complex. i am wondering is there some documents about your patch?
> 
> :)

well, it mainly offers the PREEMPT_RT feature, which is a 'no
compromises' variant of kernel preemption: virtually everything
(including normal spinlocked sections) is preemptable, with the goal of
providing hard-realtime category ~10-20 usecs maximum scheduling latency
guarantees on a typical PC (or embedded platform). Those long and
complex changes are almost all needed to achieve this goal.

this tree is mainly an experiment to see what it takes to achieve that
latency goal, and to see how much of that can go upstream (without
having to decide whether upstream wants to have the PREEMPT_RT feature
or not). (A couple of dozen patches were already split out of this patch
and are in the current upstream kernel - they already made a latency
difference for the 2.6.10 kernel.)

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
  2005-01-23 11:31                                                                                             ` Ingo Molnar
@ 2005-01-23 14:40                                                                                               ` Gene Heskett
  2005-01-24  1:01                                                                                                 ` andyliu
  0 siblings, 1 reply; 951+ messages in thread
From: Gene Heskett @ 2005-01-23 14:40 UTC (permalink / raw)
  To: linux-kernel; +Cc: Ingo Molnar, andyliu

On Sunday 23 January 2005 06:31, Ingo Molnar wrote:
>* andyliu <liudeyan@gmail.com> wrote:
>> hi , ingo
>>
>> i am trying to understand your patch,but the patch file is so long
>> and complex. i am wondering is there some documents about your
>> patch?
>>
>> :)
>
>well, it mainly offers the PREEMPT_RT feature, which is a 'no
>compromises' variant of kernel preemption: virtually everything
>(including normal spinlocked sections) is preemptable, with the goal
> of providing hard-realtime category ~10-20 usecs maximum scheduling
> latency guarantees on a typical PC (or embedded platform). Those
> long and complex changes are almost all needed to achieve this
> goal.
>
>this tree is mainly an experiment to see what it takes to achieve
> that latency goal, and to see how much of that can go upstream
> (without having to decide whether upstream wants to have the
> PREEMPT_RT feature or not). (A couple of dozen patches were already
> split out of this patch and are in the current upstream kernel -
> they already made a latency difference for the 2.6.10 kernel.)
>
> Ingo

Hijacking the thread here Ingo, but did you see my build failure 
message of yesterday?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.32% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
  2005-01-23 14:40                                                                                               ` Gene Heskett
@ 2005-01-24  1:01                                                                                                 ` andyliu
  2005-01-24  2:54                                                                                                   ` Gene Heskett
  0 siblings, 1 reply; 951+ messages in thread
From: andyliu @ 2005-01-24  1:01 UTC (permalink / raw)
  To: gene.heskett; +Cc: linux-kernel, Ingo Molnar

hi Gene

i am lucky enough to have 2.6.11-rc2-V0.7.36-02 compile and run in my i386 host.
below is my config

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-rc2-RT-V0.7.36-02
# Mon Jan 24 08:45:39 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION="RT"
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_LOG_BUF_SHIFT=15
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
CONFIG_EMBEDDED=y
# CONFIG_KALLSYMS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
# CONFIG_SHMEM is not set
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_TINY_SHMEM=y

#
# 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_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_SCHED_SMT=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT_DESKTOP is not set
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K 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_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_IRQBALANCE=y
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_BLACKLIST_YEAR=0

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=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

#
# PC-card bridges
#
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_OTHER 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

#
# 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 is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_INITRAMFS_SOURCE=""
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_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_SCSI=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set

#
# 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

#
# 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 is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP 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_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

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV 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_PNP 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_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG 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_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA 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_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT 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_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_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y

#
# 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

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET 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_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 is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# 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

#
# 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 I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
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

#
# 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

#
# 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_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
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_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_INTEL_MCH=m
# 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_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB 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
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
# CONFIG_USB is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be
needed; see USB_STORAGE Help for more information
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL 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_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_DNOTIFY is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
# CONFIG_TMPFS is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS 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

#
# 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

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_DEBUG_PREEMPT is not set
CONFIG_WAKEUP_TIMING=y
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
CONFIG_LATENCY_TIMING=y
# CONFIG_LATENCY_TRACE is not set
CONFIG_RT_DEADLOCK_DETECT=y
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_USE_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
CONFIG_4KSTACKS=y
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_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y



On Sun, 23 Jan 2005 09:40:56 -0500, Gene Heskett
<gene.heskett@verizon.net> wrote:
> On Sunday 23 January 2005 06:31, Ingo Molnar wrote:
> >* andyliu <liudeyan@gmail.com> wrote:
> >> hi , ingo
> >>
> >> i am trying to understand your patch,but the patch file is so long
> >> and complex. i am wondering is there some documents about your
> >> patch?
> >>
> >> :)
> >
> >well, it mainly offers the PREEMPT_RT feature, which is a 'no
> >compromises' variant of kernel preemption: virtually everything
> >(including normal spinlocked sections) is preemptable, with the goal
> > of providing hard-realtime category ~10-20 usecs maximum scheduling
> > latency guarantees on a typical PC (or embedded platform). Those
> > long and complex changes are almost all needed to achieve this
> > goal.
> >
> >this tree is mainly an experiment to see what it takes to achieve
> > that latency goal, and to see how much of that can go upstream
> > (without having to decide whether upstream wants to have the
> > PREEMPT_RT feature or not). (A couple of dozen patches were already
> > split out of this patch and are in the current upstream kernel -
> > they already made a latency difference for the 2.6.10 kernel.)
> >
> > Ingo
> 
> Hijacking the thread here Ingo, but did you see my build failure
> message of yesterday?
> 
> --
> Cheers, Gene
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> 99.32% setiathome rank, not too shabby for a WV hillbilly
> Yahoo.com attorneys please note, additions to this message
> by Gene Heskett are:
> Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
> 


-- 
Yours andyliu

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
  2005-01-24  1:01                                                                                                 ` andyliu
@ 2005-01-24  2:54                                                                                                   ` Gene Heskett
  0 siblings, 0 replies; 951+ messages in thread
From: Gene Heskett @ 2005-01-24  2:54 UTC (permalink / raw)
  To: linux-kernel, andyliu; +Cc: Ingo Molnar

On Sunday 23 January 2005 20:01, andyliu wrote:
>hi Gene
>
Thanks, I'll give it a shot and see if it fits my hardware.

>i am lucky enough to have 2.6.11-rc2-V0.7.36-02 compile and run in
> my i386 host. below is my config
>
>#
># Automatically generated make config: don't edit
># Linux kernel version: 2.6.11-rc2-RT-V0.7.36-02
># Mon Jan 24 08:45:39 2005
>#
>CONFIG_X86=y
>CONFIG_MMU=y
>CONFIG_UID16=y
>CONFIG_GENERIC_ISA_DMA=y
>CONFIG_GENERIC_IOMAP=y
>
>#
># Code maturity level options
>#
>CONFIG_EXPERIMENTAL=y
>CONFIG_CLEAN_COMPILE=y
>CONFIG_LOCK_KERNEL=y
>
>#
># General setup
>#
>CONFIG_LOCALVERSION="RT"
>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_LOG_BUF_SHIFT=15
>CONFIG_HOTPLUG=y
>CONFIG_KOBJECT_UEVENT=y
># CONFIG_IKCONFIG is not set
>CONFIG_EMBEDDED=y
># CONFIG_KALLSYMS is not set
>CONFIG_FUTEX=y
>CONFIG_EPOLL=y
># CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
># CONFIG_SHMEM is not set
>CONFIG_CC_ALIGN_FUNCTIONS=0
>CONFIG_CC_ALIGN_LABELS=0
>CONFIG_CC_ALIGN_LOOPS=0
>CONFIG_CC_ALIGN_JUMPS=0
>CONFIG_TINY_SHMEM=y
>
>#
># 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_MCYRIXIII is not set
># CONFIG_MVIAC3_2 is not set
># CONFIG_X86_GENERIC is not set
>CONFIG_X86_CMPXCHG=y
>CONFIG_X86_XADD=y
>CONFIG_X86_L1_CACHE_SHIFT=7
>CONFIG_GENERIC_CALIBRATE_DELAY=y
>CONFIG_X86_WP_WORKS_OK=y
>CONFIG_X86_INVLPG=y
>CONFIG_X86_BSWAP=y
>CONFIG_X86_POPAD_OK=y
>CONFIG_X86_GOOD_APIC=y
>CONFIG_X86_INTEL_USERCOPY=y
>CONFIG_X86_USE_PPRO_CHECKSUM=y
># CONFIG_HPET_TIMER is not set
>CONFIG_SMP=y
>CONFIG_NR_CPUS=2
>CONFIG_SCHED_SMT=y
># CONFIG_PREEMPT_NONE is not set
># CONFIG_PREEMPT_VOLUNTARY is not set
># CONFIG_PREEMPT_DESKTOP is not set
>CONFIG_PREEMPT_RT=y
>CONFIG_PREEMPT=y
>CONFIG_PREEMPT_SOFTIRQS=y
>CONFIG_PREEMPT_HARDIRQS=y
>CONFIG_PREEMPT_BKL=y
>CONFIG_X86_LOCAL_APIC=y
>CONFIG_X86_IO_APIC=y
>CONFIG_X86_TSC=y
>CONFIG_X86_MCE=y
>CONFIG_X86_MCE_NONFATAL=y
>CONFIG_X86_MCE_P4THERMAL=y
># CONFIG_TOSHIBA is not set
># CONFIG_I8K 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_NOHIGHMEM=y
># CONFIG_HIGHMEM4G is not set
># CONFIG_HIGHMEM64G is not set
># CONFIG_MATH_EMULATION is not set
>CONFIG_MTRR=y
>CONFIG_IRQBALANCE=y
>CONFIG_HAVE_DEC_LOCK=y
># CONFIG_REGPARM is not set
>
>#
># Power management options (ACPI, APM)
>#
># CONFIG_PM is not set
>
>#
># ACPI (Advanced Configuration and Power Interface) Support
>#
># CONFIG_ACPI is not set
>CONFIG_ACPI_BOOT=y
>CONFIG_ACPI_BLACKLIST_YEAR=0
>
>#
># CPU Frequency scaling
>#
># CONFIG_CPU_FREQ is not set
>
>#
># Bus options (PCI, PCMCIA, EISA, MCA, ISA)
>#
>CONFIG_PCI=y
># CONFIG_PCI_GOBIOS is not set
># CONFIG_PCI_GOMMCONFIG is not set
># CONFIG_PCI_GODIRECT is not set
>CONFIG_PCI_GOANY=y
>CONFIG_PCI_BIOS=y
>CONFIG_PCI_DIRECT=y
># CONFIG_PCIEPORTBUS is not set
># CONFIG_PCI_MSI is not set
>CONFIG_PCI_LEGACY_PROC=y
>CONFIG_PCI_NAMES=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
>
>#
># PC-card bridges
>#
>CONFIG_PCMCIA_PROBE=y
>
>#
># PCI Hotplug Support
>#
># CONFIG_HOTPLUG_PCI is not set
>
>#
># Executable file formats
>#
>CONFIG_BINFMT_ELF=y
>CONFIG_BINFMT_AOUT=y
>CONFIG_BINFMT_MISC=y
>
>#
># Device Drivers
>#
>
>#
># Generic Driver Options
>#
>CONFIG_STANDALONE=y
>CONFIG_PREVENT_FIRMWARE_BUILD=y
>CONFIG_FW_LOADER=m
>
>#
># Memory Technology Devices (MTD)
>#
># CONFIG_MTD is not set
>
>#
># Parallel port support
>#
>CONFIG_PARPORT=y
>CONFIG_PARPORT_PC=y
>CONFIG_PARPORT_PC_CML1=y
># CONFIG_PARPORT_SERIAL is not set
># CONFIG_PARPORT_PC_FIFO is not set
># CONFIG_PARPORT_PC_SUPERIO is not set
># CONFIG_PARPORT_OTHER 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
>
>#
># 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 is not set
># CONFIG_BLK_DEV_NBD is not set
># CONFIG_BLK_DEV_SX8 is not set
># CONFIG_BLK_DEV_RAM is not set
>CONFIG_BLK_DEV_RAM_COUNT=16
>CONFIG_INITRAMFS_SOURCE=""
>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_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_SCSI=y
># CONFIG_SCSI_PROC_FS is not set
>
>#
># SCSI support type (disk, tape, CD-ROM)
>#
># CONFIG_BLK_DEV_SD is not set
># CONFIG_CHR_DEV_ST is not set
># CONFIG_CHR_DEV_OSST is not set
># CONFIG_BLK_DEV_SR is not set
># CONFIG_CHR_DEV_SG is not set
>
>#
># 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
>
>#
># 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 is not set
># CONFIG_SCSI_IN2000 is not set
># CONFIG_MEGARAID_NEWGEN is not set
># CONFIG_MEGARAID_LEGACY is not set
># CONFIG_SCSI_SATA is not set
># CONFIG_SCSI_BUSLOGIC is not set
># CONFIG_SCSI_DMX3191D is not set
># CONFIG_SCSI_DTC3280 is not set
># CONFIG_SCSI_EATA is not set
># CONFIG_SCSI_EATA_PIO is not set
># CONFIG_SCSI_FUTURE_DOMAIN is not set
># CONFIG_SCSI_GDTH is not set
># CONFIG_SCSI_GENERIC_NCR5380 is not set
># CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
># CONFIG_SCSI_IPS is not set
># CONFIG_SCSI_INITIO is not set
># CONFIG_SCSI_INIA100 is not set
># CONFIG_SCSI_PPA is not set
># CONFIG_SCSI_IMM is not set
># CONFIG_SCSI_NCR53C406A is not set
># CONFIG_SCSI_SYM53C8XX_2 is not set
># CONFIG_SCSI_IPR is not set
># CONFIG_SCSI_PAS16 is not set
># CONFIG_SCSI_PSI240I is not set
># CONFIG_SCSI_QLOGIC_FAS is not set
># CONFIG_SCSI_QLOGIC_ISP 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_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
>
>#
># IEEE 1394 (FireWire) support
>#
># CONFIG_IEEE1394 is not set
>
>#
># I2O device support
>#
># CONFIG_I2O is not set
>
>#
># Networking support
>#
>CONFIG_NET=y
>
>#
># Networking options
>#
>CONFIG_PACKET=y
># CONFIG_PACKET_MMAP is not set
># CONFIG_NETLINK_DEV 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_PNP 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_IP_TCPDIAG=y
># CONFIG_IP_TCPDIAG_IPV6 is not set
>
>#
># IP: Virtual Server Configuration
>#
># CONFIG_IP_VS is not set
># CONFIG_IPV6 is not set
>CONFIG_NETFILTER=y
># CONFIG_NETFILTER_DEBUG 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_CT_PROTO_SCTP is not set
># CONFIG_IP_NF_FTP is not set
># CONFIG_IP_NF_IRC is not set
># CONFIG_IP_NF_TFTP is not set
># CONFIG_IP_NF_AMANDA 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_COMMENT is not set
># CONFIG_IP_NF_MATCH_HASHLIMIT 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_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_RAW=m
>CONFIG_IP_NF_TARGET_NOTRACK=m
>CONFIG_IP_NF_ARPTABLES=y
>CONFIG_IP_NF_ARPFILTER=y
>CONFIG_IP_NF_ARP_MANGLE=y
>
>#
># 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
>
>#
># QoS and/or fair queueing
>#
># CONFIG_NET_SCHED is not set
># CONFIG_NET_CLS_ROUTE is not set
>
>#
># Network testing
>#
># CONFIG_NET_PKTGEN is not set
># CONFIG_NETPOLL is not set
># CONFIG_NET_POLL_CONTROLLER is not set
># CONFIG_HAMRADIO is not set
># CONFIG_IRDA is not set
># CONFIG_BT is not set
>CONFIG_NETDEVICES=y
>CONFIG_DUMMY=m
># CONFIG_BONDING is not set
># CONFIG_EQUALIZER is not set
># CONFIG_TUN is not set
># CONFIG_NET_SB1000 is not set
>
>#
># ARCnet devices
>#
># CONFIG_ARCNET 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_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 is not set
># CONFIG_8139TOO_8129 is not set
># CONFIG_8139_OLD_RX_RESET is not set
># CONFIG_SIS900 is not set
># CONFIG_EPIC100 is not set
># CONFIG_SUNDANCE is not set
># CONFIG_TLAN is not set
># CONFIG_VIA_RHINE is not set
># CONFIG_NET_POCKET is not set
>
>#
># Ethernet (1000 Mbit)
>#
># CONFIG_ACENIC is not set
># CONFIG_DL2K is not set
># CONFIG_E1000 is not set
># CONFIG_NS83820 is not set
># CONFIG_HAMACHI is not set
># CONFIG_YELLOWFIN is not set
># CONFIG_R8169 is not set
># CONFIG_SK98LIN is not set
># CONFIG_VIA_VELOCITY is not set
># CONFIG_TIGON3 is not set
>
>#
># Ethernet (10000 Mbit)
>#
># 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
>
>#
># 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 I/O drivers
>#
># CONFIG_GAMEPORT is not set
>CONFIG_SOUND_GAMEPORT=y
>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
>
>#
># 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
>
>#
># 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_NR_UARTS=4
># CONFIG_SERIAL_8250_EXTENDED is not set
>
>#
># Non-8250 serial port support
>#
>CONFIG_SERIAL_CORE=y
>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_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_INTEL_MCH=m
># 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_MWAVE is not set
># CONFIG_RAW_DRIVER is not set
># CONFIG_HANGCHECK_TIMER is not set
>
>#
># I2C support
>#
># CONFIG_I2C is not set
>
>#
># Dallas's 1-wire bus
>#
># CONFIG_W1 is not set
>
>#
># Misc devices
>#
># CONFIG_IBM_ASM is not set
>
>#
># Multimedia devices
>#
># CONFIG_VIDEO_DEV is not set
>
>#
># Digital Video Broadcasting Devices
>#
># CONFIG_DVB is not set
>
>#
># Graphics support
>#
># CONFIG_FB 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
># CONFIG_BACKLIGHT_LCD_SUPPORT is not set
>
>#
># Sound
>#
># CONFIG_SOUND is not set
>
>#
># USB support
>#
># CONFIG_USB is not set
>CONFIG_USB_ARCH_HAS_HCD=y
>CONFIG_USB_ARCH_HAS_OHCI=y
>
>#
># NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also
> be needed; see USB_STORAGE Help for more information
>#
>
>#
># USB Gadget Support
>#
># CONFIG_USB_GADGET is not set
>
>#
># MMC/SD Card support
>#
># CONFIG_MMC is not set
>
>#
># InfiniBand support
>#
># CONFIG_INFINIBAND is not set
>
>#
># File systems
>#
>CONFIG_EXT2_FS=y
># CONFIG_EXT2_FS_XATTR is not set
>CONFIG_EXT3_FS=y
>CONFIG_EXT3_FS_XATTR=y
># CONFIG_EXT3_FS_POSIX_ACL 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_XFS_FS is not set
># CONFIG_MINIX_FS is not set
># CONFIG_ROMFS_FS is not set
># CONFIG_QUOTA is not set
># CONFIG_DNOTIFY is not set
># CONFIG_AUTOFS_FS is not set
># CONFIG_AUTOFS4_FS is not set
>
>#
># CD-ROM/DVD Filesystems
>#
># CONFIG_ISO9660_FS is not set
># CONFIG_UDF_FS is not set
>
>#
># DOS/FAT/NT Filesystems
>#
># CONFIG_MSDOS_FS is not set
># CONFIG_VFAT_FS is not set
># CONFIG_NTFS_FS is not set
>
>#
># Pseudo filesystems
>#
>CONFIG_PROC_FS=y
>CONFIG_PROC_KCORE=y
>CONFIG_SYSFS=y
># CONFIG_DEVFS_FS is not set
># CONFIG_DEVPTS_FS_XATTR is not set
># CONFIG_TMPFS is not set
># CONFIG_HUGETLBFS is not set
># CONFIG_HUGETLB_PAGE is not set
>CONFIG_RAMFS=y
>
>#
># Miscellaneous filesystems
>#
># CONFIG_ADFS_FS is not set
># CONFIG_AFFS_FS is not set
># CONFIG_HFS_FS is not set
># CONFIG_HFSPLUS_FS is not set
># CONFIG_BEFS_FS is not set
># CONFIG_BFS_FS is not set
># CONFIG_EFS_FS is not set
># CONFIG_CRAMFS is not set
># CONFIG_VXFS_FS is not set
># CONFIG_HPFS_FS is not set
># CONFIG_QNX4FS_FS is not set
># CONFIG_SYSV_FS is not set
># CONFIG_UFS_FS is not set
>
>#
># Network File Systems
>#
># CONFIG_NFS_FS is not set
># CONFIG_NFSD is not set
># CONFIG_EXPORTFS 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
>
>#
># 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
>
>#
># Kernel hacking
>#
># CONFIG_DEBUG_KERNEL is not set
># CONFIG_DEBUG_PREEMPT is not set
>CONFIG_WAKEUP_TIMING=y
># CONFIG_CRITICAL_PREEMPT_TIMING is not set
># CONFIG_CRITICAL_IRQSOFF_TIMING is not set
>CONFIG_LATENCY_TIMING=y
># CONFIG_LATENCY_TRACE is not set
>CONFIG_RT_DEADLOCK_DETECT=y
># CONFIG_DEBUG_BUGVERBOSE is not set
># CONFIG_USE_FRAME_POINTER is not set
>CONFIG_EARLY_PRINTK=y
>CONFIG_4KSTACKS=y
>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_CRC32=y
>CONFIG_LIBCRC32C=m
>CONFIG_GENERIC_HARDIRQS=y
>CONFIG_GENERIC_IRQ_PROBE=y
>CONFIG_X86_SMP=y
>CONFIG_X86_HT=y
>CONFIG_X86_BIOS_REBOOT=y
>CONFIG_X86_TRAMPOLINE=y
>
>
>
>On Sun, 23 Jan 2005 09:40:56 -0500, Gene Heskett
>
><gene.heskett@verizon.net> wrote:
>> On Sunday 23 January 2005 06:31, Ingo Molnar wrote:
>> >* andyliu <liudeyan@gmail.com> wrote:
>> >> hi , ingo
>> >>
>> >> i am trying to understand your patch,but the patch file is so
>> >> long and complex. i am wondering is there some documents about
>> >> your patch?
>> >>
>> >> :)
>> >
>> >well, it mainly offers the PREEMPT_RT feature, which is a 'no
>> >compromises' variant of kernel preemption: virtually everything
>> >(including normal spinlocked sections) is preemptable, with the
>> > goal of providing hard-realtime category ~10-20 usecs maximum
>> > scheduling latency guarantees on a typical PC (or embedded
>> > platform). Those long and complex changes are almost all needed
>> > to achieve this goal.
>> >
>> >this tree is mainly an experiment to see what it takes to achieve
>> > that latency goal, and to see how much of that can go upstream
>> > (without having to decide whether upstream wants to have the
>> > PREEMPT_RT feature or not). (A couple of dozen patches were
>> > already split out of this patch and are in the current upstream
>> > kernel - they already made a latency difference for the 2.6.10
>> > kernel.)
>> >
>> > Ingo
>>
>> Hijacking the thread here Ingo, but did you see my build failure
>> message of yesterday?
>>
>> --
>> Cheers, Gene
>> "There are four boxes to be used in defense of liberty:
>>  soap, ballot, jury, and ammo. Please use in that order."
>> -Ed Howdershelt (Author)
>> 99.32% setiathome rank, not too shabby for a WV hillbilly
>> Yahoo.com attorneys please note, additions to this message
>> by Gene Heskett are:
>> Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.32% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
  2005-01-22 21:22                                                                                         ` Gene Heskett
  2005-01-23  9:27                                                                                           ` andyliu
@ 2005-01-24  8:02                                                                                           ` Ingo Molnar
  2005-01-24 10:42                                                                                             ` Gene Heskett
  2005-01-26  1:05                                                                                             ` Lee Revell
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2005-01-24  8:02 UTC (permalink / raw)
  To: Gene Heskett; +Cc: linux-kernel


* Gene Heskett <gene.heskett@verizon.net> wrote:

> On Saturday 22 January 2005 07:29, Ingo Molnar wrote:
> >i have released the -V0.7.36-00 Real-Time Preemption patch, which
> > can be downloaded from the usual place:
> >
> >  http://redhat.com/~mingo/realtime-preempt/
> >
> >this is mainly a merge to 2.6.11-rc2.
> 
> Humm, by the time I went after the patch it was up to -02.
> 
> And I'm getting a couple of error exits:
> -------------------
> net/sched/sch_generic.c: In function `qdisc_restart':
> net/sched/sch_generic.c:128: error: label `requeue' used but not 
> defined

indeed - !PREEMPT_RT compilation broke. I've uploaded -03 with the fix
(and other fixes).

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
  2005-01-24  8:02                                                                                           ` Ingo Molnar
@ 2005-01-24 10:42                                                                                             ` Gene Heskett
  2005-01-26  1:05                                                                                             ` Lee Revell
  1 sibling, 0 replies; 951+ messages in thread
From: Gene Heskett @ 2005-01-24 10:42 UTC (permalink / raw)
  To: linux-kernel; +Cc: Ingo Molnar

On Monday 24 January 2005 03:02, Ingo Molnar wrote:
>* Gene Heskett <gene.heskett@verizon.net> wrote:
>> On Saturday 22 January 2005 07:29, Ingo Molnar wrote:
>> >i have released the -V0.7.36-00 Real-Time Preemption patch, which
>> > can be downloaded from the usual place:
>> >
>> >  http://redhat.com/~mingo/realtime-preempt/
>> >
>> >this is mainly a merge to 2.6.11-rc2.
>>
>> Humm, by the time I went after the patch it was up to -02.
>>
>> And I'm getting a couple of error exits:
>> -------------------
>> net/sched/sch_generic.c: In function `qdisc_restart':
>> net/sched/sch_generic.c:128: error: label `requeue' used but not
>> defined
>
>indeed - !PREEMPT_RT compilation broke. I've uploaded -03 with the
> fix (and other fixes).
>
> Ingo

Thanks a bunch for your work, Ingo.  I'm having fun running this 
stuff, and it really does seem to help everything but 
kmail/spamassassin.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.32% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
  2005-01-24  8:02                                                                                           ` Ingo Molnar
  2005-01-24 10:42                                                                                             ` Gene Heskett
@ 2005-01-26  1:05                                                                                             ` Lee Revell
  1 sibling, 0 replies; 951+ messages in thread
From: Lee Revell @ 2005-01-26  1:05 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Gene Heskett, linux-kernel

On Mon, 2005-01-24 at 09:02 +0100, Ingo Molnar wrote:
> indeed - !PREEMPT_RT compilation broke. I've uploaded -03 with the fix
> (and other fixes).

-03 still does not compile with CONFIG_PREEMPT_DESKTOP:

rlrevell@mindpipe:~/kernel-source/linux-2.6.11-rc2$ make
  CHK     include/linux/version.h
make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
  CHK     include/linux/compile.h
  CHK     usr/initramfs_list
  CC      net/core/rtnetlink.o
net/core/rtnetlink.c: In function `rtnl_lock_interruptible':
net/core/rtnetlink.c:63: warning: implicit declaration of function `down_write_interruptible'
  LD      net/core/built-in.o
  LD      net/built-in.o
  GEN     .version
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
net/built-in.o(.text+0x10f99): In function `rtnl_lock_interruptible':
net/core/rtnetlink.c:63: undefined reference to `down_write_interruptible'
make: *** [.tmp_vmlinux1] Error 1

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04
  2005-01-07 19:26                                                                                     ` Tom Rini
  2005-01-07 19:36                                                                                       ` Lee Revell
@ 2005-01-26  8:09                                                                                       ` Ingo Molnar
  2005-02-01 20:01                                                                                         ` Lee Revell
  1 sibling, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2005-01-26  8:09 UTC (permalink / raw)
  To: Tom Rini
  Cc: Bill Huey, linux-kernel, Lee Revell, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt


* Tom Rini <trini@kernel.crashing.org> wrote:

> Here's a handful of little things to fix issues in the patch for when
> you try and use the patchset on an architecture that doesn't (yet) work.
> 
> - cycles_t is defined in <asm/timex.h>, but that wasn't part of
>   <linux/irq.h> previously (breaks ppc32, I _think_).
> - debug_direct_keyboard & such only exist on GENERIC_HARDIRQ arches (and
>   I would guess make sense on ones you have a console & !USB keyboard
>   on).
> - The stubs for init_hardirqs / early_init_hardirqs were in a
>   conflicting state (as seen on ppc32, which is GENERIC_HARDIRQ, but not
>   yet supported).  I think this gets them down to what was intended.
> 
> Signed-off-by: Tom Rini <trini@kernel.crashing.org>

thanks - i have applied all of these and have released the
-2.6.11-rc2-V0.7.36-04 patch which can be downloaded from the usual
place:

  http://redhat.com/~mingo/realtime-preempt/

The -04 patch should also fix the down_write_interruptible() related
build error reported by Lee Revell and others.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04
  2005-01-26  8:09                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04 Ingo Molnar
@ 2005-02-01 20:01                                                                                         ` Lee Revell
  2005-02-01 20:17                                                                                           ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2005-02-01 20:01 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Tom Rini, Bill Huey, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt

On Wed, 2005-01-26 at 09:09 +0100, Ingo Molnar wrote:
> thanks - i have applied all of these and have released the
> -2.6.11-rc2-V0.7.36-04 patch which can be downloaded from the usual
> place:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> The -04 patch should also fix the down_write_interruptible() related
> build error reported by Lee Revell and others.

Assuming it's still available, what is the config option to get the
"User-space atomicity debugging" feature?  This feature is extremely
useful for debugging complex JACK clients, several Linux audio
developers have asked me about it but I can't find the config option
anymore.

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
  2005-01-22 12:29                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00 Ingo Molnar
  2005-01-22 21:22                                                                                         ` Gene Heskett
@ 2005-02-01 20:14                                                                                         ` Ingo Molnar
  2005-02-03 20:53                                                                                           ` Eugeny S. Mints
  2005-02-04  1:51                                                                                           ` Steven Rostedt
  1 sibling, 2 replies; 951+ messages in thread
From: Ingo Molnar @ 2005-02-01 20:14 UTC (permalink / raw)
  To: linux-kernel; +Cc: Manish Lachwani


i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
downloaded from the usual place:

  http://redhat.com/~mingo/realtime-preempt/

the big change in the patch is increased architecture support: most
notable i've merged the MIPS patch from Manish Lachwani. Also, the x64
port should be working again. (To make architecture merges easier in the
future the timer interrupt is not threaded anymore - if this shows
latency problems then we'll try to solve it on other ways.)

to create a -V0.7.37-02 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.11-rc2.bz2
  http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.11-rc2-V0.7.37-02

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04
  2005-02-01 20:01                                                                                         ` Lee Revell
@ 2005-02-01 20:17                                                                                           ` Ingo Molnar
  2005-02-01 20:31                                                                                             ` Lee Revell
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2005-02-01 20:17 UTC (permalink / raw)
  To: Lee Revell
  Cc: Tom Rini, Bill Huey, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt


* Lee Revell <rlrevell@joe-job.com> wrote:

> Assuming it's still available, what is the config option to get the
> "User-space atomicity debugging" feature?  This feature is extremely
> useful for debugging complex JACK clients, several Linux audio
> developers have asked me about it but I can't find the config option
> anymore.

it's always-on in the -RT tree (it's a pretty low-overhead thing). I
havent changed the mechanism so the jackd hacks from a couple of weeks
ago should still work.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04
  2005-02-01 20:17                                                                                           ` Ingo Molnar
@ 2005-02-01 20:31                                                                                             ` Lee Revell
  2005-02-01 20:44                                                                                               ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2005-02-01 20:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Tom Rini, Bill Huey, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt

On Tue, 2005-02-01 at 21:17 +0100, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > Assuming it's still available, what is the config option to get the
> > "User-space atomicity debugging" feature?  This feature is extremely
> > useful for debugging complex JACK clients, several Linux audio
> > developers have asked me about it but I can't find the config option
> > anymore.
> 
> it's always-on in the -RT tree (it's a pretty low-overhead thing). I
> havent changed the mechanism so the jackd hacks from a couple of weeks
> ago should still work.
> 

OK.  So for application triggered tracing you need 
LATENCY_TRACING enabled, as described here:

http://lkml.org/lkml/2004/10/29/312

Lee


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04
  2005-02-01 20:31                                                                                             ` Lee Revell
@ 2005-02-01 20:44                                                                                               ` Ingo Molnar
  2005-02-01 23:45                                                                                                 ` Lee Revell
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2005-02-01 20:44 UTC (permalink / raw)
  To: Lee Revell
  Cc: Tom Rini, Bill Huey, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt


* Lee Revell <rlrevell@joe-job.com> wrote:

> OK.  So for application triggered tracing you need LATENCY_TRACING
> enabled, as described here:
> 
> http://lkml.org/lkml/2004/10/29/312

correct, that too should still work fine - with the small change that
there's now a separate flag to active it:

	echo 1 > /proc/sys/kernel/trace_user_triggered  # default: 0

it is an orthogonal mechanism to atomicity-debugging.

since i wrote the above mail 3 months ago, a number of improvements have
been done to the tracer. There are a handful of modifier feature-flags
to the tracer, which can be used to get additional functionality. Here's
a quick summary:

	echo 1 > /proc/sys/kernel/trace_freerunning  # default: 0

will get a 'freerunning' tracer which never stops (and overwrites the
oldest entries if the trace gets full). Especially with long latencies 
this in some cases can be more informative.

this flag:

	echo 0 > /proc/sys/kernel/mcount_enabled  # default: 1

causes the tracer to record only key kernel events (schedule/wakeup
events, etc.), not every kernel function call. This might be useful if
you want to see the bigger picture and want to validate scheduling logic
on a bigger scale, spanning a much longer timeframe.

and if you have stability problems, this flag might be handy:

	echo 1 > /proc/sys/kernel/trace_freerunning  # default: 0

it will dump the current kernel trace to the kernel console if a crash
happens - obviously only useful with a serial console or netconsole. 
It's a big dump but can make some bugs much easier to debug.

on SMP:

	echo 1 > /proc/sys/kernel/trace_all_cpus  # default: 0

this flag will cause all activity from all CPUs to be included in the
trace. This can be useful if it is suspected that a particular latency
was caused not by the CPU where the latency triggers, but by some other
CPU.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04
  2005-02-01 20:44                                                                                               ` Ingo Molnar
@ 2005-02-01 23:45                                                                                                 ` Lee Revell
  2005-02-02  7:06                                                                                                   ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Lee Revell @ 2005-02-01 23:45 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Tom Rini, Bill Huey, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt

On Tue, 2005-02-01 at 21:44 +0100, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > OK.  So for application triggered tracing you need LATENCY_TRACING
> > enabled, as described here:
> > 
> > http://lkml.org/lkml/2004/10/29/312
> 
> correct, that too should still work fine - with the small change that
> there's now a separate flag to active it:
> 
> 	echo 1 > /proc/sys/kernel/trace_user_triggered  # default: 0
> 
> it is an orthogonal mechanism to atomicity-debugging.

OK.  Rereading my old mail, it looks like there were some possibly
unresolved false positives with the userspace atomicity debugger.

Here's one I get from alsaplayer.  Would more information be required to
know if this is a false positive?

alsaplayer:5718 userspace BUG: scheduling in user-atomic context!
 [<c0102a97>] dump_stack+0x17/0x20 (20)
 [<c026268c>] schedule+0x6c/0x100 (24)
 [<c026330c>] rwsem_down_read_failed+0x9c/0x170 (48)
 [<c01277f5>] .text.lock.futex+0x7/0xb2 (44)
 [<c01276bf>] do_futex+0x4f/0x80 (28)
 [<c01277ba>] sys_futex+0xca/0xe0 (68)
 [<c0102457>] syscall_call+0x7/0xb (-4028)

(gdb) bt
#0  0x4117c4ec in __lll_mutex_unlock_wake () from /lib/tls/libpthread.so.0
#1  0x41179a69 in _L_mutex_unlock_26 () from /lib/tls/libpthread.so.0
#2  0x0824d3c0 in ?? ()
#3  0xb7ef3958 in ?? ()
#4  0x41179a60 in pthread_mutex_unlock () from /lib/tls/libpthread.so.0
#5  0x41179a60 in pthread_mutex_unlock () from /lib/tls/libpthread.so.0
#6  0x08057a30 in CorePlayer::Read32 (this=0x1, data=0xb7508008, samples=64) at CorePlayer.cpp:1076
#7  0x08057f89 in CorePlayer::streamer_func (arg=0x824d3c0, data=0x824cc80, size=128) at CorePlayer.cpp:1257
#8  0xb7ffcd52 in process (nframes=64, arg=0x824b258) at jack.cpp:350
#9  0xb7ef99f9 in jack_client_thread (arg=0x824bb48) at client.c:1264
#10 0x41177b63 in start_thread () from /lib/tls/libpthread.so.0
#11 0x410f0c4a in clone () from /lib/tls/libc.so.6

The backtrace is incomplete because I was unable to reproduce the
problem with the debug glibc.

Lee



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04
  2005-02-01 23:45                                                                                                 ` Lee Revell
@ 2005-02-02  7:06                                                                                                   ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2005-02-02  7:06 UTC (permalink / raw)
  To: Lee Revell
  Cc: Tom Rini, Bill Huey, linux-kernel, Rui Nuno Capela,
	Mark_H_Johnson, K.R. Foley, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Fernando Pablo Lopez-Lezcano, Steven Rostedt


* Lee Revell <rlrevell@joe-job.com> wrote:

> OK.  Rereading my old mail, it looks like there were some possibly
> unresolved false positives with the userspace atomicity debugger.
> 
> Here's one I get from alsaplayer.  Would more information be required
> to know if this is a false positive?

this is a false positive that only triggers if PREEMPT_RT is disabled. 
Does the patch below fix it? (i've also updated the -37-03 patch that
includes it.)

	Ingo

--- linux/lib/rwsem.c.orig
+++ linux/lib/rwsem.c
@@ -169,6 +169,8 @@ rwsem_down_failed_common(struct rw_semap
 
 	/* wait to be given the lock */
 	for (;;) {
+		unsigned long nosched_flag = current->flags & PF_NOSCHED;
+	
 		if ((sleep_state == TASK_INTERRUPTIBLE) &&
 						signal_pending(current)) {
 			spin_lock(&sem->wait_lock);
@@ -181,7 +183,10 @@ rwsem_down_failed_common(struct rw_semap
 		}
 		if (!waiter->task)
 			break;
+
+		current->flags &= ~PF_NOSCHED;
 		schedule();
+		current->flags |= nosched_flag;
 		set_task_state(tsk, sleep_state);
 	}
 

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
  2005-02-01 20:14                                                                                         ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02 Ingo Molnar
@ 2005-02-03 20:53                                                                                           ` Eugeny S. Mints
  2005-02-03 20:55                                                                                             ` Ingo Molnar
  2005-02-04  1:51                                                                                           ` Steven Rostedt
  1 sibling, 1 reply; 951+ messages in thread
From: Eugeny S. Mints @ 2005-02-03 20:53 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

Ingo Molnar wrote:
> i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>   http://redhat.com/~mingo/realtime-preempt/
Minor fix for deadlock tracer: "...acquired at XXX"  may print  caller's 
of an up() eip instead of eip of caller of a down() in case a lock was 
initally contended before deadlock is detected.

Seems actual for 37-03 as well. pathc is attached.
	
			Eugeny


[-- Attachment #2: deadlock_trace_minor_fix.patch --]
[-- Type: text/plain, Size: 349 bytes --]

--- rt.c.orig	2005-02-03 23:35:42.000000000 +0300
+++ rt.c	2005-02-03 23:35:58.000000000 +0300
@@ -734,7 +734,7 @@
 
 	list_del_init(&waiter->pi_list);
 
-	set_new_owner(lock, old_owner, new_owner, eip);
+	set_new_owner(lock, old_owner, new_owner, waiter->eip);
 	/* Don't touch waiter after ->task has been NULLed */
 	mb();
 	waiter->task = NULL;

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
  2005-02-03 20:53                                                                                           ` Eugeny S. Mints
@ 2005-02-03 20:55                                                                                             ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2005-02-03 20:55 UTC (permalink / raw)
  To: Eugeny S. Mints; +Cc: linux-kernel


* Eugeny S. Mints <emints@ru.mvista.com> wrote:

> Ingo Molnar wrote:
> >i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
> >downloaded from the usual place:
> >
> >  http://redhat.com/~mingo/realtime-preempt/
> Minor fix for deadlock tracer: "...acquired at XXX"  may print  caller's 
> of an up() eip instead of eip of caller of a down() in case a lock was 
> initally contended before deadlock is detected.
> 
> Seems actual for 37-03 as well. patch is attached.

ah - this might explain some of the weirder deadlock traces. Thanks and
applied.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
  2005-02-01 20:14                                                                                         ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02 Ingo Molnar
  2005-02-03 20:53                                                                                           ` Eugeny S. Mints
@ 2005-02-04  1:51                                                                                           ` Steven Rostedt
  2005-02-04  2:18                                                                                             ` Steven Rostedt
  1 sibling, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2005-02-04  1:51 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML, Manish Lachwani

On Tue, 2005-02-01 at 21:14 +0100, Ingo Molnar wrote:
> i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> the big change in the patch is increased architecture support: most
> notable i've merged the MIPS patch from Manish Lachwani. Also, the x64
> port should be working again. (To make architecture merges easier in the
> future the timer interrupt is not threaded anymore - if this shows
> latency problems then we'll try to solve it on other ways.)

Ingo, 

I was just about to send you a note about why the timer interrupt as a
thread was a problem, but you changed it here, so it really isn't
anymore. But since your reason is for architecture, and not for this
reason, I'm posting it anyway.

Here was what I was about to send:

I was wondering why the timer interrupt is a thread, because this can
cause some unexpected results.

Say if you have two high priority processes A and B. A is higher than B
and both are higher than the timer interrupt (I'm on x86 so it's IRQ0)

B is doing lots of busy work, and A does a little then sleeps a little.

This is what is happening.  Once A sleeps, B goes off doing lots of busy
work, and A doesn't wake up until B is done, although A had a timeout,
that it missed.

What's going on is that the jiffies are not incrementing.  After the
first time that IRQ 0 goes goes off, the interrupt is disabled. So we
don't get any more interrupts for the timer, and B gets to run as much
as it wants leaving A in the dust.

So my question to you is why even bother having the timer interrupt as
thread.  Maybe make a tasklet or something to do more of it's work, but
let the interrupt go off as much as it wants. Otherwise, you can have
the problem mentioned above. If the fix to this is to either change the
timer interrupt to either NODELAY or just have the processes lower in
priority than the timer, then what's the point to having the timer as a
thread?


OK that was the note I was about to send, but like I stated, it isn't a
problem now that the timer interrupt is back to a hard interrupt. I just
showing this to you so you can see the real problem.  Maybe I'm missing
something, and maybe I'm not. I'll try to write up something that shows
the problem with the timer interrupt as a thread.

Thanks,

-- Steve



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
  2005-02-04  1:51                                                                                           ` Steven Rostedt
@ 2005-02-04  2:18                                                                                             ` Steven Rostedt
  2005-02-05  6:02                                                                                               ` Steven Rostedt
  0 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2005-02-04  2:18 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML, Manish Lachwani

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]


> OK that was the note I was about to send, but like I stated, it isn't a
> problem now that the timer interrupt is back to a hard interrupt. I just
> showing this to you so you can see the real problem.  Maybe I'm missing
> something, and maybe I'm not. I'll try to write up something that shows
> the problem with the timer interrupt as a thread.

Well, I wrote something up and I found a test case that locks the
machine (on 2.6.11-rc2-V0.7.37-03). I've only tried this on
2.6.10-rc3-mm1, where it works.  I don't have anymore time to look into
this today, so I haven't tried it on vanilla 2.6.11-rc2.

The attached file was going to be something that shows what happens when
you have two processes with a higher priority than the timer interrupt.
But unfortunately it locked up 36-03. I tried it on 37-03 too, and it
locked it up as well.  But if I modify this program a little, it runs
fine on both.  

Here's the case:  I have two processes waiting on a semaphore to go to
zero.  Once it does, they both run spin loops, where one sleeps, and the
other just spins for a duration. The parent of these processes, set
their priorities very high and then zeros the semaphore. 

Here's the problem: If I raise the priorities of the processes before
zeroing the semaphore, the machine hangs.  If I zero the semaphore
before raising the priorities, the program runs fine.

You would think that if the problem happened the other way around, it
could be just that one of the high priority spinners is starving
everything else. But the problem occurs if the spinners are SLEEPING! 

Attached is the code that locks up the machine. I'd look into it but
I've already done my 16 hours today ;-)

-- Steve


[-- Attachment #2: timertest.c --]
[-- Type: text/x-csrc, Size: 7668 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <time.h>
#include <sys/sem.h>
#include <sys/shm.h>
#include <sys/time.h>
#include <sys/wait.h>
#include <fcntl.h>
#include <sched.h>
#include <signal.h>

#define __USE_GNU
#include <sys/ipc.h>

static int int_spinner (int i);
static int spinner (int i);

typedef int (*callfunc_t)(int);

#define NR_PROCS 2
pid_t pids[NR_PROCS];
callfunc_t dofunc[NR_PROCS] = {
	int_spinner,
	spinner,
};



key_t key;
int semid = -1;
int shmid = -1;
int *flags;
pid_t timer_pid;
int timer_prio;


void cleanup(void)
{
	int i;

	for (i=0; i < NR_PROCS; i++) {
		if (pids[0])
			kill(pids[i],SIGKILL);
	}

	if (semid >= 0)
		semctl(semid, 0, IPC_RMID);
	if (shmid >= 0)
		shmctl(shmid, IPC_RMID, NULL);
}

void double_to_tv(double d, struct timeval *tv)
{
	tv->tv_sec = (int)d;
	tv->tv_usec = (int) ((d - (double)tv->tv_sec) * 1000000.0);
	printf ("sec:%d usecs:%d\n",(int)tv->tv_sec,(int)tv->tv_usec);
}

void catchall(int sig)
{
	cleanup();
	psignal(sig,"Caught: ");
	exit(-1);
}

static int compare_timeval(const struct timeval *a, const struct timeval *b)
{
	return (a->tv_sec > b->tv_sec) ? 1 :
		(a->tv_sec < b->tv_sec) ? -1:
		(a->tv_usec > b->tv_usec) ? 1:
		(a->tv_usec < b->tv_usec) ? -1:
		0;
}

static void add_timeval(const struct timeval *a, const struct timeval *b, struct timeval *c)
{

	c->tv_usec = a->tv_usec + b->tv_usec;
	c->tv_sec = a->tv_sec + b->tv_sec;
	while (c->tv_usec > 1000000) {
		c->tv_usec -= 1000000;
		c->tv_sec++;
	}

}

static void sub_timeval(const struct timeval *a, const struct timeval *b, struct timeval *c)
{

	c->tv_usec = a->tv_usec - b->tv_usec;
	c->tv_sec = a->tv_sec - b->tv_sec;
	while (c->tv_usec < 0) {
		c->tv_usec += 1000000;
		c->tv_sec--;
	}

}

static int int_spinner(int i)
{
	struct sembuf sops;
	int semid;
	struct timeval starttv;
	struct timeval endtv;
	struct timeval tv;
	struct timeval lasttv;
	struct timeval nexttv;
	time_t t;
	char timebuf[30];
	unsigned long long starttsc, nowtsc;

	memset(&sops,0,sizeof(sops));
	
	if ((semid = semget(key,1,0)) < 0) {
		perror("semget");
		return -1;
	}
	if ((shmid = shmget(key,30,0600)) < 0) {
		perror("shmget");
		return -1;
	}
	if ((flags = shmat(shmid, NULL, 0)) == (void*)-1) {
		perror("shmat");
		return -1;
	}
	
	printf("int_spinner %d grabbing waiting on sem\n",i);
	if (semop(semid, &sops, 1) < 0) {
		perror("semop");
		return -1;
	}
	printf("int_spinner %d got semaphore\n",i);


	if (gettimeofday(&starttv,NULL) < 0) {
		perror("gettimeofday");
		return -1;
	}

	endtv.tv_sec = 10;
	endtv.tv_usec = 0;

	add_timeval(&starttv,&endtv,&endtv);

	t = time(NULL);
	ctime_r(&t,timebuf);
	timebuf[strlen(timebuf)-1] = 0;

	printf("spinner %d starting loop (%s)\n",i,timebuf);
	lasttv = starttv;

	nexttv = starttv;
	nexttv.tv_sec += 3;

	printf("A sleeping\n");
	(*flags)++;
	sleep(1);
	printf("A a wake\n");
	
	asm ("rdtsc" : "=A"(starttsc));

	do {
		asm ("rdtsc" : "=A"(nowtsc));
		if (nowtsc - starttsc > 7000000000ULL) {
			printf("spinner %d now - start > 7000000000\n",i);
			break;
		}
		if (gettimeofday(&tv,NULL) < 0) {
			perror("gettimeofday (in loop)");
			return -1;
		}
		if (compare_timeval(&tv,&nexttv) > 0) {
			printf("A sleeping\n");
			(*flags)++;
			sleep(1);
			printf("A a wake\n");
			nexttv.tv_sec += 3;
		}
		sub_timeval(&tv,&lasttv,&lasttv);
		lasttv = tv;
	} while(compare_timeval(&endtv,&tv) > 0);

	t = time(NULL);
	ctime_r(&t,timebuf);
	timebuf[strlen(timebuf)-1] = 0;
	printf("spinner %d ended loop flags=%d (%s)\n",i,*flags,timebuf);
	

	return 0;
}

static int spinner(int i)
{
	struct sembuf sops;
	int semid;
	struct timeval starttv;
	struct timeval endtv;
	struct timeval tv;
	struct timeval lasttv;
	struct timeval deltatv;
	time_t t;
	char timebuf[30];
	unsigned long long starttsc, nowtsc;
	int last_flag;

	memset(&sops,0,sizeof(sops));
	
	if ((semid = semget(key,1,0)) < 0) {
		perror("semget");
		return -1;
	}
	if ((shmid = shmget(key,30,0600)) < 0) {
		perror("shmget");
		return -1;
	}
	if ((flags = shmat(shmid, NULL, 0)) == (void*)-1) {
		perror("shmat");
		return -1;
	}
	


	printf("spinner %d grabbing waiting on sem\n",i);
	if (semop(semid, &sops, 1) < 0) {
		perror("semop");
		return -1;
	}

	printf("spinner %d got semaphore\n",i);

	if (gettimeofday(&starttv,NULL) < 0) {
		perror("gettimeofday");
		return -1;
	}

	memset (&deltatv,0,sizeof(deltatv));

	endtv.tv_sec = 10;
	endtv.tv_usec = 0;

	add_timeval(&starttv,&endtv,&endtv);

	t = time(NULL);
	ctime_r(&t,timebuf);
	timebuf[strlen(timebuf)-1] = 0;

	printf("spinner %d starting loop flags=%d (%s)\n",i,*flags,timebuf);
	lasttv = starttv;
	asm ("rdtsc" : "=A"(starttsc));

	last_flag = *flags;
	do {
		asm ("rdtsc" : "=A"(nowtsc));
		if (nowtsc - starttsc > 7000000000ULL) {
			printf("spinner %d now - start > 7000000000\n",i);
			break;
		}
		if (gettimeofday(&tv,NULL) < 0) {
			perror("gettimeofday (in loop)");
			return -1;
		}
		if (*flags != last_flag) {
			printf("spinner %d running again (flags=%d)!\n",i,*flags);
			last_flag = *flags;
		}			

		sub_timeval(&tv,&lasttv,&lasttv);
		if (compare_timeval(&deltatv,&lasttv) < 0)
			deltatv = lasttv;
		lasttv = tv;
	} while(compare_timeval(&endtv,&tv) > 0);
	t = time(NULL);
	ctime_r(&t,timebuf);
	timebuf[strlen(timebuf)-1] = 0;
	printf("spinner %d ended loop (%s) flags=%d (%d.%06d secs delta)\n",
	       i,timebuf,*flags,(int)deltatv.tv_sec,(int)deltatv.tv_usec);
	

	return 0;
}

int set_realtime_priority(pid_t pid, unsigned int prio)
{
	struct sched_param p;
	int ret;

	memset(&p,0,sizeof(p));
	p.sched_priority = prio;
	if ((ret = sched_setscheduler(pid,SCHED_FIFO,&p)) < 0) {
		perror("sched_setscheduler");
	}
	return ret;
}

int main (int argc, char **argv)
{
	int ret=0;
	int i;
	int nr_procs=0;
	struct sched_param p;
	struct sembuf sops;
	unsigned int max;
	
	key = ftok(argv[0],123);

	if (argc >=2) {
		timer_pid = atoi(argv[1]);
		if (sched_getparam(timer_pid,&p) < 0) {
			perror("sched_getparam");
			goto out;
		}
		timer_prio = p.sched_priority;
		printf("timer priority is %d\n",timer_prio);
	}

		

	if ((semid = semget(key,1,IPC_CREAT|IPC_EXCL|0600)) < 0) {
		perror("semget");
		exit (-1);
	}
	if ((shmid = shmget(key,30,IPC_CREAT|IPC_EXCL|0600)) < 0) {
		perror("shmget");
		goto out;
	}
	if ((flags = shmat(shmid, NULL, 0)) == (void*)-1) {
		perror("shmat");
		goto out;
	}
	

	/* Grab the semaphore before anyone else can take it. */
	memset(&sops,0,sizeof(sops));
//	sops.sem_flg = SEM_UNDO;
	sops.sem_op = 1;
	if (semop(semid, &sops, 1) < 0) {
		perror("semop");
		ret = -1;
		goto out;
	}

	for (i=0; i < NR_PROCS; i++) {
		if ((pids[i] = fork()) < 0) {
			perror("fork");
			ret = -1;
			goto out;
		} else if (pids[i] == 0) {
			/* child */
			ret = dofunc[i](i);
			exit(ret);
		}
		nr_procs++;
		/* parent */
	}

	
	signal(SIGINT,catchall);
	signal(SIGILL,catchall);
	signal(SIGFPE,catchall);
	signal(SIGSEGV,catchall);
	signal(SIGBUS,catchall);


	max = sched_get_priority_max(SCHED_FIFO);
	printf("max priority is %d\n",max);
	
	sleep(1);

#if 1
	ret = -1;
	printf("setting priorities\n");
	for (i=0; i < NR_PROCS; i++) {
		printf("setting %d to prio %d\n",i,max-(1+i));
		if (set_realtime_priority(pids[0],max-(1 + i)))
			goto out;
	}
#endif

	printf("parent zeroing semaphore\n");
	sops.sem_op = -1;
       	if (semop(semid,&sops,1) < 0) {
		perror("semop");
		ret = -1;
		goto out;
	}


	while (nr_procs) {
		int status;
		pid_t pid;
		if ((pid = wait(&status)) < 0) {
			perror("wait");
			break;
		}
		for (i=0; i < NR_PROCS; i++) {
			if (pids[i] == pid) {
				pids[i] = 0;
				nr_procs--;
			}
		}
		
	}
	printf("flags = %d\n",*flags);
 out:
	cleanup();
	exit(ret);
}

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
  2005-02-04  2:18                                                                                             ` Steven Rostedt
@ 2005-02-05  6:02                                                                                               ` Steven Rostedt
  2005-02-05  7:59                                                                                                 ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2005-02-05  6:02 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML, Manish Lachwani

On Thu, 2005-02-03 at 21:18 -0500, Steven Rostedt wrote:

> Here's the problem: If I raise the priorities of the processes before
> zeroing the semaphore, the machine hangs.  If I zero the semaphore
> before raising the priorities, the program runs fine.

Hi Ingo,

I've looked into this and found where the deadlock occurs. Actually it
is a starving of processes. I finally got around to trying it on
2.6.11-rc3, and it doesn't have a problem.

Anyway, here's the scoop. 

The parent process that zeros the semaphore to allow the child process
to run after the parent upped the priority of the child really high,
gets stuck in the following:

In update_queue in ipc/sem.c (I don't have the correct line numbers,
cause I haven't stripped out the debug yet). at the point of:
			q->status = IN_WAKEUP;
			/*
			 * Continue scanning. The next operation
			 * that must be checked depends on the type of the
			 * completed operation:
			 * - if the operation modified the array, then
			 *   restart from the head of the queue and
			 *   check for threads that might be waiting
			 *   for semaphore values to become 0.
			 * - if the operation didn't modify the array,
			 *   then just continue.
			 */
			if (q->alter)
				n = sma->sem_pending;
			else
				n = q->next;
			wake_up_process(q->sleeper);

Here is where it locks up.

			/* hands-off: q will disappear immediately after
			 * writing q->status.
			 */
			q->status = error;


I also found that the high priority child is running in an infinite
while loop in sys_semtimedop in the same file, at the following:

	while(unlikely(error == IN_WAKEUP)) {
		cpu_relax();
		error = queue.status;
	}

So, what looks to be happening is that as soon as the parent wakes up
the child, the child preempts the parent, and hits this while loop. But
since the child is a realtime task, with the highest priority of the
system, it starves the system. Of course this is a UP and I don't think
this will show a problem on an SMP machine. 

I can't think of a solution right now, so I'll just pass it on to
you ;-).  Once again it's late and I'm going to bed.


Thanks,

-- Steve



^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
  2005-02-05  6:02                                                                                               ` Steven Rostedt
@ 2005-02-05  7:59                                                                                                 ` Ingo Molnar
  2005-02-05 14:32                                                                                                   ` Steven Rostedt
  0 siblings, 1 reply; 951+ messages in thread
From: Ingo Molnar @ 2005-02-05  7:59 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: LKML, Manish Lachwani


* Steven Rostedt <rostedt@goodmis.org> wrote:

> 	while(unlikely(error == IN_WAKEUP)) {
> 		cpu_relax();
> 		error = queue.status;
> 	}
> 
> So, what looks to be happening is that as soon as the parent wakes up
> the child, the child preempts the parent, and hits this while loop.
> But since the child is a realtime task, with the highest priority of
> the system, it starves the system. Of course this is a UP and I don't
> think this will show a problem on an SMP machine. 

hm - i had a fix in this area in the -V0.7 series. Then i thought this
is a performance fix only and dropped it eventually, but could you give
it a go - does it fix the deadlock?

	Ingo

--- linux/ipc/sem.c.orig
+++ linux/ipc/sem.c
@@ -359,12 +371,18 @@ static void update_queue (struct sem_arr
 			struct sem_queue *n;
 			remove_from_queue(sma,q);
 			n = q->next;
+			/*
+			 * Make sure that the wakeup doesnt preempt
+			 * _this_ CPU prematurely. (on PREEMPT_RT)
+			 */
+			preempt_disable();
 			q->status = IN_WAKEUP;
 			wake_up_process(q->sleeper);
 			/* hands-off: q will disappear immediately after
 			 * writing q->status.
 			 */
 			q->status = error;
+			preempt_enable();
 			q = n;
 		} else {
 			q = q->next;

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
  2005-02-05  7:59                                                                                                 ` Ingo Molnar
@ 2005-02-05 14:32                                                                                                   ` Steven Rostedt
  2005-02-07  9:22                                                                                                     ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Steven Rostedt @ 2005-02-05 14:32 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML, Manish Lachwani

On Sat, 2005-02-05 at 08:59 +0100, Ingo Molnar wrote:

> hm - i had a fix in this area in the -V0.7 series. Then i thought this
> is a performance fix only and dropped it eventually, but could you give
> it a go - does it fix the deadlock?
> 
> 	Ingo

Yep, it worked! I tried a similar fix earlier but I put the preempt
disable before the setting of q->status (duh!) and it didn't work. But
it was late and I was tired of looking at it.  I was about to say that I
already tried it, but then noticed the placement of preempt_disable, and
thought, I better try yours anyway. Well, it seems to fix it. By the
way, I just put in the disable and enable in -37. I haven't gotten to
your 38 yet, but this fixed 37.

Thanks,

-- Steve

> 
> --- linux/ipc/sem.c.orig
> +++ linux/ipc/sem.c
> @@ -359,12 +371,18 @@ static void update_queue (struct sem_arr
>  			struct sem_queue *n;
>  			remove_from_queue(sma,q);
>  			n = q->next;
> +			/*
> +			 * Make sure that the wakeup doesnt preempt
> +			 * _this_ CPU prematurely. (on PREEMPT_RT)
> +			 */
> +			preempt_disable();
>  			q->status = IN_WAKEUP;
>  			wake_up_process(q->sleeper);
>  			/* hands-off: q will disappear immediately after
>  			 * writing q->status.
>  			 */
>  			q->status = error;
> +			preempt_enable();
>  			q = n;
>  		} else {
>  			q = q->next;


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
  2005-02-05 14:32                                                                                                   ` Steven Rostedt
@ 2005-02-07  9:22                                                                                                     ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2005-02-07  9:22 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: LKML, Manish Lachwani


* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Sat, 2005-02-05 at 08:59 +0100, Ingo Molnar wrote:
> 
> > hm - i had a fix in this area in the -V0.7 series. Then i thought this
> > is a performance fix only and dropped it eventually, but could you give
> > it a go - does it fix the deadlock?
> > 
> > 	Ingo
> 
> Yep, it worked! I tried a similar fix earlier but I put the preempt
> disable before the setting of q->status (duh!) and it didn't work. But
> it was late and I was tired of looking at it.  I was about to say that
> I already tried it, but then noticed the placement of preempt_disable,
> and thought, I better try yours anyway. Well, it seems to fix it. By
> the way, I just put in the disable and enable in -37. I haven't gotten
> to your 38 yet, but this fixed 37.

good - i've merged this into the -38-03 release.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-23 18:06 [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Mark_H_Johnson
@ 2004-11-23 21:15 ` Ingo Molnar
  0 siblings, 0 replies; 951+ messages in thread
From: Ingo Molnar @ 2004-11-23 21:15 UTC (permalink / raw)
  To: Mark_H_Johnson
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, K.R. Foley, Bill Huey,
	Adam Heath, Florian Schmidt, Thomas Gleixner, Michal Schmidt,
	Fernando Pablo Lopez-Lezcano, Karsten Wiese, Gunther Persoons,
	emann, Shane Shrybman, Amit Shah, Esben Nielsen


* Mark_H_Johnson@raytheon.com <Mark_H_Johnson@raytheon.com> wrote:

> I do have a repeatable problem with -7 however (not yet checked in
> -9). This was with PREEMPT_DESKTOP and unthreaded IRQ's (hard and
> soft). [...]

> The system dies early in the boot process. Locks up and completely not
> responsive and no error messages prior to failure. Serial console
> output follows at the end of this email.

> The PREEMPT_RT kernel I built (same source, only difference was
> previously described .config changes) comes up OK.

i can reproduce the PREEMPT_DESKTOP boot-time hang too, it is a recent
breakage.

	Ingo

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
  2004-11-23 19:24 Mark_H_Johnson
@ 2004-11-23 19:50 ` Adam Heath
  0 siblings, 0 replies; 951+ messages in thread
From: Adam Heath @ 2004-11-23 19:50 UTC (permalink / raw)
  To: Mark_H_Johnson
  Cc: Ingo Molnar, linux-kernel, Lee Revell, Rui Nuno Capela,
	K.R. Foley, Bill Huey, Florian Schmidt, Thomas Gleixner,
	Michal Schmidt, Fernando Pablo Lopez-Lezcano, Karsten Wiese,
	Gunther Persoons, emann, Shane Shrybman, Amit Shah,
	Esben Nielsen

yOn Tue, 23 Nov 2004,  wrote:

> >i have released the -V0.7.30-9 Real-Time Preemption patch,
>
> The profile script (5 second wait, dump data if wait > 10 seconds) was
> stuck for over 300 seconds & when it woke up there were 34 jobs waiting
> to run. A couple excerpts from the data [will send that separately].
> This was with -V0.7.30-7 (PREEMPT_RT) running latencytest & I believe
> the disk write test (comparing date/time modified of log files...) plus
> a pair of data collecting scripts.

Sounds very similiar to the problem I reported with 29-0.  I left work late
saturday night, arrived back sunday around 11am, and found the machine saying
the time was 1:15am.  I've seen other pauses, were nothing runs.  Hitting a
key causes the machine to start responding/running again.

^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
@ 2004-11-23 19:24 Mark_H_Johnson
  2004-11-23 19:50 ` Adam Heath
  0 siblings, 1 reply; 951+ messages in thread
From: Mark_H_Johnson @ 2004-11-23 19:24 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah, Esben Nielsen

>i have released the -V0.7.30-9 Real-Time Preemption patch,

The profile script (5 second wait, dump data if wait > 10 seconds) was
stuck for over 300 seconds & when it woke up there were 34 jobs waiting
to run. A couple excerpts from the data [will send that separately].
This was with -V0.7.30-7 (PREEMPT_RT) running latencytest & I believe
the disk write test (comparing date/time modified of log files...) plus
a pair of data collecting scripts.

Don't know if this is the journaling problem you mention being fixed
in -9 or not. This huge delay did not recur with the disk copy test.

The odd data point I notice here was the nearly 100% cpu time for
the shell script get_ltrace.sh which is...

#!/bin/sh

let MAX=`cat /proc/sys/kernel/preempt_max_latency`
let I=0 J=1
let MP=${1:-1000}
echo "Current Maximum is $MAX, limit will be $MP."
while (( I < 100 )) ; do
    sleep 1s
    let NOW=`cat /proc/sys/kernel/preempt_max_latency`
    if (( MAX != NOW )) ; then
        echo "New trace $I w/ $NOW usec latency."
        cat /proc/latency_trace > lt.`printf "%02d" $I`
        sync ; sync
        let I++
        let MAX=NOW
    elif (( J++ >= 10 )) ; then
        if (( MAX != MP )) ; then
            echo "Resetting max latency from $MAX to $MP."
            echo $MP > /proc/sys/kernel/preempt_max_latency
            let MAX=$MP
        else
            echo "No new latency samples at `date`."
        fi
        let J=1
# else do nothing...
    fi
done

Perhaps the sync caused the 100% CPU usage for the moment (but certainly
not for five minutes!). It is however suspicious that the total run time
for that script (5:33) is very close to the delay time (336 seconds) for
the profile script. Both of these run at RT FIFO priority 1. There is also
a 5 minute gap in the files generated by get_ltrace.sh as well.

--Mark

--- excerpts follow ---

Tue Nov 23 12:40:48 CST 2004
336 seconds elapsed time.
Load Average ->
36.00 24.57 12.44 36/125 8600

Tasks in RUN state...

                        PID PRI RTPRIO  NI S     TIME %CPU CMD
041123-01/prof002.txt:    1  23      -   0 R 00:00:04  0.1 init [5]
041123-01/prof002.txt:    5  34      - -10 R 00:00:00  0.0 [desched/0]
041123-01/prof002.txt:    8  34      - -10 R 00:00:00  0.0 [desched/1]
041123-01/prof002.txt:  100  24      -   0 R 00:00:00  0.0 [pdflush]
041123-01/prof002.txt:  310  24      -   0 R 00:00:00  0.0 [kirqd]
041123-01/prof002.txt:  320  24      -   0 R 00:00:02  0.1 [kjournald]
041123-01/prof002.txt: 1208  23      -   0 R 00:00:03  0.1 [kjournald]
041123-01/prof002.txt: 1803  23      -   0 R 00:00:00  0.0 /sbin/dhclient
-1 -q -lf /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid
-cf /etc/dhclient-eth0.conf eth0
041123-01/prof002.txt: 1838  23      -   0 R 00:00:00  0.0 syslogd -m 0
041123-01/prof002.txt: 1909  23      -   0 R 00:00:00  0.0 rpc.idmapd
041123-01/prof002.txt: 2040  23      -   0 R 00:00:18  0.7 /usr/sbin/nscd
041123-01/prof002.txt: 2072  23      -   0 R 00:00:02  0.0 cupsd
041123-01/prof002.txt: 2361  23      -   0 R 00:00:00  0.0 ntpd -U ntp -p
/var/run/ntpd.pid
041123-01/prof002.txt: 2381  23      -   0 R 00:00:00  0.0
/usr/local/nagios/sbin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -d
041123-01/prof002.txt: 2400  23      -   0 R 00:00:00  0.0 sendmail:
accepting connections
041123-01/prof002.txt: 2426  23      -   0 R 00:00:00  0.0 gpm -m
/dev/input/mice -t imps2
041123-01/prof002.txt: 2551  23      -   0 R 00:00:00  0.0 crond
041123-01/prof002.txt: 2574  23      -   0 R 00:00:00  0.0 xfs -droppriv
-daemon
041123-01/prof002.txt: 2593  23      -   0 R 00:00:00  0.0 /usr/sbin/atd
041123-01/prof002.txt: 2911  23      -   0 R 00:00:00  0.0
/usr/bin/ssh-agent /home/u21305/.Xclients
041123-01/prof002.txt: 2944  23      -   0 R 00:00:00  0.0 kdeinit:
klauncher
041123-01/prof002.txt: 2947  24      -   0 R 00:00:02  0.1 kdeinit: kded
041123-01/prof002.txt: 3174  24      -   0 R 00:00:03  0.1 kdeinit: knotify
041123-01/prof002.txt: 3196  23      -   0 R 00:00:00  0.0 kwrapper
ksmserver
041123-01/prof002.txt: 3201  23      -   0 R 00:00:02  0.0 kdeinit:
kdesktop
041123-01/prof002.txt: 3203  24      -   0 R 00:00:18  0.7 kdeinit: kicker
041123-01/prof002.txt: 3216  23      -   0 R 00:00:00  0.0
/sbin/pam_timestamp_check -d root
041123-01/prof002.txt: 3220  23      -   0 R 00:00:11  0.4 kdeinit: konsole
-session 11c034d757000106674694500000017150004_1101232254_900758
041123-01/prof002.txt: 3624  41      1   0 R 00:00:04  0.2 /bin/sh
./getlog.sh
041123-01/prof002.txt: 3782   4      -  10 R 00:20:05 68.5 ./cpu_burn
041123-01/prof002.txt: 6030  23      -   0 R 00:00:01  0.1
/usr/bin/kdesktop_lock
041123-01/prof002.txt: 8497  21      -   0 R 00:00:06  1.6 head -c
750000000 /dev/zero
041123-01/prof002.txt: 8594  70      1   0 R 00:05:33 99.9 /bin/sh
./get_ltrace.sh 100


^ permalink raw reply	[flat|nested] 951+ messages in thread

* Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9
@ 2004-11-23 18:06 Mark_H_Johnson
  2004-11-23 21:15 ` Ingo Molnar
  0 siblings, 1 reply; 951+ messages in thread
From: Mark_H_Johnson @ 2004-11-23 18:06 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Lee Revell, Rui Nuno Capela, Mark_H_Johnson,
	K.R. Foley, Bill Huey, Adam Heath, Florian Schmidt,
	Thomas Gleixner, Michal Schmidt, Fernando Pablo Lopez-Lezcano,
	Karsten Wiese, Gunther Persoons, emann, Shane Shrybman,
	Amit Shah, Esben Nielsen

>i have released the -V0.7.30-9 Real-Time Preemption patch, which can be
>downloaded from the usual place:
>
>    http://redhat.com/~mingo/realtime-preempt/

Grr. Had downloaded -V0.7.30-7 and was building when this message came in.

I do have a repeatable problem with -7 however (not yet checked in -9).
This
was with PREEMPT_DESKTOP and unthreaded IRQ's (hard and soft). As I look
at the .config differences, also enabled in 7PK (and not 7RT) was
  CONFIG_ASM_SEMAPHORES=y
  CONFIG_RWSEM_XCHGADD_ALGORITHM=y
and enabled in 7RT (and not 7PK) was
  CONFIG_RT_DEADLOCK_DETECT=y
I should also note that I applied a patch for NMI profiling in my build
as well (but not sure that caused the problem).

The system dies early in the boot process. Locks up and completely not
responsive and no error messages prior to failure. Serial console output
follows at the end of this email.

The PREEMPT_RT kernel I built (same source, only difference was previously
described .config changes) comes up OK.
  --Mark

--- first attempt ---

Linux version 2.6.10-rc2-mm2-V0.7.30-7PK (root@dws77) (gcc version 3.3.3
20040412 (Red Hat Linux 3.3.3-7)) #2 SMP Tue Nov 23 10:58:11 CST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
 BIOS-e820: 000000001fff0000 - 000000001fff8000 (ACPI data)
 BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
found SMP MP-table at 000fb170
DMI 2.3 present.
Using APIC driver default
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 17
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:8 APIC version 17
Using ACPI for processor (LAPIC) configuration information
Intel MultiProcessor Specification v1.1
    Virtual Wire compatibility mode.
OEM ID: VIA      Product ID: VT3075       APIC at: 0xFEE00000
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 2
Built 1 zonelists
Initializing CPU#0
Kernel command line: ro root=LABEL=/ nmi_watchdog=1 single
console=ttyS0,38400n8r profile=2
kernel CPU profiling enabled
kernel profiling shift: 2
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 864.162 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25

--- second attempt ---

Linux version 2.6.10-rc2-mm2-V0.7.30-7PK (root@dws77) (gcc version 3.3.3
20040412 (Red Hat Linux 3.3.3-7)) #2 SMP Tue Nov 23 10:58:11 CST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
 BIOS-e820: 000000001fff0000 - 000000001fff8000 (ACPI data)
 BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
found SMP MP-table at 000fb170
DMI 2.3 present.
Using APIC driver default
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 17
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:8 APIC version 17
Using ACPI for processor (LAPIC) configuration information
Intel MultiProcessor Specification v1.1
    Virtual Wire compatibility mode.
OEM ID: VIA      Product ID: VT3075       APIC at: 0xFEE00000
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 2
Built 1 zonelists
Initializing CPU#0
Kernel command line: ro root=LABEL=/ nmi_watchdog=1 single
console=ttyS0,38400n8r profile=2
kernel CPU profiling enabled
kernel profiling shift: 2
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 864.157 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 511160k/524224k available (2236k kernel code, 12524k reserved, 634k
data, 236k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode...
Ok.
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support...


^ permalink raw reply	[flat|nested] 951+ messages in thread

end of thread, other threads:[~2005-02-07  9:23 UTC | newest]

Thread overview: 951+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-11 18:23 [patch] CONFIG_PREEMPT_REALTIME, 'Fully Preemptible Kernel', VP-2.6.9-rc4-mm1-T4 Mark_H_Johnson
2004-10-11 21:59 ` [patch] VP-2.6.9-rc4-mm1-T5 Ingo Molnar
2004-10-11 22:57   ` Florian Schmidt
2004-10-11 23:14     ` Florian Schmidt
2004-10-12  0:52       ` Lee Revell
2004-10-12  8:22         ` Wen-chien Jesse Sung
2004-10-12  6:12       ` Ingo Molnar
2004-10-12 10:45         ` Florian Schmidt
2004-10-12  0:11   ` Rui Nuno Capela
2004-10-12  0:57   ` Lee Revell
2004-10-12  6:37     ` Ingo Molnar
2004-10-12  3:51   ` K.R. Foley
2004-10-12  6:02     ` Ingo Molnar
2004-10-12 11:08       ` K.R. Foley
2004-10-12 11:43         ` Ingo Molnar
2004-10-12  9:15   ` [patch] VP-2.6.9-rc4-mm1-T6 Ingo Molnar
2004-10-12  9:31     ` Wen-chien Jesse Sung
2004-10-12 10:35       ` Ingo Molnar
2004-10-12 11:32         ` Wen-chien Jesse Sung
2004-10-12  9:42     ` Ingo Molnar
2004-10-12  9:53       ` Ingo Molnar
2004-10-12 12:33     ` Ingo Molnar
2004-10-12 13:59       ` VP-2.6.9-rc4-mm1-T7 Rui Nuno Capela
2004-10-12 14:23         ` VP-2.6.9-rc4-mm1-T7 Ingo Molnar
2004-10-12 15:12       ` [patch] VP-2.6.9-rc4-mm1-T6 K.R. Foley
2004-10-12 15:27         ` Ingo Molnar
2004-10-12 16:57           ` K.R. Foley
2004-10-12 19:54       ` [patch] VP-2.6.9-rc4-mm1-T8 Ingo Molnar
2004-10-12 20:57         ` K.R. Foley
2004-10-13  5:45           ` Ingo Molnar
2004-10-13 14:00             ` K.R. Foley
2004-10-13  6:15         ` [patch] VP-2.6.9-rc4-mm1-T9 Ingo Molnar
2004-10-13  9:15           ` Rui Nuno Capela
2004-10-13 14:52           ` K.R. Foley
2004-10-13 16:53           ` Radoslaw Szkodzinski
2004-10-14  0:24           ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Ingo Molnar
2004-10-14  1:27             ` Adam Heath
2004-10-14  1:31               ` Ingo Molnar
2004-10-14  2:22                 ` Adam Heath
2004-10-14  1:36               ` Ingo Molnar
2004-10-14  2:45             ` K.R. Foley
2004-10-14  3:59             ` K.R. Foley
2004-10-14  8:57             ` Florian Schmidt
2004-10-14  9:19               ` Ingo Molnar
2004-10-14  9:42                 ` Florian Schmidt
2004-10-14  9:36                   ` Ingo Molnar
2004-10-14 10:00                 ` Florian Schmidt
2004-10-14 10:22                   ` Rui Nuno Capela
2004-10-14 10:48                     ` Florian Schmidt
2004-10-14 10:54                       ` K.R. Foley
2004-10-14 11:16                         ` Florian Schmidt
2004-10-14 11:23                           ` Florian Schmidt
2004-10-14 11:42                           ` Florian Schmidt
2004-10-14 13:33                             ` Florian Schmidt
2004-10-14 17:43                 ` Miquel van Smoorenburg
2004-10-14 14:31             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Ingo Molnar
2004-10-14 17:34               ` Adam Heath
2004-10-14 22:16                 ` Adam Heath
2004-10-14 22:24                   ` Ingo Molnar
2004-10-14 19:42               ` Daniel Walker
2004-10-14 19:57                 ` Ingo Molnar
2004-10-14 20:34                   ` Daniel Walker
     [not found]               ` <200410142216.23572.l_allegrucci@yahoo.it>
2004-10-14 20:21                 ` Lee Revell
2004-10-14 20:28               ` Lorenzo Allegrucci
2004-10-14 20:39               ` K.R. Foley
2004-10-14 22:52               ` Radoslaw Szkodzinski
2004-10-14 23:42               ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U2 Ingo Molnar
2004-10-15  0:31                 ` Adam Heath
2004-10-15  0:41                   ` Adam Heath
2004-10-15  0:53                     ` Adam Heath
2004-10-15  7:14                     ` Ingo Molnar
2004-10-15  2:23                 ` Bill Huey
2004-10-15  2:40                   ` K.R. Foley
2004-10-15  2:47                     ` Bill Huey
2004-10-15  3:19                       ` K.R. Foley
2004-10-15  3:47                         ` Bill Huey
2004-10-15  3:48                           ` Bill Huey
2004-10-15  7:08                   ` Ingo Molnar
2004-10-15  8:21                     ` Bill Huey
2004-10-15 11:47                     ` K.R. Foley
2004-10-15 11:58                       ` Ingo Molnar
2004-10-15  2:33                 ` Adam Heath
2004-10-15 10:26                 ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 Ingo Molnar
2004-10-15 11:59                   ` Dominik Karall
2004-10-15 12:03                     ` Ingo Molnar
2004-10-15 16:48                     ` Lee Revell
2004-10-15 17:40                       ` Adam Heath
2004-10-15 17:54                   ` K.R. Foley
2004-10-15 18:16                   ` K.R. Foley
2004-10-15 20:29                   ` Gunther Persoons
2004-10-15 23:16                   ` Bill Huey
2004-10-16  0:21                     ` Bill Huey
2004-10-16  6:48                     ` Ingo Molnar
2004-10-16  1:00                   ` Lee Revell
2004-10-16  2:35                     ` Lee Revell
2004-10-16  6:42                       ` Ingo Molnar
2004-10-16  9:02                         ` Lee Revell
2004-10-16 10:36                           ` Ingo Molnar
2004-10-16 11:03                             ` Rui Nuno Capela
2004-10-16 11:12                               ` Ingo Molnar
2004-10-16 11:55                                 ` Rui Nuno Capela
2004-10-16 12:01                                   ` Ingo Molnar
2004-10-16 12:32                             ` K.R. Foley
2004-10-17 13:14                             ` Rui Nuno Capela
2004-10-17 13:21                               ` Ingo Molnar
     [not found]                                 ` <32793.192.168.1.5.1098023139.squirrel@192.168.1.5>
2004-10-17 16:12                                   ` Ingo Molnar
2004-10-17 17:20                                     ` Rui Nuno Capela
2004-10-17 17:27                                       ` Ingo Molnar
2004-10-17 16:47                                   ` Ingo Molnar
2004-10-17 19:05                                     ` Rui Nuno Capela
2004-10-17 19:24                                       ` Ingo Molnar
2004-10-17 20:23                                         ` Rui Nuno Capela
2004-10-16 10:29                       ` Rui Nuno Capela
2004-10-16 12:54                         ` K.R. Foley
2004-10-16 13:04                           ` Ingo Molnar
2004-10-16 13:07                             ` K.R. Foley
2004-10-16 13:41                           ` Rui Nuno Capela
2004-10-16 13:55                             ` K.R. Foley
2004-10-16  2:58                   ` Adam Heath
2004-10-16  7:56                     ` Ingo Molnar
2004-10-16  8:18                       ` Ingo Molnar
2004-10-16 18:38                       ` Adam Heath
2004-10-16  6:13                   ` Lee Revell
2004-10-16 14:21                   ` Dominik Karall
2004-10-16 15:24                     ` Ingo Molnar
2004-10-16 20:30                       ` Dominik Karall
2004-10-16 20:31                         ` Lee Revell
2004-10-16 21:44                           ` Dominik Karall
2004-10-17  5:21                             ` Ingo Molnar
2004-10-17 15:32                             ` OGAWA Hirofumi
2004-10-17 17:46                               ` Dominik Karall
2004-10-18  3:50                                 ` OGAWA Hirofumi
2004-10-21 10:24                                   ` Dominik Karall
2004-10-16 15:33                   ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U4 Ingo Molnar
2004-10-16 17:11                     ` K.R. Foley
2004-10-16 19:25                       ` Ingo Molnar
2004-10-16 18:54                     ` Adam Heath
2004-10-16 19:24                       ` Ingo Molnar
2004-10-16 19:27                         ` Robert Love
2004-10-16 19:35                         ` Adam Heath
2004-10-16 19:29                     ` Adam Heath
2004-10-16 19:36                       ` Ingo Molnar
2004-10-16 19:59                         ` Adam Heath
2004-10-16 20:14                           ` Ingo Molnar
2004-10-16 20:39                             ` john cooper
2004-10-16 21:02                               ` Ingo Molnar
2004-10-16 21:15                                 ` Esben Nielsen
2004-10-16 23:41                                   ` Sam Ravnborg
2004-10-17 17:03                     ` Florian Schmidt
2004-10-17 16:55                       ` Ingo Molnar
2004-10-17 17:53                         ` Florian Schmidt
2004-10-17 17:40                           ` Ingo Molnar
2004-10-18 14:50                     ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Ingo Molnar
2004-10-18 15:58                       ` Jason Munro
2004-10-18 17:08                       ` Adam Heath
2004-10-18 17:12                         ` Ingo Molnar
2004-10-18 17:57                       ` Adam Heath
2004-10-18 18:18                         ` Ingo Molnar
2004-10-18 20:58                           ` Adam Heath
2004-10-18 21:06                             ` Ingo Molnar
2004-10-18 21:21                               ` Adam Heath
2004-10-18 18:44                       ` K.R. Foley
2004-10-18 18:49                         ` Ingo Molnar
2004-10-18 19:17                           ` K.R. Foley
2004-10-18 19:32                       ` Bill Huey
2004-10-18 19:34                         ` Bill Huey
2004-10-18 19:36                         ` Ingo Molnar
2004-10-18 19:40                           ` Bill Huey
2004-10-18 19:46                             ` Ingo Molnar
2004-10-18 19:52                               ` Bill Huey
2004-10-19  1:27                       ` Adam Heath
2004-10-19  8:09                       ` Thomas Gleixner
2004-10-19  8:12                       ` Thomas Gleixner
2004-10-19  9:04                         ` Ingo Molnar
2004-10-19  9:03                           ` Thomas Gleixner
2004-10-19  9:34                             ` Ingo Molnar
2004-10-19  9:50                               ` Ingo Molnar
2004-10-19 10:12                               ` Thomas Gleixner
2004-10-19 11:07                                 ` Ingo Molnar
2004-10-19 11:14                                   ` Thomas Gleixner
2004-10-19 10:34                       ` Michal Schmidt
2004-10-19 12:46                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Ingo Molnar
2004-10-19 14:46                         ` Ingo Molnar
2004-10-19 15:23                           ` Rui Nuno Capela
2004-10-19 15:44                             ` Thomas Gleixner
2004-10-19 15:57                               ` Ingo Molnar
2004-10-19 16:44                                 ` Thomas Gleixner
2004-10-19 17:58                                   ` Thomas Gleixner
2004-10-19 18:26                                     ` Ingo Molnar
2004-10-19 20:04                                       ` Thomas Gleixner
2004-10-19 15:50                             ` Ingo Molnar
2004-10-19 16:01                               ` K.R. Foley
2004-10-19 16:20                               ` Ingo Molnar
2004-10-19 16:28                                 ` Ingo Molnar
2004-10-19 16:31                                   ` Ingo Molnar
2004-10-19 17:17                                     ` Ingo Molnar
2004-10-19 16:50                             ` Florian Schmidt
2004-10-19 16:56                               ` Ingo Molnar
2004-10-19 17:49                                 ` Florian Schmidt
2004-10-19 15:48                           ` Thomas Gleixner
2004-10-19 16:26                             ` Ingo Molnar
2004-10-19 16:39                               ` Thomas Gleixner
2004-10-19 17:22                         ` Adam Heath
2004-10-19 17:35                           ` Ingo Molnar
2004-10-19 18:52                             ` Adam Heath
2004-10-19 20:59                               ` Lee Revell
2004-10-19 18:00                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U7 Ingo Molnar
2004-10-19 19:04                           ` Thomas Gleixner
2004-10-19 22:38                             ` Thomas Gleixner
2004-10-19 23:25                             ` Thomas Gleixner
2004-10-19 19:57                           ` Bill Huey
2004-10-23  0:05                             ` Lee Revell
2004-10-19 20:46                           ` Rui Nuno Capela
2004-10-19 21:09                             ` Rui Nuno Capela
2004-10-19 21:30                           ` Rui Nuno Capela
     [not found]                             ` <1098227713.23628.10.camel@krustophenia.net>
     [not found]                               ` <1098228272.12223.1134.camel@thomas>
2004-10-19 23:34                                 ` Lee Revell
2004-10-19 23:38                           ` Fernando Pablo Lopez-Lezcano
2004-10-19 23:39                             ` Thomas Gleixner
2004-10-20  5:02                               ` Thomas Gleixner
2004-10-20  7:40                                 ` Ingo Molnar
2004-10-20  9:57                                   ` Thomas Gleixner
2004-10-20 10:27                                     ` Ingo Molnar
2004-10-20  5:40                           ` Lee Revell
2004-10-20  9:45                           ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8 Ingo Molnar
2004-10-20 10:04                             ` Ingo Molnar
2004-10-20 10:32                               ` Rui Nuno Capela
2004-10-20 10:40                                 ` Ingo Molnar
2004-10-20 11:31                                   ` Rui Nuno Capela
2004-10-20 11:43                                     ` Ingo Molnar
2004-10-20 12:40                                       ` Rui Nuno Capela
2004-10-20 10:38                             ` Michal Schmidt
2004-10-20 10:56                               ` Ingo Molnar
2004-10-20 11:01                                 ` Michal Schmidt
2004-10-20 12:04                                   ` Ingo Molnar
2004-10-20 21:34                                     ` Michal Schmidt
2004-10-21  8:12                                       ` Ingo Molnar
2004-10-21  8:18                                         ` Ingo Molnar
2004-10-21  8:20                                           ` Ingo Molnar
2004-10-20 12:50                             ` Florian Schmidt
2004-10-20 12:55                               ` Ingo Molnar
2004-10-20 13:25                                 ` Florian Schmidt
2004-10-20 13:24                                   ` Ingo Molnar
2004-10-20 14:24                                   ` Florian Schmidt
2004-10-20 14:18                                     ` Ingo Molnar
2004-10-20 14:53                                       ` Florian Schmidt
2004-10-20 15:08                                         ` Florian Schmidt
2004-10-20 15:37                                       ` Lee Revell
2004-10-20 12:52                             ` Lorenzo Allegrucci
2004-10-20 12:56                               ` Ingo Molnar
2004-10-20 16:27                             ` Adam Heath
2004-10-21 16:59                               ` Adam Heath
2004-10-20 17:49                             ` Alexander Batyrshin
2004-10-20 19:02                               ` Adam Heath
2004-10-20 22:35                               ` Daniel Walker
2004-10-22 13:19                               ` Ingo Molnar
2004-10-22 13:48                               ` Ingo Molnar
2004-10-20 21:19                             ` Esben Nielsen
2004-10-21  0:32                             ` Fernando Pablo Lopez-Lezcano
2004-10-21  9:12                             ` Rui Nuno Capela
2004-10-21  9:16                               ` Thomas Gleixner
2004-10-21  9:35                                 ` Christoph Hellwig
2004-10-21  9:44                                   ` Ingo Molnar
2004-10-21  9:47                                     ` Christoph Hellwig
2004-10-21 10:03                                       ` Ingo Molnar
2004-10-21  9:47                                   ` Thomas Gleixner
2004-10-21  9:53                                 ` Jens Axboe
2004-10-21  9:54                                   ` Thomas Gleixner
2004-10-21 10:11                                     ` Jens Axboe
2004-10-21 10:11                                       ` Thomas Gleixner
2004-10-21 10:42                                         ` Ingo Molnar
2004-10-21 11:59                                           ` john cooper
2004-10-21 14:16                                             ` Esben Nielsen
2004-10-21 14:52                                               ` john cooper
2004-10-21 15:47                                                 ` Eugeny S. Mints
2004-10-21 16:49                                                   ` john cooper
2004-10-21 17:33                                                     ` Scott Wood
2004-10-21 18:09                                                       ` john cooper
2004-10-21 18:47                                                         ` Scott Wood
2004-10-21 20:18                                                           ` john cooper
2004-10-21 21:12                                                             ` Scott Wood
2004-10-21 22:15                                                               ` john cooper
2004-10-21 22:30                                                                 ` Scott Wood
2004-10-21 22:55                                                                   ` john cooper
2004-10-21 21:01                                                           ` Esben Nielsen
2004-10-21 21:52                                                             ` Scott Wood
2004-10-22  0:46                                                             ` john cooper
2004-10-21 18:10                                                       ` Eugeny S. Mints
2004-10-21 18:29                                                         ` Scott Wood
2004-10-21 17:54                                                     ` Eugeny S. Mints
2004-10-21 17:41                                                   ` Scott Wood
2004-10-21 11:11                                         ` Jens Axboe
2004-10-21 11:18                                           ` Thomas Gleixner
2004-10-21 10:18                                       ` Ingo Molnar
2004-10-21 10:34                                         ` Jens Axboe
2004-10-21 19:58                                       ` Bill Huey
2004-10-21 20:14                                         ` Jens Axboe
2004-10-21 20:24                                           ` Bill Huey
2004-10-21 20:33                                             ` Jens Axboe
2004-10-21 20:38                                               ` Bill Huey
2004-10-21 20:43                                                 ` Thomas Gleixner
2004-10-21 23:06                                                   ` Bill Huey
2004-10-22  6:24                                                   ` Jens Axboe
2004-10-21 20:49                                                 ` Bill Huey
2004-10-22  6:19                                                 ` Jens Axboe
2004-10-22  7:29                                                   ` Ingo Molnar
2004-10-22  8:01                                                     ` Jens Axboe
2004-10-22  8:13                                                       ` Ingo Molnar
2004-10-22  8:50                                                   ` Bill Huey
2004-10-22  8:59                                                     ` Jens Axboe
2004-10-22  9:06                                                       ` Bill Huey
2004-10-22  9:09                                                         ` Bill Huey
2004-10-22  9:20                                                           ` Jens Axboe
2004-10-22  9:24                                                             ` Bill Huey
2004-10-22  9:31                                                               ` Jens Axboe
2004-10-22  9:17                                                         ` Jens Axboe
2004-10-22  9:23                                                         ` Thomas Gleixner
2004-10-22  9:00                                                     ` Ingo Molnar
2004-10-22 10:21                                                     ` Christoph Hellwig
2004-10-21 22:42                                             ` Timothy Miller
2004-10-21 23:01                                               ` Thomas Gleixner
2004-10-21  9:18                               ` Ingo Molnar
2004-10-21 10:26                                 ` Rui Nuno Capela
2004-10-21 11:20                                   ` Rui Nuno Capela
2004-10-21  9:55                               ` Thomas Gleixner
2004-10-21 13:03                               ` Rui Nuno Capela
2004-10-21 13:41                                 ` Ingo Molnar
2004-10-21 13:53                                   ` Ingo Molnar
2004-10-22 10:15                                 ` Rui Nuno Capela
2004-10-21 13:27                             ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Ingo Molnar
2004-10-21 14:22                               ` Thomas Gleixner
2004-10-21 14:43                                 ` Thomas Gleixner
2004-10-21 15:41                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 HOTFIX Thomas Gleixner
2004-10-21 15:58                                 ` Ingo Molnar
2004-10-21 15:43                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9 Michal Schmidt
2004-10-21 16:00                                 ` Ingo Molnar
2004-10-21 18:06                               ` Gunther Persoons
2004-10-21 16:40                                 ` Ingo Molnar
2004-10-21 17:54                                   ` Nikita Danilov
2004-10-22 10:22                                     ` Ingo Molnar
2004-10-22 11:50                                       ` Nikita Danilov
2004-10-22 11:57                                         ` Ingo Molnar
2004-10-22 12:27                                           ` Nikita Danilov
2004-10-22 12:42                                             ` Ingo Molnar
2004-10-21 20:21                                   ` Gunther Persoons
2004-10-21 18:07                               ` K.R. Foley
2004-10-21 18:40                                 ` Thomas Gleixner
2004-10-21 18:57                                   ` K.R. Foley
2004-10-21 18:57                                     ` Thomas Gleixner
2004-10-21 19:25                                       ` K.R. Foley
2004-10-22 14:12                                       ` K.R. Foley
2004-10-22 14:43                                         ` Thomas Gleixner
2004-10-22 15:15                                           ` K.R. Foley
2004-10-22 15:57                                             ` Thomas Gleixner
2004-10-22 16:51                                               ` Ingo Molnar
2004-10-22 17:44                                               ` K.R. Foley
2004-10-21 19:09                                   ` K.R. Foley
2004-10-22 11:54                                 ` Ingo Molnar
2004-10-21 18:34                               ` Adam Heath
2004-10-21 20:06                               ` Michal Schmidt
2004-10-22 13:35                               ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3 Ingo Molnar
2004-10-22 15:50                                 ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10 Ingo Molnar
2004-10-22 16:47                                   ` Gene Heskett
2004-10-22 16:51                                     ` Ingo Molnar
2004-10-22 16:19                                       ` Jeff V. Merkey
2004-10-22 17:27                                         ` Russell Miller
2004-10-22 16:48                                           ` Jeff V. Merkey
2004-10-22 21:47                                         ` Gene Heskett
2004-10-22 17:56                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Ingo Molnar
2004-10-22 21:49                                     ` Gene Heskett
2004-10-22 22:06                                       ` Lee Revell
2004-10-22 22:30                                         ` Lee Revell
2004-10-23 10:36                                         ` Ingo Molnar
2004-10-25  0:33                                           ` john cooper
2004-10-25 10:09                                             ` remi.colinet
2004-10-25 13:35                                               ` john cooper
2004-10-22 22:38                                     ` K.R. Foley
2004-10-23 10:32                                       ` Ingo Molnar
2004-10-23 14:03                                         ` K.R. Foley
2004-10-23  0:27                                     ` Rui Nuno Capela
2004-10-23  0:41                                       ` Fernando Pablo Lopez-Lezcano
2004-10-23 10:29                                       ` Ingo Molnar
2004-10-23 12:30                                         ` Rui Nuno Capela
2004-10-23 12:51                                           ` Ingo Molnar
2004-10-23 13:45                                             ` Rui Nuno Capela
2004-10-23 13:54                                               ` Ingo Molnar
2004-10-23 20:59                                                 ` Rui Nuno Capela
2004-10-23  1:15                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.3 Thomas Gleixner
2004-10-23 18:51                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10.2 Paul E. McKenney
2004-10-23 19:14                                       ` Lee Revell
2004-10-23 19:31                                         ` Thomas Gleixner
2004-10-23 20:24                                       ` Ingo Molnar
2004-10-23 21:12                                         ` Paul E. McKenney
2004-10-24 15:19                                     ` Gunther Persoons
2004-10-25 10:40                                     ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0 Ingo Molnar
2004-10-25 11:08                                       ` K.R. Foley
2004-10-25 11:10                                         ` Ingo Molnar
2004-10-25 11:13                                           ` K.R. Foley
2004-10-25 12:12                                           ` Ingo Molnar
2004-10-25 13:24                                             ` Florian Schmidt
2004-10-25 13:26                                               ` Ingo Molnar
2004-10-25 14:03                                                 ` Florian Schmidt
2004-10-25 14:10                                                   ` Ingo Molnar
2004-10-25 14:16                                                     ` Ingo Molnar
2004-10-25 19:40                                                       ` Rui Nuno Capela
2004-10-26  3:01                                                         ` Lee Revell
2004-10-26  3:11                                                           ` K.R. Foley
2004-10-26  3:58                                                             ` Lee Revell
2004-10-26  4:15                                                               ` K.R. Foley
2004-10-26  5:11                                                           ` Fernando Pablo Lopez-Lezcano
2004-10-26 17:25                                                             ` Lee Revell
2004-10-26 17:45                                                               ` Fernando Pablo Lopez-Lezcano
2004-10-26 17:55                                                                 ` Lee Revell
2004-10-26  5:28                                                         ` Denis Vlasenko
2004-10-26 10:40                                                           ` Rui Nuno Capela
2004-10-26 19:09                                                             ` Denis Vlasenko
2004-10-27  8:23                                                               ` Rui Nuno Capela
2004-10-25 15:06                                                     ` Florian Schmidt
2004-10-25 16:45                                                       ` K.R. Foley
2004-10-26  8:29                                                         ` Eran Mann
2004-10-25 13:39                                             ` Florian Schmidt
2004-10-25 13:48                                               ` Florian Schmidt
2004-10-25 13:35                                                 ` Ingo Molnar
2004-10-25 18:52                                       ` K.R. Foley
2004-10-25 20:38                                         ` Ingo Molnar
2004-10-26 10:53                                           ` K.R. Foley
2004-10-26 10:57                                             ` Ingo Molnar
2004-10-27  0:24                                             ` Ingo Molnar
2004-10-27  0:53                                               ` K.R. Foley
2004-10-27  3:32                                               ` K.R. Foley
2004-10-27  8:28                                                 ` Ingo Molnar
2004-10-27  8:44                                                   ` Ingo Molnar
2004-10-27  8:52                                                     ` Ingo Molnar
2004-10-27  9:06                                                       ` Ingo Molnar
2004-10-27 10:03                                                         ` Ingo Molnar
2004-10-27 10:33                                                         ` Florian Schmidt
2004-10-27 10:29                                                           ` Ingo Molnar
2004-10-27 10:58                                                             ` Florian Schmidt
2004-10-27 10:45                                                           ` Florian Schmidt
2004-10-27 11:09                                                             ` Ingo Molnar
2004-10-27  9:24                                                 ` Ingo Molnar
2004-10-27  9:32                                                   ` Ingo Molnar
2004-10-27 12:19                                                     ` K.R. Foley
2004-10-27 13:29                                                 ` Ingo Molnar
2004-10-27 15:00                                                   ` K.R. Foley
2004-10-27 15:05                                                     ` Ingo Molnar
2004-10-27 15:13                                                       ` Lee Revell
2004-10-27 15:17                                                         ` Ingo Molnar
2004-10-27 17:14                                                           ` Lee Revell
2004-10-27 17:21                                                             ` K.R. Foley
2004-10-27 17:26                                                               ` Lee Revell
2004-10-27 17:40                                                                 ` K.R. Foley
2004-10-27 17:44                                                                   ` Lee Revell
2004-10-27 17:43                                                                 ` K.R. Foley
2004-10-27 19:47                                                                   ` Lee Revell
2004-10-27 21:40                                                                     ` K.R. Foley
2004-10-27 20:09                                                           ` Andrew Morton
2004-10-27 21:43                                                             ` K.R. Foley
2004-10-27 15:16                                                       ` K.R. Foley
2004-10-27 20:49                                                       ` Bill Huey
2004-10-27 20:54                                                         ` Bill Huey
2004-10-27 21:01                                                           ` Bill Huey
2004-10-28  7:11                                                             ` Ingo Molnar
2004-10-27  3:48                                               ` K.R. Foley
2004-10-25 21:41                                         ` Esben Nielsen
2004-10-25 21:47                                       ` Michal Schmidt
2004-10-25 23:04                                       ` Remi Colinet
2004-10-27  0:15                                       ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Ingo Molnar
2004-10-27  0:44                                         ` Ingo Molnar
2004-10-27  1:43                                         ` Bill Huey
2004-10-27  2:04                                           ` K.R. Foley
2004-10-27  3:29                                             ` Bill Huey
2004-10-27  3:35                                               ` K.R. Foley
2004-10-27  3:40                                                 ` Bill Huey
2004-10-27 10:50                                         ` Michal Schmidt
2004-10-27 13:48                                           ` Ingo Molnar
2004-10-27 17:25                                             ` Michal Schmidt
2004-10-28 11:57                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 Ingo Molnar
2004-10-30  0:02                                                 ` Bill Huey
2004-10-30 11:46                                                   ` Ingo Molnar
2004-11-02  8:56                                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5 (networking problems) Bill Huey
2004-11-02  9:37                                                     ` Ingo Molnar
2004-11-02 11:08                                                       ` Bill Huey
2004-11-02 11:45                                                         ` Ingo Molnar
2004-11-02 12:02                                                           ` Ingo Molnar
2004-11-02 17:34                                                             ` Karsten Wiese
2004-11-02 13:35                                                           ` Ingo Molnar
2004-11-02 22:08                                                           ` Bill Huey
2004-10-27 12:43                                         ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3 Rui Nuno Capela
2004-10-27 13:53                                           ` Ingo Molnar
2004-10-27 15:26                                             ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4 Rui Nuno Capela
2004-10-27 15:30                                               ` Lee Revell
2004-10-27 17:39                                                 ` Rui Nuno Capela
2004-10-27 18:57                                                   ` karsten wiese
2004-10-27 20:28                                                     ` Rui Nuno Capela
2004-10-27 18:59                                                   ` karsten wiese
2004-10-27 20:01                                               ` Ingo Molnar
2004-10-27 20:51                                               ` Ingo Molnar
2004-10-27 21:19                                                 ` Ingo Molnar
2004-10-27 23:31                                                   ` Rui Nuno Capela
2004-10-28  6:36                                                     ` Ingo Molnar
2004-10-28  8:31                                                       ` Rui Nuno Capela
2004-10-28  8:56                                                         ` Ingo Molnar
2004-10-28  9:17                                                           ` Rui Nuno Capela
2004-10-28  9:32                                                             ` Ingo Molnar
2004-10-28 13:57                                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.5.2 Ingo Molnar
2004-10-28 14:10                                                                 ` DaMouse
2004-10-28 14:18                                                                   ` Ingo Molnar
2004-10-28 16:33                                                               ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4 Rui Nuno Capela
2004-10-28 19:16                                                                 ` Ingo Molnar
2004-10-28 23:49                                                                   ` Rui Nuno Capela
2004-10-29  0:07                                                                     ` Lee Revell
2004-10-29  7:30                                                                     ` Ingo Molnar
2004-10-29 15:00                                                                       ` Rui Nuno Capela
2004-10-29 17:57                                                                         ` Lee Revell
2004-10-29 14:31                                                                 ` Florian Schmidt
2004-10-29 14:25                                                                   ` Ingo Molnar
2004-10-29 15:09                                                                     ` Florian Schmidt
2004-10-29 14:53                                                                   ` Florian Schmidt
2004-10-30  3:09                                                                   ` Lee Revell
2004-10-30  3:22                                                                     ` Joe
2004-10-27 13:03                                         ` Ingo Molnar
2004-10-27 21:41                                           ` Magnus Naeslund(t)
2004-10-28  6:55                                             ` Ingo Molnar
2004-10-28  9:31                                               ` Magnus Naeslund(t)
2004-10-28  6:58                                             ` Ingo Molnar
2004-10-28 14:14                                           ` K.R. Foley
2004-10-28 14:20                                             ` Ingo Molnar
2004-11-03 10:58                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1 Ingo Molnar
2004-11-03 13:44                                           ` Lorenzo Allegrucci
2004-11-03 13:46                                             ` Ingo Molnar
2004-11-03 17:53                                               ` Lorenzo Allegrucci
2004-11-03 20:41                                                 ` Lorenzo Allegrucci
2004-11-03 20:43                                                   ` Ingo Molnar
2004-11-03 21:05                                                     ` Lorenzo Allegrucci
2004-11-03 19:33                                           ` john cooper
2004-11-03 23:03                                           ` Magnus Naeslund(t)
2004-11-04  6:56                                             ` Ingo Molnar
2004-11-04 19:34                                           ` Gunther Persoons
2004-11-04 20:31                                             ` Chris Friesen
2004-11-06 15:57                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.18 Ingo Molnar
2004-11-06 17:17                                             ` Gunther Persoons
2004-11-06 19:25                                               ` Lorenzo Allegrucci
2004-11-06 17:55                                             ` Rui Nuno Capela
2004-11-06 18:56                                               ` Peter Zijlstra
2004-11-06 22:52                                             ` Rui Nuno Capela
2004-11-07 22:22                                             ` Karsten Wiese
2004-11-08  8:21                                               ` Ingo Molnar
2004-11-08  7:50                                             ` Eran Mann
2004-11-08  9:45                                               ` Ingo Molnar
2004-11-08  9:16                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19 Ingo Molnar
2004-11-08  9:15                                               ` Karsten Wiese
2004-11-08 10:19                                                 ` Ingo Molnar
2004-11-08 12:42                                                   ` Karsten Wiese
2004-11-08 10:24                                                 ` Ingo Molnar
2004-11-08  9:50                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.20 Ingo Molnar
2004-11-08 13:13                                                 ` Lorenzo Allegrucci
2004-11-08 14:15                                                 ` Rui Nuno Capela
2004-11-08 16:17                                                 ` Florian Schmidt
2004-11-08 16:57                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.21 Ingo Molnar
2004-11-08 17:41                                                 ` Gunther Persoons
2004-11-08 23:41                                                   ` Ingo Molnar
2004-11-08 17:59                                                 ` Norberto Bensa
2004-11-08 19:01                                                   ` K.R. Foley
2004-11-08 23:42                                                     ` Ingo Molnar
2004-11-09 16:05                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.23 Ingo Molnar
2004-11-10 13:52                                                   ` Karsten Wiese
2004-11-10 13:58                                                     ` Karsten Wiese
2004-11-10 15:01                                                     ` Ingo Molnar
2004-11-10 14:20                                                       ` Karsten Wiese
2004-11-10 14:50                                                         ` Karsten Wiese
2004-11-10 15:33                                                         ` Ingo Molnar
2004-11-11  4:34                                                   ` K.R. Foley
2004-11-11  5:01                                                   ` K.R. Foley
2004-11-11  9:52                                                     ` Ingo Molnar
2004-11-11 10:20                                                     ` Ingo Molnar
2004-11-11 13:05                                                       ` Ingo Molnar
2004-11-11 12:27                                                         ` K.R. Foley
2004-11-11 14:44                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-0 Ingo Molnar
2004-11-11 16:03                                                     ` Gunther Persoons
2004-11-11 16:08                                                       ` Ingo Molnar
2004-11-11 16:12                                                         ` Ingo Molnar
2004-11-11 16:25                                                           ` Gunther Persoons
2004-11-11 16:30                                                           ` Ingo Molnar
2004-11-11 17:36                                                             ` Gunther Persoons
2004-11-11 16:16                                                         ` Gunther Persoons
2004-11-11 20:56                                                     ` Remi Colinet
2004-11-11 18:12                                                       ` K.R. Foley
2004-11-11 18:42                                                       ` K.R. Foley
2004-11-11 21:41                                                         ` Ingo Molnar
2004-11-12  3:49                                                         ` Remi Colinet
2004-11-11 21:38                                                     ` Ingo Molnar
2004-11-11 21:51                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.25-1 Ingo Molnar
2004-11-12  4:08                                                       ` Bill Huey
2004-11-12  5:03                                                         ` Bill Huey
2004-11-12  8:39                                                           ` Ingo Molnar
2004-11-12 10:52                                                             ` Bill Huey
2004-11-12 14:31                                                       ` Shane Shrybman
2004-11-12 17:27                                                         ` K.R. Foley
2004-11-12 17:50                                                           ` Shane Shrybman
2004-11-12 20:13                                                         ` Ingo Molnar
2004-11-12 22:15                                                           ` Shane Shrybman
2004-11-12 23:44                                                           ` Shane Shrybman
2004-11-14 12:51                                                             ` Ingo Molnar
2004-11-12 19:48                                                       ` Gunther Persoons
2004-11-12 20:19                                                         ` Ingo Molnar
2004-11-13 12:55                                                           ` Gunther Persoons
2004-11-13 14:36                                                           ` Gunther Persoons
2004-11-14 12:49                                                             ` Ingo Molnar
2004-11-14 14:25                                                               ` Gunther Persoons
2004-11-13 23:12                                                           ` Gunther Persoons
2004-11-14 12:38                                                             ` Ingo Molnar
2004-11-14 12:56                                                       ` Florian Schmidt
2004-11-14 13:26                                                         ` K.R. Foley
2004-11-14 13:35                                                           ` Florian Schmidt
2004-11-14 13:56                                                           ` K.R. Foley
2004-11-14 14:11                                                           ` Florian Schmidt
2004-11-14 14:15                                                         ` Ingo Molnar
2004-11-15  1:27                                                           ` Florian Schmidt
2004-11-15  2:22                                                             ` K.R. Foley
2004-11-15 15:15                                                           ` Florian Schmidt
2004-11-15 14:33                                                       ` Rui Nuno Capela
2004-11-15 15:40                                                         ` Ingo Molnar
2004-11-15 16:11                                                         ` Ingo Molnar
2004-11-15 16:52                                                           ` Rui Nuno Capela
     [not found]                                                           ` <33583.195.245.190.93.1100537554.squirrel@195.245.190.93>
2004-11-15 22:35                                                             ` Rui Nuno Capela
2004-11-16 10:41                                                               ` Ingo Molnar
2004-11-16 12:05                                                                 ` Rui Nuno Capela
2004-11-16 13:16                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-2 Ingo Molnar
2004-11-16 12:54                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-0 Ingo Molnar
2004-11-16 13:09                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-1 Ingo Molnar
2004-11-16 13:40                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3 Ingo Molnar
2004-11-16 14:20                                                             ` Florian Schmidt
2004-11-16 15:08                                                               ` Florian Schmidt
2004-11-16 15:29                                                                 ` Florian Schmidt
2004-11-16 15:52                                                                   ` Stefan Schweizer
2004-11-16 18:43                                                             ` Marcos D. Marado Torres
2004-11-16 18:51                                                               ` Lee Revell
2004-11-16 19:53                                                               ` Ingo Molnar
2004-11-17  0:36                                                             ` Bill Huey
2004-11-17 12:42                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 Ingo Molnar
2004-11-17 18:18                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-10 Adam Heath
2004-11-18 15:44                                                                 ` Ingo Molnar
2004-11-18  2:38                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 K.R. Foley
2004-11-18  9:57                                                                 ` Ingo Molnar
2004-11-18 10:24                                                               ` Christian Meder
2004-11-18 16:11                                                                 ` Ingo Molnar
2004-11-18 15:58                                                                   ` Christian Meder
2004-11-18 16:39                                                                   ` Christian Meder
2004-11-18 19:58                                                                     ` Ingo Molnar
2004-11-18 19:51                                                                       ` Adam Heath
2004-11-18 12:35                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-1 Ingo Molnar
2004-11-18 12:23                                                                 ` Florian Schmidt
2004-11-18 14:46                                                                 ` Rui Nuno Capela
2004-11-18 20:01                                                                   ` Ingo Molnar
2004-11-18 20:49                                                                   ` Ingo Molnar
2004-11-18 21:05                                                                   ` Ingo Molnar
2004-11-18 22:54                                                                     ` Christian Meder
2004-11-19  9:54                                                                       ` Ingo Molnar
2004-11-22  9:31                                                                         ` Christian Meder
2004-11-22  9:44                                                                           ` Bill Huey
2004-11-22 13:19                                                                             ` Ingo Molnar
2004-11-22 13:05                                                                           ` Ingo Molnar
2004-11-22 13:32                                                                             ` Christian Meder
2004-11-22 14:38                                                                               ` Ingo Molnar
2004-11-18 21:50                                                                   ` Lee Revell
2004-11-19  9:56                                                                     ` Ingo Molnar
2004-11-19 15:44                                                                       ` Shane Shrybman
2004-11-20 13:17                                                                         ` Ingo Molnar
2004-11-18 15:23                                                                 ` Christian Meder
2004-11-18 15:37                                                                   ` Jan Engelhardt
2004-11-18 20:06                                                                   ` [patch] " Ingo Molnar
2004-11-18 16:46                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 Ingo Molnar
2004-11-18 21:27                                                                   ` Michal Schmidt
2004-11-19 10:05                                                                     ` Ingo Molnar
2004-11-19 14:11                                                                       ` Steven Rostedt
2004-11-19 17:08                                                                         ` K.R. Foley
2004-11-21 21:50                                                                           ` Ingo Molnar
2004-11-19 19:05                                                                   ` Peter Zijlstra
2004-11-20 13:13                                                                     ` Ingo Molnar
2004-11-20  3:22                                                                   ` Lee Revell
2004-11-20 11:50                                                                     ` Florian Schmidt
2004-11-20 12:59                                                                       ` Ingo Molnar
2004-11-20 12:55                                                                     ` Ingo Molnar
2004-11-20 17:19                                                                       ` Lee Revell
2004-11-20 19:14                                                                         ` Ingo Molnar
2004-11-20 18:35                                                                           ` Lee Revell
2004-11-20 19:11                                                                             ` Florian Schmidt
2004-11-20 20:40                                                                               ` Florian Schmidt
2004-11-21 12:45                                                                                 ` Ingo Molnar
2004-11-21 14:32                                                                                   ` Ingo Molnar
2004-11-21 14:49                                                                                   ` Florian Schmidt
2004-11-21 12:50                                                                                 ` Ingo Molnar
2004-11-21 14:50                                                                                   ` Florian Schmidt
2004-11-21 12:54                                                                                 ` Ingo Molnar
2004-11-21 13:43                                                                                   ` Ingo Molnar
2004-11-21 15:05                                                                                     ` Florian Schmidt
2004-11-21 14:52                                                                                   ` Florian Schmidt
2004-11-21 15:12                                                                               ` Ingo Molnar
2004-11-21 15:18                                                                                 ` Ingo Molnar
2004-11-21 14:44                                                                                   ` Florian Schmidt
2004-11-21 15:28                                                                                 ` Florian Schmidt
2004-11-20 19:09                                                                           ` Lee Revell
2004-11-21 12:47                                                                             ` Ingo Molnar
2004-11-21 13:27                                                                               ` Ingo Molnar
2004-11-21 13:32                                                                                 ` Ingo Molnar
2004-11-21  0:32                                                                           ` Lee Revell
2004-11-24 12:15                                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-1 Ingo Molnar
2004-11-24 12:28                                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-2 Ingo Molnar
2004-11-20 20:23                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0 K.R. Foley
2004-11-20 20:51                                                                     ` K.R. Foley
2004-11-22  0:54                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2 Ingo Molnar
2004-11-22  1:07                                                                     ` Florian Schmidt
2004-11-22  9:46                                                                       ` Ingo Molnar
2004-11-22 10:36                                                                         ` Rui Nuno Capela
2004-11-22 13:24                                                                           ` Ingo Molnar
2004-11-22 12:56                                                                             ` Rui Nuno Capela
2004-11-22 15:00                                                                               ` Ingo Molnar
2004-11-22 15:10                                                                                 ` Ingo Molnar
2004-11-22 15:20                                                                                   ` Ingo Molnar
2004-11-22 13:27                                                                             ` Florian Schmidt
2004-11-22 14:18                                                                               ` Rui Nuno Capela
2004-11-22 15:41                                                                                 ` Ingo Molnar
2004-11-22 15:45                                                                                 ` Ingo Molnar
2004-11-22 16:53                                                                                   ` Rui Nuno Capela
2004-11-23 13:55                                                                                     ` Ingo Molnar
2004-11-23 13:56                                                                                       ` Ingo Molnar
2004-11-23 13:58                                                                                       ` Ingo Molnar
2004-11-23 14:11                                                                                         ` Ingo Molnar
2004-11-23 14:32                                                                                           ` Ingo Molnar
2004-11-23 14:41                                                                                             ` Ingo Molnar
2004-11-23 14:00                                                                                       ` Rui Nuno Capela
2004-11-23 15:41                                                                                         ` Ingo Molnar
2004-11-23 16:53                                                                                           ` Rui Nuno Capela
2004-11-23 18:00                                                                                             ` Ingo Molnar
2004-11-23 14:46                                                                                     ` Ingo Molnar
2004-11-23 13:57                                                                                       ` Florian Schmidt
2004-11-23 15:05                                                                                         ` Ingo Molnar
2004-11-23 15:21                                                                                         ` Ingo Molnar
2004-11-23 14:41                                                                                           ` Florian Schmidt
2004-12-01 13:57                                                                                             ` Paul Davis
2004-12-01 14:37                                                                                               ` Ingo Molnar
2004-12-01 14:56                                                                                                 ` Paul Davis
2004-12-01 15:53                                                                                                   ` Ingo Molnar
2004-12-01 16:05                                                                                                     ` Paul Davis
2004-12-01 16:16                                                                                                     ` Esben Nielsen
2004-12-01 21:24                                                                                                       ` Ingo Molnar
2004-12-01 21:40                                                                                                         ` Chris Friesen
2004-12-01 16:08                                                                                                   ` Esben Nielsen
2004-11-23 14:53                                                                                       ` Ingo Molnar
2004-11-22  8:44                                                                     ` Eran Mann
2004-11-22 10:01                                                                       ` Ingo Molnar
2004-11-22 13:34                                                                         ` Eran Mann
2004-11-22 14:42                                                                           ` Ingo Molnar
2004-11-23  8:24                                                                             ` Eran Mann
2004-11-23 17:58                                                                     ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Ingo Molnar
2004-11-23 17:53                                                                       ` K.R. Foley
2004-11-23 18:01                                                                       ` K.R. Foley
2004-11-24  0:28                                                                       ` Florian Schmidt
2004-11-24  3:19                                                                         ` Ingo Molnar
2004-11-24  2:48                                                                           ` Florian Schmidt
2004-11-24  0:58                                                                       ` Lee Revell
2004-11-24  3:45                                                                         ` Ingo Molnar
2004-11-24 13:33                                                                           ` Steven Rostedt
2004-11-24 15:23                                                                             ` kernel builds starving evolution process - scheduler issue? (was Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9) Lee Revell
2004-11-24 10:16                                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-10 Ingo Molnar
2004-11-24 11:27                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-0 Ingo Molnar
2004-11-24 19:43                                                                           ` Gene Heskett
2004-11-25 10:03                                                                           ` Rui Nuno Capela
2004-11-25 11:13                                                                             ` Ingo Molnar
2004-11-25 10:38                                                                               ` Rui Nuno Capela
2004-11-25 11:44                                                                                 ` Ingo Molnar
2004-11-25 10:47                                                                                   ` Rui Nuno Capela
2004-11-25 11:17                                                                               ` Ingo Molnar
2004-11-25 12:01                                                                             ` Ingo Molnar
2004-11-25 11:14                                                                               ` Rui Nuno Capela
2004-11-25 12:20                                                                                 ` Ingo Molnar
2004-11-25 14:33                                                                               ` [patch, 2.6.10-rc2] floppy boot-time detection fix Ingo Molnar
2004-11-25 14:44                                                                                 ` Ingo Molnar
2004-11-25 14:48                                                                                 ` Ingo Molnar
2004-11-25 15:27                                                                                   ` Ingo Molnar
2004-11-25 15:00                                                                                 ` Arjan van de Ven
2004-12-03 20:58                                                                         ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.32-0 Ingo Molnar
2004-12-03 21:04                                                                           ` Ingo Molnar
2004-12-04 22:32                                                                           ` Rui Nuno Capela
2004-12-04 22:46                                                                             ` Ingo Molnar
2004-12-04 23:38                                                                               ` Rui Nuno Capela
2004-12-04 23:55                                                                               ` K.R. Foley
2004-12-05  3:10                                                                                 ` Gene Heskett
2004-12-05  3:05                                                                             ` Gene Heskett
2004-12-05 23:14                                                                           ` Esben Nielsen
2004-12-06 13:14                                                                             ` Ingo Molnar
2004-12-06 15:01                                                                               ` Esben Nielsen
2004-12-06 15:27                                                                                 ` Ingo Molnar
2004-12-07 13:29                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-4 Ingo Molnar
2004-12-07 14:11                                                                             ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 Ingo Molnar
2004-12-08  4:31                                                                               ` K.R. Foley
2004-12-08  8:34                                                                                 ` Ingo Molnar
2004-12-08 16:07                                                                                   ` K.R. Foley
2004-12-08 16:18                                                                                     ` Lee Revell
2004-12-08 16:52                                                                                       ` K.R. Foley
2004-12-08 16:58                                                                                         ` Lee Revell
2004-12-09  9:02                                                                                         ` Ingo Molnar
2004-12-09  2:45                                                                                     ` K.R. Foley
2004-12-09 12:11                                                                                       ` Ingo Molnar
2004-12-09 14:50                                                                                         ` K.R. Foley
2004-12-08 17:13                                                                               ` Steven Rostedt
2004-12-08 18:14                                                                                 ` Rui Nuno Capela
2004-12-08 19:03                                                                                   ` Steven Rostedt
2004-12-08 21:39                                                                                     ` Rui Nuno Capela
2004-12-08 22:11                                                                                       ` Steven Rostedt
2004-12-09  9:32                                                                                         ` Ingo Molnar
2004-12-09 13:13                                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-12 Ingo Molnar
2004-12-09 14:23                                                                                             ` Gene Heskett
2004-12-09 14:33                                                                                             ` Steven Rostedt
2004-12-09 19:19                                                                                               ` Steven Rostedt
2004-12-09 20:33                                                                                                 ` john cooper
2004-12-09 22:19                                                                                                   ` Steven Rostedt
2004-12-09 23:10                                                                                                     ` john cooper
2004-12-09 22:10                                                                                                 ` Ingo Molnar
2004-12-10  6:11                                                                                                   ` Steven Rostedt
2004-12-10 11:05                                                                                                     ` Ingo Molnar
2004-12-10 11:11                                                                                                     ` Ingo Molnar
2004-12-10 16:32                                                                                                       ` K.R. Foley
2004-12-10 18:02                                                                                                         ` Steven Rostedt
2004-12-11  2:26                                                                                                       ` Steven Rostedt
2004-12-11  3:01                                                                                                         ` Steven Rostedt
2004-12-11  7:37                                                                                                         ` Fernando Lopez-Lezcano
2004-12-11 12:30                                                                                                           ` Steven Rostedt
2004-12-13 23:34                                                                                                             ` Fernando Lopez-Lezcano
2004-12-15  9:51                                                                                                               ` Ingo Molnar
2004-12-11  9:57                                                                                                         ` Ingo Molnar
2004-12-09 14:43                                                                                             ` Rui Nuno Capela
2004-12-09 13:36                                                                                           ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6 Steven Rostedt
2004-12-09  9:06                                                                                 ` Ingo Molnar
2004-12-14 13:28                                                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc3-mm1-V0.7.33-0 Ingo Molnar
2004-12-14 19:34                                                                                 ` Steven Rostedt
2004-12-14 20:08                                                                                   ` Lee Revell
2004-12-14 20:45                                                                                     ` Steven Rostedt
2004-12-14 21:18                                                                                       ` Ingo Molnar
2004-12-14 21:47                                                                                         ` Lee Revell
2004-12-14 21:51                                                                                           ` Ingo Molnar
2004-12-14 21:57                                                                                             ` Lee Revell
2004-12-14 21:52                                                                                         ` George Anzinger
2004-12-14 21:59                                                                                           ` Steven Rostedt
2004-12-14 22:28                                                                                           ` Ingo Molnar
2004-12-14 22:13                                                                                         ` Lee Revell
2004-12-14 22:31                                                                                           ` Ingo Molnar
2004-12-14 22:47                                                                                             ` Lee Revell
2004-12-14 22:57                                                                                               ` Paul Davis
2004-12-15  9:32                                                                                                 ` Ingo Molnar
2004-12-15 16:23                                                                                                   ` Lee Revell
2004-12-14 23:18                                                                                               ` linux-os
2004-12-15  1:53                                                                                                 ` Paul Davis
2004-12-15  2:49                                                                                                 ` Gene Heskett
2004-12-15  2:38                                                                                             ` Gene Heskett
2004-12-15 15:24                                                                                               ` K.R. Foley
2004-12-15 16:34                                                                                                 ` Gene Heskett
2004-12-15 16:38                                                                                                   ` K.R. Foley
2004-12-14 20:07                                                                                 ` Fernando Lopez-Lezcano
2004-12-14 20:35                                                                                   ` Ingo Molnar
2004-12-14 23:21                                                                                 ` Fernando Lopez-Lezcano
2004-12-15  0:43                                                                                   ` Florian Schmidt
2004-12-15  1:09                                                                                   ` Lee Revell
2004-12-15  2:04                                                                                     ` Fernando Lopez-Lezcano
2004-12-15  9:09                                                                                       ` Ingo Molnar
2004-12-15 10:17                                                                                         ` Andrew Walrond
2004-12-15 16:51                                                                                         ` Lee Revell
2004-12-17  0:45                                                                                   ` Fernando Lopez-Lezcano
2004-12-15 20:52                                                                                 ` Magnus Määttä
2005-01-04  6:40                                                                                 ` Bill Huey
2005-01-04  9:45                                                                                   ` [patch] Real-Time Preemption, -RT-2.6.10-mm1-V0.7.34-00 Ingo Molnar
2005-01-04 10:48                                                                                     ` Bill Huey
2005-01-04 10:52                                                                                       ` Ingo Molnar
2005-01-04 10:55                                                                                     ` Felipe Alfaro Solana
2005-01-06 18:45                                                                                     ` Florian Schmidt
2005-01-07 19:26                                                                                     ` Tom Rini
2005-01-07 19:36                                                                                       ` Lee Revell
2005-01-26  8:09                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04 Ingo Molnar
2005-02-01 20:01                                                                                         ` Lee Revell
2005-02-01 20:17                                                                                           ` Ingo Molnar
2005-02-01 20:31                                                                                             ` Lee Revell
2005-02-01 20:44                                                                                               ` Ingo Molnar
2005-02-01 23:45                                                                                                 ` Lee Revell
2005-02-02  7:06                                                                                                   ` Ingo Molnar
2005-01-15 13:34                                                                                     ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00 Ingo Molnar
2005-01-15 15:16                                                                                       ` K.R. Foley
2005-01-15 19:29                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-01 Gene Heskett
2005-01-21 20:34                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc1-V0.7.35-00 K.R. Foley
2005-01-22 12:29                                                                                       ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00 Ingo Molnar
2005-01-22 21:22                                                                                         ` Gene Heskett
2005-01-23  9:27                                                                                           ` andyliu
2005-01-23 11:31                                                                                             ` Ingo Molnar
2005-01-23 14:40                                                                                               ` Gene Heskett
2005-01-24  1:01                                                                                                 ` andyliu
2005-01-24  2:54                                                                                                   ` Gene Heskett
2005-01-24  8:02                                                                                           ` Ingo Molnar
2005-01-24 10:42                                                                                             ` Gene Heskett
2005-01-26  1:05                                                                                             ` Lee Revell
2005-02-01 20:14                                                                                         ` [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02 Ingo Molnar
2005-02-03 20:53                                                                                           ` Eugeny S. Mints
2005-02-03 20:55                                                                                             ` Ingo Molnar
2005-02-04  1:51                                                                                           ` Steven Rostedt
2005-02-04  2:18                                                                                             ` Steven Rostedt
2005-02-05  6:02                                                                                               ` Steven Rostedt
2005-02-05  7:59                                                                                                 ` Ingo Molnar
2005-02-05 14:32                                                                                                   ` Steven Rostedt
2005-02-07  9:22                                                                                                     ` Ingo Molnar
2004-11-24 19:23                                                                       ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Fernando Lopez-Lezcano
2004-11-24 22:17                                                                         ` Ingo Molnar
2004-11-24 21:56                                                                           ` Fernando Lopez-Lezcano
     [not found]                                                               ` <1100732223.3472.10.camel@localhost>
2004-11-18 15:54                                                                 ` [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0 Ingo Molnar
2004-11-18 15:07                                                                   ` Christian Meder
2004-11-18 20:42                                                                     ` Ingo Molnar
2004-11-18 22:41                                                                       ` Christian Meder
2004-11-18 22:33                                                                   ` Christian Meder
2004-11-08 22:21                                               ` [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm3-V0.7.19 Adam Heath
2004-10-22 21:44                                   ` [patch] Real-Time Preemption, -RT-2.6.9-mm1-U10 Gene Heskett
2004-10-22 18:41                                 ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U9.3 Alexander Batyrshin
2004-10-22 20:08                                   ` Ingo Molnar
2004-10-19 18:54                         ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 Adam Heath
2004-10-19 20:52                         ` Michal Schmidt
2004-10-20 16:31                         ` Adam Heath
2004-10-19 12:57                       ` [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U5 Kevin Hilman
2004-10-19 13:04                         ` Ingo Molnar
2004-10-15 11:22               ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1 Florian Schmidt
2004-10-15 11:44                 ` Ingo Molnar
2004-10-15 12:25                   ` Florian Schmidt
2004-10-14 18:52             ` [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0 Daniel Walker
2004-10-14 19:28               ` Ingo Molnar
2004-10-14 19:43                 ` Dipankar Sarma
2004-10-14 20:30               ` Bill Huey
2004-10-14 20:02             ` Daniel Walker
2004-10-14 20:23               ` Ingo Molnar
2004-10-14 22:13             ` Radoslaw Szkodzinski
2004-10-14 22:40             ` Karim Yaghmour
2004-10-14 23:46               ` Ingo Molnar
2004-10-15  0:07                 ` Karim Yaghmour
2004-10-15  0:31                   ` Roland Dreier
2004-10-15  1:22                     ` Karim Yaghmour
2004-10-15  2:00                     ` Robert Wisniewski
2004-10-15  2:21                       ` Lee Revell
2004-10-15 12:27                         ` Robert Wisniewski
2004-10-15  6:59                   ` Ingo Molnar
2004-10-15 12:32                     ` Robert Wisniewski
2004-10-15 13:11                       ` Ingo Molnar
2004-10-15 14:50                         ` Robert Wisniewski
2004-10-15 14:58                           ` Ingo Molnar
2004-11-23 18:06 [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-9 Mark_H_Johnson
2004-11-23 21:15 ` Ingo Molnar
2004-11-23 19:24 Mark_H_Johnson
2004-11-23 19:50 ` Adam Heath

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).