Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]


* Bill Huey <billh@xxxxxxxxxxxxxxxxx> wrote:

On Thu, Sep 21, 2006 at 09:22:16AM +0200, Ingo Molnar wrote:
* Bill Huey <billh@xxxxxxxxxxxxxxxxx> wrote:

Also, triggering a panic() at the beginning of the rt mutex acquire
was very useful since it made "in_atomic()" violations an explicit
error stopping the machine. Stack traces started to get really crazy
in this preemptive kernel with all sorts of things running unlike the
non-preemptive kernel and it was time consuming to figure out the real
stuff from the noise in the stack trace.

well you should absolutely have serial console if you effectively want
to hack the Linux kernel. And in the serial console log you should
search for stacktraces top-down, and concentrate on the first one - any
subsequent one might be collateral damage of the first one.

Of course I did that. I'm not that stupid. :) The stack traces, even
with your above suggestions were too many and I had to break it down a
bug at a time, stack trace at a time, since I realize problems earlier
could clash and trigger other unrelated problems.

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 :-)

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]
    ... Stack traces started to get really crazy ... in this preemptive kernel with all sorts of things running unlike the ... non-preemptive kernel and it was time consuming to figure out the real ... well you should absolutely have serial console if you effectively want ...
    (Linux-Kernel)
  • Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]
    ... Stack traces started to get really crazy ... in this preemptive kernel with all sorts of things running unlike the ... non-preemptive kernel and it was time consuming to figure out the real ... well you should absolutely have serial console if you effectively want ...
    (Linux-Kernel)
  • Re: 6.0 random freezes
    ... the probe/attach sequence relies on the kernel being in a reasonably sane state (and I'm not sure if it will detect the keyboard as a console device except at boot time). ... I'm in process of getting a serial console, so if there's no response as well, I will enable the sanity checks. ...
    (freebsd-stable)
  • Re: changing debuglevel of kernel messaging going to console
    ... Moreover, several kernel messages ... > sending bogus ARP replies. ... > FreeBSD box with serial console may lead to a DoS like conditions. ... while working on a Linux firewall which was printing all NetFilter's log ...
    (freebsd-current)
  • Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]
    ... what the reason is for those crashes, ... necessiate the pushing of task-reapdown into yet another set of kernel ... If I had his hardware I'd have a better way of replicating those ... Robert's stack traces looked completely wrong as well which is why I gave up. ...
    (Linux-Kernel)