lock order reversal in sys/kern/vfs_mount.c
Good day, After updating to yesterdays -current, I got this on boot: lock order reversal: 1st 0xfe0007b04c38 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1254 2nd 0xfe0007ed9478 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x853 __lockmgr_args() at __lockmgr_args+0x113a vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b devfs_allocv() at devfs_allocv+0x13f devfs_root() at devfs_root+0x4d dounmount() at dounmount+0x45c vfs_unmountall() at vfs_unmountall+0x4c kern_reboot() at kern_reboot+0x84b sys_reboot() at sys_reboot+0x68 amd64_syscall() at amd64_syscall+0x2e0 Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ebbc, rsp = 0x7fffd6c8, rbp = 0x65 --- Reverting to old kernel (that was built about a week ago) helped to avoid this. Any thoughts? -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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
Re: lock order reversal in sys/kern/vfs_mount.c
Ruslan Mahmatkhanov wrote on 08.06.2012 12:10: Good day, After updating to yesterdays -current, I got this on boot: lock order reversal: 1st 0xfe0007b04c38 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1254 2nd 0xfe0007ed9478 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x853 __lockmgr_args() at __lockmgr_args+0x113a vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b devfs_allocv() at devfs_allocv+0x13f devfs_root() at devfs_root+0x4d dounmount() at dounmount+0x45c vfs_unmountall() at vfs_unmountall+0x4c kern_reboot() at kern_reboot+0x84b sys_reboot() at sys_reboot+0x68 amd64_syscall() at amd64_syscall+0x2e0 Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ebbc, rsp = 0x7fffd6c8, rbp = 0x65 --- Reverting to old kernel (that was built about a week ago) helped to avoid this. Any thoughts? And this one comes up with the recent update too: driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) cpu0: ACPI CPU on acpi0 driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu1: ACPI CPU on acpi0 driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu2: ACPI CPU on acpi0 driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu3: ACPI CPU on acpi0 What the additional info should I supply to understand what's wrong? Here is my full dmesg; http://people.freebsd.org/~rm/dmesg.txt -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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
How to add symbol to be exported in lib/libc/arm/Symbol.map
Hello group! I have a few questions regarding adding symbols to lib/libc/arch/Symbol.map, so that function signatures are exported: - what are the conventions regarding putting symbols in FBSD_X.Y or FBSDprivate_X.Y sections of the aforementioned files? - when it is necessary to bump X.Y numbers? - what is the difference between FBSD_X.Y and FBSDprivate_X.Y sections? The above questions arose from the discussion on freebsd-arm@ (http://lists.freebsd.org/pipermail/freebsd-arm/2012-June/003555.html) which concerns fixing Perl on ARM. The fix is to add __flt_rounds function signature to lib/libc/arm/Symbols.map. Regarding this fix it appears (after Symbols.map files analysis and checking their SVN history) that adding this symbol is just a bug fix and should be put to FBSD_1.0 section without incrementing numbers. But I don't have more in-depth explanation so sending this email. Anyone can comment on the above questions or point to some documentation (I've searched Developer's Handbook and Internet but found nothing)? Regards, Jan Sieka ___ 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
Re: lock order reversal in sys/kern/vfs_mount.c
On Friday, June 08, 2012 4:21:34 am Ruslan Mahmatkhanov wrote:
Ruslan Mahmatkhanov wrote on 08.06.2012 12:10:
Good day,
After updating to yesterdays -current, I got this on boot:
lock order reversal:
1st 0xfe0007b04c38 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1254
2nd 0xfe0007ed9478 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
_witness_debugger() at _witness_debugger+0x2c
witness_checkorder() at witness_checkorder+0x853
__lockmgr_args() at __lockmgr_args+0x113a
vop_stdlock() at vop_stdlock+0x39
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf
_vn_lock() at _vn_lock+0x47
vget() at vget+0x7b
devfs_allocv() at devfs_allocv+0x13f
devfs_root() at devfs_root+0x4d
dounmount() at dounmount+0x45c
vfs_unmountall() at vfs_unmountall+0x4c
kern_reboot() at kern_reboot+0x84b
sys_reboot() at sys_reboot+0x68
amd64_syscall() at amd64_syscall+0x2e0
Xfast_syscall() at Xfast_syscall+0xf7
--- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ebbc, rsp =
0x7fffd6c8, rbp = 0x65 ---
Reverting to old kernel (that was built about a week ago) helped to
avoid this. Any thoughts?
And this one comes up with the recent update too:
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
driver bug: Unable to set devclass (class: acpi_timer devname: (unknown))
cpu0: ACPI CPU on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
cpu1: ACPI CPU on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
cpu2: ACPI CPU on acpi0
driver bug: Unable to set devclass (class: acpi_sysresource devname:
(unknown))
cpu3: ACPI CPU on acpi0
What the additional info should I supply to understand what's wrong?
Here is my full dmesg; http://people.freebsd.org/~rm/dmesg.txt
Is this a verbose boot? Also, can you try this to get more details in
the log message:
Index: subr_bus.c
===
--- subr_bus.c (revision 236680)
+++ subr_bus.c (working copy)
@@ -1988,7 +1990,7 @@ device_probe_child(device_t dev, device_t child)
devclass_t dc;
driverlink_t best = NULL;
driverlink_t dl;
- int result, pri = 0;
+ int error, result, pri = 0;
int hasclass = (child-devclass != NULL);
GIANT_REQUIRED;
@@ -2019,17 +2021,18 @@ device_probe_child(device_t dev, device_t child)
else if (result != 0)
continue;
if (!hasclass) {
- if (device_set_devclass(child,
- dl-driver-name) != 0) {
+ error = device_set_devclass(child,
+ dl-driver-name);
+ if (error != 0) {
char const * devname =
device_get_name(child);
if (devname == NULL)
devname = (unknown);
printf(driver bug: Unable to set
devclass (class: %s
- devname: %s)\n,
+ devname: %s): %d\n,
dl-driver-name,
- devname);
+ devname, error);
(void)device_set_driver(child, NULL);
continue;
}
--
John Baldwin
___
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
Re: How to add symbol to be exported in lib/libc/arm/Symbol.map
On Fri, Jun 08, 2012 at 02:51:09PM +0200, Jan Sieka wrote: Hello group! I have a few questions regarding adding symbols to lib/libc/arch/Symbol.map, so that function signatures are exported: - what are the conventions regarding putting symbols in FBSD_X.Y or FBSDprivate_X.Y sections of the aforementioned files? FBSD_X.Y are for public interfaces, i.e. non-system code is supposed to link to symbols from that versions. FBSDprivate is for exclusive base system use (so to say). We do not guarantee ABI stability for private. - when it is necessary to bump X.Y numbers? Currently, it is done when major branch is created. - what is the difference between FBSD_X.Y and FBSDprivate_X.Y sections? This is a repeat. The above questions arose from the discussion on freebsd-arm@ (http://lists.freebsd.org/pipermail/freebsd-arm/2012-June/003555.html) which concerns fixing Perl on ARM. The fix is to add __flt_rounds function signature to lib/libc/arm/Symbols.map. Regarding this fix it appears (after Symbols.map files analysis and checking their SVN history) that adding this symbol is just a bug fix and should be put to FBSD_1.0 section without incrementing numbers. But I don't have more in-depth explanation so sending this email. No, since you are adding it in the CURRENT-10 timeframe, it goes to FBSD_1.3. Anyone can comment on the above questions or point to some documentation (I've searched Developer's Handbook and Internet but found nothing)? http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt In fact, I do not like this policy, and would some day write a proposal, which essentially requests creation of separate version for each ABI change. But what is referenced is the current accepted project policy. pgpKS5OS8RCrg.pgp Description: PGP signature
Re: lock order reversal in sys/kern/vfs_mount.c
Am 08.06.2012 10:10, schrieb Ruslan Mahmatkhanov: Good day, After updating to yesterdays -current, I got this on boot: lock order reversal: 1st 0xfe0007b04c38 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1254 2nd 0xfe0007ed9478 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2158 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x853 __lockmgr_args() at __lockmgr_args+0x113a vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b devfs_allocv() at devfs_allocv+0x13f devfs_root() at devfs_root+0x4d dounmount() at dounmount+0x45c vfs_unmountall() at vfs_unmountall+0x4c kern_reboot() at kern_reboot+0x84b sys_reboot() at sys_reboot+0x68 amd64_syscall() at amd64_syscall+0x2e0 Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ebbc, rsp = 0x7fffd6c8, rbp = 0x65 --- Reverting to old kernel (that was built about a week ago) helped to avoid this. Any thoughts? I have been getting those for a long time in -CURRENT, but with ZFS instead of UFS, and during system shutdown, not startup. And this LOR seems to cause the system to lock-up on shutdown with relatively high probability (I often have to remove power to halt the system, Since the ACPI power-off is not issued because of the LOR). My system is only rebooted from the local console and thus the LOR is not that much of a problem, and I did not bother to further look into the cause. But in case of remote system that is rebooted via SSH, the LOR could be quite a nuisance ... Regards, STefan ___ 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
