Kernel panic on boot at dm_crypt

[Stefan Unterweger]

Since I’m currently stuck staring at rebooting screeny anyway, I thought
I might as well copy the contents of the kernel page as plain text, for
easier reference.  I hope I haven’t mistyped too many of those horribly
long memory addresses in the process.


Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic->id    = 00000000
fault virtual address   = 0xffffffe07ff40318
fault code              = supervisor write data, page not present
instruction pointer     = 0x8:0xffffffff80606056
stack pointer           = 0x10:0xffffffe0b6140810
frame pointer           = 0x10:0xffffffe0b6140850
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 0, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = Idle
current thread          = pri 28 (CRIT)
kernel: type 12 trap, code=0

CPU0 stopping CPUs: 0x0000000e
 stopped
Stopped at     mpipe_alloc_callback+0x13d:    movq    %rcv,(%rax)
db>


Cheers,
    Stefan

* Stefan Unterweger on Tue, Jul 05, 2016 at 11:54:23PM +0200:
> Yet another problem on the same virtualised host as in the other thread
> a few weeks back.
> 
> As before, this is a presumably KVM virtualised host.  With the
> exception of a small boot partition, all storage volumes are encrypted
> via cryptsetup‘s LUKS mode.
> 
> It looks like a race condition of some weird sort, and there’s no doubt
> that the virtualisation is again playing tricks with me.  If I type in
> the password incorrectly, then it will most likely crash violently right
> there.  If typed in correctly, then in one of five it -might- boot.  The
> kernel panic is attached below.
> 
> The same thing happens if I boot the live CD and try to unlock the
> volumes there, or if I sometimes later want to attach further dm_crypt
> instances.  The probability of a crash seems to rise rather quickly with
> the number of CPU cores and the number of crypto volumes that need to be
> unlocked.
> 
> At this point, I sometimes need the better part of an hour to finally
> get the server to boot (the fiddlyness of virtual hoster‘s
> administration console adds considerably to this).  Any ideas, any
> patches?
> 
> I lack the skill to interpret what the kernel panic is trying
> to tell me.  Are there some knobs that I could tweak in the meantime?
> 
> Heartfelt thanks for anyone who can help,
>     Stefan
> 
> -- 
> Getting an inch of snow is like winning ten cents in the lottery!
> 		-- Calvin; "Calvin & Hobbes"




-- 
Diplomacy is being able to tell people to go to hell in such a way that
they actually look forward to the trip.