From: Dave Jones <davej@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [3.4-rc3] Thread overran stack, or stack corrupted
Date: Wed, 18 Apr 2012 13:14:38 -0400 [thread overview]
Message-ID: <20120418171438.GA24290@redhat.com> (raw)
In-Reply-To: <CA+55aFwrARr4=ZztWseFbND1h6W=QV52r98qioL+bK6jKrehSA@mail.gmail.com>
On Wed, Apr 18, 2012 at 10:02:06AM -0700, Linus Torvalds wrote:
> > the traces below, which look pretty.. deep.
>
> Yeah. Sadly, they are less useful than I was hoping for. It's not some
> single deep call-chain, it's almost all debug stuff and the "did we
> release the RCU lock" or preemption checks, which I guess makes sense.
> You have tons of options enabled in your kernel that makes for deeper
> stack traces, and then all the interesting stuff gets overwritten by
> what happened later.
One thing I'm curious about.. Some of the function names are repeated
for a reason that doesn't seem obvious to me, when the call chain doesn't
call them in a loop. What's that about ?
> I assume you have USB serial console on for a reason (ie: great for
> catching oopses before the machine dies), but in this case it hurts.
Yeah, there's a (possibly related) problem where once a day some oops
gets triggered that just wedges the machine. I've not managed to capture
it yet, and the most I've gotten over the usb console was about
a dozen characters before it hung.
I've disabled the console blanking, and hooked up a monitor to it.
Perhaps that'll be enough to capture it without resorting to usb console.
> Could you try just adding a
>
> console_lock();
> ...
> console_unlock();
>
> around the show_trace() call. That will force the code to not actually
> call down to the console layer until after the console_unlock(), so
> the printing of the stack trace won't affect the stack *too* much.
That's a neat trick. I'll add that, in case I do have to fall back to usb console.
thanks,
Dave
next prev parent reply other threads:[~2012-04-18 17:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 17:21 [3.4-rc3] Thread overran stack, or stack corrupted Dave Jones
2012-04-17 20:20 ` Linus Torvalds
2012-04-17 20:32 ` Dave Jones
2012-04-18 1:36 ` Linus Torvalds
2012-04-18 2:27 ` Steven Rostedt
2012-04-18 3:15 ` Dave Jones
2012-04-18 3:43 ` Steven Rostedt
2012-04-18 3:50 ` Dave Jones
2012-04-18 3:57 ` Steven Rostedt
2012-04-18 4:00 ` Steven Rostedt
2012-04-18 4:07 ` Dave Jones
2012-04-18 4:06 ` Dave Jones
2012-04-18 4:09 ` Steven Rostedt
2012-04-18 13:58 ` Dave Jones
2012-04-18 14:56 ` Steven Rostedt
2012-04-18 15:27 ` Dave Jones
2012-04-18 15:30 ` Dave Jones
2012-04-18 16:43 ` Steven Rostedt
2012-05-23 14:37 ` Steven Rostedt
2012-05-23 15:05 ` Dave Jones
2012-05-23 15:14 ` Steven Rostedt
2012-04-18 15:40 ` Steven Rostedt
2012-04-18 3:19 ` Dave Jones
2012-04-18 17:02 ` Linus Torvalds
2012-04-18 17:14 ` Dave Jones [this message]
2012-04-18 18:24 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120418171438.GA24290@redhat.com \
--to=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox