Re: -CURRENT panics in NFS
Thanks. I adjusted the namecache. However, the nfs fix provided by Rick should go in regardless. On 2/27/21, Juraj Lutter wrote: > > >> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote: >> >> Can you dump 'struct componentname *cnp'? This should do the trick: >> f 12 >> p cnp >> >> Most notably I want to know if the name to added is a literal dot. >> > > Yes, it is a dot (the directory itself): > > cn_nameptr = 0xfe0011428018 ".", cn_namelen = 1 > > otis > > -- Mateusz Guzik ___ 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: -CURRENT panics in NFS
> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote: > > Can you dump 'struct componentname *cnp'? This should do the trick: > f 12 > p cnp > > Most notably I want to know if the name to added is a literal dot. > Yes, it is a dot (the directory itself): cn_nameptr = 0xfe0011428018 ".", cn_namelen = 1 otis ___ 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: -CURRENT panics in NFS
You should be able to just use kgdb on the old kernel and the
crashdump you already collected, provided both are still around.
Alternatively boot with this without the fix:
diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c
index fef1e31d197b..c4d2990b155d 100644
--- a/sys/kern/vfs_cache.c
+++ b/sys/kern/vfs_cache.c
@@ -2266,6 +2266,9 @@ cache_enter_time(struct vnode *dvp, struct vnode
*vp, struct componentname *cnp,
KASSERT(cnp->cn_namelen <= NAME_MAX,
("%s: passed len %ld exceeds NAME_MAX (%d)", __func__,
cnp->cn_namelen,
NAME_MAX));
+ if (dvp == vp) {
+ panic("%s: same vnodes; cnp [%s] len %ld\n", __func__,
cnp->cn_nameptr, cnp->cn_namelen);
+ }
VNPASS(dvp != vp, dvp);
VNPASS(!VN_IS_DOOMED(dvp), dvp);
VNPASS(dvp->v_type != VNON, dvp);
On 2/27/21, Juraj Lutter wrote:
> I am now running a patched kernel, without problems.
>
> I can boot to unpatched one and see the output of these ddb commands.
>
> otis
>
> —
> Juraj Lutter
> XMPP: juraj (at) lutter.sk
> GSM: +421907986576
>
>> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote:
>>
>> Can you dump 'struct componentname *cnp'? This should do the trick:
>> f 12
>> p cnp
>>
>
>
>
--
Mateusz Guzik
___
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: -CURRENT panics in NFS
I am now running a patched kernel, without problems. I can boot to unpatched one and see the output of these ddb commands. otis — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 21:49, Mateusz Guzik wrote: > > Can you dump 'struct componentname *cnp'? This should do the trick: > f 12 > p cnp > ___ 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: -CURRENT panics in NFS
Can you dump 'struct componentname *cnp'? This should do the trick: f 12 p cnp Most notably I want to know if the name to added is a literal dot. That case is handled if necessary, but the assert was added to start making the interface stricter. If the name is a dot I'll be inclined to remove the assert for 13.x to avoid problems with other callers of the sort. Otherwise I'll have to check what's going on there. On 2/27/21, Juraj Lutter wrote: > Hi, > > thank you for the swift reaction. This patch fixed my problem. > > otis > > — > Juraj Lutter > XMPP: juraj (at) lutter.sk > GSM: +421907986576 > >> On 27 Feb 2021, at 16:53, Rick Macklem wrote: >> >> I reproduced the problem and the attached trivial patch >> seems to fix it. Please test the patch if you can. >> > > -- Mateusz Guzik ___ 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: -CURRENT panics in NFS
Hi, thank you for the swift reaction. This patch fixed my problem. otis — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 16:53, Rick Macklem wrote: > > I reproduced the problem and the attached trivial patch > seems to fix it. Please test the patch if you can. > ___ 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: -CURRENT panics in NFS
I reproduced the problem and the attached trivial patch seems to fix it. Please test the patch if you can. Mateusz, I assume the directory shouldn't try and add a cache entry for itself? I don't test NFSv3 much and I don't test "rdirplus" much, so it slipped through the cracks. Thanks for reporting it, rick From: owner-freebsd-curr...@freebsd.org on behalf of Juraj Lutter Sent: Saturday, February 27, 2021 9:31 AM To: freebsd-current Subject: Re: -CURRENT panics in NFS CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca And a kgdb backtrace: (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=textdump@entry=0) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0x804c7b2a in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:575 #3 0x804c78ee in db_command (last_cmdp=, cmd_table=, dopager=dopager@entry=1) at /usr/src/sys/ddb/db_command.c:482 #4 0x804c762d in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0x804cac36 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:270 #6 0x80c59d04 in kdb_trap (type=type@entry=3, code=code@entry=0, tf=, tf@entry=0xfe00d01c3d40) at /usr/src/sys/kern/subr_kdb.c:727 #7 0x810bc1ee in trap (frame=0xfe00d01c3d40) at /usr/src/sys/amd64/amd64/trap.c:576 #8 #9 kdb_enter (why=0x812accc9 "panic", msg=) at /usr/src/sys/kern/subr_kdb.c:506 #10 0x80c0d5d2 in vpanic (fmt=, ap=, ap@entry=0xfe00d01c3ea0) at /usr/src/sys/kern/kern_shutdown.c:907 #11 0x80c0d363 in panic (fmt=0x81e9a178 "\177\256&\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:843 #12 0x80cd6d74 in cache_enter_time (dvp=0xf80079321e00, vp=0xf80079321e00, cnp=cnp@entry=0xfe00d01c4030, tsp=tsp@entry=0xfe00d01c40e0, dtsp=) at /usr/src/sys/kern/vfs_cache.c:2274 #13 0x80ae2bd6 in nfsrpc_readdirplus (vp=, vp@entry=0xf80079321e00, uiop=, uiop@entry=0xfe00d01c4540, cookiep=cookiep@entry=0xfe00d01c44e0, cred=cred@entry=0xf80079307e00, p=, p@entry=0xfe00de06be00, nap=nap@entry=0xfe00d01c4400, attrflagp=0xfe00d01c44f0, eofp=0xfe00d01c44f4, stuff=0x0) at /usr/src/sys/fs/nfsclient/nfs_clrpcops.c:3766 #14 0x80aed4ec in ncl_readdirplusrpc (vp=vp@entry=0xf80079321e00, uiop=uiop@entry=0xfe00d01c4540, cred=0xf80079307e00, td=td@entry=0xfe00de06be00) at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:2490 #15 0x80afdc93 in ncl_doio (vp=vp@entry=0xf80079321e00, bp=bp@entry=0xfe000ee1c610, cr=0xfe00d01c3d00, cr@entry=0xf80079307e00, td=td@entry=0xfe00de06be00, called_from_strategy=called_from_strategy@entry=0) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1686 #16 0x80afce3c in ncl_bioread (vp=, vp@entry=0xf80079321e00, uio=, ioflag=ioflag@entry=0, cred=) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:604 #17 0x80af1baf in nfs_readdir (ap=ap@entry=0xfe00d01c4918) at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:2383 #18 0x80ce490f in vop_sigdefer (vop=, a=0xfe00d01c4918) at /usr/src/sys/kern/vfs_default.c:1471 #19 0x81181f38 in VOP_READDIR_APV (vop=0x81af00d8 , a=a@entry=0xfe00d01c4918) at vnode_if.c:1939 #20 0x80d0b23b in VOP_READDIR (vp=0xf80079321e00, uio=0xfe00d01c48d0, cred=, eofflag=0xfe00d01c48cc, ncookies=0x0, cookies=0x0) at ./vnode_if.h:985 #21 kern_getdirentries (td=, fd=, buf=0x801851000 , count=4096, basep=basep@entry=0xfe00d01c49b0, residp=residp@entry=0x0, bufseg=UIO_USERSPACE) at /usr/src/sys/kern/vfs_syscalls.c:4142 #22 0x80d0b449 in sys_getdirentries (td=0x81e9a178 , uap=0xfe00de06c1e8) at /usr/src/sys/kern/vfs_syscalls.c:4089 #23 0x810bd00e in syscallenter (td=) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #24 amd64_syscall (td=0xfe00de06be00, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1156 #25 #26 0x0008012a83fa in ?? () Backtrace stopped: Cannot access memory at address 0x7fffd928 — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 15:18, Juraj Lutter wrote: > > Reliably reproducible: > ___ 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" rdirplus.patch Description: rdirplus.patch ___ 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: -CURRENT panics in NFS
And a kgdb backtrace: (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=textdump@entry=0) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0x804c7b2a in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:575 #3 0x804c78ee in db_command (last_cmdp=, cmd_table=, dopager=dopager@entry=1) at /usr/src/sys/ddb/db_command.c:482 #4 0x804c762d in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0x804cac36 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:270 #6 0x80c59d04 in kdb_trap (type=type@entry=3, code=code@entry=0, tf=, tf@entry=0xfe00d01c3d40) at /usr/src/sys/kern/subr_kdb.c:727 #7 0x810bc1ee in trap (frame=0xfe00d01c3d40) at /usr/src/sys/amd64/amd64/trap.c:576 #8 #9 kdb_enter (why=0x812accc9 "panic", msg=) at /usr/src/sys/kern/subr_kdb.c:506 #10 0x80c0d5d2 in vpanic (fmt=, ap=, ap@entry=0xfe00d01c3ea0) at /usr/src/sys/kern/kern_shutdown.c:907 #11 0x80c0d363 in panic (fmt=0x81e9a178 "\177\256&\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:843 #12 0x80cd6d74 in cache_enter_time (dvp=0xf80079321e00, vp=0xf80079321e00, cnp=cnp@entry=0xfe00d01c4030, tsp=tsp@entry=0xfe00d01c40e0, dtsp=) at /usr/src/sys/kern/vfs_cache.c:2274 #13 0x80ae2bd6 in nfsrpc_readdirplus (vp=, vp@entry=0xf80079321e00, uiop=, uiop@entry=0xfe00d01c4540, cookiep=cookiep@entry=0xfe00d01c44e0, cred=cred@entry=0xf80079307e00, p=, p@entry=0xfe00de06be00, nap=nap@entry=0xfe00d01c4400, attrflagp=0xfe00d01c44f0, eofp=0xfe00d01c44f4, stuff=0x0) at /usr/src/sys/fs/nfsclient/nfs_clrpcops.c:3766 #14 0x80aed4ec in ncl_readdirplusrpc (vp=vp@entry=0xf80079321e00, uiop=uiop@entry=0xfe00d01c4540, cred=0xf80079307e00, td=td@entry=0xfe00de06be00) at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:2490 #15 0x80afdc93 in ncl_doio (vp=vp@entry=0xf80079321e00, bp=bp@entry=0xfe000ee1c610, cr=0xfe00d01c3d00, cr@entry=0xf80079307e00, td=td@entry=0xfe00de06be00, called_from_strategy=called_from_strategy@entry=0) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:1686 #16 0x80afce3c in ncl_bioread (vp=, vp@entry=0xf80079321e00, uio=, ioflag=ioflag@entry=0, cred=) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:604 #17 0x80af1baf in nfs_readdir (ap=ap@entry=0xfe00d01c4918) at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:2383 #18 0x80ce490f in vop_sigdefer (vop=, a=0xfe00d01c4918) at /usr/src/sys/kern/vfs_default.c:1471 #19 0x81181f38 in VOP_READDIR_APV (vop=0x81af00d8 , a=a@entry=0xfe00d01c4918) at vnode_if.c:1939 #20 0x80d0b23b in VOP_READDIR (vp=0xf80079321e00, uio=0xfe00d01c48d0, cred=, eofflag=0xfe00d01c48cc, ncookies=0x0, cookies=0x0) at ./vnode_if.h:985 #21 kern_getdirentries (td=, fd=, buf=0x801851000 , count=4096, basep=basep@entry=0xfe00d01c49b0, residp=residp@entry=0x0, bufseg=UIO_USERSPACE) at /usr/src/sys/kern/vfs_syscalls.c:4142 #22 0x80d0b449 in sys_getdirentries (td=0x81e9a178 , uap=0xfe00de06c1e8) at /usr/src/sys/kern/vfs_syscalls.c:4089 #23 0x810bd00e in syscallenter (td=) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #24 amd64_syscall (td=0xfe00de06be00, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1156 #25 #26 0x0008012a83fa in ?? () Backtrace stopped: Cannot access memory at address 0x7fffd928 — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 15:18, Juraj Lutter wrote: > > Reliably reproducible: > ___ 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: -CURRENT panics in NFS
Reliably reproducible: VNASSERT failed: dvp != vp not true at /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) 0xf80079321e00: type VDIR usecount 4, writecount 0, refcount 3 seqc users 0 mountedhere 0 hold count flags () flags (VV_ROOT|VV_VMSIZEVNLOCK) v_object 0xf801eeaf1d68 ref 0 pages 2 cleanbuf 1 dirtybuf 0 lock type nfs: SHARED (count 1) fileid 34 fsid 0x3a3a00ff02 panic: condition dvp != vp not met at /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) cpuid = 1 time = 1614435453 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00d01c3e10 vpanic() at vpanic+0x181/frame 0xfe00d01c3e60 panic() at panic+0x43/frame 0xfe00d01c3ec0 cache_enter_time() at cache_enter_time+0x1574/frame 0xfe00d01c3fa0 nfsrpc_readdirplus() at nfsrpc_readdirplus+0xcb6/frame 0xfe00d01c43d0 ncl_readdirplusrpc() at ncl_readdirplusrpc+0xdc/frame 0xfe00d01c4520 ncl_doio() at ncl_doio+0x423/frame 0xfe00d01c45b0 ncl_bioread() at ncl_bioread+0x5cc/frame 0xfe00d01c4740 nfs_readdir() at nfs_readdir+0x18f/frame 0xfe00d01c4850 vop_sigdefer() at vop_sigdefer+0x2f/frame 0xfe00d01c4880 VOP_READDIR_APV() at VOP_READDIR_APV+0x38/frame 0xfe00d01c48a0 kern_getdirentries() at kern_getdirentries+0x1fb/frame 0xfe00d01c4990 sys_getdirentries() at sys_getdirentries+0x29/frame 0xfe00d01c49c0 amd64_syscall() at amd64_syscall+0x12e/frame 0xfe00d01c4af0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00d01c4af0 --- syscall (554, FreeBSD ELF64, sys_getdirentries), rip = 0x8012a83fa, rsp = 0x7fffd928, rbp = 0x7fffd960 --- KDB: enter: panic [ thread pid 1879 tid 101207 ] Stopped at kdb_enter+0x37: movq$0,0x128bdde(%rip) db> — Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 > On 27 Feb 2021, at 15:10, Juraj Lutter wrote: > > - poudriere data stored on NFS > - NFS server 12-STABLE > - NFS client (that panicked) 14-CURRENT > - Panic string: > > condition dvp != vp not met at /usr/src/sys/kern/vfs_cache.c:2269 > (cache_enter_time) > > backtrace: > > Tracing pid 27294 tid 100893 td 0xfe00ea1a3500 > kdb_enter() at kdb_enter+0x37/frame 0xfe00ea3dee10 > vpanic() at vpanic+0x1b2/frame 0xfe00ea3dee60 > panic() at panic+0x43/frame 0xfe00ea3deec0 > cache_enter_time() at cache_enter_time+0x1574/frame 0xfe00ea3defa0 > nfsrpc_readdirplus() at nfsrpc_readdirplus+0xcb6/frame 0xfe00ea3df3d0 > ncl_readdirplusrpc() at ncl_readdirplusrpc+0xdc/frame 0xfe00ea3df520 > ncl_doio() at ncl_doio+0x423/frame 0xfe00ea3df5b0 > ncl_bioread() at ncl_bioread+0x5cc/frame 0xfe00ea3df740 > nfs_readdir() at nfs_readdir+0x18f/frame 0xfe00ea3df850 > vop_sigdefer() at vop_sigdefer+0x2f/frame 0xfe00ea3df880 > VOP_READDIR_APV() at VOP_READDIR_APV+0x38/frame 0xfe00ea3df8a0 > kern_getdirentries() at kern_getdirentries+0x1fb/frame 0xfe00ea3df990 > sys_getdirentries() at sys_getdirentries+0x29/frame 0xfe00ea3df9c0 > amd64_syscall() at amd64_syscall+0x12e/frame 0xfe00ea3dfaf0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00ea3dfaf0 > > > running processes: > > 27295 27179 27179 0 S+ piperd 0xf800090b4ba0 xargs > 27294 27179 27179 0 R+ CPU 1 find > 27179 816 27179 0 S+ wait0xf80181b69528 sh > > Dump header from device: /dev/vtbd0p3 > Architecture: amd64 > Architecture Version: 2 > Dump Length: 1860571136 > Blocksize: 512 > Compression: none > Dumptime: 2021-02-27 14:59:59 +0100 > Hostname: b14.builder.wilbury.net > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 14.0-CURRENT #0 main-n245107-172f2fc11cc: Fri Feb 26 > 15:20:00 CET 2021 >r...@b14.builder.wilbury.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > Panic String: condition dvp != vp not met at > /usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time) > Dump Parity: 1481068399 > Bounds: 0 > Dump Status: good > > — > Juraj Lutter > XMPP: juraj (at) lutter.sk > GSM: +421907986576 > > ___ > 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" ___ 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: Current panics on connecting disks to a LSI-3108 controller
On 14.07.2020 1:47, Yuri Pankov wrote: >> AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd >> mfi0: port 0x6000-0x60ff mem >> 0xc730-0xc730,0xc720-0xc72f irq 26 at device >> 0.0 numa-domain 0 on pci3 >> mfi0: Using MSI >> mfi0: Megaraid SAS driver Ver 4.23 >> mfi0: FW MaxCmds = 928, limiting to 128 >> mfi0: MaxCmd = 928, Drv MaxCmd = 128, MaxSgl = 70, state = 0xb73c03a0 >> . >> mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started (PCI >> ID 005d/1000/0809/15d9) >> pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - Firmware >> version 4.290.00-4536 >> >> >> I have posted screenshots of the panic at: >> www.tegenbosch28.nl/FreeBSD/Crash-LSI3108 >> >> But basically it crashes in >> mfi_tbolt_send_frame() +0x132 >> >> So is there anybody out there that can help me with analyzing and fixing >> this panic? > > I guess it's not the answer you are looking for, but you could try the mrsas > driver and check if it's behaves better for you, by setting 'set > hw.mfi.mrsas_enable=1' from loader prompt. I'm puzzled. I'm have SuperMicro add-on card based on LSI/Avago/Broadcom 3008. An I'm using "mpr" driver: mpr0: port 0xe000-0xe0ff mem 0xf724-0xf724,0xf720-0xf723 irq 16 at device 0.0 on pci1 mpr0: Firmware: 14.00.00.00, Driver: 23.00.00.00-fbsd mpr0: IOCCapabilities: 7a85c "man mpr" mentions LSI-3108 too, and "man mfi" doesn't mention LSI-3xxx chips. Why does "mfi" attaches to LSI-3xxx? What is proper driver for these chips? -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: Current panics on connecting disks to a LSI-3108 controller
On Wed, Jul 15, 2020 at 11:56:43AM +0200, Willem Jan Withagen wrote: > A bit of a pain, since pkg does not do it because ... > you need to manually fetch the tar from Broadcom first. Finally: > [pkg] also does not tell you why Just ask it: portsjail% cd sysutils/storcli portsjail% make -V IGNORE You must manually fetch the distribution file (007.1211.._Unified_StorCLI.zip) from https://docs.broadcom.com/docs-and-downloads/raid-controllers/raid-controllers-common-files/007.1211.._Unified_StorCLI.zip, place it in /home/linimon/ports/default/distfiles and then run make again portsjail% make -V LICENSE storcli portsjail% make -V LICENSE_TEXT Source recipient must acknowledge license. Reproduction or redistribution prohibited. See https://www.broadcom.com/cs/Satellite?pagename=AVG2/Utilities/EulaMsg mcl ___ 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: Current panics on connecting disks to a LSI-3108 controller
On 14-7-2020 22:59, mike tancsa wrote: On 7/14/2020 5:14 AM, Willem Jan Withagen wrote: On 14-7-2020 07:45, Andriy Gapon wrote: On 14/07/2020 03:39, Willem Jan Withagen wrote: And what I read from the manual page, mrsas plays even nicer with CAM which is a plus. If by "nicer" you mean that mfi does not integrate with CAM at all, then you are right :-) Also, last I looked mfi has some pretty serious bugs in its direct interface to GEOM. We've seen all kinds of crashes with mfi at work. Right that was what I meant. Disadvantage is that mfiutil no longer works. But then if you JBOD, it does not really matter. Unless it still uses caching for JBODs and then I'd like to know the state of the battery. Take a look from the ports storcli or MegaCli You can do pretty well everything you need with those 2 tools to talk to mrsas attached disks eg MegaCli -CfgEachDskRaid0 WT NORA Direct CachedBadBBU -Automatic -a0 or storcli /c0 show all storcli /c0 show help storcli /c0 set jbod=on (enable jbod mode for drives) storcli /c0/e252/s0 set jbod (sets a disk into jbod mode) Great suggestion. Seems storcli is a followup on MegaCli. So I just got the last one. A bit of a pain, since PKG does not do it, but it also does not tell you why. But you need to manually fetch the tar from Broadcom first. But then it works like a charm, actual upgrading whilest the system is running of that controller: root@quad-a:/usr/ports/sysutils/storcli # storcli /c0 download file=/tmp/smc3108.rom Download Completed. Flashing image to adapter... CLI Version = 007.1211.. Nov 07, 2019 Operating system = FreeBSD 13.0-CURRENT Controller = 0 Status = Success Description = F/W Flash Completed. Please reboot the system for the changes to take effect Current package version = 24.9.0-0022 New package version = 24.21.0-0100 Thanx, --WjW ___ 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: Current panics on connecting disks to a LSI-3108 controller
On 7/14/2020 5:14 AM, Willem Jan Withagen wrote: > On 14-7-2020 07:45, Andriy Gapon wrote: >> On 14/07/2020 03:39, Willem Jan Withagen wrote: >>> And what I read from the manual page, mrsas plays even nicer with >>> CAM which is a >>> plus. >> If by "nicer" you mean that mfi does not integrate with CAM at all, >> then you are >> right :-) >> Also, last I looked mfi has some pretty serious bugs in its direct >> interface to >> GEOM. We've seen all kinds of crashes with mfi at work. > Right that was what I meant. > Disadvantage is that mfiutil no longer works. > But then if you JBOD, it does not really matter. > Unless it still uses caching for JBODs and then I'd like to know the > state of the > battery. > Take a look from the ports storcli or MegaCli You can do pretty well everything you need with those 2 tools to talk to mrsas attached disks eg MegaCli -CfgEachDskRaid0 WT NORA Direct CachedBadBBU -Automatic -a0 or storcli /c0 show all storcli /c0 show help storcli /c0 set jbod=on (enable jbod mode for drives) storcli /c0/e252/s0 set jbod (sets a disk into jbod mode) ___ 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: Current panics on connecting disks to a LSI-3108 controller
On 14-7-2020 11:18, Hans Petter Selasky wrote: On 2020-07-14 02:39, Willem Jan Withagen wrote: I guess that there are reason not to do this by default. I've seen the exact same panic. +1 for fixing it :-) I do not have the knowledge to fix this panic. So the only thing I/we can do is: Get extra information in the mfi manpages. And perhaps get the preference reverted for mrsas <> mfi but I would not know where to start that discussion? --WjW ___ 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: Current panics on connecting disks to a LSI-3108 controller
On 2020-07-14 02:39, Willem Jan Withagen wrote: I guess that there are reason not to do this by default. I've seen the exact same panic. +1 for fixing it :-) --HPS ___ 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: Current panics on connecting disks to a LSI-3108 controller
On 14-7-2020 07:45, Andriy Gapon wrote: On 14/07/2020 03:39, Willem Jan Withagen wrote: And what I read from the manual page, mrsas plays even nicer with CAM which is a plus. If by "nicer" you mean that mfi does not integrate with CAM at all, then you are right :-) Also, last I looked mfi has some pretty serious bugs in its direct interface to GEOM. We've seen all kinds of crashes with mfi at work. Right that was what I meant. Disadvantage is that mfiutil no longer works. But then if you JBOD, it does not really matter. Unless it still uses caching for JBODs and then I'd like to know the state of the battery. Whatever the reason why mrsas is not always preferred over mfi, it must pretty nebulous like POLA for existing users. From technical point of view, mrsas appears to be superior Right, the Pola argument... Least it would warrant for is a warning in the mfi/mfiutil manpage that mrsas is a lot more modern and that it should be prefered is user has no specific reason to select mfi. And perhaps it is too complicated in the build of the boot images for isos and sticks, but there it would help a lot. Now booting with this controller and disk in the system leads to a panic. And a heavy one which requires hard reset/power-cycle, since the console is dead. --WjW ___ 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: Current panics on connecting disks to a LSI-3108 controller
On 14/07/2020 03:39, Willem Jan Withagen wrote: > And what I read from the manual page, mrsas plays even nicer with CAM which > is a > plus. If by "nicer" you mean that mfi does not integrate with CAM at all, then you are right :-) Also, last I looked mfi has some pretty serious bugs in its direct interface to GEOM. We've seen all kinds of crashes with mfi at work. Whatever the reason why mrsas is not always preferred over mfi, it must pretty nebulous like POLA for existing users. From technical point of view, mrsas appears to be superior. -- Andriy Gapon ___ 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: Current panics on connecting disks to a LSI-3108 controller
On 14-7-2020 00:47, Yuri Pankov wrote: Willem Jan Withagen wrote: Hi, I have this Supermicro SUPERSERVER®2028TP Which hold four nodes each with a X10DRT-PT motherboard and a LSI-3108 SAS controller connecting to 6 disks. Trying to run the most recent current snapshot on it. # uname -a FreeBSD quadbox-d.digiware.nl 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r363032: Thu Jul 9 04:13:17 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I have installed the OS on a SATA flash DOM. Booting works fine as long as there are no disks connected to LSI-3108 controller. Booting with SAS disks connected results in a panic. Attaching a SAS disk to the LSI-3108 controller give a panic as well. AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd mfi0: port 0x6000-0x60ff mem 0xc730-0xc730,0xc720-0xc72f irq 26 at device 0.0 numa-domain 0 on pci3 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23 mfi0: FW MaxCmds = 928, limiting to 128 mfi0: MaxCmd = 928, Drv MaxCmd = 128, MaxSgl = 70, state = 0xb73c03a0 . mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started (PCI ID 005d/1000/0809/15d9) pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - Firmware version 4.290.00-4536 I have posted screenshots of the panic at: www.tegenbosch28.nl/FreeBSD/Crash-LSI3108 But basically it crashes in mfi_tbolt_send_frame() +0x132 So is there anybody out there that can help me with analyzing and fixing this panic? I guess it's not the answer you are looking for, but you could try the mrsas driver and check if it's behaves better for you, by setting 'set hw.mfi.mrsas_enable=1' from loader prompt. That was a great suggestion. And what I read from the manual page, mrsas plays even nicer with CAM which is a plus. I guess that there are reason not to do this by default. So one gets mrsas unless it does not attach to that specific card in the system? --WjW ___ 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: Current panics on connecting disks to a LSI-3108 controller
Willem Jan Withagen wrote: Hi, I have this Supermicro SUPERSERVER®2028TP Which hold four nodes each with a X10DRT-PT motherboard and a LSI-3108 SAS controller connecting to 6 disks. Trying to run the most recent current snapshot on it. # uname -a FreeBSD quadbox-d.digiware.nl 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r363032: Thu Jul 9 04:13:17 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I have installed the OS on a SATA flash DOM. Booting works fine as long as there are no disks connected to LSI-3108 controller. Booting with SAS disks connected results in a panic. Attaching a SAS disk to the LSI-3108 controller give a panic as well. AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd mfi0: port 0x6000-0x60ff mem 0xc730-0xc730,0xc720-0xc72f irq 26 at device 0.0 numa-domain 0 on pci3 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23 mfi0: FW MaxCmds = 928, limiting to 128 mfi0: MaxCmd = 928, Drv MaxCmd = 128, MaxSgl = 70, state = 0xb73c03a0 . mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started (PCI ID 005d/1000/0809/15d9) pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - Firmware version 4.290.00-4536 I have posted screenshots of the panic at: www.tegenbosch28.nl/FreeBSD/Crash-LSI3108 But basically it crashes in mfi_tbolt_send_frame() +0x132 So is there anybody out there that can help me with analyzing and fixing this panic? I guess it's not the answer you are looking for, but you could try the mrsas driver and check if it's behaves better for you, by setting 'set hw.mfi.mrsas_enable=1' from loader prompt. ___ 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: current panics
It seems Kirill Ponomarew wrote: I got panic during the boot: ioapic0: Changing APIC ID to 2 ioapic0 Version 0.3 irqs 0-23 on motherboard panic: Can't find ExtINT pin to route through! cpuid=0; Is it known problem ? Dunno, but I get it as well when I set interrupt mode to APIC in the BIOS, if I choose PIC it works (but without an APIC of course). -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: current panics
Hi, On Thu, Nov 06, 2003 at 01:42:30PM +0100, Soren Schmidt wrote: Dunno, but I get it as well when I set interrupt mode to APIC in the BIOS, if I choose PIC it works (but without an APIC of course). I had the same situation as you. But jhb@ fixed it already. -Kirill pgp0.pgp Description: PGP signature
RE: current panics
On 06-Nov-2003 Kirill Ponomarew wrote: Hi, I got panic during the boot: ioapic0: Changing APIC ID to 2 ioapic0 Version 0.3 irqs 0-23 on motherboard panic: Can't find ExtINT pin to route through! cpuid=0; Is it known problem ? No, can you provide a boot -v dmesg? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: current panics
Hi, On Thu, Nov 06, 2003 at 11:34:06AM -0500, John Baldwin wrote: Is it known problem ? No, can you provide a boot -v dmesg? You fixed it by your last commit of src/sys/i386/acpica/madt.c,v 1.4 No panic now ;-) -Kirill pgp0.pgp Description: PGP signature
Re: current panics in mount(2)
* Garrett Wollman [EMAIL PROTECTED] [010122 10:27] wrote: On Tue, 23 Jan 2001 01:28:11 +1100 (EST), Bruce Evans [EMAIL PROTECTED] said: Somehow there were few problems when `struct mtx' was added to `struct ucred'. The critical args were probably usually 0. It's a bug that mount(2) uses a bare `struct ucred' and not a well-defined, user-exportable credential structure (like struct cmsgcred used for SCM_CREDS ancillary data). I looked at fixing this once, but got scared off because of binary compatibility issues. Would 'fixing' mount to use cmsgcred be acceptable? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current panics in mount(2)
In message [EMAIL PROTECTED] Alfred Perlstein writes: : I looked at fixing this once, but got scared off because of binary : compatibility issues. Would 'fixing' mount to use cmsgcred be : acceptable? I think so. Right now we have lots of killer, panic inducing binary incompatibilities. One more that doesn't suffer from the panic inducing part would be an excellent idea. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current panics in mount(2)
On Mon, 22 Jan 2001 10:54:04 -0800, Alfred Perlstein [EMAIL PROTECTED] said: I looked at fixing this once, but got scared off because of binary compatibility issues. Would 'fixing' mount to use cmsgcred be acceptable? No, it should use a structure appropriately named and designed for its own purpose. (By preference, it should be binary-compatible with 4.x to make upgrades easier in six months' time.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current panics in mount(2)
I got quite upset about this last time, and I guess it's time to do it again. Folks, *please* stop exporting "pure" kernel structures to userland. Make a sanitisied, versioned structure and just copy your damn args back and forth. 'struct ucred' should probably never have been exported to userspace, and it *certainly* never should have been exported to userpsace with a mutex in it! I also asked the perpetrator of this error to do something about it following the last debacle it caused. In the meantime, perhaps we could ask that one of the SMPng rules of engagement mandate that no mutex structures or structure members should ever be exported as part of a userspace interface? My nfs server now always panics when it attempts to export ufs filesystems. This is caused by my mount(8) being slightly out of date. This shouldn't be a problem, but `struct export_args' contains a `struct ucred' which contains a `struct mtx', so when `struct mtx' shrunk by 1 pointer yesterday, the out of date mount(8) started supplying garbage for all the export args following the ucred one. FreeBSD does very little checking of the export args and panics in the following malloc() in vfs_hang_addrlist(): i = sizeof(struct netcred) + argp-ex_addrlen + argp-ex_masklen; np = (struct netcred *)malloc(i, M_NETADDR, M_WAITOK | M_ZERO); ISTR a PR about lack of checking of export args. Somehow there were few problems when `struct mtx' was added to `struct ucred'. The critical args were probably usually 0. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current panics in mount(2)
On Mon, Jan 22, 2001 at 12:16:38PM -0800, Mike Smith wrote: In the meantime, perhaps we could ask that one of the SMPng rules of engagement mandate that no mutex structures or structure members should ever be exported as part of a userspace interface? This sounds fine in principle, but the real problem is that kernel structures are exported. In order for us to fix some of the places where structures are exported and an embedded mutex becomes necessary, we would have to go out of our way to fix an existing design flaw. Under normal circumstances, I would agree with you that broken code should be fixed as it is modified. However, the amount of work that the SMPng project is already taking on is overwhelming. Placing this additional burden on the SMPng developers would in my opinion be detrimental to the medium-term success of the project. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current panics in mount(2)
On Mon, Jan 22, 2001 at 12:16:38PM -0800, Mike Smith wrote: In the meantime, perhaps we could ask that one of the SMPng rules of engagement mandate that no mutex structures or structure members should ever be exported as part of a userspace interface? This sounds fine in principle, but the real problem is that kernel structures are exported. In order for us to fix some of the places where structures are exported and an embedded mutex becomes necessary, we would have to go out of our way to fix an existing design flaw. This would seem to be more or less obvious, yes. Under normal circumstances, I would agree with you that broken code should be fixed as it is modified. However, the amount of work that the SMPng project is already taking on is overwhelming. Placing this additional burden on the SMPng developers would in my opinion be detrimental to the medium-term success of the project. I think that the alternative is also fairly undesirable. However, you're in the hot seat on this one, so it's your call. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current panics
On Thu, Mar 23, 2000 at 12:29:28PM +0100, Niels Chr. Bank-Pedersen wrote: Hi, I know it isn't much (no debugger compiled in (yet)), but is anybody else seeing panics like this: mode = 0100644, inum = 214354, fs = /data0 panic: ffs_valloc: dup alloc syncing disks... 23 13 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 giving up on 2 buffers Uptime: 3m24s Automatic reboot in 15 seconds - press a key on the console to abort and dev = #vinum/1, block = 9757, fs = /data10 panic: ffs_blkfree: freeing free frag syncing disks... 63 13 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up on 1 buffers Uptime: 3m34s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Happening within a couple of minutes on -current kernels from 22/3 and 23/3 but not on a kernel from around the 18/3. Running SU and vinum (both panics on a vinum fs), but otherwise its just a plain nfs-server. What vinum config are you using? 'vinum list' ist best for this. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
