>> Some architectures already have their own recursive
>> locking for oopses and we have another version for
>> serialising dump_stack.
>>
>> Create a common version and use it everywhere (oopses,
>> BUGs, WARNs, dump_stack, soft lockups and hard lockups).
>
> Dunno. I've had cases where the simult
On 3/23/2012 12:22 PM, Andrew Morton wrote:
> On Mon, 13 Feb 2012 12:16:41 -0800
> Arjan van de Ven wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>> The bug looks pretty generic, nothing very PPC-specific there. It
>>> might aff
On 2/14/2012 11:57 AM, Srivatsa S. Bhat wrote:
>> In addition to this, the reality is that the whole "bring cpus up"
>> sequence needs to be changed; the current one is very messy and requires
>> the hotplug lock for the whole bring up of each individual cpu... which
>> is a very unfortunate desig
Its more than acpi ... machine checks can do it too etc
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Peter Zijlstra wrote:
On Tue, 2012-02-14 at 06:31 -0800, Arjan van de Ven wrote:
>
> frankly, such code HAS to worry about cpus going online and offline
> e
one coments; will comment more when I get to work
On Tue, Feb 14, 2012 at 1:48 AM, Srivatsa S. Bhat
7. And whichever code between smp_init() and async_synchronize_full() didn't
>
> care about CPU hotplug till today but depended on all cpus being online
> must
> suddenly start worrying about CPU H
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/13/2012 12:05 PM, Andrew Morton wrote:
> On Mon, 13 Feb 2012 06:18:34 -0800 Arjan van de Ven
> wrote:
>
>> On 2/12/2012 7:04 PM, Michael Neuling wrote:
>>>> Just a quick note to say I got a boot OOPs with next-2012
On 2/12/2012 7:04 PM, Michael Neuling wrote:
>> Just a quick note to say I got a boot OOPs with next-20120208 and 9 on a
>> Power7 blade (my other PowerPC boot tests are ok. I'll investigate this
>> further on Monday.
>>
>> The line referenced below is:
>>
>> BUG_ON(!kobj || !kobj->sd || !attr);
>
On Fri, 25 Sep 2009 10:54:24 +0200
Peter Zijlstra wrote:
> On Fri, 2009-09-25 at 12:36 +0530, Vaidyanathan Srinivasan wrote:
> > * Arjan van de Ven [2009-09-24 14:22:28]:
> >
> > > On Thu, 24 Sep 2009 10:42:41 +0530
> > > Arun R Bharadwaj wrote:
> > >
even with Venki's patch, all our measurements indicate that taking
cores away is damage on x86. Don't let that stop what you do for
powerpc, but for x86 it's not a win. Linux is good at keeping cores in
C6 long enough that the downside of offlining is bigger...
--
Arjan van de Ve
s,
but not on others.
in practice when this happens it tends to be a bug.. but it's
technically a valid configuration
--
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
eption that generally powering down sockets
help; it does not help for all cpus. Some cpus are so efficient in idle
that the incremental gain one would get by "offlining" a core is just
not worth it
(in fact, in x86, it's the same thing)
I obviously can't speak for p-series cpus, just wa
nabled in SuSE kernels.
>
but are there users of it?
I thought Andrea stopped the cpushare thing that was the only user of
this
--
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
Michael Neuling wrote:
powerpc has dot symbols, so the dmesg output looks like:
<4>[0.327310] calling .migration_init+0x0/0x9c @ 1
<4>[0.327595] initcall .migration_init+0x0/0x9c returned 1 after 0 usecs
The below fixes bootgraph.pl so it handles this correctly.
question for the
t way I suppose would be to do
#define __WARN_printf(arg..) do { printk(arg); __WARN(); } while (0)
any obvious problems with this ?
--
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings,
visit htt
Kamalesh Babulal wrote:
Thanks for reference of the patch, After replacing the patch with the latest
one above on the powerpc, the warning still remains
Badness at kernel/notifier.c:86
sadly you have something going on that doesn't list the modules loaded etc...
is this during boot or way
001
From: Arjan van de Ven <[EMAIL PROTECTED]>
Date: Tue, 26 Aug 2008 09:01:06 -0700
Subject: [PATCH] debug: add notifier chain debugging
during some development we suspected a case where we left something
in a notifier chain that was from a module that was unloaded already...
and that sort of
On Sun, 20 Jul 2008 21:25:51 +0200
Stefan Richter <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Sun, 20 Jul 2008 20:36:23 +0200
> > Stefan Richter <[EMAIL PROTECTED]> wrote:
> >
> >> PS: I don't want to set the DMA mask of this devi
On Sun, 20 Jul 2008 21:25:51 +0200
Stefan Richter <[EMAIL PROTECTED]> wrote:
>
> Later on:
>
> if (dev->needs_dma_mask_workaround)
> pci_set_consistent_dma_mask(pdev, DMA_31BIT_MASK);
> allocate_something_special;
> if (dev->needs_dma_mask_workaround)
>
On Sun, 20 Jul 2008 20:36:23 +0200
Stefan Richter <[EMAIL PROTECTED]> wrote:
> PS: I don't want to set the DMA mask of this device to
> DMA_31BIT_MASK because that would be detrimental to other functions
> of the device. It's a TI TSB43AB22A FireWire controller.
Hi,
just want to mention that yo
across architectures)
that once you deal with what there is today... you pretty much deal with
everything.
I also like the improvement; I wished something like this existed several times
already
in the last few months so for sure
Acked-by: Arjan van de Ven <[EMAIL PROTECTED]>
__
On Tue, 19 Feb 2008 13:33:53 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> Actually one thing I don't like about gcc is that I think it still
> emits cmovs for likely/unlikely branches, which is silly (the gcc
> developers seem to be in love with that instruction). If that goes
> away, then bra
On Mon, 18 Feb 2008 21:58:42 +0100
Jean Delvare <[EMAIL PROTECTED]> wrote:
> On Tue, 19 Feb 2008 07:42:03 +1100, Benjamin Herrenschmidt wrote:
> >
> > > Maybe Christian's patch can be improved to not do the check on
> > > these? As long as /dev/port exists, it seems reasonable that the
> > > kern
On Mon, 18 Feb 2008 13:11:06 -0500
[EMAIL PROTECTED] wrote:
> On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
>
> > __builtin_expect() is useful on FRV where you _have_ to give each
> > branch and conditional branch instruction a measure of probability
> > whether the branch will be taken.
On Sat, 16 Feb 2008 10:31:26 -0800
Geoff Levand <[EMAIL PROTECTED]> wrote:
> On 02/16/2008 09:42 AM, Arjan van de Ven wrote:
> > On Sat, 16 Feb 2008 18:33:16 +0100
> > Willy Tarreau <[EMAIL PROTECTED]> wrote:
> >
> >> On Sat, Feb 16, 2008 at 09:25:52A
On Sat, 16 Feb 2008 18:58:49 +0100
> > If you think unlikely() means something else, we should fix what it
> > maps to towards gcc ;) (to.. be empty ;)
>
> eventhough the gcc docs say it's just a hint to help the compiler
> optimize the branch it takes by default, I too have noticed that it
> more
On Sat, 16 Feb 2008 18:33:16 +0100
Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 16, 2008 at 09:25:52AM -0800, Arjan van de Ven wrote:
> > On Sat, 16 Feb 2008 17:08:01 +0100
> > Roel Kluin <[EMAIL PROTECTED]> wrote:
> >
> > > The patch below wa
On Sat, 16 Feb 2008 17:08:01 +0100
Roel Kluin <[EMAIL PROTECTED]> wrote:
> The patch below was not yet tested. If it's correct as it is, please
> comment. ---
> Fix Unlikely(x) == y
>
you found a great set of bugs..
but to be honest... I suspect it's just best to remove unlikely altogether for
27 matches
Mail list logo
