[lkml]   [2004]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3

* Adam Heath <> wrote:

> On Fri, 15 Oct 2004, Ingo Molnar wrote:
> >
> > i have released the -U3 PREEMPT_REALTIME patch:
> >
> >
> 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

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,

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.623 / U:6.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site