Re: Heads up - please recompile ifconfig if you're using wireless
On Friday, 22 April 2011, Adrian Chadd adr...@freebsd.org wrote: Hm, I'll revert this change for now. Sorry! Could you post a diff of your reverted change, I currently have no connectivity to be able to update src. Sevan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 g_eli_worker,
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' repeats 63 times, 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' repeats 63 times},
sc_ivkey = [scrubbed], sc_ivctx = {state = {0, 0, 0, 0, 0, 0, 0, 0},
bitcount = 0, buffer = '\0' repeats 63 times}, 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
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
Re: Heads up - please recompile ifconfig if you're using wireless
On 22 April 2011 15:20, Sevan / Venture37 ventur...@gmail.com wrote: On Friday, 22 April 2011, Adrian Chadd adr...@freebsd.org wrote: Hm, I'll revert this change for now. Sorry! Could you post a diff of your reverted change, I currently have no connectivity to be able to update src. or I could just pull the diff from the svn-src-head mailing list, thanks to Nick for the help. Sorry about the noise. Sevan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
bsd/linux ioctl.
So at work (fusion-io) we have a driver that runs on lots of OS,
including FreeBSD
(hint: ask your fio sales rep, it's not on the website!).
But as usual the BSD way of doing the copy in and out of user space
caused lots of grief.
Then suddenly I heard it was solved and I thought nothing more of it..
The following comment comes from the FreeBSD 'wrapper' in the driver,
talking about the ioctl code..
/* Define dir as void in FreeBSD to prevent*/
/* kernel from copying ioctl arguments in and */
/* out automatically. The driver expects to*/
/* deal with copying itself. We also need to */
/* specify zero as a argument size to force*/
/* generic IOCL code in kernel pointer to give */
/* us the raw userland pointer unchanged. */
So I never actually read this code before so my first reaction
was hmm that's neat, a cool workaround for people who want linux
or SysV compat ioctl behavior
So my first question is is this hack commonly known?
and secondly should we clean it up and put it in an ioctl(9) man page?
We should probably have such a page. Do we have a driver porter's
handbook?
a quick look failed to find any mention of this in any documentation.
Looking at ioctl we can see how this works:
Also see that because we force the size to be 0 or sizeof(int),
the driver has to know the size and can not do a size based version
check as is sometimes done.
It seems a pity to force the size and direction information to be lost.
is it really necessary? It seems to me that we could still allow current
behaviour but allow this information through by testing for IOC_VOID
in a few more places
and switching some of the tests around a bit..
from ioctl()
size = IOCPARM_LEN(com);
if ((size IOCPARM_MAX) ||
((com (IOC_VOID | IOC_IN | IOC_OUT)) == 0) ||
#if defined(COMPAT_FREEBSD5) || defined(COMPAT_FREEBSD4) ||
defined(COMPAT_43)
((com IOC_OUT) size == 0) ||
#else
((com (IOC_IN | IOC_OUT)) size == 0) ||
#endif
((com IOC_VOID) size 0 size != sizeof(int)))
return (ENOTTY);
if (size 0) {
if (com IOC_VOID) {
/* Integer argument. */
arg = (intptr_t)uap-data;
data = (void *)arg;
size = 0;
} else
data = malloc((u_long)size, M_IOCTLOPS,
M_WAITOK);
} else
data = (void *)uap-data;
if (com IOC_IN) {
error = copyin(uap-data, data, (u_int)size);
if (error) {
if (size 0)
free(data, M_IOCTLOPS);
return (error);
}
} else if (com IOC_OUT) {
/*
* Zero the buffer so the user always
* gets back something deterministic.
*/
bzero(data, size);
}
[...]
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
