Re: lock order reversal in sys/kern/vfs_mount.c
John Baldwin wrote on 08.06.2012 18:45: 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: on acpi0 driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu1: on acpi0 driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu2: on acpi0 driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu3: 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: Sorry for delay. This particular panic had triggered by intel video driver (x11-drivers/xf86-video-intel v 2.19.0). After I rebuild it with new kernel, all is going fine. The panic appeared after GDM login, and I was able to catch some driver-related errors in xorg log. Thanks John. -- 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
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"
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: on acpi0 > driver bug: Unable to set devclass (class: acpi_sysresource devname: > (unknown)) > cpu1: on acpi0 > driver bug: Unable to set devclass (class: acpi_sysresource devname: > (unknown)) > cpu2: on acpi0 > driver bug: Unable to set devclass (class: acpi_sysresource devname: > (unknown)) > cpu3: 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: 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: on acpi0 driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu1: on acpi0 driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu2: on acpi0 driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu3: 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"
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"