----- Original Message ----- > Hi all, > > I'm wondering about the use of the kernel 'nr_node_ids' variable in > memory.c. In kmem_cache_downsize(), vt->kmem_cache_len_nodes defaults > to 1 when 'nr_node_ids' isn't present. But in vm_init() an error > message is printed in the same case. The reason I'm asking is that I'm > getting that error > > "unable to initialize kmem slab cache subsystem" > > on a 3.4 kernel. Having vm_init() default to > > vt->kmem_cache_len_nodes=1 > > as well seems to bring up the slab subsystem, although I'm getting a > couple of > > "kmem: vm_area_struct: full list: slab: <nn1> bad next pointer: <nn2>" > > mixed into my kmem -S output. I have no idea if it's related. Hi Per,

I don't have any recent sample kernels that have the configuration that your kernel is running, so I can't confidently answer/test this. I presume that your kernel does not configure CONFIG_NODES_SHIFT (or set it to 0), so that nr_node_ids becomes a #define instead of a variable. And to get it

to work, I'm also presuming that you changed the "else" clause in vm_init() to something like this: if (MEMBER_TYPE("kmem_cache", "nodelists") == TYPE_CODE_PTR) { int nr_node_ids; /* * nodelists now a pointer to an outside array */ vt->flags |= NODELISTS_IS_PTR; if (kernel_symbol_exists("nr_node_ids")) { get_symbol_data("nr_node_ids", sizeof(int), &nr_node_ids); vt->kmem_cache_len_nodes = nr_node_ids; } else { - error(INFO, "nr_node_ids: symbol does not exist\n"); - error(INFO, "unable to initialize kmem slab cache subsystem\n\n"); - vt->flags |= KMEM_CACHE_UNAVAIL; + vt->kmem_cache_len_nodes = 1; }

That looks reasonable to me.

As far as the "kmem -S" output, are you running it on a live system?

Dave -- Crash-utility mailing list Crash-utility(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility

----- Original Message ----- > On Fri, Sep 7, 2012 at 4:28 PM, Dave Anderson <anderson(a)redhat.com&gt; > wrote: > > > > > > ----- Original Message ----- > >> Hi all, > >> > >> I'm wondering about the use of the kernel 'nr_node_ids' variable in > >> memory.c. In kmem_cache_downsize(), vt->kmem_cache_len_nodes defaults > >> to 1 when 'nr_node_ids' isn't present. But in vm_init() an error > >> message is printed in the same case. The reason I'm asking is that I'm > >> getting that error > >> > >> "unable to initialize kmem slab cache subsystem" > >> > >> on a 3.4 kernel. Having vm_init() default to > >> > >> vt->kmem_cache_len_nodes=1 > >> > >> as well seems to bring up the slab subsystem, although I'm getting a > >> couple of > >> > >> "kmem: vm_area_struct: full list: slab: <nn1> bad next pointer: <nn2>" > >> > >> mixed into my kmem -S output. I have no idea if it's related. > > > > Hi Per, > > Hello =o) > > > > > I don't have any recent sample kernels that have the configuration that your > > kernel is running, so I can't confidently answer/test this. I presume that > > your kernel does not configure CONFIG_NODES_SHIFT (or set it to 0), so > > that nr_node_ids becomes a #define instead of a variable. And to get it > > Indeed, that's exactly what happened. > > > to work, I'm also presuming that you changed the "else" clause in vm_init() > > to something like this: > > > > if (MEMBER_TYPE("kmem_cache", "nodelists") == TYPE_CODE_PTR) { > > int nr_node_ids; > > /* > > * nodelists now a pointer to an outside array > > */ > > vt->flags |= NODELISTS_IS_PTR; > > if (kernel_symbol_exists("nr_node_ids")) { > > get_symbol_data("nr_node_ids", sizeof(int), > > &nr_node_ids); > > vt->kmem_cache_len_nodes = nr_node_ids; > > } else { > > - error(INFO, "nr_node_ids: symbol does not exist\n"); > > - error(INFO, "unable to initialize kmem slab cache subsystem\n\n"); > > - vt->flags |= KMEM_CACHE_UNAVAIL; > > + vt->kmem_cache_len_nodes = 1; > > } > > Again, indeed, that's more or less to the character what I changed it to. > > > > > That looks reasonable to me. > > > > Ok, because that was the main purpose of my first mail, understanding > whether there was a reason why the 'nr_node_ids'-has-been-turned-into-a-macro-case > was treated as an error in this context. So, you agree we could change it? Yep -- it's queued for crash-6.1.0. > > > As far as the "kmem -S" output, are you running it on a live system? > > > > Nope, dead as a doornail. Are these messages to be expected then? Not really. You could follow the vm_area_struct's full-list in question and verify that something's out of whack, starting from the (single) kmem_cache->nodelists.slab_full linked list. The list should either point back to itself (empty) or be a simple list_head linked list, that leads to a slab with a next value of "nn2". Although, it would also be interesting to know what the "nn2" value was? In other words, was it a bogus address entirely, or a maybe an address in a page that wasn't capture in the dump? (which shouldn't happen...) It's here in verify_slab_v2(): list_head = (struct kernel_list_head *)(slab_buf + OFFSET(slab_list)); if (!IS_KVADDR((ulong)list_head->next) || !accessible((ulong)list_head->next)) { error(INFO, "%s: %s list: slab: %lx bad next pointer: %lx\n", si->curname, list, si->slab, (ulong)list_head->next); errcnt++; }

> Oh, and sorry for putting "[PATCH]" in the title when there wasn't > one. It was by accident. > > /Per No problem... Thanks, Dave -- Crash-utility mailing list Crash-utility(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility

I looked into this. The problem was with this particular dump (the next pointer was simply overwritten) and had nothing to do with Crash or the nr_node_ids change. Just wanted to let you know. /Per