* Steven Rostedt [EMAIL PROTECTED] wrote:
Ingo,
The below ifndef, shouldn't that be ifndef CONFIG_PREEMPT_SOFTIRQS ? I
hit that warning while I was running !PREEMPT_RT but with both hard
and softiqs as threads.
yeah, indeed - fixed.
P.S. I really found out that the system becomes VERY
* Steven Rostedt [EMAIL PROTECTED] wrote:
I don't have time to look further now, and it's something that isn't
easily reproducible (Well, it happened once out of two boots). If
you need me to look further, or need a config or dmesg (I have
both), then just give me a holler.
Silly
--
On Sun, 5 Aug 2007, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
I don't have time to look further now, and it's something that isn't
easily reproducible (Well, it happened once out of two boots). If
you need me to look further, or need a config or dmesg (I have
* Steven Rostedt [EMAIL PROTECTED] wrote:
The code on line 133 is:
WARN_ON_ONCE(current-rcu_read_lock_nesting NR_CPUS);
I have NR_CPUS set to 2 since the box I'm running this on only has 2
cpus and I see no reason to waste more data structures.
Is rcu read lock nesting deeper
Paul and Ingo,
Should we just remove the upper limit check, or is something like this
patch sound?
-- Steve
When DEBUG_KERNEL is set, place an upper bound limit on the rcu read
lock set to 100. If we go that deep, then a warn on will print.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
On Sun, 2007-08-05 at 08:56 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
P.S. I really found out that the system becomes VERY non-responsive
when you run with both hard and softirqs as threads, but with
PREEMPT_NONE ;-)
hm. That's not supposed to happen. Could
On Sun, Aug 05, 2007 at 07:53:10PM +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Paul and Ingo,
Should we just remove the upper limit check, or is something like this
patch sound?
i've changed the limit to 30 (the same depth limit is used by lockdep).
* Peter Williams [EMAIL PROTECTED] wrote:
I've just been reviewing these patches and have spotted a possible
error in the file arch/ia64/kernel/time.c in that the scope of the
#ifdef on CONFIG_TIME_INTERPOLATION seems to have grown quite a lot
since 2.2.23-rc1-rt7. It used to chop out one
