>>> > 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++; >> } >> > > It certainly seems completely unrelated to the nr_node_ids question. > I'm guessing it's to do with the state of my dump, which isn't > accessible to me until after the weekend. In the unlikely event that > the fault's in Crash (see what what I did there?) I'm sure I'll be > back. > 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 > /Per > >>> 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@xxxxxxxxxx >> https://www.redhat.com/mailman/listinfo/crash-utility -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility