Re: Debugging kernel memory allocation

[Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>]

Rich Neswold <rich.neswold%gmail.com@localhost> writes:

> Had several stalls on Sunday morning on the 8-core Dell. I moved the
> services over to the 4-core machine. Now I can do testing on the 8-core and
> the 4-core has been running well.

Good!  :)

> Tom, what information are you looking for? I can provide details from my
> machine, as well. I know some of the things you looked at didn't shed much
> light.

I'm beginning to think that I have two (possibly related) problems: one
involves being unable to allocate pages, and has been reduced by doing
this, to keep more of them available most of the time:

--- uvm_pdaemon.c	25 Oct 2013 20:28:33 -0000	1.108
+++ uvm_pdaemon.c	2 Dec 2014 18:20:47 -0000
@@ -203,7 +203,7 @@
 	 */
 	val = uvmexp.npages / 200;
 	val = MAX(val, (128*1024) >> PAGE_SHIFT);
-	val = MIN(val, (1024*1024) >> PAGE_SHIFT);
+	/* val = MIN(val, (1024*1024) >> PAGE_SHIFT); */
 	val *= ncpu;
 
 	/* Make sure there's always a user page free. */

The other problem seems to be that I'm missing interrupts from the disk
controller in the 2850.  I finally managed to get on the console during
a hang yesterday, and get backtraces for all four CPUs, and they were
all idle.  Simplified log, copied out by hand:

> machine cpu 0
> bt
printf()
kdb_trap()
trap()
--- trap
x86_stihlt()
acpicpu_cstate_idle_enter()
acpicpu_cstate_idle()
idle_loop()
> machine cpu 1
> bt
x86_stihlt()
acpicpu_cstate_idle_enter()
acpicpu_cstate_idle()
idle_loop()
cpu_hatch()
mpt_pci_attach()
> machine cpu 2
> bt
printf()
kdb_trap()
trap()
--- trap
x86_stihlt()
acpicpu_cstate_idle_enter()
acpicpu_cstate_idle()
idle_loop()
cpu_hatch()
mpt_pci_attach()
> machine cpu 3
> bt
printf()
kdb_trap()
trap()
--- trap
x86_stihlt()
acpicpu_cstate_idle_enter()
acpicpu_cstate_idle()
idle_loop()
cpu_hatch()
mpt_pci_attach()

-tih
-- 
It doesn't matter how beautiful your theory is, it doesn't matter how smart
you are. If it doesn't agree with experiment, it's wrong.  -Richard Feynman