[lkml]   [2012]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [3.4-rc3] Thread overran stack, or stack corrupted
    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.



     \ /
      Last update: 2012-04-18 22:37    [W:0.031 / U:35.524 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site