Hi Jean-Yves,thanks for your answer. I have discovered additional peculiarities and have to think a bit on getting a clean test environment before doing anything else.
I will look at your suggestions next week. Best regards, Dirk Jean-Yves Migeon schrieb:
Dirk H. Schulz wrote:This kernel repeatedly crashed the Debian dom0 kernel; I tested that on 2 different servers (one dual PIII, where the crash happened within an hour, and one Dual Xeon 3.2 GHz, where the crashes took a few hours to happen).At the moment this is simply a coincidence (as the Debian dom0 kernels crash every few weeks anyway), but in the case of the self built domU kernel the dom0 kernel crashes looked different: no error output, just a blank screen.>After disabling the self compiled kernel everything went back to normal.First question of course is: Is it technically possible that the dom0 kernel crashes are related to the NMBCLUSTERS parameter in the domU kernel?Unlikely. nmbclusters is a value arbitrarily defined to tweak the pool_cache(9) routines (similar to Linux slab allocator) used for allocation/deallocation of mbufs.One thing is evident, domU should not crash dom0, whatever happened in the domU. Xen's role being limited when dealing with heavy I/O, I dare say that something is wrong within dom0.Next one of course: Is this a known problem? Is there a workaround? I would very much love to test NetBSD as domU for high load use.Well, you do have a workaround, by decreasing the number of mbuf clusters. Yes, it does not sound reasonable.Perhaps faulty hardware?Does it happen when you change the nmbclusters dynamically? (sysctl -w kern.mbuf.nmbclusters=...)