Kernel panic on boot at dm_crypt

[Stefan Unterweger]

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"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5GG5+bh13 ? calmisdelvini png-#01173.png
Type: image/png
Size: 20802 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20160705/376d40a6/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5GG5+bh13 ? calmisdelvini png-#01174.png
Type: image/png
Size: 20975 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20160705/376d40a6/attachment-0007.png>