Athough I seem to be talking to myself here, I have good news for RC2!
Just did an "freebsd-update -R 8.0-RC2 upgrade". Both GENERIC and
XENHVM kernels work without any problems.
Maybe somebody else can chime in an confirm that, too? Probably good
for the developers to see positive feedback, while 8.0-RELEASE is
coming closer :-)
On 25 Oct 2009, at 00:31, Carsten Heesch wrote:
I realised that it's still possible to use 8.0-BETA* as a target for
freebsd-update. So I investigated a bit further. For whatever it's
The problems described earlier started with BETA-4.
BETA-3 is fine with both GENERIC and XENHVM kernel, except that I
see this on the console and in dmesg every now and then (with both
lock order reversal:
1st 0xffffff8014810620 bufwait (bufwait) @ /usr/src/sys/kern/
2nd 0xffffff00015a7c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
_sx_xlock() at _sx_xlock+0x55
ufsdirhash_acquire() at ufsdirhash_acquire+0x33
ufsdirhash_add() at ufsdirhash_add+0x19
ufs_direnter() at ufs_direnter+0x88b
ufs_makeinode() at ufs_makeinode+0x31c
VOP_CREATE_APV() at VOP_CREATE_APV+0x8d
vn_open_cred() at vn_open_cred+0x423
kern_openat() at kern_openat+0x179
syscall() at syscall+0x1af
Xfast_syscall() at Xfast_syscall+0xe1
--- syscall (5, FreeBSD ELF64, open), rip = 0x800e32dfc, rsp =
0x7fffffffe608, rbp = 0x1a4 ---
I though this might be XENHVM kernel related, but it happens with
GENERIC kernel as well. Not sure if this is related to XEN at all.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"