Re: vm_reserv.c panic on sparc64 current
On 01/19/2014 18:06, Manfred Antar wrote: > vm_reserv.c starting with revision 25 causes panic on sparc64 (netra T1 > 200) > version 259998 works > > backtrace: > Starting apache22. > panic: Bad link elm 0xf8007d4728f8 prev->next != elm > cpuid = 0 > KDB: enter: panic > [ thread pid 1965 tid 100058 ] > Stopped at kdb_enter+0x80: ta %xcc, 1 > db> bt > Tracing pid 1965 tid 100058 td 0xf80001880db0 > vpanic() at vpanic+0x1f8 > panic() at panic+0x20 > vm_page_dequeue() at vm_page_dequeue+0xf8 Can you provide the full contents of the struct vm_page that is being passed to vm_page_dequeue? > vm_fault_hold() at vm_fault_hold+0x54c > vm_fault() at vm_fault+0x88 > trap_pfault() at trap_pfault+0x1ac > trap() at trap+0xdc > -- data access protection tar=0x4100679c sfar=0x41006010 sfsr=0x85 > %o7=0x4062ea3c -- > userland() at 0x4062eab8 > user trace: trap %o7=0x4062ea3c > pc 0x4062eab8, sp 0x7fdd811 > pc 0x4062ecd0, sp 0x7fdd8d1 > pc 0x406397f0, sp 0x7fdd991 > pc 0x1121f8, sp 0x7fdda71 > pc 0x11bc4c, sp 0x7fddb31 > pc 0x10fce8, sp 0x7fddbf1 > pc 0x107e14, sp 0x7fddcb1 > pc 0x106310, sp 0x7fddd71 > pc 0x107160, sp 0x7fdde81 > pc 0x106360, sp 0x7fde041 > pc 0x106284, sp 0x7fde151 > pc 0x111c6c, sp 0x7fde261 > pc 0x112118, sp 0x7fde341 > pc 0x102bc4, sp 0x7fde441 > pc 0x402258f4, sp 0x7fde501 > done > > > > || n...@pozo.com || > || || > > > ___ 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: using ConnectX card as Ethernet (mlxen)
Hi, On 2013-7-9, at 22:08, John Nielsen wrote: On Jul 9, 2013, at 9:58 AM, John Baldwin wrote: >> So this was just fixed (finally) in HEAD in r253048. You can how use the >> sysctls to change this. > > I saw the commit. Thanks! I'll give it a try at some point (whenever my > schedule and hardware availability align). is this supposed to work at the moment? When I try, the machine seems to crash: root@one:~ # sysctl sys.device.mlx4_core0.mlx4_port1=eth sys.device.mlx4_core0.mlx4_port1: auto (ib) Write failed: Broken pipe Shared connection to xxx closed. Unfortunately I don't have serial console access at the moment, so I can't access any messages that may have gotten dumped. The cards in question are: mlx4_core0@pci0:17:0:0: class=0x028000 card=0x005015b3 chip=0x100315b3 rev=0x00 hdr=0x00 vendor = 'Mellanox Technologies' device = 'MT27500 Family [ConnectX-3]' class = network Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: using ConnectX card as Ethernet (mlxen)
Hi, if I leave the mlx4ib device out of the kernel (i.e., only compile in mlxen), doing the sysctl switch to Ethernet mode works fine. Lars On 2014-1-20, at 13:08, Eggert, Lars wrote: > Hi, > > On 2013-7-9, at 22:08, John Nielsen wrote: > On Jul 9, 2013, at 9:58 AM, John Baldwin wrote: >>> So this was just fixed (finally) in HEAD in r253048. You can how use the >>> sysctls to change this. >> >> I saw the commit. Thanks! I'll give it a try at some point (whenever my >> schedule and hardware availability align). > > is this supposed to work at the moment? When I try, the machine seems to > crash: > > root@one:~ # sysctl sys.device.mlx4_core0.mlx4_port1=eth > sys.device.mlx4_core0.mlx4_port1: auto (ib) > Write failed: Broken pipe > Shared connection to xxx closed. > > Unfortunately I don't have serial console access at the moment, so I can't > access any messages that may have gotten dumped. > > The cards in question are: > > mlx4_core0@pci0:17:0:0: class=0x028000 card=0x005015b3 chip=0x100315b3 > rev=0x00 hdr=0x00 >vendor = 'Mellanox Technologies' >device = 'MT27500 Family [ConnectX-3]' >class = network > > Lars signature.asc Description: Message signed with OpenPGP using GPGMail
panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx...
I saw this on my "build machine" after updating the "head" slice from:
FreeBSD 11.0-CURRENT #1387 r260875M/260877:115: Sun Jan 19 11:57:25 PST
2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386
to
FreeBSD 11.0-CURRENT #1388 r260904M/260904:115: Mon Jan 20 06:25:53 PST
2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386
A bit of context: On this machine and my laptop, it is my practice to perform
the following on a daily basis:
* Ensure the machine is booted from slice 1 (stable/9).
* Update the ports tree.
* Update the source tree.
* Start fetching any ports that are to be updated.
* Update stable/9.
* Reboot (staying on slice 1 -- stable/9).
* Update the installed ports that warrant it ("portmaster -da --index").
* Update the sources on slice 3 (stable/10).
* Remove old libraries for stable/9 ("make delete-old-libs").
* Reboot to slice 3 (stable/10).
* Update stable/10.
* Reboot (staying on slice 3 -- stable/10).
* Update the sources on slice 4 (head).
* Remove old libraries for stable/10 ("make delete-old-libs").
* Reboot to slice 4 (head)
* Update head.
* Reboot (staying on slice 4 -- head).
* Remove old libraries for head ("make delete-old-libs").
[If a given slice didn't have source updates, I don't try to rebuild
FreeBSD on it, though.]
For my laptop, I then reboot to slice 1 (usually; sometimes slice
3, especially if there were no source updates for stable/9). For
the build machine, I set the default boot slice back to 1, then issue
"shutdown -p now" to shut it off until just before midnight.
Today, there were a couple of perturbations from the above:
* The only update for stable/10 I had was:
U/S3/usr/src/release/doc/en_US.ISO8859-1/errata/article.xml
so I decided that didn't warrant rebuilding FreeBSD stable/10.
* The panic in the Subject line -- only on the build machine.
Here's what I see (cut/paste) on serial console:
...
Jan 20 07:02:12 freebeast shutdown: power-down by david:
Stopping cron.
Waiting for PIDS: 1090.
Stopping sshd.
Waiting for PIDS: 1080.
Stopping rsyncd.
Waiting for PIDS: 1057.
Stopping powerd.
Waiting for PIDS: 1042.
sysctl: dev.cpu.0.freq=3600: Device not configured
Stopping ntpd.
Waiting for PIDS: 1039.
Stopping lpd.
Waiting for PIDS: 1018.
Stopping lockd.
Waiting for PIDS: 1001.
Stopping statd.
Waiting for PIDS: 998.
Stopping nfsd.
Waiting for PIDS: 994 995.
Stopping mountd.
Waiting for PIDS: 992.
Stopping casperd.
Waiting for PIDS: 951.
Stopping amd.
Waiting for PIDS: 943.
Stopping ypbind.
Stopping rpcbind.
Waiting for PIDS: 916, 916.
Stopping devd.
Writing entropy file:.
Terminated
.
Jan 20 07:02:16 freebeast syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
All buffers synced.
lock order reversal:
1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237
2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412
KDB: stack backtrace:
db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at
db_trace_self_wrapper+0x2d/frame 0xe1fb9828
kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at
kdb_backtrace+0x30/frame 0xe1fb9890
witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at
witness_checkorder+0xc8a/frame 0xe1fb98e0
__lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at
__lockmgr_args+0x844/frame 0xe1fb99b4
vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at
vop_stdlock+0x4d/frame 0xe1fb99e4
VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at VOP_LOCK1_APV+0x104/frame
0xe1fb9a10
_vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at _vn_lock+0xa1/frame
0xe1fb9a50
ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at
ffs_flushfiles+0x14c/frame 0xe1fb9a9c
softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at
softdep_flushfiles+0x6e/frame 0xe1fb9af0
ffs_unmount(c753f000,8,e1fb9b70,518,c6f0a310,...) at
ffs_unmount+0x194/frame 0xe1fb9b38
dounmount(c753f000,8,c6f0a310,0,e1db3eb0,...) at dounmount+0x4dc/frame
0xe1fb9b98
vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at
vfs_unmountall+0x4e/frame 0xe1fb9bb8
kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame 0xe1fb9c20
sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/frame
0xe1fb9c40
syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc
Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc
--- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = 0xbfbfd88c,
ebp = 0xbfbfd960 ---
Uptime: 4m28s
panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @
/usr/src/sys/dev/uart/uart_cpu.h:94
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c112d57c,2f727375,2f637273,2f737973,2f766564,...) at
db_trace_self_wrapper+0x2d/frame 0xe1fb9a60
kdb_backtrace(c1
Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx...
On Mon, Jan 20, 2014 at 07:36:15AM -0800, David Wolfskill wrote: > Jan 20 07:02:16 freebeast syslogd: exiting on signal 15 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > All buffers synced. > lock order reversal: > 1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237 > 2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412 > KDB: stack backtrace: > db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at > db_trace_self_wrapper+0x2d/frame 0xe1fb9828 > kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at > kdb_backtrace+0x30/frame 0xe1fb9890 > witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at > witness_checkorder+0xc8a/frame 0xe1fb98e0 > __lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at > __lockmgr_args+0x844/frame 0xe1fb99b4 > vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at > vop_stdlock+0x4d/frame 0xe1fb99e4 > VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at > VOP_LOCK1_APV+0x104/frame 0xe1fb9a10 > _vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at _vn_lock+0xa1/frame > 0xe1fb9a50 > ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at > ffs_flushfiles+0x14c/frame 0xe1fb9a9c > softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at > softdep_flushfiles+0x6e/frame 0xe1fb9af0 > ffs_unmount(c753f000,8,e1fb9b70,518,c6f0a310,...) at > ffs_unmount+0x194/frame 0xe1fb9b38 > dounmount(c753f000,8,c6f0a310,0,e1db3eb0,...) at dounmount+0x4dc/frame > 0xe1fb9b98 > vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at > vfs_unmountall+0x4e/frame 0xe1fb9bb8 > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame 0xe1fb9c20 > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/frame > 0xe1fb9c40 > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc > --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = > 0xbfbfd88c, ebp = 0xbfbfd960 --- > Uptime: 4m28s > panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @ > /usr/src/sys/dev/uart/uart_cpu.h:94 > > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c112d57c,2f727375,2f637273,2f737973,2f766564,...) at > db_trace_self_wrapper+0x2d/frame 0xe1fb9a60 > kdb_backtrace(c12ec1f3,0,c11269a2,e1fb9b38,e1fb9b08,...) at > kdb_backtrace+0x30/frame 0xe1fb9ac8 > vpanic(c140d0c8,100,c11269a2,e1fb9b38,e1fb9b38,...) at vpanic+0x11f/frame > 0xe1fb9b08 > kassert_panic(c11269a2,c10f66d8,c10f6758,5e,8,...) at > kassert_panic+0xea/frame 0xe1fb9b2c > __mtx_lock_spin_flags(c7291830,0,c10f6758,5e,c137d684,...) at > __mtx_lock_spin_flags+0x190/frame 0xe1fb9b5c > ns8250_bus_grab(c7291800,c7062b28,c137d684,5e,c140b9a4,...) at > ns8250_bus_grab+0x40/frame 0xe1fb9b78 > uart_grab(c13fd070) at uart_grab+0x83/frame 0xe1fb9b9c > uart_cngrab(c137d69c,8889,e1fb9c20,c0ac7d43,c1128e43,...) at > uart_cngrab+0x12/frame 0xe1fb9ba8 > cngrab(c1128e43,1c,c112895a,144,c6d8b1a0,...) at cngrab+0x33/frame 0xe1fb9bb8 > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x6d3/frame 0xe1fb9c20 > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/frame > 0xe1fb9c40 > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc > --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = > 0xbfbfd88c, ebp = 0xbfbfd960 --- > KDB: enter: panic > [ thread pid 1 tid 12 ] > Stopped at kdb_enter+0x3d: movl$0,kdb_why > db> show locks > exclusive sleep mutex Giant (Giant) r = 0 (0xc1724910) locked @ > /usr/src/sys/vm/swap_pager.c:2365 > db> > > > When I issued "reset", the machine came back up normally (in slice > 1 -- stable/9). I then rebooted to slice 4 (head), and issued the > same commands I usually do to set the default boot slice back to 1, then > "shutdown -p now" -- and re-created the panic. > > I can leave the machine up for a while if anyone has suggestions for me > to poke around. I have a local private mirror of the FreeBSD SVN repos > and a spare bootable slice; I'm williing to try patches. The machine > isn't especially fast, but it's generally OK. > > If it would be worthwhile, I could reboot my laptop to slice 4 (head) & > attempt the same reset-to-slice-1-default & power-off. > > This definitely did not happen @r260875, and it appears to be quite > repeatable @r260904. You do not have option WITNESS_SKIPSPIN in your kernel config, do you ? pgpY3Jf7_Mo70.pgp Description: PGP signature
Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx...
On Mon, Jan 20, 2014 at 11:37 AM, Konstantin Belousov wrote: > On Mon, Jan 20, 2014 at 07:36:15AM -0800, David Wolfskill wrote: > > Jan 20 07:02:16 freebeast syslogd: exiting on signal 15 > > Waiting (max 60 seconds) for system process `vnlru' to stop...done > > Waiting (max 60 seconds) for system process `syncer' to stop... > > Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done > > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > > All buffers synced. > > lock order reversal: > > 1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237 > > 2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412 > > KDB: stack backtrace: > > db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at > db_trace_self_wrapper+0x2d/frame 0xe1fb9828 > > kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at > kdb_backtrace+0x30/frame 0xe1fb9890 > > witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at > witness_checkorder+0xc8a/frame 0xe1fb98e0 > > __lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at > __lockmgr_args+0x844/frame 0xe1fb99b4 > > vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at > vop_stdlock+0x4d/frame 0xe1fb99e4 > > VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at > VOP_LOCK1_APV+0x104/frame 0xe1fb9a10 > > _vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at > _vn_lock+0xa1/frame 0xe1fb9a50 > > ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at > ffs_flushfiles+0x14c/frame 0xe1fb9a9c > > softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at > softdep_flushfiles+0x6e/frame 0xe1fb9af0 > > ffs_unmount(c753f000,8,e1fb9b70,518,c6f0a310,...) at > ffs_unmount+0x194/frame 0xe1fb9b38 > > dounmount(c753f000,8,c6f0a310,0,e1db3eb0,...) at > dounmount+0x4dc/frame 0xe1fb9b98 > > vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at > vfs_unmountall+0x4e/frame 0xe1fb9bb8 > > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame > 0xe1fb9c20 > > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at > sys_reboot+0x6f/frame 0xe1fb9c40 > > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc > > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc > > --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = > 0xbfbfd88c, ebp = 0xbfbfd960 --- > > Uptime: 4m28s > > panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @ > /usr/src/sys/dev/uart/uart_cpu.h:94 > > > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self_wrapper(c112d57c,2f727375,2f637273,2f737973,2f766564,...) > at db_trace_self_wrapper+0x2d/frame 0xe1fb9a60 > > kdb_backtrace(c12ec1f3,0,c11269a2,e1fb9b38,e1fb9b08,...) at > kdb_backtrace+0x30/frame 0xe1fb9ac8 > > vpanic(c140d0c8,100,c11269a2,e1fb9b38,e1fb9b38,...) at > vpanic+0x11f/frame 0xe1fb9b08 > > kassert_panic(c11269a2,c10f66d8,c10f6758,5e,8,...) at > kassert_panic+0xea/frame 0xe1fb9b2c > > __mtx_lock_spin_flags(c7291830,0,c10f6758,5e,c137d684,...) at > __mtx_lock_spin_flags+0x190/frame 0xe1fb9b5c > > ns8250_bus_grab(c7291800,c7062b28,c137d684,5e,c140b9a4,...) at > ns8250_bus_grab+0x40/frame 0xe1fb9b78 > > uart_grab(c13fd070) at uart_grab+0x83/frame 0xe1fb9b9c > > uart_cngrab(c137d69c,8889,e1fb9c20,c0ac7d43,c1128e43,...) at > uart_cngrab+0x12/frame 0xe1fb9ba8 > > cngrab(c1128e43,1c,c112895a,144,c6d8b1a0,...) at cngrab+0x33/frame > 0xe1fb9bb8 > > kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x6d3/frame > 0xe1fb9c20 > > sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at > sys_reboot+0x6f/frame 0xe1fb9c40 > > syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc > > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc > > --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = > 0xbfbfd88c, ebp = 0xbfbfd960 --- > > KDB: enter: panic > > [ thread pid 1 tid 12 ] > > Stopped at kdb_enter+0x3d: movl$0,kdb_why > > db> show locks > > exclusive sleep mutex Giant (Giant) r = 0 (0xc1724910) locked @ > /usr/src/sys/vm/swap_pager.c:2365 > > db> > > > > > > When I issued "reset", the machine came back up normally (in slice > > 1 -- stable/9). I then rebooted to slice 4 (head), and issued the > > same commands I usually do to set the default boot slice back to 1, then > > "shutdown -p now" -- and re-created the panic. > > > > I can leave the machine up for a while if anyone has suggestions for me > > to poke around. I have a local private mirror of the FreeBSD SVN repos > > and a spare bootable slice; I'm williing to try patches. The machine > > isn't especially fast, but it's generally OK. > > > > If it would be worthwhile, I could reboot my laptop to slice 4 (head) & > > attempt the same reset-to-slice-1-default & power-off. > > > > This definitely did not happen @r260875, and it appears to be quite > > repeatable @r260904 > > You do not have option WITNESS_SKIPSPIN in your kernel config, do you ? > My recent source upgrade from 10.0-RELEASE r260689 to 11.0-CURRENT r260850 left me with a GENERIC kernel with the follow
Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx...
On Mon, 2014-01-20 at 07:36 -0800, David Wolfskill wrote:
> I saw this on my "build machine" after updating the "head" slice from:
>
> FreeBSD 11.0-CURRENT #1387 r260875M/260877:115: Sun Jan 19 11:57:25 PST
> 2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC
> i386
>
> to
>
> FreeBSD 11.0-CURRENT #1388 r260904M/260904:115: Mon Jan 20 06:25:53 PST
> 2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC
> i386
>
>
> A bit of context: On this machine and my laptop, it is my practice to
> perform the following on a daily basis:
> * Ensure the machine is booted from slice 1 (stable/9).
> * Update the ports tree.
> * Update the source tree.
> * Start fetching any ports that are to be updated.
> * Update stable/9.
> * Reboot (staying on slice 1 -- stable/9).
> * Update the installed ports that warrant it ("portmaster -da --index").
> * Update the sources on slice 3 (stable/10).
> * Remove old libraries for stable/9 ("make delete-old-libs").
> * Reboot to slice 3 (stable/10).
> * Update stable/10.
> * Reboot (staying on slice 3 -- stable/10).
> * Update the sources on slice 4 (head).
> * Remove old libraries for stable/10 ("make delete-old-libs").
> * Reboot to slice 4 (head)
> * Update head.
> * Reboot (staying on slice 4 -- head).
> * Remove old libraries for head ("make delete-old-libs").
>
> [If a given slice didn't have source updates, I don't try to rebuild
> FreeBSD on it, though.]
>
> For my laptop, I then reboot to slice 1 (usually; sometimes slice
> 3, especially if there were no source updates for stable/9). For
> the build machine, I set the default boot slice back to 1, then issue
> "shutdown -p now" to shut it off until just before midnight.
>
> Today, there were a couple of perturbations from the above:
> * The only update for stable/10 I had was:
> U/S3/usr/src/release/doc/en_US.ISO8859-1/errata/article.xml
>
> so I decided that didn't warrant rebuilding FreeBSD stable/10.
>
> * The panic in the Subject line -- only on the build machine.
>
> Here's what I see (cut/paste) on serial console:
>
> ...
> Jan 20 07:02:12 freebeast shutdown: power-down by david:
> Stopping cron.
> Waiting for PIDS: 1090.
> Stopping sshd.
> Waiting for PIDS: 1080.
> Stopping rsyncd.
> Waiting for PIDS: 1057.
> Stopping powerd.
> Waiting for PIDS: 1042.
> sysctl: dev.cpu.0.freq=3600: Device not configured
> Stopping ntpd.
> Waiting for PIDS: 1039.
> Stopping lpd.
> Waiting for PIDS: 1018.
> Stopping lockd.
> Waiting for PIDS: 1001.
> Stopping statd.
> Waiting for PIDS: 998.
> Stopping nfsd.
> Waiting for PIDS: 994 995.
> Stopping mountd.
> Waiting for PIDS: 992.
> Stopping casperd.
> Waiting for PIDS: 951.
> Stopping amd.
> Waiting for PIDS: 943.
> Stopping ypbind.
> Stopping rpcbind.
> Waiting for PIDS: 916, 916.
> Stopping devd.
> Writing entropy file:.
> Terminated
> .
> Jan 20 07:02:16 freebeast syslogd: exiting on signal 15
> Waiting (max 60 seconds) for system process `vnlru' to stop...done
> Waiting (max 60 seconds) for system process `syncer' to stop...
> Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done
> Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
> All buffers synced.
> lock order reversal:
> 1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237
> 2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412
> KDB: stack backtrace:
> db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at
> db_trace_self_wrapper+0x2d/frame 0xe1fb9828
> kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at
> kdb_backtrace+0x30/frame 0xe1fb9890
> witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at
> witness_checkorder+0xc8a/frame 0xe1fb98e0
> __lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at
> __lockmgr_args+0x844/frame 0xe1fb99b4
> vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at
> vop_stdlock+0x4d/frame 0xe1fb99e4
> VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at
> VOP_LOCK1_APV+0x104/frame 0xe1fb9a10
> _vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at _vn_lock+0xa1/frame
> 0xe1fb9a50
> ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at
> ffs_flushfiles+0x14c/frame 0xe1fb9a9c
> softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at
> softdep_flushfiles+0x6e/frame 0xe1fb9af0
> ffs_unmount(c753f000,8,e1fb9b70,518,c6f0a310,...) at
> ffs_unmount+0x194/frame 0xe1fb9b38
> dounmount(c753f000,8,c6f0a310,0,e1db3eb0,...) at dounmount+0x4dc/frame
> 0xe1fb9b98
> vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at
> vfs_unmountall+0x4e/frame 0xe1fb9bb8
> kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame 0xe1fb9c20
> sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/frame
> 0xe1fb9c40
> syscall(e1fb9d08) at syscall+0x2de/frame 0xe1fb9cfc
> Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc
> --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp =
> 0xbfbf
Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx...
On Jan 20, 2014, at 10:14 AM, Ian Lepore wrote:
> On Mon, 2014-01-20 at 07:36 -0800, David Wolfskill wrote:
>> I saw this on my "build machine" after updating the "head" slice from:
>>
>> FreeBSD 11.0-CURRENT #1387 r260875M/260877:115: Sun Jan 19 11:57:25 PST
>> 2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC
>> i386
>>
>> to
>>
>> FreeBSD 11.0-CURRENT #1388 r260904M/260904:115: Mon Jan 20 06:25:53 PST
>> 2014 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC
>> i386
>>
>>
>> A bit of context: On this machine and my laptop, it is my practice to
>> perform the following on a daily basis:
>> * Ensure the machine is booted from slice 1 (stable/9).
>> * Update the ports tree.
>> * Update the source tree.
>> * Start fetching any ports that are to be updated.
>> * Update stable/9.
>> * Reboot (staying on slice 1 -- stable/9).
>> * Update the installed ports that warrant it ("portmaster -da --index").
>> * Update the sources on slice 3 (stable/10).
>> * Remove old libraries for stable/9 ("make delete-old-libs").
>> * Reboot to slice 3 (stable/10).
>> * Update stable/10.
>> * Reboot (staying on slice 3 -- stable/10).
>> * Update the sources on slice 4 (head).
>> * Remove old libraries for stable/10 ("make delete-old-libs").
>> * Reboot to slice 4 (head)
>> * Update head.
>> * Reboot (staying on slice 4 -- head).
>> * Remove old libraries for head ("make delete-old-libs").
>>
>> [If a given slice didn't have source updates, I don't try to rebuild
>> FreeBSD on it, though.]
>>
>> For my laptop, I then reboot to slice 1 (usually; sometimes slice
>> 3, especially if there were no source updates for stable/9). For
>> the build machine, I set the default boot slice back to 1, then issue
>> "shutdown -p now" to shut it off until just before midnight.
>>
>> Today, there were a couple of perturbations from the above:
>> * The only update for stable/10 I had was:
>> U/S3/usr/src/release/doc/en_US.ISO8859-1/errata/article.xml
>>
>> so I decided that didn't warrant rebuilding FreeBSD stable/10.
>>
>> * The panic in the Subject line -- only on the build machine.
>>
>> Here's what I see (cut/paste) on serial console:
>>
>> ...
>> Jan 20 07:02:12 freebeast shutdown: power-down by david:
>> Stopping cron.
>> Waiting for PIDS: 1090.
>> Stopping sshd.
>> Waiting for PIDS: 1080.
>> Stopping rsyncd.
>> Waiting for PIDS: 1057.
>> Stopping powerd.
>> Waiting for PIDS: 1042.
>> sysctl: dev.cpu.0.freq=3600: Device not configured
>> Stopping ntpd.
>> Waiting for PIDS: 1039.
>> Stopping lpd.
>> Waiting for PIDS: 1018.
>> Stopping lockd.
>> Waiting for PIDS: 1001.
>> Stopping statd.
>> Waiting for PIDS: 998.
>> Stopping nfsd.
>> Waiting for PIDS: 994 995.
>> Stopping mountd.
>> Waiting for PIDS: 992.
>> Stopping casperd.
>> Waiting for PIDS: 951.
>> Stopping amd.
>> Waiting for PIDS: 943.
>> Stopping ypbind.
>> Stopping rpcbind.
>> Waiting for PIDS: 916, 916.
>> Stopping devd.
>> Writing entropy file:.
>> Terminated
>> .
>> Jan 20 07:02:16 freebeast syslogd: exiting on signal 15
>> Waiting (max 60 seconds) for system process `vnlru' to stop...done
>> Waiting (max 60 seconds) for system process `syncer' to stop...
>> Syncing disks, vnodes remaining...2 4 4 4 3 3 3 2 1 1 0 0 0 0 done
>> Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
>> All buffers synced.
>> lock order reversal:
>> 1st 0xc7336c68 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237
>> 2nd 0xc76846dc devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1412
>> KDB: stack backtrace:
>> db_trace_self_wrapper(c112d57c,a3231,e1fb9888,c0b1bfe7,1,...) at
>> db_trace_self_wrapper+0x2d/frame 0xe1fb9828
>> kdb_backtrace(c1131131,c76846dc,c1124024,c6dad2d0,c1162dc1,...) at
>> kdb_backtrace+0x30/frame 0xe1fb9890
>> witness_checkorder(c76846dc,9,c1162dc1,584,0,...) at
>> witness_checkorder+0xc8a/frame 0xe1fb98e0
>> __lockmgr_args(c76846dc,80400,c76846fc,0,0,0,c1162dc1,584) at
>> __lockmgr_args+0x844/frame 0xe1fb99b4
>> vop_stdlock(e1fb9a28,c6dad3a0,c6dad408,c169bc38,e1fb9a4c,...) at
>> vop_stdlock+0x4d/frame 0xe1fb99e4
>> VOP_LOCK1_APV(c13828dc,e1fb9a28,0,0,c13cded0,...) at
>> VOP_LOCK1_APV+0x104/frame 0xe1fb9a10
>> _vn_lock(c76846a8,80400,c1162dc1,584,c1393aac,...) at _vn_lock+0xa1/frame
>> 0xe1fb9a50
>> ffs_flushfiles(c753f000,a,c6f0a310,e1fb9b38,c0d416e3,...) at
>> ffs_flushfiles+0x14c/frame 0xe1fb9a9c
>> softdep_flushfiles(c753f000,2,c6f0a310,0,0,...) at
>> softdep_flushfiles+0x6e/frame 0xe1fb9af0
>> ffs_unmount(c753f000,8,e1fb9b70,518,c6f0a310,...) at
>> ffs_unmount+0x194/frame 0xe1fb9b38
>> dounmount(c753f000,8,c6f0a310,0,e1db3eb0,...) at dounmount+0x4dc/frame
>> 0xe1fb9b98
>> vfs_unmountall(e1db4058,0,c112895a,144,c6d8b1a0,...) at
>> vfs_unmountall+0x4e/frame 0xe1fb9bb8
>> kern_reboot(4008,0,c112895a,c3,0,...) at kern_reboot+0x5af/frame 0xe1fb9c20
>> sys_reboot(c6f0a310,e1fb9cc8,14,c112b5b7,7a2,...) at sys_reboot+0x6f/frame
>> 0xe1fb9c40
>> syscall(e1fb9d08) at s
Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx...
> On Mon, 2014-01-20 at 07:36 -0800, David Wolfskill wrote: >> panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx @ >> /usr/src/sys/dev/uart/uart_cpu.h:94 > > Since you mention serial console, I think r260890 might be a candidate. I have a fix for this. I committed the wrong version of uart_core.c. r260911 should fix this. So this is broken from r260890-r260910. Warner ___ 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: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx...
On Mon, Jan 20, 2014 at 06:37:50PM +0200, Konstantin Belousov wrote: > ... > You do not have option WITNESS_SKIPSPIN in your kernel config, do you ? It was a GENERIC kernel for i386; it has WITNESS_SKIPSPIN. On Mon, Jan 20, 2014 at 10:14:08AM -0700, Ian Lepore wrote: > ... > Since you mention serial console, I think r260890 might be a candidate. Good call. :-} On Mon, Jan 20, 2014 at 10:24:01AM -0700, Warner Losh wrote: > ... > I'm pretty sure that it is. I'll take a look at it. On Mon, Jan 20, 2014 at 10:47:12AM -0700, Warner Losh wrote: > ... > I have a fix for this. I committed the wrong version of uart_core.c. r260911 > should fix this. So this is broken from r260890-r260910. > So I see. I'll hand-apply that, rebuild the kernel, and give it a shot, Thanks, all! :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgph4ZfTZFeNo.pgp Description: PGP signature
Re: panic: mtx_lock_spin: recursed on non-recursive mutex uart_hwmtx...
On Mon, Jan 20, 2014 at 10:33:41AM -0800, David Wolfskill wrote: > ... > On Mon, Jan 20, 2014 at 10:47:12AM -0700, Warner Losh wrote: > > ... > > I have a fix for this. I committed the wrong version of uart_core.c. > > r260911 should fix this. So this is broken from r260890-r260910. > > > > So I see. I'll hand-apply that, rebuild the kernel, and give it a shot, > > Thanks, all! :-) > We have a winner! Ref.: ... Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xe1fb9cfc --- syscall (55, FreeBSD ELF32, sys_reboot), eip = 0x805a9df, esp = 0xbfbfd88c, ebp = 0xbfbfd960 --- Uptime: 5m15s usbus0: Controller shutdown uhub0: at usbus0, port 1, addr 1 (disconnected) usbus0: Controller shutdown complete usbus1: Controller shutdown uhub1: at usbus1, port 1, addr 1 (disconnected) usbus1: Controller shutdown complete usbus2: Controller shutdown uhub2: at usbus2, port 1, addr 1 (disconnected) usbus2: Controller shutdown complete usbus3: Controller shutdown uhub3: at usbus3, port 1, addr 1 (disconnected) usbus3: Controller shutdown complete usbus4: Controller shutdown uhub4: at usbus4, port 1, addr 1 (disconnected) usbus4: Controller shutdown complete aac0: shutting down controller...done acpi0: Powering system off Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpbPKVHHmFOI.pgp Description: PGP signature
[head tinderbox] failure on arm/arm
TB --- 2014-01-20 15:50:22 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-20 15:50:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-20 15:50:22 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-20 15:50:22 - cleaning the object tree TB --- 2014-01-20 15:51:45 - /usr/local/bin/svn stat /src TB --- 2014-01-20 15:51:48 - At svn revision 260909 TB --- 2014-01-20 15:51:49 - building world TB --- 2014-01-20 15:51:49 - CROSS_BUILD_TESTING=YES TB --- 2014-01-20 15:51:49 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-20 15:51:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-20 15:51:49 - SRCCONF=/dev/null TB --- 2014-01-20 15:51:49 - TARGET=arm TB --- 2014-01-20 15:51:49 - TARGET_ARCH=arm TB --- 2014-01-20 15:51:49 - TZ=UTC TB --- 2014-01-20 15:51:49 - __MAKE_CONF=/dev/null TB --- 2014-01-20 15:51:49 - cd /src TB --- 2014-01-20 15:51:49 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jan 20 15:51:56 UTC 2014 >>> 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 >>> World build completed on Mon Jan 20 18:53:38 UTC 2014 TB --- 2014-01-20 18:53:38 - generating LINT kernel config TB --- 2014-01-20 18:53:38 - cd /src/sys/arm/conf TB --- 2014-01-20 18:53:38 - /usr/bin/make -B LINT TB --- 2014-01-20 18:53:38 - cd /src/sys/arm/conf TB --- 2014-01-20 18:53:38 - /usr/sbin/config -m LINT TB --- 2014-01-20 18:53:39 - building LINT kernel TB --- 2014-01-20 18:53:39 - CROSS_BUILD_TESTING=YES TB --- 2014-01-20 18:53:39 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-20 18:53:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-20 18:53:39 - SRCCONF=/dev/null TB --- 2014-01-20 18:53:39 - TARGET=arm TB --- 2014-01-20 18:53:39 - TARGET_ARCH=arm TB --- 2014-01-20 18:53:39 - TZ=UTC TB --- 2014-01-20 18:53:39 - __MAKE_CONF=/dev/null TB --- 2014-01-20 18:53:39 - cd /src TB --- 2014-01-20 18:53:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 20 18:53:39 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_mem' uart_cpu_fdt.o: warning: previous common is here uart_cpu_pxa.o: warning: multiple common of `uart_bus_space_io' uart_cpu_fdt.o: warning: previous common is here board_hl201.o: In function `board_init': /src/sys/arm/at91/board_hl201.c:(.text+0x174): undefined reference to `at91_enable_nand' board_sam9260ek.o: In function `board_init': /src/sys/arm/at91/board_sam9260ek.c:(.text+0x2a8): undefined reference to `at91_enable_nand' *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-20 19:10:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-20 19:10:16 - ERROR: failed to build LINT kernel TB --- 2014-01-20 19:10:16 - 9319.49 user 1835.60 system 11993.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.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"
Problem updating bootcode on ZFS on root system with MBR
I am running 11.0-CURRENT (r260850) with zfs on root with MBR. After upgrading my 10.0-RELEASE (r260669) system to 11.0-CURRENT (r260850) my zpools reported that they needed to be upgraded. So, I upgraded my zpools and I am attempting to update the bootcode (as required). I managed to get the boot1 stage code updated, but cannot get the boot2 stage code updated. Here is what I have done: # sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 -> 16 # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.014996 secs (34142 bytes/sec) # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 bootcode written to ada0s1 # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 dd: /dev/ada0s1a: Operation not permitted The final dd statement fails with "operation not permitted". In all my research, understood the initial sysctl command I ran would prevent this particular error from happening. What do I need to do to get the boot2 code written to /dev/ada0s1a? Thanks. -Tom ___ 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: using ConnectX card as Ethernet (mlxen)
On Monday 20 January 2014 12:08:34 Eggert, Lars wrote: > Hi, > > On 2013-7-9, at 22:08, John Nielsen wrote: > > On Jul 9, 2013, at 9:58 AM, John Baldwin wrote: > >> So this was just fixed (finally) in HEAD in r253048. You can how use the > >> sysctls to change this. > > > > I saw the commit. Thanks! I'll give it a try at some point (whenever my > > schedule and hardware availability align). > is this supposed to work at the moment? When I try, the machine seems to > crash: > > root@one:~ # sysctl sys.device.mlx4_core0.mlx4_port1=eth > sys.device.mlx4_core0.mlx4_port1: auto (ib) > Write failed: Broken pipe > Shared connection to xxx closed. > > Unfortunately I don't have serial console access at the moment, so I can't > access any messages that may have gotten dumped. > > The cards in question are: > > mlx4_core0@pci0:17:0:0: class=0x028000 card=0x005015b3 chip=0x100315b3 > rev=0x00 hdr=0x00 vendor = 'Mellanox Technologies' > device = 'MT27500 Family [ConnectX-3]' > class = network I believe this should work, yes. Getting a crashdump or the panic messages would be really helpful in figuring out why it isn't. Thanks. -- 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"
