On Fri, 2013-12-06 at 05:35 -0700, Lisa Mitchell wrote: > On Thu, 2013-12-05 at 21:58 +0000, Hoemann, Jerry wrote: > > > > Sorry if you're getting multiple copies, but i have had problems with > > my subscription to the kexec mailing list and am resending. > > > > > > > > On Tue, Dec 03, 2013 at 10:25:36AM -0500, Vivek Goyal wrote: > > > > > > Hi Hatayama, > > > > > > We are almost there. A minor nit. Why have we specified KEXEC here. This > > > parameter disabled_cpu_apicid does not seem to dependon CONFIG_KEXEC? > > > > > > Jerry, this patch looks good to me. Does it work on your system? > > > > > > Thanks > > > Vivek > > > > > > Vivek, Hatayama, > > > > I've back ported v9 of this patch to 2.6.32 and 3.0.80 based kernels to > > test with existing distros. > > > > I've tested on our smaller prototype server specifying nr_cpus=8/maxcpus=8 > > to the capture kernel. One hundred iterations (echo c > /proc/sysrq-trigger) > > varying target cpu and system load to each kernel. > > > > The 2.6.32 based distro kernel showed the < 5% soft lockup > > (still unresolved) during boot of capture kernel. This is > > something i've seen on all versions of the patch that i've tested. > > > > The 3.0.80 based distro kernel has had zero failures. > > > > I have not had a chance to test upstream kernels or on > > our larger prototype configuration. > > > > We still plan to test on our larger prototype. Testing of > > prior versions of the patch on the larger systems didn't show > > problems w/ this functionality and I don't anticipate we'll > > find anything this time either. > > > > I am okay with this patch being accepted upstream and working > > the intermittent 2.6.32 failures separately. > > > > > > Jerry > > > > Another update, I have tested our max cpu configuration prototype, with > a fairly large IO config with the backported 3.0.80 kernel Jerry > mentions above with the v9 patch backported, and this system got 7 out > of 7 successful dumps, with max_cpus=8, so far in testing. This system > has a a fairly large IO configuration too, such that intermittently > booting the crashkernel with 1 cpu the crashkernel boot would hang due > to IRQ for system disk not getting assigned. So this is early > indication that this patch is working well on larger IO configurations. > > I plan to test with the 2.6.32 base with v9 patch over the weekend on > this large configuration. The system takes much longer to dump than > the minimum config, so it is harder to build up as many iterations over > a short time, plus I have to share the system with others. > > Thanks, > > Lisa Mitchell > I have now tested the version 9 patch on a 2.6.32 base on the max cpu/large IO configuration, and got 8 out of 8 successful dumps, (7 with nr_cpus=8, and one with nr_cpus=16).
