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 w
> 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_
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 shou
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
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.
h 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
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 0x
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 0xf801
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
>> mf
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
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 mf
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
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
https://lists.freebsd.org/mailman/listin
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 s
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 direc
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 FreeB
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
Descrip
It seems Kirill Ponomarew wrote:
> I got panic during the boot:
>
> ioapic0: Changing APIC ID to 2
> ioapic0 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,
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
On 06-Nov-2003 Kirill Ponomarew wrote:
> Hi,
>
> I got panic during the boot:
>
> ioapic0: Changing APIC ID to 2
> ioapic0 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 <[E
> 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
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
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
< 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
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
* Garrett Wollman <[EMAIL PROTECTED]> [010122 10:27] wrote:
> < 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-export
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
30 matches
Mail list logo
