Re: panic: g_eli_key_hold: sc_ekeys_total=1
Fabian Keil wrote: > Fabian Keil wrote: > > > 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=1 > > cpuid = 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 > > 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 > > Which of course isn't the sector size normally > used for the swap device. > > The panic can be reproduced with: > /sbin/geli onetime -l 256 -s 4096 /dev/ada0s1b Somehow http://lists.freebsd.org/pipermail/freebsd-current/2011-April/024199.html and http://lists.freebsd.org/pipermail/freebsd-current/2011-April/024210.html haven't reached me. fk@r500 ~ $diskinfo -v /dev/ada0s1b /dev/ada0s1b 512 # sectorsize 2147483648 # mediasize in bytes (2.0G) 4194304 # mediasize in sectors 0 # stripesize 1073782272 # stripeoffset 4161# Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. 090509FB2F32LLEY6D8A# Disk ident. It is indeed fixed in r220984. Thanks, Pawel. Fabian signature.asc Description: PGP signature
Re: panic: g_eli_key_hold: sc_ekeys_total=1
On Sun, Apr 24, 2011 at 11:12:03AM +0200, Fabian Keil wrote: > The panic can be reproduced with: > /sbin/geli onetime -l 256 -s 4096 /dev/ada0s1b That's why I asked for ada0s1b size. It should be fixed in HEAD (r220984). -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpAuN5zvAX8k.pgp Description: PGP signature
Re: panic: g_eli_key_hold: sc_ekeys_total=1
Fabian Keil wrote:
> 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=1
> cpuid = 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/kernel/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 0x805354f7 in kern_reboot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:418
> #2 0x80534f91 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:591
> #3 0x811acab2 in g_eli_key_hold (sc=0xfe0005c33400, offset=0,
> blocksize=Variable "blocksize" is not available.
> ) at
> /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli_key_cache.c:266
> #4 0x811acdbc in g_eli_crypto_run (wr=0xfe0005cc3a80,
> bp=0xfe0005b9f0e8) at
> /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli_privacy.c:317
> #5 0x811a5301 in g_eli_worker (arg=Variable "arg" is not available.
> ) at /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli.c:519
> #6 0x80509845 in fork_exit (callout=0x811a4f20
> , arg=0xfe0005cc3a80, frame=0xff80e68d5c50) at
> /usr/src/sys/kern/kern_fork.c:920
> #7 0x807bd67e in fork_trampoline () at
> /usr/src/sys/amd64/amd64/exception.S:603
> [...]
> (kgdb) f 3
> #3 0x811acab2 in g_eli_key_hold (sc=0xfe0005c33400, offset=0,
> blocksize=Variable "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=%ju",
> __func__,
> (kgdb) p *sc
> $1 = {sc_geom = 0xfe00028a1000, sc_crypto = 2,
> sc_mkey = "[scrubbed]", sc_ekey = '\0' , sc_ekeys_queue =
> {tqh_first = 0xfe0005c2b380, tqh_last = 0xfe0005c2b3d0},
> sc_ekeys_tree = {rbh_root = 0xfe0005c2b380}, sc_ekeys_lock =
> {lock_object = {lo_name = 0x811adf38 "geli:ekeys", lo_flags =
> 16973824, lo_data = 0, lo_witness = 0x0},
> mtx_lock = 4}, sc_ekeys_total = 1, sc_ekeys_allocated = 1, sc_ealgo = 22,
> sc_ekeylen = 256,
> sc_akey = "[scrubbed]", sc_aalgo = 0, sc_akeylen = 0, sc_alen = 0,
> sc_akeyctx = {state = {0, 0, 0, 0, 0, 0, 0,
> 0}, bitcount = 0, buffer = '\0' },
> sc_ivkey = "[scrubbed]", sc_ivctx = {state = {0, 0, 0, 0, 0, 0, 0, 0},
> bitcount = 0, buffer = '\0' }, sc_nkey = -1, sc_flags =
> 13, sc_inflight = 1, sc_mediasize = 2147483648, sc_sectorsize = 4096,
> sc_bytes_per_sector = 0,
> sc_data_per_sector = 0, sc_queue = {queue = {tqh_first = 0x0, tqh_last =
> 0xfe0005c336a8}, last_offset = 2147479552, insert_point = 0x0},
> sc_queue_mtx = {lock_object = {
> lo_name = 0x811adf2d "geli:queue", lo_flags = 16973824, lo_data
> = 0, lo_witness = 0x0}, mtx_lock = 4}, sc_workers = {lh_first =
> 0xfe0005cc3a40}}
>
> 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
Which of course isn't the sector size normally
used for the swap device.
The panic can be reproduced with:
/sbin/geli onetime -l 256 -s 4096 /dev/ada0s1b
Fabian
signature.asc
Description: PGP signature
Re: panic: g_eli_key_hold: sc_ekeys_total=1
On Fri, Apr 22, 2011 at 05:04:01PM +0200, Fabian Keil wrote: > 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=1 > cpuid = 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 [...] Could you provide the output of: # diskinfo -v /dev/ada0s1b And could you try: # /sbin/geli onetime -l 256 -s 4096 /dev/ada0s1b -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgp1PdPS9g7QC.pgp Description: PGP signature
panic: g_eli_key_hold: sc_ekeys_total=1
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=1
cpuid = 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/kernel/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 0x805354f7 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:418
#2 0x80534f91 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:591
#3 0x811acab2 in g_eli_key_hold (sc=0xfe0005c33400, offset=0,
blocksize=Variable "blocksize" is not available.
) at /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli_key_cache.c:266
#4 0x811acdbc in g_eli_crypto_run (wr=0xfe0005cc3a80,
bp=0xfe0005b9f0e8) at
/usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli_privacy.c:317
#5 0x811a5301 in g_eli_worker (arg=Variable "arg" is not available.
) at /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli.c:519
#6 0x80509845 in fork_exit (callout=0x811a4f20 ,
arg=0xfe0005cc3a80, frame=0xff80e68d5c50) at
/usr/src/sys/kern/kern_fork.c:920
#7 0x807bd67e in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:603
[...]
(kgdb) f 3
#3 0x811acab2 in g_eli_key_hold (sc=0xfe0005c33400, offset=0,
blocksize=Variable "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=%ju",
__func__,
(kgdb) p *sc
$1 = {sc_geom = 0xfe00028a1000, sc_crypto = 2,
sc_mkey = "[scrubbed]", sc_ekey = '\0' , sc_ekeys_queue =
{tqh_first = 0xfe0005c2b380, tqh_last = 0xfe0005c2b3d0},
sc_ekeys_tree = {rbh_root = 0xfe0005c2b380}, sc_ekeys_lock = {lock_object
= {lo_name = 0x811adf38 "geli:ekeys", lo_flags = 16973824, lo_data = 0,
lo_witness = 0x0},
mtx_lock = 4}, sc_ekeys_total = 1, sc_ekeys_allocated = 1, sc_ealgo = 22,
sc_ekeylen = 256,
sc_akey = "[scrubbed]", sc_aalgo = 0, sc_akeylen = 0, sc_alen = 0, sc_akeyctx
= {state = {0, 0, 0, 0, 0, 0, 0,
0}, bitcount = 0, buffer = '\0' },
sc_ivkey = "[scrubbed]", sc_ivctx = {state = {0, 0, 0, 0, 0, 0, 0, 0},
bitcount = 0, buffer = '\0' }, sc_nkey = -1, sc_flags =
13, sc_inflight = 1, sc_mediasize = 2147483648, sc_sectorsize = 4096,
sc_bytes_per_sector = 0,
sc_data_per_sector = 0, sc_queue = {queue = {tqh_first = 0x0, tqh_last =
0xfe0005c336a8}, last_offset = 2147479552, insert_point = 0x0},
sc_queue_mtx = {lock_object = {
lo_name = 0x811adf2d "geli:queue", lo_flags = 16973824, lo_data =
0, lo_witness = 0x0}, mtx_lock = 4}, sc_workers = {lh_first =
0xfe0005cc3a40}}
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 DumpPass#
/dev/ada0s1b.eli noneswapsw 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="YES"
geli_ada0s1d_keyfile0_type="ada0s1d:geli_keyfile0"
geli_ada0s1d_keyfile0_name="[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
signature.asc
Description: PGP signature
