[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060921075242.GB11644@gnuppy.monkey.org>
Date: Thu, 21 Sep 2006 00:52:42 -0700
From: Bill Huey (hui) <billh@...ppy.monkey.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
John Stultz <johnstul@...ibm.com>,
"Paul E. McKenney" <paulmck@...ibm.com>,
Dipankar Sarma <dipankar@...ibm.com>,
Arjan van de Ven <arjan@...radead.org>,
Esben Nielsen <simlo@...s.au.dk>,
"Bill Huey (hui)" <billh@...ppy.monkey.org>
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]
On Thu, Sep 21, 2006 at 09:31:30AM +0200, Ingo Molnar wrote:
> * Bill Huey <billh@...ppy.monkey.org> wrote:
> > It was even problematic with the serial console on which is why I did
> > that. Maybe it was an artifact of having both the serial console and
> > video consoles on ?
>
> perhaps the real problem was that you got 'intermixed' stackdumps from
> multiple CPUs crashing at once? Or was it simply the myriads of
> stackdumps? The myriads effect is easy to solve: only look at the first
> one, and fix them one by one :-)
I don't think I have to tell you that things got "really weird" for a
while which is why I took the route of most severity and elected to use
extreme debugging methods. :)
I mean, some of those stack traces kept triggering a jumble of schedule()
calls, etc... I decided to hack the heads off of them one at at time and
stop the kernel immediately after one of those bugs. The immediate panic()
is what caught the tbl raw_spinlock issue and therefore my lock reversion
after auditing that portion of the lock graph.
bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists