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 simultaneity of the
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
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 a.p.zijls...@chello.nl 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
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 design; a much
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);
in
-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
ar...@linux.intel.com wrote:
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
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 VenIntel Open Source Technology Centre
For development, discussion
On Fri, 25 Sep 2009 10:54:24 +0200
Peter Zijlstra a.p.zijls...@chello.nl wrote:
On Fri, 2009-09-25 at 12:36 +0530, Vaidyanathan Srinivasan wrote:
* Arjan van de Ven ar...@infradead.org [2009-09-24 14:22:28]:
On Thu, 24 Sep 2009 10:42:41 +0530
Arun R Bharadwaj a...@linux.vnet.ibm.com
not worth it
(in fact, in x86, it's the same thing)
I obviously can't speak for p-series cpus, just wanted to point out
that there is no universal truth about offlining saves power.
--
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings
,
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
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
___
Linuxppc-dev mailing list
Linuxppc-dev
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
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 http://www.lesswatts.org
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
: 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 thing
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 you
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 device to
DMA_31BIT_MASK because that would be detrimental
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]
___
Linuxppc-dev
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.
What
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
kernel should
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 branch
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
these
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 often
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:52AM -0800, Arjan van de Ven wrote:
On Sat, 16 Feb 2008 17
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 was not yet tested. If it's correct as it is,
please
26 matches
Mail list logo
