Re: ZFS panic with r255937
On Wed, 2 Oct 2013, Andriy Gapon wrote: on 30/09/2013 02:11 kwh...@site.uottawa.ca said the following: Sorry, debugging this is *way* beyond me. Any hints, patches to try? Please share the stack trace. -- Andriy Gapon There's now a pr for this panic: kern/182570 Here's the stack trace: root@freebsd10:/usr/src # kgdb /boot/kernel/kernel /var/crash/vmcore.last GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: solaris assert: dn->dn_maxblkid == 0 && (BP_IS_HOLE(&dn->dn_phys->dn_blkptr[0]) || dnode_block_freed(dn, 0)), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c, line: 598 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00992b3280 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00992b3330 vpanic() at vpanic+0x126/frame 0xfe00992b3370 panic() at panic+0x43/frame 0xfe00992b33d0 assfail() at assfail+0x22/frame 0xfe00992b33e0 dnode_reallocate() at dnode_reallocate+0x225/frame 0xfe00992b3430 dmu_object_reclaim() at dmu_object_reclaim+0x123/frame 0xfe00992b3480 dmu_recv_stream() at dmu_recv_stream+0xd79/frame 0xfe00992b36b0 zfs_ioc_recv() at zfs_ioc_recv+0x96c/frame 0xfe00992b3920 zfsdev_ioctl() at zfsdev_ioctl+0x54a/frame 0xfe00992b39c0 devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xfe00992b3a20 kern_ioctl() at kern_ioctl+0x2ca/frame 0xfe00992b3a90 sys_ioctl() at sys_ioctl+0x11f/frame 0xfe00992b3ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00992b3bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00992b3bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8019dc9ca, rsp = 0x7fff5ad8, rbp = 0x7fff5b60 --- KDB: enter: panic Uptime: 37m10s Dumping 874 out of 2023 MB: ... (kgdb) where #0 doadump (textdump=1) at pcpu.h:218 #1 0x808b7217 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x808b7725 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x808b7773 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:683 #4 0x81e5 in assfail (a=, f=, l=) at /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81 #5 0x81d09735 in dnode_reallocate (dn=0xf8006dde3000, ot=DMU_OT_PLAIN_FILE_CONTENTS, blocksize=1024, bonustype=DMU_OT_SA, bonuslen=168, tx=0xf8006d7a2600) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c:596 #6 0x81cff463 in dmu_object_reclaim (os=, object=, ot=DMU_OT_PLAIN_FILE_CONTENTS, blocksize=1024, bonustype=DMU_OT_SA, bonuslen=168) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_object.c:155 #7 0x81cfd849 in dmu_recv_stream (drc=0xfe00992b3728, fp=, voffp=0xfe00992b3718, cleanup_fd=8, action_handlep=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c:1231 #8 0x81d8b1fc in zfs_ioc_recv (zc=0xfe00372e1000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:4102 #9 0x81d864ea in zfsdev_ioctl (dev=, zcmd=, arg=, flag=, td=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:5960 #10 0x807af840 in devfs_ioctl_f (fp=0xf800052e1460, com=3222821403, data=0xf8006ff1faa0, cred=, td=0xf8003f7ba920) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #11 0x8090e94a in kern_ioctl (td=0xf8003f7ba920, fd=, com=0) at file.h:319 #12 0x8090e62f in sys_ioctl (td=0xf8003f7ba920, uap=0xfe00992b3b80) at /usr/src/sys/kern/sys_generic.c:698 #13 0x80caee35 in amd64_syscall (td=0xf8003f7ba920, traced=0) at subr_syscall.c:134 #14 0x80c961ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #15 0x0008019dc9ca in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) Here's a how to repeat: Assuming pool "tank" and non-existent tank/nobj tank/xobj === cut here === #!/bin/sh zfs create tank/nobj zfs snapshot tank/nobj@0 __MAKECONF=/dev/null SRCCONF=/dev/null MAKEOBJDIRPREFIX=/tank/nobj make -j6 buildkernel zfs snapshot tank/nobj@1 #find /tank/nobj -name '.h' -print | xargs rm zfs snapshot tank/nobj@2 #rm -rf /tank/nobj/* zfs snapshot tank/nobj@3 __MAKECONF=/dev/null SRCCONF=/dev/null MAKEOBJDIRPREFIX=/tank/nobj make -j6 buildkernel zfs snapshot tank/nobj@4 #rm -rf /tank/nobj/* zfs snapshot tank/nobj@5 zfs send -vR tank/nobj@5 | zfs recv -vF
Re: ZFS panic with r255937
On Thu, 3 Oct 2013, Andriy Gapon wrote:
on 02/10/2013 20:59 Keith White said the following:
On Wed, 2 Oct 2013, Andriy Gapon wrote:
on 30/09/2013 02:11 kwh...@site.uottawa.ca said the following:
Sorry, debugging this is *way* beyond me. Any hints, patches to try?
Please share the stack trace.
--
Andriy Gapon
There's now a pr for this panic: kern/182570
Here's the stack trace:
root@freebsd10:/usr/src # kgdb /boot/kernel/kernel /var/crash/vmcore.last
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
panic: solaris assert: dn->dn_maxblkid == 0 &&
(BP_IS_HOLE(&dn->dn_phys->dn_blkptr[0]) || dnode_block_freed(dn, 0)), file:
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c,
line: 598
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00992b3280
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00992b3330
vpanic() at vpanic+0x126/frame 0xfe00992b3370
panic() at panic+0x43/frame 0xfe00992b33d0
assfail() at assfail+0x22/frame 0xfe00992b33e0
dnode_reallocate() at dnode_reallocate+0x225/frame 0xfe00992b3430
dmu_object_reclaim() at dmu_object_reclaim+0x123/frame 0xfe00992b3480
dmu_recv_stream() at dmu_recv_stream+0xd79/frame 0xfe00992b36b0
zfs_ioc_recv() at zfs_ioc_recv+0x96c/frame 0xfe00992b3920
zfsdev_ioctl() at zfsdev_ioctl+0x54a/frame 0xfe00992b39c0
devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xfe00992b3a20
kern_ioctl() at kern_ioctl+0x2ca/frame 0xfe00992b3a90
sys_ioctl() at sys_ioctl+0x11f/frame 0xfe00992b3ae0
amd64_syscall() at amd64_syscall+0x265/frame 0xfe00992b3bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00992b3bf0
Thank you very much.
To me this looks very similar to a problem discovered and fixed in illumos some
time ago. Please check if the following change improves the situation for you.
https://github.com/avg-I/freebsd/commit/a7e7dece215bc5d00077e9c7f4db34d9e5c30659
Raw:
https://github.com/avg-I/freebsd/commit/a7e7dece215bc5d00077e9c7f4db34d9e5c30659.patch
...
Yes, it does. send/recv completes with no panic. That patch fixes kern/182570
for me.
Thanks!
...keith
Once the patch is applied "svn diff" gives me:
Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c
===
--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c(revision
255986)
+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c(working copy)
@@ -677,6 +677,16 @@
if (err != 0)
return (err);
err = dmu_free_long_range_impl(os, dn, offset, length);
+
+ /*
+* It is important to zero out the maxblkid when freeing the entire
+* file, so that (a) subsequent calls to dmu_free_long_range_impl()
+* will take the fast path, and (b) dnode_reallocate() can verify
+* that the entire file has been freed.
+*/
+ if (offset == 0 && length == DMU_OBJECT_END)
+ dn->dn_maxblkid = 0;
+
dnode_rele(dn, FTAG);
return (err);
}
Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c
===
--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c (revision
255986)
+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c (working copy)
@@ -616,7 +616,7 @@
*/
if (dn->dn_datablkshift == 0) {
if (off != 0 || len < dn->dn_datablksz)
- dmu_tx_count_write(txh, off, len);
+ dmu_tx_count_write(txh, 0, dn->dn_datablksz);
} else {
/* first block will be modified if it is not aligned */
if (!IS_P2ALIGNED(off, 1 << dn->dn_datablkshift))
___
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"
ZFS panic (dn->dn_datablkshift != 0) with r256304 and send/recv
I get the following assert failure with a recent current: panic: solaris assert: dn->dn_datablkshift != 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, line: 638 # uname -a FreeBSD freebsd10 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r256304: Thu Oct 10 19:38:55 EDT 2013 kwhite@freebsd10:/tank/obj/usr/src/sys/GENERIC amd64 # kgdb /boot/kernel/kernel /var/crash/vmcore.last GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: ... <118># zfs send -vi tank/RPI@20131004 tank/RPI@20131013 | zfs recv -vF m_tank/RPI@20131013 <118>send from @20131004 to tank/RPI@20131013 estimated size is 85.0M <118>total estimated size is 85.0M <118>TIMESENT SNAPSHOT <118>receiving incremental stream of tank/RPI@20131013 into m_tank/RPI@20131013 <118>19:45:12 5.90M tank/RPI@20131013 <118>19:45:13 36.4M tank/RPI@20131013 <118>19:45:15 38.4M tank/RPI@20131013 <118>19:45:16 41.3M tank/RPI@20131013 panic: solaris assert: dn->dn_datablkshift != 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, line: 638 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00977711a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0097771250 vpanic() at vpanic+0x126/frame 0xfe0097771290 panic() at panic+0x43/frame 0xfe00977712f0 assfail() at assfail+0x22/frame 0xfe0097771300 dmu_tx_hold_free() at dmu_tx_hold_free+0x162/frame 0xfe00977713e0 dmu_free_long_range() at dmu_free_long_range+0x244/frame 0xfe0097771450 dmu_free_long_object() at dmu_free_long_object+0x1f/frame 0xfe0097771480 dmu_recv_stream() at dmu_recv_stream+0x86e/frame 0xfe00977716b0 zfs_ioc_recv() at zfs_ioc_recv+0x96c/frame 0xfe0097771920 zfsdev_ioctl() at zfsdev_ioctl+0x54a/frame 0xfe00977719c0 devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xfe0097771a20 kern_ioctl() at kern_ioctl+0x2ca/frame 0xfe0097771a90 sys_ioctl() at sys_ioctl+0x11f/frame 0xfe0097771ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe0097771bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0097771bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8019f49ca, rsp = 0x7fff9438, rbp = 0x7fff94c0 --- KDB: enter: panic Uptime: 7m30s ... (kgdb) where #0 doadump (textdump=1) at pcpu.h:219 #1 0x808b88b7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x808b8dc5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x808b8e13 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:683 #4 0x81dd1222 in assfail (a=, f=, l=) at /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81 #5 0x81c847c2 in dmu_tx_hold_free (tx=0xf800118bda00, object=, off=, len=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c:638 #6 0x81c78124 in dmu_free_long_range (os=0xf8000580f000, object=, offset=0, length=18446744073709551615) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:654 #7 0x81c781df in dmu_free_long_object (os=0xf8000580f000, object=66055) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:700 #8 0x81c7c39e in dmu_recv_stream (drc=0xfe0097771728, fp=, voffp=0xfe0097771718, cleanup_fd=8, action_handlep=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c:1289 #9 0x81d0a1fc in zfs_ioc_recv (zc=0xfe000183) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:4102 #10 0x81d054ea in zfsdev_ioctl (dev=, zcmd=, arg=, flag=, td=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:5960 #11 0x807b0d40 in devfs_ioctl_f (fp=0xf80005304dc0, com=3222821403, data=0xf800027abc40, cred=, td=0xf8000524f000) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #12 0x8090ffea in kern_ioctl (td=0xf8000524f000, fd=, com=0) at file.h:319 #13 0x8090fccf in sys_ioctl (td=0xf8000524f000, uap=0xfe0097771b80) at /usr/src/sys/kern/sys_generic.c:698 #14 0x80cb2e05 in amd64_syscall (td=0xf8000524f000, traced=0) at subr_syscall.c:134 #15 0x80c979fb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #16 0x0008019f49ca in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ...keith _
Re: ZFS panic (dn->dn_datablkshift != 0) with r256304 and send/recv
On Mon, 14 Oct 2013, Andriy Gapon wrote: on 14/10/2013 03:34 Keith White said the following: I get the following assert failure with a recent current: panic: solaris assert: dn->dn_datablkshift != 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, line: 638 Please see https://www.illumos.org/issues/4188 The current best known fix is to simply drop the assertion. ... Thanks! It works for me. Receive completes, and filesystems compare the same. Index: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c === --- /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c (revision 256304) +++ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c (working copy) @@ -635,7 +635,7 @@ uint64_t start = off >> shift; uint64_t end = (off + len) >> shift; - ASSERT(dn->dn_datablkshift != 0); + /* XXX may be false alarm: ASSERT(dn->dn_datablkshift != 0); XXX */ ASSERT(dn->dn_indblkshift != 0); zio = zio_root(tx->tx_pool->dp_spa, Though, I am not entirely sure if this will be the final solution. I'll double-check with Matt. ...keith ___ 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"
gnop panic with recent kernel (r256923)
I get a "gnop lock" panic when trying to create a gnop device: # gnop create -S 4k ada3 panic: lock "gnop lock" 0xf80002566640 already initialized # kgdb /boot/kernel.r256923/kernel /var/crash/vmcore.last ... Unread portion of the kernel message buffer: panic: lock "gnop lock" 0xf80002566640 already initialized cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00934f3830 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00934f38e0 vpanic() at vpanic+0x126/frame 0xfe00934f3920 kassert_panic() at kassert_panic+0x136/frame 0xfe00934f3990 lock_init() at lock_init+0x43/frame 0xfe00934f39e0 _mtx_init() at _mtx_init+0x7c/frame 0xfe00934f3a20 g_nop_config() at g_nop_config+0x51a/frame 0xfe00934f3b30 g_ctl_req() at g_ctl_req+0x100/frame 0xfe00934f3b70 g_run_events() at g_run_events+0x1a7/frame 0xfe00934f3bb0 fork_exit() at fork_exit+0x84/frame 0xfe00934f3bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00934f3bf0 --- trap 0, rip = 0, rsp = 0xfe00934f3cb0, rbp = 0 --- (kgdb) bt #0 doadump (textdump=1) at pcpu.h:219 #1 0x808bbb57 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x808bc065 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x808bbef6 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:642 #4 0x808f47c3 in lock_init (lock=0xf80002566640, class=0x813e9ce0, name=0x81c947ce "gnop lock", type=0x0, flags=131072) at /usr/src/sys/kern/subr_lock.c:81 #5 0x808a8acc in _mtx_init (c=0xf80002566658, name=0x81c947ce "gnop lock", type=0x0, opts=) at /usr/src/sys/kern/kern_mutex.c:905 #6 0x81c9351a in g_nop_config (req=0xf800052a48c0, mp=0x81c94a20, verb=) at /usr/src/sys/modules/geom/geom_nop/../../../geom/nop/g_nop.c:229 #7 0x8081d790 in g_ctl_req (arg=0xf800052a48c0, flag=) at /usr/src/sys/geom/geom_ctl.c:454 #8 0x80820d27 in g_run_events () at /usr/src/sys/geom/geom_event.c:257 #9 0x8088b094 in fork_exit (callout=0x80822df0 , arg=0x0, frame=0xfe00934f3c00) at /usr/src/sys/kern/kern_fork.c:995 #10 0x80c9bf4e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:606 #11 0x in ?? () Current language: auto; currently minimal (kgdb) ...keith ___ 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: gnop panic with recent kernel (r256923)
On Wed, 23 Oct 2013, Mateusz Guzik wrote: On Tue, Oct 22, 2013 at 07:59:29PM -0400, Keith White wrote: I get a "gnop lock" panic when trying to create a gnop device: # gnop create -S 4k ada3 panic: lock "gnop lock" 0xf80002566640 already initialized # kgdb /boot/kernel.r256923/kernel /var/crash/vmcore.last ... Unread portion of the kernel message buffer: panic: lock "gnop lock" 0xf80002566640 already initialized cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00934f3830 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00934f38e0 vpanic() at vpanic+0x126/frame 0xfe00934f3920 kassert_panic() at kassert_panic+0x136/frame 0xfe00934f3990 lock_init() at lock_init+0x43/frame 0xfe00934f39e0 _mtx_init() at _mtx_init+0x7c/frame 0xfe00934f3a20 g_nop_config() at g_nop_config+0x51a/frame 0xfe00934f3b30 g_ctl_req() at g_ctl_req+0x100/frame 0xfe00934f3b70 g_run_events() at g_run_events+0x1a7/frame 0xfe00934f3bb0 fork_exit() at fork_exit+0x84/frame 0xfe00934f3bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00934f3bf0 --- trap 0, rip = 0, rsp = 0xfe00934f3cb0, rbp = 0 --- (kgdb) bt #0 doadump (textdump=1) at pcpu.h:219 #1 0x808bbb57 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x808bc065 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x808bbef6 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:642 #4 0x808f47c3 in lock_init (lock=0xf80002566640, class=0x813e9ce0, name=0x81c947ce "gnop lock", type=0x0, flags=131072) at /usr/src/sys/kern/subr_lock.c:81 #5 0x808a8acc in _mtx_init (c=0xf80002566658, name=0x81c947ce "gnop lock", type=0x0, opts=) at /usr/src/sys/kern/kern_mutex.c:905 #6 0x81c9351a in g_nop_config (req=0xf800052a48c0, mp=0x81c94a20, verb=) at /usr/src/sys/modules/geom/geom_nop/../../../geom/nop/g_nop.c:229 #7 0x8081d790 in g_ctl_req (arg=0xf800052a48c0, flag=) at /usr/src/sys/geom/geom_ctl.c:454 #8 0x80820d27 in g_run_events () at /usr/src/sys/geom/geom_event.c:257 #9 0x8088b094 in fork_exit (callout=0x80822df0 , arg=0x0, frame=0xfe00934f3c00) at /usr/src/sys/kern/kern_fork.c:995 #10 0x80c9bf4e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:606 #11 0x in ?? () Current language: auto; currently minimal (kgdb) ...keith Try this (untested): diff --git a/sys/geom/nop/g_nop.c b/sys/geom/nop/g_nop.c index e6b44bb..bd72d78 100644 --- a/sys/geom/nop/g_nop.c +++ b/sys/geom/nop/g_nop.c @@ -216,7 +216,7 @@ g_nop_create(struct gctl_req *req, struct g_class *mp, struct g_provider *pp, } } gp = g_new_geomf(mp, "%s", name); - sc = g_malloc(sizeof(*sc), M_WAITOK); + sc = g_malloc(sizeof(*sc), M_WAITOK | M_ZERO); sc->sc_offset = offset; sc->sc_explicitsize = explicitsize; sc->sc_error = ioerror; -- Mateusz Guzik Yes, that fixes it for me. Thanks! ...keith ___ 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: (unionfs) panic: excl->share with r230341 and above
On Tue, 10 Apr 2012, Daichi GOTO wrote: Thanks kwhite, I found an another lock issue. Please try a patch included. ... Success. Your latest patch fixes the problem. Thanks! ...keith ___ 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"
panic: UMA: Increase vm.boot_pages on Dell R920 r279210
I (temporarily) have a Dell R920 with 1T RAM, and 4 CPUs with 15 cores. I get a kernel panic when attempting to boot FreeBSD-11.0-CURRENT-amd64-20150223-r279210-memstick.img: ... Dell System PowerEdge R920 www.dell.com ... Four 2.30 GHz Fifteen-core Processors, L2/L3 Cache:3.75 MB/30 MB System running at 2.30 GHz System Bus Speed: 8.00 GT/s System Memory Size: 1024.0 GB, System Memory Speed: 1333 MHz, Voltage: 1.35V ... Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r279210: Mon Feb 23 19:14:12 UTC 2015 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.5.1 (tags/RELEASE_351/final 225668) 20150115 WARNING: WITNESS option enabled, expect reduced performance. panic: UMA: Increase vm.boot_pages cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x81bfe7a0 vpanic() at vpanic+0x189/frame 0x81bfe820 panic() at panic+0x43/frame 0x81bfe880 startup_alloc() at startup_alloc+0x1da/frame 0x81bfe8d0 keg_alloc_slab() at keg_alloc_slab+0xce/frame 0x81bfe930 keg_fetch_slab() at keg_fetch_slab+0x171/frame 0x81bfe980 zone_fetch_slab() at zone_fetch_slab+0x6e/frame 0x81bfe9c0 zone_import() at zone_import+0x40/frame 0x81bfea30 zone_alloc_item() at zone_alloc_item+0x36/frame 0x81bfea70 uma_zcreate() at uma_zcreate+0x8a/frame 0x81bfeb10 vm_map_startup() at vm_map_startup+0x52/frame 0x81bfeb30 vm_mem_init() at vm_mem_init+0x31/frame 0x81bfeb50 mi_startup() at mi_startup+0x118/frame 0x81bfeb70 btext() at btext+0x2c KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db> I tried the suggestion "Increase vm.boot_pages" but am unsure how much. I tried doubling to 128, and even excessive(?) values like 102400; but got the same panic. If, however, I reduce the number of active cores to 10 in the BIOS, I am able to boot with the original value of vm.boot_pages. I have serial console and sneaker net access for the next couple of days. Any suggestions? ...keith -- Keith White, genie.uottawa.ca engineering.uottawa.ca kwh...@uottawa.ca [+1 613 562 5800 x6681] ___ 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: panic: UMA: Increase vm.boot_pages on Dell R920 r279210
On Tue, 24 Mar 2015, Rui Paulo wrote:
On Mar 24, 2015, at 04:19, kwh...@site.uottawa.ca wrote:
I'm using /boot/loader.conf. Is there another place I should be doing this?
No, that's correct, but apparently there's a problem: the RDTUN sysctl is not
picked up early enough. Can you try this patch? I haven't really tested it.
:-)
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 79665ba..a764788 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -134,8 +134,9 @@ long first_page;
int vm_page_zero_count;
static int boot_pages = UMA_BOOT_PAGES;
-SYSCTL_INT(_vm, OID_AUTO, boot_pages, CTLFLAG_RDTUN, &boot_pages, 0,
- "number of pages allocated for bootstrapping the VM system");
+SYSCTL_INT(_vm, OID_AUTO, boot_pages, CTLFLAG_RDTUN | CTLFLAG_NOFETCH,
+&boot_pages, 0,
+"number of pages allocated for bootstrapping the VM system");
static int pa_tryrelock_restart;
SYSCTL_INT(_vm, OID_AUTO, tryrelock_restart, CTLFLAG_RD,
@@ -349,6 +350,7 @@ vm_page_startup(vm_offset_t vaddr)
* Allocate memory for use when boot strapping the kernel memory
* allocator.
*/
+ TUNABLE_INT_FETCH("vm.boot_pages", &boot_pages);
new_end = end - (boot_pages * UMA_SLAB_SIZE);
new_end = trunc_page(new_end);
mapped = pmap_map(&vaddr, new_end, end,
@@ -443,7 +445,7 @@ vm_page_startup(vm_offset_t vaddr)
--
Rui Paulo
Patch tried. Success!
I now get this after setting vm.boot_pages=1024 in /boot/loader.conf:
Booting...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #1: Tue Mar 24 13:44:48 UTC 2015
root@:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.5.1 (tags/RELEASE_351/final 225668) 20150115
WARNING: WITNESS option enabled, expect reduced performance.
UMA startup boot_pages: 1024
...
And can start all 120 processors.
Thanks!
...keith
--
Keith White, genie.uottawa.ca engineering.uottawa.ca
kwh...@uottawa.ca [+1 613 562 5800 x6681]
___
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"
RPI-B 11.0-ALPHA3 r301815 panic
I get the following panic when connecting via WiFi to an RPI-B running the r301815 snapshot: Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xc18f28c0 FSR=0001, FAR=c21a287a, spsr=6013 r0 =c07a6548, r1 =0004, r2 =c060513d, r3 =07b6 r4 =c18f2a28, r5 =c18f2b40, r6 =c21a2876, r7 =c1cce3e0 r8 =c1cce3e0, r9 =c21a2876, r10=c18f2b40, r11=c18f2988 r12=, ssp=c18f2950, slr=c1a48370, pc =c0449928 Suggestions on where to start to track this down? Here's the console output over the serial port from boot to panic: U-Boot 2016.01 (Jun 11 2016 - 12:28:01 +) DRAM: 224 MiB RPI Model B (no P5) (0x3) MMC: bcm2835_sdhci: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In:serial Out: lcd Err: lcd Net: Net Initialization Skipped No ethernet found. reading uEnv.txt ** Unable to read file uEnv.txt ** Hit any key to stop autoboot: 0 starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Booting from: mmc 0 ubldr.bin reading ubldr.bin 223912 bytes read in 30 ms (7.1 MiB/s) ## No elf image at address 0x0020 ## Starting application at 0x0020 ... Consoles: U-Boot console Compatible U-Boot API signature found @0xdb464d0 FreeBSD/armv6 U-Boot loader, Revision 1.2 (r...@releng2.nyi.freebsd.org, Sat Jun 11 12:55:20 UTC 2016) DRAM: 224MB Number of U-Boot devices: 2 U-Boot env: loaderdev='mmc 0' Found U-Boot device: disk Checking unit=0 slice= partition=... good. Booting from disk0s2a: /boot/kernel/kernel data=0x606164+0xfde9c syms=[0x4+0xcaf70+0x4+0x984e7] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x100. Kernel entry at 0x0x400100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-ALPHA3 #0 r301815: Sat Jun 11 13:02:45 UTC 2016 r...@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) VT: init without driver. sema_sysinit CPU: ARM1176JZ-S rev 7 (ARM11J core) Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext WB enabled LABT branch prediction disabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 234876928 (223 MB) avail memory = 219312128simplebus0: mem 0x2000-0x20ff on ofwbus0 cpulist0: on ofwbus0 cpu0: on cpulist0 bcm2835_cpufreq0: on cpu0 intc0: mem 0x10001c-0x100027 on simplebus0 gpio0: mem 0x20-0x2000af on simplebus0 gpio0: read-only pins: 46-53. gpio0: reserved pins: 48-53. gpiobus0: on gpio0 gpioled0: at pin 16 on gpiobus0 gpioc0: on gpio0 iichb0: mem 0x205000-0x20501f on simplebus0 iicbus0: on iichb0 iic0: on iicbus0 iichb1: mem 0x804000-0x80401f on simplebus0 iicbus1: on iichb1 iic1: on iicbus1 spi0: mem 0x204000-0x20401f on simplebus0 spibus0: on spi0 bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff on simplebus0 mbox0: mem 0xb880-0xb8bf on simplebus0 sdhci_bcm0: mem 0x30-0x3000ff on simplebus0 mmc0: on sdhci_bcm0 uart0: mem 0x201000-0x201fff on simplebus0 uart0: console (115200,n,8,1) vchiq0: mem 0xb800-0xb84f on simplebus0 vchiq: local ver 8 (min 3), remote ver 8. pcm0: on vchiq0 bcm283x_dwcotg0: mem 0x98-0x99 on simplebus0 usbus0 on bcm283x_dwcotg0 fb0: on ofwbus0 fbd0 on fb0 VT: initialize with new VT driver "fb". fb0: 656x416(656x416@0,0) 24bpp fb0: fbswap: 1, pitch 1968, base 0x0eaac000, screen_size 818688 cryptosoft0: Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 bcm2835_cpufreq0: ARM 700MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF ugen0.1: at usbus0 uhub0: at mmc0 41.6MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/rootfs [rw]... warning: no time-of-day clock registered, system time will not be set accurately ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled uhub1: 3 ports with 2 removable, self powered Setting hostuuid: 4af361f9-2fd5-11e6-bfe7-b827ebdc1f36. Setting hostid: 0xe2d1bb69. No suitable dump device was found. Starting file system checks: ugen0.3: at usbus0 smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:dc/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/rootfs: clean, 276308 free (196 frags, 34514 blocks, 0.0% fragmentation) ugen0.4: at usbus0 Mounting local filesystems:. ELF ldconfig path:
Re: RPI-B 11.0-ALPHA3 r301815 panic
On Thu, 16 Jun 2016, Svatopluk Kraus wrote: There was a fix committed in r301872 which should help. Svatopluk Kraus ... Thanks! I'd tried r301932 with the same panic. I'll try again with r301872 and a pristine /usr/obj ...keith ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Wed, 15 Jun 2016, Mark Millard wrote: https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061904.html reports an RPI-B alignment fault for -r301815 (the snapshot) "when connecting via WiFi". -r301872 ( https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088339.html ) has a fix for networking vs. alignment handling for armv6 contexts that might be needed. Quoting: Author: ian Date: Mon Jun 13 16:48:27 2016 New Revision: 301872 URL: https://svnweb.freebsd.org/changeset/base/301872 ... Thanks for pointing this out! I'll see if a (complete) rebuild at that rev fixes the problem. ...keith ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Thu, 16 Jun 2016, Keith White wrote:
On Wed, 15 Jun 2016, Mark Millard wrote:
https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061904.html
reports an RPI-B alignment fault for -r301815 (the snapshot) "when
connecting via WiFi".
-r301872 (
https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088339.html )
has a fix for networking vs. alignment handling for armv6 contexts that
might be needed. Quoting:
Author: ian
Date: Mon Jun 13 16:48:27 2016
New Revision: 301872
URL:
https://svnweb.freebsd.org/changeset/base/301872
...
Thanks for pointing this out! I'll see if a (complete) rebuild at
that rev fixes the problem.
Tried that. I still get a panic.
I cross built on an amd64 at r301840, I'll try upgrading that machine too.
In the meantime, other suggestions?
FreeBSD 11.0-ALPHA3 #0 r301872: Thu Jun 16 21:11:44 EDT 2016
kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM
3.8.0)
VT: init without driver.
...
Starting devd.
urtwn0: on
usbus0
urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
urtwn0: enabling 11n
wlan0: Ethernet address: 00:13:ef:74:07:a8
Created wlan(4) interfaces: wlan0.
...
[ nc rpi-b 22 ]
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xc18f28c0
FSR=0001, FAR=c21a487a, spsr=6013
r0 =c07a6548, r1 =0004, r2 =c0605338, r3 =07b6
r4 =c18f2a28, r5 =c18f2b40, r6 =c21a4876, r7 =c1ccd240
r8 =c1ccd240, r9 =c21a4Stopped at $a.17+0x38: ldmib r6, {r1-r2}
db>
...keith
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Fri, 17 Jun 2016, Ian Lepore wrote:
On Fri, 2016-06-17 at 07:52 -0700, Adrian Chadd wrote:
Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.)
See if it's that.
-adrian
You can see from the crash info that it's an alignment fault:
r6 =c21a4876
ldmib r6,{r1-r2}
An ldm instruction requires 4-byte alignment. Now the question is why
undefining __NO_STRICT_ALIGNMENT didn't fix the problem. Maybe the
wifi code doesn't use __NO_STRICT_ALIGNMENT the same way other network
drivers do?
Unfortunately the pasted info lists the nearby symbol as $a.17+0x38,
which doesn't help find the actual code. A stack backtrace might help.
-- Ian
...
What do I need to type at the "db> " prompt that would be useful?
I should be able to access the RPI-B in 5 hours.
Here's the result of a "where" taken from an earlier logged session
(different r6 value):
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xd3c8c8c0
FSR=0001, FAR=c218607a, spsr=6013
r0 =c07a6548, r1 =0004, r2 =c06059f6, r3 =07b6
r4 =d3c8ca28, r5 =d3c8cb40, r6 =c2186076, r7 =c1dd4ce0
r8 =c1dd4ce0, r9 =c2186076, r10=d3c8cb40, r11=d3c8c988
r12=, ssp=d3c8c950, slr=c1b50370, pc =c0449ff8
[ thread pid 13 tid 100036 ]
Stopped at $a.17+0x38: ldmib r6, {r1-r2}
db> where
Tracing pid 13 tid 100036 td 0xc1b50370
db_trace_self() at db_trace_self
pc = 0xc055c774 lr = 0xc0145be4 ($a.19+0xf4)
sp = 0xd3c8c5b8 fp = 0xd3c8c5d0
$a.19() at $a.19+0xf4
pc = 0xc0145be4 lr = 0xc0145838 ($a.11+0x250)
sp = 0xd3c8c5d8 fp = 0xd3c8c678
r4 = 0x0001 r5 = 0x
r6 = 0xc05fb0e7 r10 = 0xc07ab1a8
$a.11() at $a.11+0x250
pc = 0xc0145838 lr = 0xc01455c0 (db_command_loop+0x5c)
sp = 0xd3c8c680 fp = 0xd3c8c690
r4 = 0xc05c8ec6 r5 = 0xc05ead58
r6 = 0xc07ab194 r7 = 0xc06b7ea0
r8 = 0xc079ed28 r9 = 0xc079ed2c
r10 = 0x
db_command_loop() at db_command_loop+0x5c
pc = 0xc01455c0 lr = 0xc014872c (db_trap+0xec)
sp = 0xd3c8c698 fp = 0xd3c8c7b0
r4 = 0x0001 r5 = 0x
r6 = 0xc07ab1a0 r10 = 0x
db_trap() at db_trap+0xec
pc = 0xc014872c lr = 0xc02f83b0 (kdb_trap+0xb8)
sp = 0xd3c8c7b8 fp = 0xd3c8c7d8
r4 = 0x r5 = 0x0001
r6 = 0xc079ed48 r10 = 0x
kdb_trap() at kdb_trap+0xb8
pc = 0xc02f83b0 lr = 0xc05770b4 ($a.4+0x1c0)
sp = 0xd3c8c7e0 fp = 0xd3c8c800
r4 = 0xd3c8c8c0 r5 = 0x0013
r6 = 0xc218607a r7 = 0x0001
r8 = 0x0001 r9 = 0xc1b50370
r10 = 0x
$a.4() at $a.4+0x1c0
pc = 0xc05770b4 lr = 0xc0577190 ($a.7+0x78)
sp = 0xd3c8c808 fp = 0xd3c8c820
r4 = 0xc218607a r5 = 0xd3c8c840
r6 = 0x0001 r7 = 0x0001
r8 = 0x0013 r10 = 0x
$a.7() at $a.7+0x78
pc = 0xc0577190 lr = 0xc0576eac (abort_handler+0x438)
sp = 0xd3c8c828 fp = 0xd3c8c8b8
r4 = 0xd3c8c8c0 r5 = 0xc0577118
abort_handler() at abort_handler+0x438
pc = 0xc0576eac lr = 0xc055eed0 (exception_exit)
sp = 0xd3c8c8c0 fp = 0xd3c8c988
r4 = 0xd3c8ca28 r5 = 0xd3c8cb40
r6 = 0xc2186076 r7 = 0xc1dd4ce0
r8 = 0xc1dd4ce0 r9 = 0xc2186076
r10 = 0xd3c8cb40
exception_exit() at exception_exit
pc = 0xc055eed0 lr = 0xc1b50370 (0xc1b50370)
sp = 0xd3c8c950 fp = 0xd3c8c988
r0 = 0xc07a6548 r1 = 0x0004
r2 = 0xc06059f6 r3 = 0x07b6
r4 = 0xd3c8ca28 r5 = 0xd3c8cb40
r6 = 0xc2186076 r7 = 0xc1dd4ce0
r8 = 0xc1dd4ce0 r9 = 0xc2186076
r10 = 0xd3c8cb40 r12 = 0x
$a.17() at $a.17+0x3c
pc = 0xc0449ffc lr = 0xc0449068 (syncache_expand+0x10c)
sp = 0xd3c8c990 fp = 0xd3c8cad8
r4 = 0xc1dd4cf0 r5 = 0xc23c9000
r6 = 0xc1f65208 r7 = 0xd3c8ca28
r8 = 0xc1dd4ce0 r9 = 0xc2186076
r10 = 0xd3c8cb40
syncache_expand() at syncache_expand+0x10c
pc = 0xc0449068 lr = 0xc0438df8 ($a.21+0x100)
sp = 0xd3c8cae0 fp = 0xd3c8cbb0
r4 = 0xc0604081 r5 = 0xc23b53a8
r6 = 0xd3c8cb6c r7 = 0xc2186076
r8 = 0xc23b54a4 r9 = 0x
r10 = 0xc07ae0d8
$a.21() at $a.21+0x100
pc = 0xc0438df8 lr = 0xc03bf95c (ip_input+0x230)
sp = 0xd3c8cbb8 fp = 0xd3c8cbf0
r4 = 0xc2186062 r5 = 0xc1e068e0
r6 = 0x0003 r7 = 0x
r8 = 0x r9 = 0xc06ff570
r10 = 0xc07ad790
ip_input() at ip_input+0x230
pc = 0xc03bf95c lr = 0xc039e7dc (netisr_dispatch_src+0xa8)
sp = 0xd3c8cbf8 fp = 0xd3c8cc20
r4 = 0x0001 r5 = 0xc07a59b4
r6 = 0x r7 = 0xc07a59b0
r8 = 0xc2102a00 r9 = 0xc05fd75c
r10 = 0xc2102a00
netisr_dispatch_src() at netisr_dispatch_src+0xa8
pc = 0xc039e7dc lr = 0xc03996cc (ether
Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Fri, 17 Jun 2016, Adrian Chadd wrote: Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.) See if it's that. -adrian ... Apparently not. I have the same panic even with 11n disabled. ...keith ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: BBB (cpsw(4)) seems to be broken in the latest 11-current
On Mon, 20 Jun 2016, Luiz Otavio O Souza wrote: On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote: Jim, some update from here. Running r283287 of the driver, I still see the same "watchdog timeout" messages, but they do not lead to the interface lockout. The traffic resumes momentarily. Which is probably why I never paid much attention to those warnings before. Therefore, I suspect that the new MAC code does not deal with watchdog-triggered interface reset as good as the old code. Does it give you any ideas about what could be wrong there by any chance? Hi Maxim, My recent changes contributed somehow to expose the bug more frequently. There was a condition in tx packet reclamation where we aren't restarting the tx queue in one of the possible stall conditions. Please try the attached patch and let me know if it works for you. Luiz Your patch fixes the problem for me. Thanks! FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r302028M: Mon Jun 20 18:19:55 EDT 2016 kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE-LOCAL arm armv6 ...keith ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]
On Tue, 21 Jun 2016, Mark Millard wrote:
Otacílio otacilio.neto at bsd.com.br wrote on Tue Jun 21 00:06:39 UTC 2016 :
> The kernel panic is totally reproducible. I need only do a ssh in the
> beaglebone using ptty on windows or ssh on freebsd and the kernel
> panic is raised.
. . .
FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need to
raise the fault is ssh in the beaglebone.
(After this quotes are command input/output from my test activity.)
Under 11.0 -r310975 on a rpi2 I can ssh out of the rpi2 just fine. . .
# uname -apKU
FreeBSD rpi2 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #1 r301975M: Thu Jun 16 18:12:02
PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG
arm armv6 1100117 1100117
This is a no-debug kernel build (but with symbols). Details are given later
below.
# ssh markmi@192.168.0.105
Password:
Last login: Tue Jun 21 01:04:46 2016
markmi$
Similarly I can ssh into the rpi2 from outside, here using new remote
connection in Mac OS X terminal: ssh 192.168.0.119 resulted in. . .
Password for markmi@rpi2:
Last login: Mon May 9 19:27:33 2016 from 192.168.2.1
FreeBSD 11.0-ALPHA4 (RPI2-NODBG) #1 r301975M: Thu Jun 16 18:12:02 PDT 2016
Welcome to FreeBSD!
Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories: https://www.FreeBSD.org/security/
FreeBSD Handbook: https://www.FreeBSD.org/handbook/
FreeBSD FAQ: https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:https://forums.FreeBSD.org/
Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with: pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.
Show the version of FreeBSD installed: freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages: man man
FreeBSD directory layout: man hier
Edit /etc/motd to change this login announcement.
To determine whether a file is a text file, executable, or some other type
of file, use
file filename
-- Dru
$
No panics or other odd notices.
The problem is apparently not general to all armv6 contexts.
Various context details follow. . .
# more ~/src.configs/src.conf.rpi2-clang-bootstrap.rpi2-host
TO_TYPE=armv6
#
KERNCONF=RPI2-NODBG
TARGET=arm
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
#WITH_CROSS_COMPILER=
WITH_SYSTEM_COMPILER=
#
#CPUTYPE=soft
WITH_LIBSOFT=
WITH_LIBCPLUSPLUS=
WITH_BINUTILS_BOOTSTRAP=
#WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
#
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_DEBUG_FILES=
#
XCFLAGS+= -march=armv7-a -mcpu=cortex-a7
XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7
# There is no XCPPFLAGS but XCPP ets XCFLAGS content.
~/src.configs/make.conf was empty.
# more /usr/src/sys/arm/conf/RPI2-NODBG
#
# RPI2 -- Custom configuration for the Raspberry Pi 2
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
ident RPI2-NODBG
include "RPI2"
makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols
options ALT_BREAK_TO_DEBUGGER
#optionsVERBOSE_SYSINIT # Enable verbose sysinit messages
options KDB # Enable kernel debugger support
# For minimum debugger support (stable branch) use:
#optionsKDB_TRACE # Print a stack trace for a panic
options DDB # Enable the kernel debugger
nooptions INVARIANTS # Enable calls of extra sanity checking
nooptions INVARIANT_SUPPORT # Extra sanity checks of internal
structures, required by INVARIANTS
nooptions WITNESS # Enable checks to detect deadlocks and
cycles
nooptions WITNESS_SKIPSPIN# Don't run witness on spinlocks for
speed
nooptions DIAGNOSTIC
My /usr/src tree has some changes/additions --but mostly for powerpc64 and
powerpc issues:
# svnlite status /usr/src/
M /usr/src/contrib/llvm/lib/CodeGen/Sele
Re: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]
On Tue, 21 Jun 2016, Ian Lepore wrote: On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote: Em 21/06/2016 07:33, Keith White escreveu: In an earlier message Ian said that he thought he knew what the problem was... Here the problem occurs when using wifi. I do not have tested wired because I don't have a cable here. []'s -Otacilio The wifi alignment fault should be fixed as of r302064. Sorry it took so long. -- Ian Many thanks Ian! Yes, this has fixed the problem. No more panics on ssh to rpi-b. ...keith ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
gstat(8) regression
This regression still exists as of r302073: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204852 Run /usr/sbin/gstat, press 'q' Prior to 11-CURRENT gstat would exit. "Currently" gstat regressively also requires . ...keith ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
