Date: Fri, 22 Apr 2011 17:04:01 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: FreeBSD-Current <freebsd-current@freebsd.org> Cc: Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: panic: g_eli_key_hold: sc_ekeys_total=1 Message-ID: <20110422170401.4847857d@fabiankeil.de>
next in thread | raw e-mail | index | archive | help
--Sig_/cDBZtPrS/4M1Nd37ARP9ivI
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
With sources from today my system panics at boot time
after attaching the swap device:
GEOM_ELI: Device ada0s1b.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI: Crypto: software
panic: g_eli_key_hold: sc_ekeys_total=3D1
cpuid =3D 0
KDB: enter: panic
Uptime: 2m16s
Physical memory: 1974 MB
Dumping 213 MB: 198 182 166 150 134 118 102 86 70 54 38 22 6
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kerne=
l/zfs.ko.symbols...done.
done.
[...]
Loaded symbols for /boot/kernel/acpi_ibm.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250
250 if (textdump_pending)
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250
#1 0xffffffff805354f7 in kern_reboot (howto=3D260) at /usr/src/sys/kern/ke=
rn_shutdown.c:418
#2 0xffffffff80534f91 in panic (fmt=3DVariable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:591
#3 0xffffffff811acab2 in g_eli_key_hold (sc=3D0xfffffe0005c33400, offset=
=3D0, blocksize=3DVariable "blocksize" is not available.
) at /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli_key_cache.c=
:266
#4 0xffffffff811acdbc in g_eli_crypto_run (wr=3D0xfffffe0005cc3a80, bp=3D0=
xfffffe0005b9f0e8) at /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/=
g_eli_privacy.c:317
#5 0xffffffff811a5301 in g_eli_worker (arg=3DVariable "arg" is not availab=
le.
) at /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli.c:519
#6 0xffffffff80509845 in fork_exit (callout=3D0xffffffff811a4f20 <g_eli_wo=
rker>, arg=3D0xfffffe0005cc3a80, frame=3D0xffffff80e68d5c50) at /usr/src/sy=
s/kern/kern_fork.c:920
#7 0xffffffff807bd67e in fork_trampoline () at /usr/src/sys/amd64/amd64/ex=
ception.S:603
[...]
(kgdb) f 3
#3 0xffffffff811acab2 in g_eli_key_hold (sc=3D0xfffffe0005c33400, offset=
=3D0, blocksize=3DVariable "blocksize" is not available.
) at /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli_key_cache.c=
:266
266 KASSERT(sc->sc_ekeys_total > 1, ("%s: sc_ekeys_total=3D%ju"=
, __func__,
(kgdb) p *sc
$1 =3D {sc_geom =3D 0xfffffe00028a1000, sc_crypto =3D 2,=20
sc_mkey =3D "[scrubbed]", sc_ekey =3D '\0' <repeats 63 times>, sc_ekeys_q=
ueue =3D {tqh_first =3D 0xfffffe0005c2b380, tqh_last =3D 0xfffffe0005c2b3d0=
},=20
sc_ekeys_tree =3D {rbh_root =3D 0xfffffe0005c2b380}, sc_ekeys_lock =3D {l=
ock_object =3D {lo_name =3D 0xffffffff811adf38 "geli:ekeys", lo_flags =3D 1=
6973824, lo_data =3D 0, lo_witness =3D 0x0},=20
mtx_lock =3D 4}, sc_ekeys_total =3D 1, sc_ekeys_allocated =3D 1, sc_eal=
go =3D 22, sc_ekeylen =3D 256,=20
sc_akey =3D "[scrubbed]", sc_aalgo =3D 0, sc_akeylen =3D 0, sc_alen =3D 0=
, sc_akeyctx =3D {state =3D {0, 0, 0, 0, 0, 0, 0,=20
0}, bitcount =3D 0, buffer =3D '\0' <repeats 63 times>},=20
sc_ivkey =3D "[scrubbed]", sc_ivctx =3D {state =3D {0, 0, 0, 0, 0, 0, 0, =
0},=20
bitcount =3D 0, buffer =3D '\0' <repeats 63 times>}, sc_nkey =3D -1, sc=
_flags =3D 13, sc_inflight =3D 1, sc_mediasize =3D 2147483648, sc_sectorsiz=
e =3D 4096, sc_bytes_per_sector =3D 0,=20
sc_data_per_sector =3D 0, sc_queue =3D {queue =3D {tqh_first =3D 0x0, tqh=
_last =3D 0xfffffe0005c336a8}, last_offset =3D 2147479552, insert_point =3D=
0x0}, sc_queue_mtx =3D {lock_object =3D {
lo_name =3D 0xffffffff811adf2d "geli:queue", lo_flags =3D 16973824, l=
o_data =3D 0, lo_witness =3D 0x0}, mtx_lock =3D 4}, sc_workers =3D {lh_firs=
t =3D 0xfffffe0005cc3a40}}
Before the panic, the geli provider (AES-CBC 128) for the ZFS pool
is attached without issues. Attaching geli providers located on
USB disks doesn't seem to cause issues either, and I haven't
been able to reproduce the panic by manually running:
/sbin/geli onetime -l 256 /dev/ada0s1b
swapon /dev/ada0s1b.eli
once the system was up. Booting normally, or leaving single-user
mode seems to reliably reproduce the problem after the swap device
is attached, though.
My /etc/fstab is:
# Device Mountpoint FStype Options Dump Pass#
/dev/ada0s1b.eli none swap sw 0 0
/dev/ada0s1a / ufs rw 1 1
/dev/cd0 /cdrom cd9660 ro,noauto 0 0
The ZFS pool is attached with the /boot/loader.conf entries:
geli_ada0s1d_keyfile0_load=3D"YES"
geli_ada0s1d_keyfile0_type=3D"ada0s1d:geli_keyfile0"
geli_ada0s1d_keyfile0_name=3D"[scrubbed]"
The KASSERT seems to originate from r220922, so it's not particularly
surprising that my previous kernel from Tue Apr 19 23:39:24 CEST 2011
is unaffected.
Fabian
--Sig_/cDBZtPrS/4M1Nd37ARP9ivI
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)
iEYEARECAAYFAk2xmOQACgkQBYqIVf93VJ3udACfU8aEdSUphjaYkedHxC2gvgUk
SJAAoMSyT1ef/zZGmGxwYkkw1LLM75JY
=kJl3
-----END PGP SIGNATURE-----
--Sig_/cDBZtPrS/4M1Nd37ARP9ivI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110422170401.4847857d>