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

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 ".",

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

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

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

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

Re: -CURRENT panics in NFS

s. 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

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

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

-CURRENT panics in NFS

- 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

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 >>

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

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

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

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

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

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

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

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

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

Current panics on connecting disks to a LSI-3108 controller

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

Re: 12-Current panics on boot (didn't a week ago.)

The drm-next-kmod, and drm-stable-kmod modules panic for me. I will attach logs when I can. On Friday, March 30, 2018, Andrew Reilly wrote: > Hi Jonathan, all, > > I've just compiled and booted a kernel derived from current-GENERIC > but with nooptions TCP_BLACKBOX, and

Re: 12-Current panics on boot (didn't a week ago.)

Hi Jonathan, all, I've just compiled and booted a kernel derived from current-GENERIC but with nooptions TCP_BLACKBOX, and much to my surprise it boots. Possible link to network-related activities is that the next line of boot output that was not being displayed during the crash is: [ath_hal]

Re: 12-Current panics on boot (didn't a week ago.)

For now, you can update through r331485 and then take TCP_BLACKBOX out of your kernel config file. That won’t really “fix” anything, but should at least get you a booting system (assuming the new code from r331347 is really triggering a problem). I’ll take another look to see if I missed

Re: 12-Current panics on boot (didn't a week ago.)

On Sun, 25 Mar 2018 05:21:10 +0200, Andrew Reilly wrote: > > OK, I've completed the search: r331346 works, r331347 panics > somewhere in the initialization of random. > > In the 331347 change (Add the "TCP Blackbox Recorder") I can't see > anything obvious to tweak, unfortunately. It's a fair

Re: 12-Current panics on boot (didn't a week ago.)

OK, I've completed the search: r331346 works, r331347 panics somewhere in the initialization of random. In the 331347 change (Add the "TCP Blackbox Recorder") I can't see anything obvious to tweak, unfortunately. It's a fair chunk of new code but it's all network-stack related, and my kernel is

Re: 12-Current panics on boot (didn't a week ago.)

So, r331464 crashes in the same place, on my system. r331064 still boots OK. I'll keep searching. One week ago there was a change to randomdev to poll for signals every so often, as a defence against very large reads. That wouldn't have introduced a race somewhere, or left things in an

Re: 12-Current panics on boot (didn't a week ago.)

Thanks Andrew... I can't recreate this on my VM nor my real hardware. Warner On Sat, Mar 24, 2018 at 5:22 PM, Andrew Reilly wrote: > So, r331464 crashes in the same place, on my system. r331064 still boots > OK. I'll keep searching. > > One week ago there was a change

Re: 12-Current panics on boot (didn't a week ago.)

Hi Warner, The breakage was in 331470, and at least one version earlier, that I updated past when it panicked. I'm guessing that kdb's inability to dump would be down to it not having found any disk devices yet, right? So yes, bisecting to narrow down the issue is probably the best bet.

Re: 12-Current panics on boot (didn't a week ago.)

Also, what rev failed? I booted r331464 last night w/o issue. Warner On Fri, Mar 23, 2018 at 9:56 PM, Andrew Reilly wrote: > Hi all, > > For reasons that still escape me, I haven't been able to get a kernel dump > to debug, sorry. > > Just thought that I'd generate a

Re: 12-Current panics on boot (didn't a week ago.)

That lock has been there for a long, long time (like 5 or 6 major releases)... It's surprising that it's causing issues now. Can you bisect versions to find when this starts happening? Warner On Fri, Mar 23, 2018 at 9:56 PM, Andrew Reilly wrote: > Hi all, > > For

12-Current panics on boot (didn't a week ago.)

Hi all, For reasons that still escape me, I haven't been able to get a kernel dump to debug, sorry. Just thought that I'd generate a fairly low-quality report, to see if anyone has some ideas. The last kernel that I have that booted OK (and I'm now running) is: FreeBSD Zen.ac-r.nu

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

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

current panics

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 ? -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

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

Four -CURRENT panics (backtrace included)

Hello everyone, I have encounted several panics in recent kernels. The kernel was compiled right after cvsup, so the date will apply to the source code. panic 1: beastie# gdb -k kernel.debug

-current panics of today

Hi, attached are three backtraces (sorry, no matching kernel.debug for them) of some panics of today. The first was during an copy operation from CDROM to /tmp (md disk) The next where during background fsck-ing after the first dump... Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis,

Re: 5.0-20010304-CURRENT panics during boot on Sony Vaio

John Baldwin wrote: On 05-Mar-01 Tom Uffner wrote: John Baldwin wrote: On 04-Mar-01 Tom Uffner wrote: all of the snapshots since the 24th have exhibited this same or very similar behavior. Does it happen for snapshots before the 24th? no, it does not, at least not for the

Re: 5.0-20010304-CURRENT panics during boot on Sony Vaio

Tom Uffner wrote: all of the snapshots since the 24th have exhibited this same or very similar behavior. when booting from the kern mfsroot floppies i get: . . . unknown: PNP0e03 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0501 can't assign resources

5.0-20010304-CURRENT panics during boot on Sony Vaio

all of the snapshots since the 24th have exhibited this same or very similar behavior. when booting from the kern mfsroot floppies i get: . . . unknown: PNP0e03 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign

RE: 5.0-20010304-CURRENT panics during boot on Sony Vaio

On 04-Mar-01 Tom Uffner wrote: all of the snapshots since the 24th have exhibited this same or very similar behavior. Does it happen for snapshots before the 24th? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power

Re: 5.0-20010304-CURRENT panics during boot on Sony Vaio

John Baldwin wrote: On 04-Mar-01 Tom Uffner wrote: all of the snapshots since the 24th have exhibited this same or very similar behavior. Does it happen for snapshots before the 24th? no, it does not, at least not for the 5.0-20010210-CURRENT snap. it boots from the floppies and once

Re: 5.0-20010304-CURRENT panics during boot on Sony Vaio

On 05-Mar-01 Tom Uffner wrote: John Baldwin wrote: On 04-Mar-01 Tom Uffner wrote: all of the snapshots since the 24th have exhibited this same or very similar behavior. Does it happen for snapshots before the 24th? no, it does not, at least not for the 5.0-20010210-CURRENT snap.

current panics in mount(2)

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

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)

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

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

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

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

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,

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

current panics

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