search for: kdb_backtrac

...xfffff800122f8200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 messages-Sep 26 02:01:27 leader kernel: KDB: stack backtrace: messages-Sep 26 02:01:27 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0238a8f270 messages-Sep 26 02:01:27 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0238a8f320 messages-Sep 26 02:01:27 leader kernel: witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe0238a8f3b0 messages-Sep 26 02:01:27 leader kernel: _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe0238a8f3f0 messages-Sep 26 02:01:27 leader kerne...

...s 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (zio_write_issue_hig) trap number = 12 panic: page fault cpuid = 22 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffffcf75bd5b30 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffffcf75bd5bf0 panic() at panic+0x1ce/frame 0xffffffcf75bd5cf0 trap_fatal() at trap_fatal+0x290/frame 0xffffffcf75bd5d50 trap_pfault() at trap_pfault+0x211/frame 0xffffffcf75bd5de0 trap() at trap+0x344/frame 0xffffffcf75bd5fe0 calltrap() at calltrap+0x8/frame 0xff...

...le acting as an sftp server receiving large (GB) files from another system. Fri Sep 20 16:48:34 2013 +1000 ozsrv04# kgdb kernel.debug /var/crash/vmcore.0 ... panic: vm_page_unwire: page 0xfffffe0233510578's wire count is zero cpuid = 3 KDB: stack backtrace: #0 0xffffffff80490268 at kdb_backtrace+0x68 #1 0xffffffff8045630a at panic+0x21a #2 0xffffffff8068bbc2 at vm_page_unwire+0x102 #3 0xffffffff80678702 at vm_fault_unwire+0xd2 #4 0xffffffff80680841 at vm_map_delete+0x171 #5 0xffffffff80680abf at vm_map_remove+0x5f #6 0xffffffff80683ee9 at vmspace_exit+0xc9 #7 0xffffffff8041f...

9.2 PRERELEASE (today) / amd64 Hello, I'm seeing a panic while trying to build a poudriere repository. As far I can see it always happens when gam_server is started (ie xfce is running) and under disk load (poudriere bulk build) : (That is something new, the box was pretty stable) the complete crash dump (core.0.txt) is here: http://user.lamaiziere.net/patrick/panic_gam_server.txt Fatal

...ordinate bus 7 pcib7: no prefetched decode device_attach: pcib7 attach returned 6 pcib7: <ACPI PCI-PCI bridge> irq 19 at device 28.7 on pci0 panic: Bad tailq NEXT(0xffffffff80e52660->tqh_last) != NULL cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 rman_init() at rman_init+0x17c pcib_alloc_window() at pcib_alloc_window+0x9f pcib_attach_common() at pcib_attach_common+0x457 acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x1c device_attach() at device_attach+0x72 bus_generic_attach() at bus_generic...

...0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/sys/kern/kern_cons.c:500 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff9185023940 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff9185023a00 panic() at panic+0x1d8/frame 0xffffff9185023b00 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x123/frame 0xffffff9185023b40 cnputs() at cnputs+0x7a/frame 0xffffff9185023b60 putbuf() at putbuf+0xbf/frame 0xffffff9185023be0 kvprintf() at kvprintf+0x...

...PL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 13 (swi4: clock) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c074bb2f,dd4f6b14,c05514af,c0749d10,c07b85e0,...) at 0xc0478466 = db_trace_self_wrapper+0x26 kdb_backtrace(c0749d10,c07b85e0,c073b02b,dd4f6b20,dd4f6b20,...) at 0xc057a639 = kdb_backtrace+0x29 panic(c073b02b,c0761cb4,c36104dc,1,1,...) at 0xc05514af = panic+0xaf trap_fatal(c0761bb6,c,c3a89460,c3a8965c,c,...) at 0xc0705723 = trap_fatal+0x353 trap(dd4f6bf4) at 0xc07060ca = trap+0x10a calltrap() at 0xc06f46...

Colleagues, one of my servers had to be rebooted uncleanly and then I have backgrounded fsck locked for more than an our in snaplk: 742 root 1 -4 4 1320K 688K snaplk 0:02 0.00% fsck_ufs File system in question is 200G gmirror on SATA. Usually making a snapshot (e.g., for making dumps) consumes 3-4 minutes for that fs, so it seems to me that filesystem is in a deadlock. Any

Hello, Since FreeBSD 9.1 I have strange problems with the distribution. Some servers are rebooting without any kernel panic, instanly. First i thought it's a problem with my KVM system, but one of my FreeBSD under a Dell R210 have the same problem. The servers concerned are now: - Monitoring server - LDAP test server - Some other servers, randomly (not in production). First i thought it's

...= DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 16502 (rsync) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff80920bb6 at kdb_backtrace+0x66 #1 0xffffffff808eabce at panic+0x1ce #2 0xffffffff80bd8640 at trap_fatal+0x290 #3 0xffffffff80bd897d at trap_pfault+0x1ed #4 0xffffffff80bd8f9e at trap+0x3ce #5 0xffffffff80bc355f at calltrap+0x8 #6 0xffffffff80bd7ee6 at amd64_syscall+0x546 #7 0xffffffff80bc3847 at Xfast_syscall+0xf7...

...f mem 0xc2460000-0xc2463fff,0xc2400000-0xc243ffff irq 17 at device 0.0 on pci2 tws0: Using legacy INTx panic: _mtx_lock_sleep: recursed on non-recursive mutex tws_io_lock @ /usr/HEAD/src/sys/dev/tws/tws_hdm.c:287 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 _mtx_lock_sleep() at _mtx_lock_sleep+0x27f _mtx_lock_flags() at _mtx_lock_flags+0xf1 tws_submit_command() at tws_submit_command+0x3f tws_dmamap_data_load_cbfn() at tws_dmamap_data_load_cbfn+0xb7 bus_dmamap_load() at bus_dmamap_load+0x16c tws_map_reque...

...at() at kern_do_pat+0x10f sched_sync() at sched_sync+0x1ea fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff869b172bb0, rbp = 0 --- panic: sleeping thread cpuid = 26 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 propagate_priority() at propagate_priority+0x223 turnstile_wait() at turnstile_wait+0x252 _mtx_lock_sleep() at _mtx_lock_sleep+0x124 _mtx_lock_flags() at _mtx_lock_flags+0xae vn_syncer_add_to_worklist() at vn_syncer_add_to_worklist+0x3d reassignbuf()...

...= 0x28:0xe78e78ec frame pointer = 0x28:0xe78e7914 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 847 (nfsd) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: kdb_backtrace(100,c532f900,28,e78e78ac,c,...) at kdb_backtrace+0x29 panic(c0976f0c,c09cfe95,0,fffff,c532e49b,...) at panic+0x114 trap_fatal(e78e78ac,1c,c532f900,0,c,...) at trap_fatal+0x2ce trap_pfault(e78e78ac,0,1c) at trap_pfault+0x1f7 trap(e78e0008,c06a0028,e78e0028,200012,d9156118,...) at trap+0x325 calltra...

Hello, I'm experiencing a kernel panic that appears to be caused by zfs. No errors are making it into /var/log/messages, but here is the error message that appears on my screen after panic (transcribed): panic solaris assert BSWAP_32(sa_hdr_phys->sa_magic) == SA_MAGIC, file: /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c, line 1262 I can reproduce this by

Hello, I have not had much time to research this problem yet, so please let me know what further information I might be able to provide. This weekend I attempted to upgrade a computer from 8.2-RELEASE-p3 to 8.4 using freebsd-update. After I rebooted to test the new kernel, I got a panic. I had to take a picture of the screen. Here's a condensed version: panic: page fault cpuid = 1 KDB:

.... No core dumps found. lock order reversal: 1st 0xfffffe012e861e28 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3050 2nd 0xfffff80005b87c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: X_db_symbol_values() at X_db_symbol_values+0x10b/frame 0xfffffe012fb8c410 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe012fb8c4c0 witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe012fb8c550 _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe012fb8c590 ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xfffffe012fb8c5d0 ufs_direnter() at ufs_direnter+0x688/frame 0xfffffe012f...

...0x28:0xffffff8092c978b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1489 (ibping) trap number = 12 panic: page fault cpuid = 6 KDB: stack backtrace: #0 0xffffffff80632a96 at kdb_backtrace+0x66 #1 0xffffffff805f9fce at panic+0x1ce #2 0xffffffff808a7380 at trap_fatal+0x290 #3 0xffffffff808a76e1 at trap_pfault+0x211 #4 0xffffffff808a7c94 at trap+0x344 #5 0xffffffff80891043 at calltrap+0x8 #6 0xffffffff80513c39 at devfs_destroy_cdevpriv+0x69 #7 0xffffffff80513e47 at devfs_close_f+0x57...

Two machines (NFS Server: running ZFS / Client: disk-less), both are running FreeBSD r253506. The NFS client starts to deadlock processes within a few hours. It usually gets worse from there on. The processes stay in "D" state. I haven't been able to reproduce it when I want it to happen. I only have to wait a few hours until the deadlocks occur when traffic to the client machine

Guys, I've heard about some absurd RAM requirements for 9.1, has anybody tested it? e.g. http://forums.freebsd.org/showthread.php?t=36314 -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-minimal-ram-requirements-tp5771583.html Sent from the freebsd-stable mailing list archive at Nabble.com.

...mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) <empty line> Abort manual input mountroot> panic: mountroot: unable to (re-)mount root. cpuid = 1 KDB: stack backtrace: #0 0xffffffff8092aee6 at kdb_backtrace+0x66 #1 0xffffffff808f511e at panic+0x1ce #2 0xffffffff809866a1 at vfs_mountroot+0x14a1 #3 0xffffffff808a698d at start_init+0x4d #4 0xffffffff808c5caf at fork_exit+0x11f #5 0xffffffff80bf4fee at fork_trampoline+0xe Uptime: 57s Automatic reboot in 15 seconds - press a key on the console to abort --...