All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Chiang <achiang@hp.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
	linux-ia64@vger.kernel.org, linux-mm@kvack.org
Subject: Re: SLUB ia64 linux-next crash bisected to 756dee75
Date: Thu, 14 Jan 2010 21:29:33 +0000	[thread overview]
Message-ID: <20100114212933.GK4545@ldl.fc.hp.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1001141457250.19915@router.home>

* Christoph Lameter <cl@linux-foundation.org>:
> On Thu, 14 Jan 2010, Alex Chiang wrote:
> 
> > coffee0:/usr/src/linux-2.6 # addr2line 0xa0000001001add60 -e vmlinux
> > /usr/src/linux-2.6/include/linux/mm.h:543
> >
> >  538 #ifdef NODE_NOT_IN_PAGE_FLAGS
> >  539 extern int page_to_nid(struct page *page);
> >  540 #else
> >  541 static inline int page_to_nid(struct page *page)
> >  542 {
> >  543         return (page->flags >> NODES_PGSHIFT) & NODES_MASK;
> >  544 }
> >  545 #endif
> 
> That may mean that early_kmem_node_alloc gets a screwy page number from
> the page allocator? ????
> 
> Can you print the address of page returned from new_slab() in
> early_kmem_cache_node_alloc()?

diff --git a/mm/slub.c b/mm/slub.c
index 9e86e6b..2909cc4 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2062,7 +2062,7 @@ init_kmem_cache_node(struct kmem_cache_node *n, struct kme
m_cache *s)
 #endif
 }
 
-static DEFINE_PER_CPU(struct kmem_cache_cpu, kmalloc_percpu[SLUB_PAGE_SHIFT]);
+static DEFINE_PER_CPU(struct kmem_cache_cpu, kmalloc_percpu[KMALLOC_CACHES]);
 
 static inline int alloc_kmem_cache_cpus(struct kmem_cache *s, gfp_t flags)
 {
@@ -2100,6 +2100,7 @@ static void early_kmem_cache_node_alloc(gfp_t gfpflags, in
t node)
        BUG_ON(kmalloc_caches->size < sizeof(struct kmem_cache_node));
 
        page = new_slab(kmalloc_caches, gfpflags, node);
+       printk("page from new_slab() %#llx\n", page);
 
        BUG_ON(!page);
        if (page_to_nid(page) != node) {

Memory: 66849344k/66910528k available (8033k code, 110720k reserved, 10805k data, 1984k init)
page from new_slab() 0xa07fffffff900000
page from new_slab() 0xa07fffffe39000e0
SLUB: Unable to allocate memory from node 2
SLUB: Allocating a useless per node structure in order to be able to continue
SLUB: Genslabs\x18, HWalign\x128, Order=0-3, MinObjects=0, CPUs\x16, Nodes\x1024

[...]

Unable to handle kernel paging request at virtual address a07ffffe5a7838a8
modprobe[6043]: Oops 8813272891392 [1]
Modules linked in: sr_mod(+) sg container(+) button usbhid ohci_hcd ehci_hcd usbcore fan thermal processor thermal_sys

Pid: 6043, CPU 9, comm:             modprobe
psr : 0000101008526010 ifs : 8000000000000b1d ip  : [<a0000001001add60>]    Not tainted (2.6.33-rc3-next-20100111-dirty)
ip is at kmem_cache_open+0x420/0xb40


WARNING: multiple messages have this Message-ID (diff)
From: Alex Chiang <achiang@hp.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
	linux-ia64@vger.kernel.org, linux-mm@kvack.org
Subject: Re: SLUB ia64 linux-next crash bisected to 756dee75
Date: Thu, 14 Jan 2010 14:29:33 -0700	[thread overview]
Message-ID: <20100114212933.GK4545@ldl.fc.hp.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1001141457250.19915@router.home>

* Christoph Lameter <cl@linux-foundation.org>:
> On Thu, 14 Jan 2010, Alex Chiang wrote:
> 
> > coffee0:/usr/src/linux-2.6 # addr2line 0xa0000001001add60 -e vmlinux
> > /usr/src/linux-2.6/include/linux/mm.h:543
> >
> >  538 #ifdef NODE_NOT_IN_PAGE_FLAGS
> >  539 extern int page_to_nid(struct page *page);
> >  540 #else
> >  541 static inline int page_to_nid(struct page *page)
> >  542 {
> >  543         return (page->flags >> NODES_PGSHIFT) & NODES_MASK;
> >  544 }
> >  545 #endif
> 
> That may mean that early_kmem_node_alloc gets a screwy page number from
> the page allocator? ????
> 
> Can you print the address of page returned from new_slab() in
> early_kmem_cache_node_alloc()?

diff --git a/mm/slub.c b/mm/slub.c
index 9e86e6b..2909cc4 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2062,7 +2062,7 @@ init_kmem_cache_node(struct kmem_cache_node *n, struct kme
m_cache *s)
 #endif
 }
 
-static DEFINE_PER_CPU(struct kmem_cache_cpu, kmalloc_percpu[SLUB_PAGE_SHIFT]);
+static DEFINE_PER_CPU(struct kmem_cache_cpu, kmalloc_percpu[KMALLOC_CACHES]);
 
 static inline int alloc_kmem_cache_cpus(struct kmem_cache *s, gfp_t flags)
 {
@@ -2100,6 +2100,7 @@ static void early_kmem_cache_node_alloc(gfp_t gfpflags, in
t node)
        BUG_ON(kmalloc_caches->size < sizeof(struct kmem_cache_node));
 
        page = new_slab(kmalloc_caches, gfpflags, node);
+       printk("page from new_slab() %#llx\n", page);
 
        BUG_ON(!page);
        if (page_to_nid(page) != node) {

Memory: 66849344k/66910528k available (8033k code, 110720k reserved, 10805k data, 1984k init)
page from new_slab() 0xa07fffffff900000
page from new_slab() 0xa07fffffe39000e0
SLUB: Unable to allocate memory from node 2
SLUB: Allocating a useless per node structure in order to be able to continue
SLUB: Genslabs=18, HWalign=128, Order=0-3, MinObjects=0, CPUs=16, Nodes=1024

[...]

Unable to handle kernel paging request at virtual address a07ffffe5a7838a8
modprobe[6043]: Oops 8813272891392 [1]
Modules linked in: sr_mod(+) sg container(+) button usbhid ohci_hcd ehci_hcd usbcore fan thermal processor thermal_sys

Pid: 6043, CPU 9, comm:             modprobe
psr : 0000101008526010 ifs : 8000000000000b1d ip  : [<a0000001001add60>]    Not tainted (2.6.33-rc3-next-20100111-dirty)
ip is at kmem_cache_open+0x420/0xb40

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-01-14 21:29 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-13  0:29 SLUB ia64 linux-next crash bisected to 756dee75 Alex Chiang
2010-01-13 14:59 ` Christoph Lameter
2010-01-13 14:59   ` Christoph Lameter
2010-01-14  0:53   ` Alex Chiang
2010-01-14  0:53     ` Alex Chiang
2010-01-14 15:01     ` Christoph Lameter
2010-01-14 15:01       ` Christoph Lameter
2010-01-14 18:01       ` Alex Chiang
2010-01-14 18:01         ` Alex Chiang
2010-01-14 15:18 ` Christoph Lameter
2010-01-14 15:18   ` Christoph Lameter
2010-01-14 18:22   ` Alex Chiang
2010-01-14 18:22     ` Alex Chiang
2010-01-14 19:17     ` Pekka Enberg
2010-01-14 19:17       ` Pekka Enberg
2010-01-14 20:32       ` Alex Chiang
2010-01-14 20:32         ` Alex Chiang
2010-01-14 20:58         ` Christoph Lameter
2010-01-14 20:58           ` Christoph Lameter
2010-01-14 21:29           ` Alex Chiang [this message]
2010-01-14 21:29             ` Alex Chiang
2010-01-14 21:31             ` Pekka Enberg
2010-01-14 21:31               ` Pekka Enberg
2010-01-14 21:59               ` Christoph Lameter
2010-01-14 21:59                 ` Christoph Lameter
2010-01-14 22:01             ` Christoph Lameter
2010-01-14 22:01               ` Christoph Lameter
2010-01-15 20:07 ` Christoph Lameter
2010-01-15 20:07   ` Christoph Lameter
2010-01-15 20:35   ` Lee Schermerhorn
2010-01-15 20:35     ` Lee Schermerhorn
2010-01-15 23:32     ` Christoph Lameter
2010-01-15 23:32       ` Christoph Lameter
2010-01-19 18:53       ` Christoph Lameter
2010-01-19 18:53         ` Christoph Lameter
2010-01-19 20:02         ` Alex Chiang
2010-01-19 20:02           ` Alex Chiang
2010-01-19 20:29           ` Christoph Lameter
2010-01-19 20:29             ` Christoph Lameter
2010-01-19 21:29             ` Alex Chiang
2010-01-19 21:29               ` Alex Chiang
2010-01-19 21:50               ` Christoph Lameter
2010-01-19 21:50                 ` Christoph Lameter
2010-01-20 22:46                 ` Alex Chiang
2010-01-20 22:46                   ` Alex Chiang
2010-01-21 21:47                 ` Alex Chiang
2010-01-21 21:47                   ` Alex Chiang
2010-01-21 22:45                   ` Christoph Lameter
2010-01-21 22:45                     ` Christoph Lameter
2010-01-21 23:05                     ` Alex Chiang
2010-01-21 23:05                       ` Alex Chiang
2010-01-21 23:43                       ` Christoph Lameter
2010-01-21 23:43                         ` Christoph Lameter
2010-01-22  0:15                         ` Alex Chiang
2010-01-22  0:15                           ` Alex Chiang
2010-01-22 14:43                           ` Christoph Lameter
2010-01-22 14:43                             ` Christoph Lameter
2010-01-22 16:37                             ` Pekka Enberg
2010-01-22 16:37                               ` Pekka Enberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100114212933.GK4545@ldl.fc.hp.com \
    --to=achiang@hp.com \
    --cc=cl@linux-foundation.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@cs.helsinki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.