From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: Linux/PPC Development <linuxppc-dev@ozlabs.org>,
Aaron Tokhy <atokhy@gmail.com>
Subject: Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
Date: Wed, 15 Oct 2008 22:49:52 +1100 [thread overview]
Message-ID: <1224071392.8157.455.camel@pasglop> (raw)
In-Reply-To: <Pine.LNX.4.64.0810151343480.1133@vixen.sonytel.be>
On Wed, 2008-10-15 at 13:46 +0200, Geert Uytterhoeven wrote:
> On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
> > > > Well, at the time of the sample, the other CPU indeed -seems- to be in
> > > > an IRQ disabled section yes.
> > >
> > > This is not really a sample. The hardirqs enable/disable is actually tracked
> > > using the TRACE_{EN,DIS}ABLE_INTS macros.
> >
> > That's what I meant. IE. the hardirq state was updated by the stuck CPU
> > but sampled by the non-stuck one. ie. the non-stuck one could have
> > sampled a transcient value where it happened to have hard irq
> > disabled...
>
> These states are per_cpu.
I know, but that doesn't prevent another CPU from peeking at them :-)
The question is, was the message printed by the CPU that locked up or by
the other one that detected the lockup ?
> They do call TRACE_DISABLE_INTS, which records the interrupt being disabled.
> So this makes the actual state recording useless...
Well, they record that when they disable it. They don't enable it. Can
you find a spot where the IRQ is enabled and it's not recorded or a case
where it's not disabled and recorded as disabled ?
Cheers,
Ben.
next prev parent reply other threads:[~2008-10-15 11:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-12 4:32 [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64 Aaron Tokhy
2008-10-13 7:58 ` Geert Uytterhoeven
2008-10-14 9:32 ` Geert Uytterhoeven
2008-10-15 4:49 ` Benjamin Herrenschmidt
2008-10-15 9:25 ` Geert Uytterhoeven
2008-10-15 9:28 ` Benjamin Herrenschmidt
2008-10-15 9:46 ` Geert Uytterhoeven
2008-10-15 11:37 ` Benjamin Herrenschmidt
2008-10-15 11:46 ` Geert Uytterhoeven
2008-10-15 11:49 ` Benjamin Herrenschmidt [this message]
2008-10-15 12:05 ` Geert Uytterhoeven
2008-10-15 20:53 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2008-10-13 2:32 Aaron Tokhy
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=1224071392.8157.455.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=Geert.Uytterhoeven@sonycom.com \
--cc=atokhy@gmail.com \
--cc=linuxppc-dev@ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.