ctions where
> appropriate.
Very nice cleanup series to the page table code!
FWIW:
Reviewed-by: Pekka Enberg
Hi Sasha,
On 3/11/15 1:43 PM, Sasha Levin wrote:
As discussed on LSF/MM, kill kmemcheck.
KASan is a replacement that is able to work without the limitation of
kmemcheck (single CPU, slow). KASan is already upstream.
We are also not aware of any users of kmemcheck (or users who don't consider
void *cache_alloc_node(struct kmem_cache
*cachep, gfp_t flags,
void *obj;
int x;
- VM_BUG_ON(nodeid num_online_nodes());
+ VM_BUG_ON(nodeid 0 || nodeid = MAX_NUMNODES);
n = get_node(cachep, nodeid);
BUG_ON(!n);
Reviewed-by: Pekka Enberg penb
On Sun, Mar 10, 2013 at 3:06 PM, Alex Grad alex.g...@gmail.com wrote:
Signed-off-by: Alex Grad alex.g...@gmail.com
---
arch/powerpc/kernel/kgdb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index
On Mon, 2011-06-13 at 12:59 -0500, Christoph Lameter wrote:
On Sun, 12 Jun 2011, Hugh Dickins wrote:
3.0-rc won't boot with SLUB on my PowerPC G5: kernel BUG at mm/slub.c:1950!
Bisected to 1759415e630e slub: Remove CONFIG_CMPXCHG_LOCAL ifdeffery.
After giving myself a medal for finding
On Mon, Jun 13, 2011 at 10:29 PM, Christoph Lameter c...@linux.com wrote:
On Mon, 13 Jun 2011, Pekka Enberg wrote:
Hmmm.. The allocpercpu in alloc_kmem_cache_cpus should take care of the
alignment. Uhh.. I see that a patch that removes the #ifdef CMPXCHG_LOCAL
was not applied? Pekka
Hi Milton,
On Wed, Jun 9, 2010 at 10:20 AM, Milton Miller milt...@bga.com wrote:
However, in this case you are removing casts that, while not necessary
for C, are indeed there for a reason.
Specifically, they are of the form
type *p;
code
p = (type *)kmalloc(sizeof(type), ...);
For
On Sun, Jun 21, 2009 at 7:28 AM, Frans Popelen...@planet.nl wrote:
On Sunday 21 June 2009, Sean MacLennan wrote:
I found the source of the badness. The backtrace is correct:
uic_init_one
So that's in arch/powerpc/sysdev/uic.c.
___alloc_bootmem
___alloc_bootmem_nopanic
Hi Sean,
On Mon, Jun 22, 2009 at 1:36 AM, Sean MacLennansmaclen...@pikatech.com wrote:
On Mon, 22 Jun 2009 08:25:04 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
Right, our interrupt controllers need those fixes, they are low
on my priority list since it's a reasonably
().
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Looks good to me!
Acked-by: Pekka Enberg penb...@cs.helsinki.fi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Fri, 2009-06-12 at 10:21 +0200, Nick Piggin wrote:
On Fri, Jun 12, 2009 at 01:38:50PM +0530, Sachin Sant wrote:
Nick Piggin wrote:
I was able to boot yesterday's next (20090611) on this machine. Not sure
Still with SLQB? With debug options turned on?
Ah .. spoke too
On Fri, 2009-06-12 at 18:35 +1000, Stephen Rothwell wrote:
Hi Pekka,
On Fri, 12 Jun 2009 11:25:39 +0300 Pekka Enberg penb...@cs.helsinki.fi
wrote:
Hmm, SLQB in my for-next branch. Stephen, is slab.git dropped from
linux-next or something?
Yesterday (next-20090611) the slab tree
Hi Sachin,
On Thu, 2009-05-14 at 14:00 +0530, Sachin Sant wrote:
Nick Piggin wrote:
This one possibly looks like a problem with remote memory allocation
or memory hotplug or something like that. I'll do a bit of code
review
Removed linux-scsi from the cc list.
I can recreate this
On Thu, 2009-05-14 at 15:24 +0530, Sachin Sant wrote:
Pekka Enberg wrote:
I wasn't able to find your .config in this thread. Can you please post
it?
Config attached.
Thanks! Can you please enable CONFIG_DEBUG_VM, CONFIG_DEBUG_LIST, and
decrease CONFIG_NR_CPUS=1024 to, say, 32
Hi Sachin,
On Thu, 2009-05-14 at 12:59 +0300, Pekka Enberg wrote:
On Thu, 2009-05-14 at 15:24 +0530, Sachin Sant wrote:
Pekka Enberg wrote:
I wasn't able to find your .config in this thread. Can you please post
it?
Config attached.
Thanks! Can you please enable CONFIG_DEBUG_VM
On Thu, 2009-04-30 at 16:10 +0200, Nick Piggin wrote:
On Fri, May 01, 2009 at 12:00:33AM +1000, Stephen Rothwell wrote:
Hi Nick,
On Thu, 30 Apr 2009 15:05:42 +0200 Nick Piggin npig...@suse.de wrote:
Hmm, this might do it. The following code now passes some stress testing
in a
On Thu, 2009-04-30 at 18:10 +0400, Anton Vorontsov wrote:
@@ -2194,16 +2197,16 @@ static void *kmem_cache_dyn_array_alloc(
* never get freed by definition so we can do it rather
* simply.
*/
- if (!nextmem) {
- nextmem
On Thu, 2009-04-30 at 12:35 +0200, Nick Piggin wrote:
On Thu, Apr 30, 2009 at 03:17:12PM +0530, Sachin Sant wrote:
Nick Piggin wrote:
Hmm, forget that. Actually my last patch had a silly mistake because I
forgot MAX_ORDER shift is applied to PAGE_SIZE, rather than 1. So
kmalloc(PAGE_SIZE)
On Thu, Apr 30, 2009 at 2:00 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Pekka, Nick,
On Thu, 30 Apr 2009 13:38:04 +0300 Pekka Enberg penb...@cs.helsinki.fi
wrote:
Stephen, does this patch fix all the boot problems for you as well?
Unfortunately not, I am still getting
On Thu, 2009-04-30 at 13:18 +0200, Nick Piggin wrote:
OK thanks. So I think we have 2 problems. One with MAX_ORDER = 9
that is fixed by the previous patch, and another which is probably
due to having no memory on node 0 which I will take another look
at now.
We can merge the previous patch
On Tue, Feb 10, 2009 at 11:54 AM, Sachin P. Sant sach...@in.ibm.com wrote:
Sachin P. Sant wrote:
Hi Stephen,
Todays next randconfig build on powerpc fails with
CC mm/slqb.o
mm/slqb.c: In function __slab_free:
mm/slqb.c:1648: error: implicit declaration of function
On Mon, Nov 17, 2008 at 11:18 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
I do wonder just _what_ it is that causes the stack frames to be so
horrid. For example, you have
18) 8896 160 .kmem_cache_alloc+0xfc/0x140
and I'm looking at my x86-64 compile, and it has a stack
On Sat, Jul 05, 2008 at 08:41:39PM +0200, Vegard Nossum wrote:
Single letters are bad because it hurts readability and limits the
usefulness of the extension./MHO
On Sat, Jul 5, 2008 at 9:52 PM, Matthew Wilcox [EMAIL PROTECTED] wrote:
I think you need a little warning noise that goes off in
On Tue, 04 Mar 2008 18:42:19 +0530 Kamalesh Babulal
[EMAIL PROTECTED] wrote:
3) Third attempt kernel booted up but had the following call trace 264
times while running
test
Badness at include/linux/gfp.h:110
NIP: c00b4ff0 LR: c00b4fa0 CTR: c019cdb4
REGS:
Andrew Morton wrote:
[c9edf5f0] [c00b56e4] .__alloc_pages_internal+0xf8/0x470
[c9edf6e0] [c00e0458] .kmem_getpages+0x8c/0x194
[c9edf770] [c00e1050] .fallback_alloc+0x194/0x254
[c9edf820] [c00e14b0] .kmem_cache_alloc+0xd8/0x144
-by: Christoph Lameter [EMAIL PROTECTED]
Indeed, good catch. I spotted the same thing just few seconds ago.
Reviewed-by: Pekka Enberg [EMAIL PROTECTED]
Was it you Kamalesh that reported this? Can you please re-test?
___
Linuxppc-dev mailing list
Linuxppc-dev
(adding Christoph as cc)
On Tue, Mar 4, 2008 at 9:35 PM, Mel Gorman [EMAIL PROTECTED] wrote:
[c9edf5f0] [c00b56e4] .__alloc_pages_internal+0xf8/0x470
[c9edf6e0] [c00e0458] .kmem_getpages+0x8c/0x194
[c9edf770] [c00e1050]
Andrew Morton wrote:
On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
I think this is the correct fix.
The NUMA fallback logic should be passing local_flags to kmem_get_pages()
and not simply the flags.
Maybe a stable candidate since we are now simply
Hi Christoph,
On Jan 23, 2008 1:18 AM, Christoph Lameter [EMAIL PROTECTED] wrote:
My patch is useless (fascinating history of the changelog there through).
fallback_alloc calls kmem_getpages without GFP_THISNODE. This means that
alloc_pages_node() will try to allocate on the current node but
Hi,
On Jan 23, 2008 9:52 PM, Nishanth Aravamudan [EMAIL PROTECTED] wrote:
On at least one of the machines in question, wasn't it the case that
node 0 had all the memory and node 1 had all the CPUs? In that case, you
would have to boot off a memoryless node? And as long as that is a
physically
Hi,
Mel Gorman wrote:
Faulting instruction address: 0xc03c8c00
cpu 0x0: Vector: 300 (Data Access) at [c05c3840]
pc: c03c8c00: __lock_text_start+0x20/0x88
lr: c00dadec: .cache_grow+0x7c/0x338
sp: c05c3ac0
msr: 80009032
dar:
Hi Olaf,
[Adding Christoph as cc.]
On Jan 15, 2008 5:09 PM, Olaf Hering [EMAIL PROTECTED] wrote:
Current linus tree crashes in kmem_cache_init, as shown below. The
system is a 8cpu 2.2GHz POWER5 system, model 9117-570, with 4GB ram.
Firmware is 240_332, 2.6.23 boots ok with the same config.
32 matches
Mail list logo
