Hello, > > > > I found this in dmesg: > > > > > > > > BUG: swapper:0 task might have lost a preemption check! > > > > Pid: 0, comm: swapper Not tainted 2.6.24-rc7-rt2 #3 > > > > [<c010386b>] show_trace_log_lvl+0x1d/0x3b > > > > [<c01042f3>] show_trace+0x12/0x14 > > > > [<c0104a2f>] dump_stack+0x6a/0x70 > > > > [<c0115419>] preempt_enable_no_resched+0x5c/0x5e > > > > > > This is really really strange. cpu_idle calls __preempt_enable_no_resched > > > and not preempt_enable_no_resched (notice the prefixed underscores). > > > So I don't know how you got that output. Did you get any strance rejects > > > in applying this patch? > > > > Nope. Your rt patch applied cleanly to vanilla 2.6.24-rc7. > > > > OK, do you still get this message? Also I'm assuming this is x86, right? > > Could you also do the following. > > Go into your kernel build directory. > Start up gdb (I'm hoping that you compiled with DEBUG_INFO) > gdb vmlinux > (gdb) li *0xc0100e35 > > and show me what you get. Oh crap. You are totaly right. I messed with quilt on that tree to bisect that thing with LOCKDEP. A few patches from rt series were left unapplied somehow :/ Sorry for the noise then. Regards, Mariusz BTW this is the gdb output which ofcourse is bogus. (gdb) l*0xc0100e35 0xc0100e35 is in cpu_idle (arch/x86/kernel/process_32.c:203). 198 __get_cpu_var(irq_stat).idle_timestamp = jiffies; 199 idle(); 200 } 201 tick_nohz_restart_sched_tick(); 202 preempt_enable_no_resched(); 203 schedule(); 204 preempt_disable(); 205 } 206 } 207 - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
