>> 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 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);
>
-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
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
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
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
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
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
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
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
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:
> > >
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
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
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 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: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 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 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 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
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 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
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 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
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
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
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
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
27 matches
Mail list logo
