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
> 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 ".",
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
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
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
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
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
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
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
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
>>
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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)
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
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
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
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
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,
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
30 matches
Mail list logo
