Re: Spinlock panic in FreeBSD 7
on 17/12/2011 00:38 Charlie Martin said the following: (This was originally posted to freebsd-hackers, I'm reposting following email suggestions.) We've observed a panic in FreeBSD 7 (7.2-PRERELEASE FreeBSD) several times that we've not been able to track down. Upgrading is not an option at this time. Does this look at all familiar to anyone? Here's an example stack trace after panic: See r219502. spin lock 0x8086bdc0 (smp rendezvous) held by 0xff0006d1f000 (tid 100060) too long panic: spin lock held too long cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x8019120a = db_trace_self_wrapper+0x2a panic() at 0x80308797 = panic+0x187 _mtx_lock_spin_failed() at 0x802fbda9 = _mtx_lock_spin_failed+0x39 _mtx_lock_spin() at 0x802fbe4e = _mtx_lock_spin+0x9e _mtx_lock_spin_flags() at 0x802fc354 = _mtx_lock_spin_flags+0x104 smp_rendezvous_cpus() at 0x80340cb3 = smp_rendezvous_cpus+0xd3 xcall() at 0x80ad755e = xcall+0x3e cyclic_remove_here() at 0x80ad7715 = cyclic_remove_here+0x1a5 cyclic_remove() at 0x80ad7a0f = cyclic_remove+0x5f profile_disable() at 0x80acf0e5 = profile_disable+0x15 dtrace_state_destroy() at 0x80adfabd = dtrace_state_destroy+0x35d dtrace_close() at 0x80adffed = dtrace_close+0x8d devfs_close() at 0x802a825d = devfs_close+0x2dd vn_close() at 0x8039cb06 = vn_close+0xb6 vn_closefile() at 0x8039cc00 = vn_closefile+0x80 devfs_close_f() at 0x802a5738 = devfs_close_f+0x28 fdrop() at 0x802d98bb = fdrop+0xdb closef() at 0x802db2f9 = closef+0x29 fdfree() at 0x802dc061 = fdfree+0x161 exit1() at 0x802e56b2 = exit1+0x2c2 sigexit() at 0x8030a86f = sigexit+0x8f postsig() at 0x8030b6ce = postsig+0x38e ast() at 0x803425f7 = ast+0x337 Xfast_syscall() at 0x80494efd = Xfast_syscall+0xdd --- syscall (32, FreeBSD ELF64, getsockname), rip = 0x800df4d5c, rsp = 0x7fffe398, rbp = 0x5 --- KDB: enter: panic The panic always shows up from a syscall, and almost always from syscall 32, getsockname, but we've also observed it with syscall 5. -- Andriy Gapon ___ 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: [head tinderbox] failure on mips/mips
On 17. Dec 2011, at 02:39 , Bjoern A. Zeeb wrote: On 16. Dec 2011, at 16:42 , Dimitry Andric wrote: On 2011-12-16 16:46, FreeBSD Tinderbox wrote: ... === usr.sbin/bsnmpd/modules/snmp_mibII (all) cc -fpic -DPIC -O -pipe -G0 -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/lib -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmpd -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_SYS_TREE_H -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c -o mibII.So cc1: warnings being treated as errors /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c: In function 'handle_rtmsg': /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:964: warning: cast increases required alignment of target type /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:991: warning: cast increases required alignment of target type This seems to be caused by the changes to struct ifa_msghdr in r228571. Gleb, can you please have a look at it? I did and started a universe and will commit as it finishes. Sorry it took a bit longer; should be fixed in r228623. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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
[head tinderbox] failure on mips/mips
TB --- 2011-12-17 10:38:16 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-17 10:38:16 - starting HEAD tinderbox run for mips/mips TB --- 2011-12-17 10:38:16 - cleaning the object tree TB --- 2011-12-17 10:38:25 - cvsupping the source tree TB --- 2011-12-17 10:38:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-12-17 10:38:55 - building world TB --- 2011-12-17 10:38:55 - CROSS_BUILD_TESTING=YES TB --- 2011-12-17 10:38:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-17 10:38:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-17 10:38:55 - SRCCONF=/dev/null TB --- 2011-12-17 10:38:55 - TARGET=mips TB --- 2011-12-17 10:38:55 - TARGET_ARCH=mips TB --- 2011-12-17 10:38:55 - TZ=UTC TB --- 2011-12-17 10:38:55 - __MAKE_CONF=/dev/null TB --- 2011-12-17 10:38:55 - cd /src TB --- 2011-12-17 10:38:55 - /usr/bin/make -B buildworld World build started on Sat Dec 17 10:38:56 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] building shared library snmp_hostres.so.6 sed -e 's%@MODPATH@%/usr/lib/%g' -e 's%@DEFPATH@%/usr/share/snmp/defs/%g'-e 's%@MIBSPATH@%/usr/share/snmp/mibs/%g' /src/usr.sbin/bsnmpd/modules/snmp_hostres/snmp_hostres.3 | gzip -cn snmp_hostres.3.gz === usr.sbin/bsnmpd/modules/snmp_mibII (all) cc -fpic -DPIC -O -pipe -G0 -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/lib -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmpd -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_SYS_TREE_H -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c -o mibII.So cc1: warnings being treated as errors /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c: In function 'handle_rtmsg': /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:964: warning: cast increases required alignment of target type /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:991: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules/snmp_mibII. *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules. *** Error code 1 Stop in /src/usr.sbin/bsnmpd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-12-17 11:33:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-17 11:33:05 - ERROR: failed to build world TB --- 2011-12-17 11:33:05 - 2313.39 user 637.45 system 3289.10 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ 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: 9.0-RC1 panic in tcp_input: negative winow.
On Mon, Dec 12, 2011 at 11:00:23AM -0500, John Baldwin wrote: An update. I've sent Pawel a testing patch to see if my hypothesis is correct (www.freebsd.org/~jhb/patches/tcp_negwin_test.patch). If it is then I intend to commit www.freebsd.org/~jhb/patches/tcp_negwin2.patch as the fix. Unfortunately it paniced today. Take a look at: http://people.freebsd.org/~pjd/misc/tcp_panic.jpg -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpdhigg3fyKF.pgp Description: PGP signature
Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662
Since three days for now I get a panic when I shutdown or reboot my FreeBSD 10.0-CURREN/amd64 box: Sleeping thread (tid 100033, pid 16) owns a non sleepable lock panic: sleeping thread cpuid = 0 PID 16 is always USB on my box. Any advice or tip to get rid of it? Oliver signature.asc Description: OpenPGP digital signature
Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662
On Sun, 18 Dec 2011 01:09:00 +0100 O. Hartmann ohart...@zedat.fu-berlin.de wrote: Sleeping thread (tid 100033, pid 16) owns a non sleepable lock panic: sleeping thread cpuid = 0 PID 16 is always USB on my box. You really need to give us a backtrace when you quote panics. It is impossible to make any sense of the above panic message without more context. -- Alexander Kabaev signature.asc Description: PGP signature
Re: SCHED_ULE should not be the default
On 13/12/2011 09:00, Andrey Chernov wrote: I observe ULE interactivity slowness even on single core machine (Pentium 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 second. When I switch back to SHED_4BSD, all slowness is gone. I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine with 16 logical CPUs. If I run tar xf somefile.tar and make -j16 buildworld then logging into another console can take several seconds. Sometimes even the Password: prompt can take a couple of seconds to appear after typing my username. -- Bruce Cran ___ 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: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662
On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev kab...@gmail.com wrote: On Sun, 18 Dec 2011 01:09:00 +0100 O. Hartmann ohart...@zedat.fu-berlin.de wrote: Sleeping thread (tid 100033, pid 16) owns a non sleepable lock panic: sleeping thread cpuid = 0 PID 16 is always USB on my box. You really need to give us a backtrace when you quote panics. It is impossible to make any sense of the above panic message without more context. In the case of this panic, the stack of the thread which panics is useless; it's someone trying to propagate priority that discovered it. A backtrace on tid 100033 would be useful. With WITNESS enabled, it's possible to have this panic display the stack of the incorrectly sleeping thread at the time it acquired the lock, as well, but this code isn't in CURRENT or any release. I have a patch at $WORK I can dig up on Monday. Cheers, matthew ___ 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: SCHED_ULE should not be the default
On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote: On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote: On 13/12/2011 09:00, Andrey Chernov wrote: I observe ULE interactivity slowness even on single core machine (Pentium 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 second. When I switch back to SHED_4BSD, all slowness is gone. I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine with 16 logical CPUs. If I run tar xf somefile.tar and make -j16 buildworld then logging into another console can take several seconds. Sometimes even the Password: prompt can take a couple of seconds to appear after typing my username. I'd resigned myself to expecting this sort of behaviour as 'normal' on my single core 1133MHz PIII-M. As a reproducable data point, running 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat the CPU while testing my manual fan control script, hogs it up pretty much while regularly running the script below in another konsole to check values - which often gets stuck half way, occasionally pausing _twice_ before finishing. Switching back to the first konsole (on another desktop) to kill the dd can also take a couple/few seconds. This issue not about slow machine under load, because the same slow machine under exact the same load, but with SCHED_4BSD is very fast to response interactively. I think we should not misinterpret interactivity with speed. I see no big speed (i.e. compilation time) differences, switching schedulers, but see big _interactivity_ difference. ULE in general tends to underestimate interactive processes in favour of background ones. It perhaps helps to compilation, but looks like slowpoke OS from the interactive user experience. -- http://ache.vniz.net/ ___ 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
