* 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 raw
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 pa
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 tri
* 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 stup
* 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
* 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_spinlo
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_
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 t
* 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 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 irq
* 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 a
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 c
* 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 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 cl
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
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), b
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 occurre
18 matches
Mail list logo
