g_eli kernel panic on freshly updated 6.3-STABLE

[Pascal Hofstee]

Today i took the time to update 2 workstations to a fresh RELENG_6
build (6.3-STABLE)
after they've been running on 6.2-STABLE for a long time.

To my surprise both systems now exhibit a 100% repeatable kernel panic
during boot directly
after/during the initialisation of the GELI module.

Console output shows

GEOM_ELI: Device ad10se.eli created.
GEOM_ELI: Encryption: AES-CBC-128
GEOM_ELI:        Crypto: software
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode

cpuid = 0; apic id = 00
fault virtual address                           = 0xf9
fault code                                          = supervisor read,
page not present
instruction pointer                             = 0x20:0xc0721420
stack pointer                                     = 0x28:0xe771fc10
frame pointer                                     = 0x28:0xe771fc18
code segment                                    = base 0x0, limit
0xffff, type 0x11b
                                                         = DPL 0, pres
1, def32 1, gran 1
processor eflags                                = resume, IOPL = 0
current process                                 = 44 (g_eli[1] ad10s1e
trap number                                      = 12
panic: page fault
cpuid = 0
uptime = 1s


Normally the first line on the console after the GEOM_ELI entries is
Trying to mount root from ufs:/dev/ad12s1a

I was lucky enough to be able to transplant a compatible
(6.3-PRERELEASE) kernel from a
system i had upgraded to a fresh RELENG_6 last friday to get these
systems in a workable
state again as the old 6.2-STABLE kernel turned out to no longer be
compatible with the
now 6.3 core userland (which was kinda to be expected).

This does mean though that the change that seems to cause this
instability must have made
its way into RELENG_6 somewhere between friday January 18th (afternoon
CET) and tuesday
January 22nd (around 14:00 CET). Considering that a kernel built from
fresh sources just before
that timeframe seems to work as expected.

Unfortunately i had to get these systems into a workable state ASAP
again so i was unable do
acquire a kernel dump. (Tried but the kernel kept insisting no
dumpdevice to be defined).

I hope the information may be useful regardless and would definitely
appreciate to be kept in
touch on any possible resolutions.

With kind regards,
-- 
  Pascal Hofstee