Project

General

Profile

Bug #5759

kernel panic dmu_tx.c, line: 1067 FreeNAS-9.2.1.7-RELEASE-x64

Added by Christian H over 6 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Nice to have
Assignee:
Xin Li
Category:
OS
Target version:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

Hi,
this is my first ticket, please be gentle :)

Hardware:

  • Dell Poweredge T20 Xeon
  • 16 GB ecc RAM
  • 2*4 WD red as raid1 + encryption
  • 2*3 WD red as raid1 + encryption

Issue:
Machine crashed and reboot, this i in the logs:

18 Aug 12 18:07:54 freenas syslogd: kernel boot file is /boot/kernel-debug/kernel
19 Aug 12 18:07:54 freenas kernel: panic: solaris assert: wakeup >= now, file: /fusion/jkh/921/freenas/FreeBSD/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, line: 1067
20 Aug 12 18:07:54 freenas kernel: cpuid = 2
21 Aug 12 18:07:54 freenas kernel: KDB: stack backtrace:
22 Aug 12 18:07:54 freenas kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff84382ab0d0
23 Aug 12 18:07:54 freenas kernel: kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff84382ab190
24 Aug 12 18:07:54 freenas kernel: panic() at panic+0x1d8/frame 0xffffff84382ab290
25 Aug 12 18:07:54 freenas kernel: assfail() at assfail+0x1a/frame 0xffffff84382ab2a0
26 Aug 12 18:07:54 freenas kernel: dmu_tx_wait() at dmu_tx_wait+0x36d/frame 0xffffff84382ab300
27 Aug 12 18:07:54 freenas kernel: dmu_tx_assign() at dmu_tx_assign+0x23e/frame 0xffffff84382ab390
28 Aug 12 18:07:54 freenas kernel: zfs_freebsd_write() at zfs_freebsd_write+0x511/frame 0xffffff84382ab5c0
29 Aug 12 18:07:54 freenas kernel: VOP_WRITE_APV() at VOP_WRITE_APV+0x16e/frame 0xffffff84382ab6d0
30 Aug 12 18:07:54 freenas kernel: vn_write() at vn_write+0x311/frame 0xffffff84382ab760
31 Aug 12 18:07:54 freenas kernel: vn_io_fault() at vn_io_fault+0x9e/frame 0xffffff84382ab8e0
32 Aug 12 18:07:54 freenas kernel: dofilewrite() at dofilewrite+0x85/frame 0xffffff84382ab930
33 Aug 12 18:07:54 freenas kernel: kern_pwritev() at kern_pwritev+0x68/frame 0xffffff84382ab980
34 Aug 12 18:07:54 freenas kernel: sys_pwrite() at sys_pwrite+0x68/frame 0xffffff84382ab9d0
35 Aug 12 18:07:54 freenas kernel: amd64_syscall() at amd64_syscall+0x2b8/frame 0xffffff84382abaf0
36 Aug 12 18:07:54 freenas kernel: Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff84382abaf0
37 Aug 12 18:07:54 freenas kernel: --- syscall (476, FreeBSD ELF64, sys_pwrite), rip = 0x804cf361c, rsp = 0x7fffffffd9e8, rbp = 0xe41fdc ---
38 Aug 12 18:07:54 freenas kernel: KDB: enter: panic
39 Aug 12 18:07:54 freenas kernel: Textdump complete.

another:

panic: solaris assert: wakeup >= now, file: /fusion/jkh/921/freenas/FreeBSD/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, line: 1067
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff843826f0d0
kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff843826f190
panic() at panic+0x1d8/frame 0xffffff843826f290
assfail() at assfail+0x1a/frame 0xffffff843826f2a0
dmu_tx_wait() at dmu_tx_wait+0x36d/frame 0xffffff843826f300
dmu_tx_assign() at dmu_tx_assign+0x23e/frame 0xffffff843826f390
zfs_freebsd_write() at zfs_freebsd_write+0x511/frame 0xffffff843826f5c0
VOP_WRITE_APV() at VOP_WRITE_APV+0x16e/frame 0xffffff843826f6d0
vn_write() at vn_write+0x311/frame 0xffffff843826f760
vn_io_fault() at vn_io_fault+0x9e/frame 0xffffff843826f8e0
dofilewrite() at dofilewrite+0x85/frame 0xffffff843826f930
kern_pwritev() at kern_pwritev+0x68/frame 0xffffff843826f980
sys_pwrite() at sys_pwrite+0x68/frame 0xffffff843826f9d0
amd64_syscall() at amd64_syscall+0x2b8/frame 0xffffff843826faf0
Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff843826faf0
--- syscall (476, FreeBSD ELF64, sys_pwrite), rip = 0x804cf361c, rsp = 0x7fffffffd9e8, rbp = 0x14f181f7f ---
KDB: enter: panic>

When does this happen:

when I make some "big" file transfers

What was already tested by me:
  • > memtest, runs 8 times successfully
  • > hardware check from bioa/uefi was also successfully
  • > > * change same cache parameter in the loader.conf, but AFTER I saw the crashes, so not the issue:

Do you need more information?
Did I miss something?

Thank you very much and best regards,
Christian

Associated revisions

Revision 39da2018 (diff)
Added by Xin Li over 6 years ago

Don't assert that wakeup > now, skip the sleep if we shouldn't. Ticket: #5759

Revision 39da2018 (diff)
Added by Xin Li over 6 years ago

Don't assert that wakeup > now, skip the sleep if we shouldn't. Ticket: #5759

Revision aa2a8040 (diff)
Added by Xin Li over 6 years ago

Don't assert that wakeup > now, skip the sleep if we shouldn't. Ticket: #5759

Revision aa2a8040 (diff)
Added by Xin Li over 6 years ago

Don't assert that wakeup > now, skip the sleep if we shouldn't. Ticket: #5759

History

#1 Updated by Xin Li over 6 years ago

  • Status changed from Unscreened to Resolved
  • Assignee set to Xin Li
  • Target version set to 9.3-M3

#2 Updated by Xin Li over 6 years ago

  • % Done changed from 0 to 100

#3 Updated by Dru Lavigne almost 3 years ago

  • File deleted (dmesg)

Also available in: Atom PDF