* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > +/*
> > + * Migration helpers - the proper API is the local_read_flags API.
> > + * Will go away in v2.6.26.
> > + */
> > +#define local_save_flags local_read_flags
> > +#define __local_save_flags __local_read_flags
> > +#define
On Fri, 21 Dec 2007 12:12:07 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > I'd suggest that we add a local_read_flags() along with
> > local_save_flags(). Then I can merge the parts of the patch which
> > don't get destroyed by ongoing churn
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> I'd suggest that we add a local_read_flags() along with
> local_save_flags(). Then I can merge the parts of the patch which
> don't get destroyed by ongoing churn and then we can come in and clean
> up the stragglers later.
ah, indeed.
like the
On Fri, 21 Dec 2007 11:27:27 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > local_read_flags().
> >
> > > that should have been raw_local_irq_save(flags)!
> >
> > So raw_local_save_flags() and raw_local_irq_save() have different semantics.
> >
> > omigawd, what have we done?
>
> i really
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > raw_local_save_flags() doesn't disable interrupts?
> >
> > argh. Indeed! (I wanted us to fix that misleading name eons ago, to
>
> The naming of those functions is truly awful and it goes back to year 0.
>
> > *_save_flags_only(), but some
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > btw, I think we should track this as a regression, please.
>
> Added, http://bugzilla.kernel.org/show_bug.cgi?id=9610, thanks.
fixed by:
commit c0a698b7443a9fce76b0a849f06c45ac78f3b0a0
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date: Fri
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
btw, I think we should track this as a regression, please.
Added, http://bugzilla.kernel.org/show_bug.cgi?id=9610, thanks.
fixed by:
commit c0a698b7443a9fce76b0a849f06c45ac78f3b0a0
Author: Ingo Molnar [EMAIL PROTECTED]
Date: Fri Dec 21
* Andrew Morton [EMAIL PROTECTED] wrote:
raw_local_save_flags() doesn't disable interrupts?
argh. Indeed! (I wanted us to fix that misleading name eons ago, to
The naming of those functions is truly awful and it goes back to year 0.
*_save_flags_only(), but some stupid bikeshed
On Fri, 21 Dec 2007 11:27:27 +0100 Ingo Molnar [EMAIL PROTECTED] wrote:
local_read_flags().
that should have been raw_local_irq_save(flags)!
So raw_local_save_flags() and raw_local_irq_save() have different semantics.
omigawd, what have we done?
i really tried to get this
* Andrew Morton [EMAIL PROTECTED] wrote:
I'd suggest that we add a local_read_flags() along with
local_save_flags(). Then I can merge the parts of the patch which
don't get destroyed by ongoing churn and then we can come in and clean
up the stragglers later.
ah, indeed.
like the patch
On Fri, 21 Dec 2007 12:12:07 +0100 Ingo Molnar [EMAIL PROTECTED] wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
I'd suggest that we add a local_read_flags() along with
local_save_flags(). Then I can merge the parts of the patch which
don't get destroyed by ongoing churn and then we
* Andrew Morton [EMAIL PROTECTED] wrote:
+/*
+ * Migration helpers - the proper API is the local_read_flags API.
+ * Will go away in v2.6.26.
+ */
+#define local_save_flags local_read_flags
+#define __local_save_flags __local_read_flags
+#define
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > + raw_local_irq_save(flags);
> > __raw_spin_lock();
> > - raw_local_save_flags(flags);
> > die.lock_owner = smp_processor_id();
> > die.lock_owner_depth = 0;
> > bust_spinlocks(1);
On Fri, 21 Dec 2007 01:30:35 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 21 Dec 2007 00:47:59 +0100
> > Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > > __raw_spin_lock();
> > > >
On Thursday, 20 of December 2007, Andrew Morton wrote:
> On Thu, 20 Dec 2007 14:54:15 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 20 Dec 2007 17:40:47 -0500
> > Trond Myklebust <[EMAIL PROTECTED]> wrote:
> >
> > > I just got the following interesting behaviour. Never mind why
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Dec 2007 00:47:59 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > __raw_spin_lock();
> > > raw_local_save_flags(flags);
> > > - die.lock_owner = smp_processor_id();
> > > + die.lock_owner =
On Fri, 21 Dec 2007 00:47:59 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > __raw_spin_lock();
> > raw_local_save_flags(flags);
> > - die.lock_owner = smp_processor_id();
> > + die.lock_owner = raw_smp_processor_id();
>
> we just disabled irqs with
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Dec 2007 00:47:59 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > it needs to be found out why the preempt_count suddenly went to zero. Is
> > task struct corruption out of question?
>
> Strictly we shouldn't care - we _know_ we've
On Fri, 21 Dec 2007 00:47:59 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> it needs to be found out why the preempt_count suddenly went to zero. Is
> task struct corruption out of question?
Strictly we shouldn't care - we _know_ we've already hit a kernel bug and
who knows, perhaps that buggy
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> Yes - I don't know why the smp_processor_id() test has suddenly
> started triggering in there.
it's a "must not happen".
here:
> __raw_spin_lock();
> raw_local_save_flags(flags);
> - die.lock_owner =
On Thu, 2007-12-20 at 14:56 -0800, Andrew Morton wrote:
> btw, I think we should track this as a regression, please. It may not
> strictly be a regression: the same problem might happen under 2.6.23,
> although reports are only agaisnt 2.6.24-rc.
>
> But things which impact our ability to get
On Thu, 2007-12-20 at 14:54 -0800, Andrew Morton wrote:
> On Thu, 20 Dec 2007 17:40:47 -0500
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> > I just got the following interesting behaviour. Never mind why the
> > original Oops (I was testing some experimental RPC patches), but there
> >
On Thu, 20 Dec 2007 14:54:15 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Dec 2007 17:40:47 -0500
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> > I just got the following interesting behaviour. Never mind why the
> > original Oops (I was testing some experimental RPC patches),
On Thu, 20 Dec 2007 17:40:47 -0500
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> I just got the following interesting behaviour. Never mind why the
> original Oops (I was testing some experimental RPC patches), but there
> appears to be a BUG_ON() triggered inside the dump() call.
>
> Oops
On Thu, 20 Dec 2007 17:40:47 -0500
Trond Myklebust [EMAIL PROTECTED] wrote:
I just got the following interesting behaviour. Never mind why the
original Oops (I was testing some experimental RPC patches), but there
appears to be a BUG_ON() triggered inside the dump() call.
Oops occurred with
On Thu, 20 Dec 2007 14:54:15 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 20 Dec 2007 17:40:47 -0500
Trond Myklebust [EMAIL PROTECTED] wrote:
I just got the following interesting behaviour. Never mind why the
original Oops (I was testing some experimental RPC patches), but there
On Thu, 2007-12-20 at 14:54 -0800, Andrew Morton wrote:
On Thu, 20 Dec 2007 17:40:47 -0500
Trond Myklebust [EMAIL PROTECTED] wrote:
I just got the following interesting behaviour. Never mind why the
original Oops (I was testing some experimental RPC patches), but there
appears to be a
On Thu, 2007-12-20 at 14:56 -0800, Andrew Morton wrote:
btw, I think we should track this as a regression, please. It may not
strictly be a regression: the same problem might happen under 2.6.23,
although reports are only agaisnt 2.6.24-rc.
But things which impact our ability to get clean
* Andrew Morton [EMAIL PROTECTED] wrote:
Yes - I don't know why the smp_processor_id() test has suddenly
started triggering in there.
it's a must not happen.
here:
__raw_spin_lock(die.lock);
raw_local_save_flags(flags);
- die.lock_owner =
On Fri, 21 Dec 2007 00:47:59 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
it needs to be found out why the preempt_count suddenly went to zero. Is
task struct corruption out of question?
Strictly we shouldn't care - we _know_ we've already hit a kernel bug and
who knows, perhaps that buggy code
* Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 21 Dec 2007 00:47:59 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
it needs to be found out why the preempt_count suddenly went to zero. Is
task struct corruption out of question?
Strictly we shouldn't care - we _know_ we've already hit a
On Fri, 21 Dec 2007 00:47:59 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
__raw_spin_lock(die.lock);
raw_local_save_flags(flags);
- die.lock_owner = smp_processor_id();
+ die.lock_owner = raw_smp_processor_id();
we just disabled irqs with
* Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 21 Dec 2007 00:47:59 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
__raw_spin_lock(die.lock);
raw_local_save_flags(flags);
- die.lock_owner = smp_processor_id();
+ die.lock_owner =
On Thursday, 20 of December 2007, Andrew Morton wrote:
On Thu, 20 Dec 2007 14:54:15 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 20 Dec 2007 17:40:47 -0500
Trond Myklebust [EMAIL PROTECTED] wrote:
I just got the following interesting behaviour. Never mind why the
original
On Fri, 21 Dec 2007 01:30:35 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 21 Dec 2007 00:47:59 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
__raw_spin_lock(die.lock);
raw_local_save_flags(flags);
* Andrew Morton [EMAIL PROTECTED] wrote:
+ raw_local_irq_save(flags);
__raw_spin_lock(die.lock);
- raw_local_save_flags(flags);
die.lock_owner = smp_processor_id();
die.lock_owner_depth = 0;
bust_spinlocks(1);
-
36 matches
Mail list logo
