I'll try the command-line option and see what I get. I thought about memory corruption, so ran memtest86 for a few hours with no errors (whatever that's worth). .....Ron Sent from my iPhone On Aug 5, 2015, at 12:09, Christoph Lameter <cl@xxxxxxxxx> wrote: >> [1.] One line summary of the problem: >> 4.1.4 -- Kernel Panic on shutdown > > This is a kfree of an object that was not allocated via the slab > allocators or was already freed. If you boot with the kernel command line > argument "slub_debug" then you could get some more information. Could also > be that memory was somehow corrupted. > > The backtrace shows that this is a call occurring in the > scheduler. > > CCing scheduler developers. > > > > Call Trace: > <IRQ> > [<ffffffff81072189>] free_sched_group+0x29/0x30 > [<ffffffff810721a0>] free_sched_group+rcu+0x10/0x20 > [<ffffffff81099771>] rcu_process_callbacks+0x231/0x510 > [<ffffffff81055cee>] __do_softirq+0xee/0x1e0 > [<ffffffff81055ef5>] irq_exit+0x55/0x60 > [<ffffffff810382f5>] smp_apic_timer_interrupt+0x45/0x60 > [<ffffffff815e4f5b>] apic_timer_interrupt+0x6b/0x70 > <EOI> > [<ffffffff81071b61>] ? finish_task_switch+0x61/0x100 > [<ffffffff814ddc7d>] ? cpuidle_enter_state+0xad/0x170 > [<ffffffff814ddc76>] ? cpuidle_enter_state+0xa6/0x170 > [<ffffffff814ddd62>] cpuidle_enter+0x12/0x20 > [<ffffffff810883a8>] cpu_startup_entry+0x268/0x2e0 > [<ffffffff81036437>] start_secondary+0x167/0x170 > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href