On Wed, 2008-10-15 at 14:05 +0200, Geert Uytterhoeven wrote:
> I guess it's auto-enabled when the decrementer interrupt handler exits?
> So shouldn't there be a `bl trace_hardirqs_on' somewhere?
The interrupts are restored to their previous state on exit of
interrupts via the TRACE_AND_RESTORE_IRQ
On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
> 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.
> > > >
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/disabl
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.
>
> > 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
On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-10-15 at 11:25 +0200, Geert Uytterhoeven wrote:
> > On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
> > > On Tue, 2008-10-14 at 11:32 +0200, Geert Uytterhoeven wrote:
> > > > which points again to smp_call_function_single...
> > >
On Wed, 2008-10-15 at 11:25 +0200, Geert Uytterhoeven wrote:
> On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
> > On Tue, 2008-10-14 at 11:32 +0200, Geert Uytterhoeven wrote:
> > > which points again to smp_call_function_single...
> >
> > Yup, it doesn't bring more information. At this stage,
On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
> On Tue, 2008-10-14 at 11:32 +0200, Geert Uytterhoeven wrote:
> > which points again to smp_call_function_single...
>
> Yup, it doesn't bring more information. At this stage, your 'other' CPU
> is stuck with interrupts disabled. Hard to tell what
On Tue, 2008-10-14 at 11:32 +0200, Geert Uytterhoeven wrote:
>
> which points again to smp_call_function_single...
Yup, it doesn't bring more information. At this stage, your 'other' CPU
is stuck with interrupts disabled. Hard to tell what's happening without
some HW assist. Do you have ways to
On Mon, 13 Oct 2008, Geert Uytterhoeven wrote:
> On Sun, 12 Oct 2008, Aaron Tokhy wrote:
> > I recently built 2.6.27 with these patches on my PS3.
> >
> > http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-patches/ps3-wip/ps3vram-driver.patch
> > http://www.kernel.org/pub/linux/ker
On Sun, 12 Oct 2008, Aaron Tokhy wrote:
> I recently built 2.6.27 with these patches on my PS3.
>
> http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-patches/ps3-wip/ps3vram-driver.patch
> http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-patches/ps3-wip/ps3vram-p
11 matches
Mail list logo
