on
It does react to -9 though.
--
Mateusz Guzik
On 2/3/24, David Chisnall wrote:
> On 3 Feb 2024, at 09:15, Mateusz Guzik wrote:
>>
>> Binary startup is very slow, for example execve of a hello world
>> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2
>> compared to a native one. As such perf-wis
d chroot on FreeBSD is faster by a factor of 2
compared to a native one. As such perf-wise this looks like a step in
the wrong direction.
Is there a problem making it so that libc ends up unchanged, but all
the bits are available separately in libsys if one does not want libc?
--
Mateusz Guzik
On 11/14/23, Rick Macklem wrote:
> On Tue, Nov 14, 2023 at 10:46 AM Alexander Motin wrote:
>>
>> On 14.11.2023 12:44, Alexander Motin wrote:
>> > On 14.11.2023 12:39, Mateusz Guzik wrote:
>> >> One of the vnodes is probably not zfs, I suspect this will do i
On 11/14/23, Alexander Motin wrote:
> On 14.11.2023 12:44, Alexander Motin wrote:
>> On 14.11.2023 12:39, Mateusz Guzik wrote:
>>> One of the vnodes is probably not zfs, I suspect this will do it
>>> (untested):
>>>
>>> diff --git a/sys/contrib/openz
On 11/14/23, Alexander Motin wrote:
> On 14.11.2023 12:39, Mateusz Guzik wrote:
>> One of the vnodes is probably not zfs, I suspect this will do it
>> (untested):
>>
>> diff --git a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
>> b/sys/cont
in critical section or under mutex
> cpuid = 2
> time = 1699966486
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x38
> vpanic() at vpanic+0x1a0
> panic() at panic+0x48
> data_abort() at data_abort+0x2fc
> handle_el1h_sync() at handle_el1h_sync+0x18
> --- exception, esr 0x9604
> rms_rlock() at rms_rlock+0x1c
> zfs_clone_range() at zfs_clone_range+0x68
> zfs_freebsd_copy_file_range() at zfs_freebsd_copy_file_range+0x19c
> null_bypass() at null_bypass+0x118
> vn_copy_file_range() at vn_copy_file_range+0x1c0
> kern_copy_file_range() at kern_copy_file_range+0x36c
> sys_copy_file_range() at sys_copy_file_range+0x8c
> do_el0_sync() at do_el0_sync+0x634
> handle_el0_sync() at handle_el0_sync+0x48
> --- exception, esr 0x5600
> KDB: enter: panic
> [ thread pid 3620 tid 100911 ]
> Stopped at kdb_enter+0x48: str xzr, [x19, #768]
> db>
>
> This happens as soon as I start poudriere in a jenkins-agent jail.
>
> AFAIK this includes the two recent vn_copy_file_range changes of
> Konstantin.
>
> Next I will install a GENERIC kernel instead of GENERIC-NODEBUG.
>
One of the vnodes is probably not zfs, I suspect this will do it (untested):
diff --git a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
index 107cd69c756c..e799a7091b8e 100644
--- a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
+++ b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
@@ -6270,6 +6270,11 @@ zfs_freebsd_copy_file_range(struct
vop_copy_file_range_args *ap)
goto bad_write_fallback;
}
}
+
+ if (invp->v_mount->mnt_vfc != outvp->v_mount->mnt_vfc) {
+ goto bad_write_fallback;
+ }
+
if (invp == outvp) {
if (vn_lock(outvp, LK_EXCLUSIVE) != 0) {
goto bad_write_fallback;
--
Mateusz Guzik
On 10/14/23, Graham Perrin wrote:
> On 03/09/2023 20:25, Mateusz Guzik wrote:
>
>> …
>>
>> Sorry mate, neglected to specify: collect sysctl -a once you run into
>> the problem.
>>
>> Once I look at that I'm probably going to ship some debug patches
but
I'm happy to review an implementation which avoids being a problem.
That is to say, a laptop-scale API can probably be implemented as is,
but solution which can provide reliable events (not to be confused
with reliably notifying about all events) would require numerous
changes.
--
Mateusz Guzik
On 9/4/23, Alexander Leidinger wrote:
> Am 2023-08-28 22:33, schrieb Alexander Leidinger:
>> Am 2023-08-22 18:59, schrieb Mateusz Guzik:
>>> On 8/22/23, Alexander Leidinger wrote:
>>>> Am 2023-08-21 10:53, schrieb Konstantin Belousov:
>>>>> On Mon
On 9/3/23, Graham Perrin wrote:
> On 03/09/2023 17:55, Mateusz Guzik wrote:
>> On 9/3/23, Graham Perrin wrote:
>>> On 02/09/2023 18:31, Mateusz Guzik wrote:
>>>> On 9/2/23, Graham Perrin wrote:
>>>>> … I began the trace /after/ the issue became ob
On 9/3/23, Graham Perrin wrote:
> On 02/09/2023 18:31, Mateusz Guzik wrote:
>> On 9/2/23, Graham Perrin wrote:
>>> … I began the trace /after/ the issue became observable.
>>> Will it be more meaningful to begin a trace and then reproduce the issue
>>> (before
a219-gjp4-8570p-freebsd:/home/grahamperrin/Documents/IT/BSD/FreeBSD/kernel-cpu
>
The script is intended to run when you have git executing for a long time.
--
Mateusz Guzik
On 9/2/23, Graham Perrin wrote:
> On 02/09/2023 10:17, Mateusz Guzik wrote:
>> On 9/2/23, Graham Perrin wrote:
>>> Some inspections are extraordinarily time-consuming. Others complete
>>> very quickly, as they should.
>>>
>>> One recent inspection too
basic profiling tooling immediately shows the issue, in this
case for example:
pmcstat -S inst_retired.any_p -TI
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
>
>
--
Mateusz Guzik
/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
>
> amd64 150 150
> %
>
>
>
get a flamegraph with dtrace
https://github.com/brendangregg/FlameGraph
--
Mateusz Guzik
On 8/25/23, Mateusz Guzik wrote:
> On 8/25/23, Yasuhiro Kimura wrote:
>> Hello,
>>
>> I made regular update of my amd64 system from main-n264870-e5e6a865358
>> to main-n265022-1554ba03b65 and system crashed with panic while
>> building packages with poudr
bsd.org/~yasu/FreeBSD-15-CURRENT-amd64-main-n265022-1554ba03b65.20230825.panic.png
>
this is a fallout from the recent timerfd commit. I'll fix it in few.
--
Mateusz Guzik
On 8/24/23, Mark Millard wrote:
> On Aug 23, 2023, at 15:10, Mateusz Guzik wrote:
>
>> On 8/23/23, Mark Millard wrote:
>>> [Forked off the ZFS deadlock 14 discussion, per feedback.]
>>>
>>> On Aug 23, 2023, at 11:40, Alexander Motin wrote:
>>&
d000 83a0 uftdi.ko
> 171 0x83b56000 4e58 ucom.ko
> 181 0x83b5b000 3360 wmt.ko
> 191 0x83b5f000 e268 ng_l2cap.ko
> 201 0x83b6e0001bf68 ng_btsocket.ko
> 211 0x83b8a000 38f8 ng_socket.ko
> 221 0x83b8e000 3250 filemon.ko
> 231 0x83b92000 4758 nullfs.ko
> 241 0x83b97000 73c0 linprocfs.ko
> 253 0x83b9f000 be70 linux_common.ko
> 261 0x83bab000 3558 fdescfs.ko
> 271 0x83baf00031b20 linux.ko
> 281 0x83be10002ed40 linux64.ko
>
>
> Note that before the "Cleaning up" notice, the vfs.freevnodes
> shows as being around (for example) 2210796. But after
> "Exiting with status": 61362. vfs.vnodes_created has a
> similar staging of in the ball park of up to 1343 but
> then the change to: 20135479. Similarly, vfs.numvnodes
> 2216564 -> 59860.
>
>
>
> Anything else I should gather and report as basic information?
>
This is a known problem, but it is unclear if you should be running
into it in this setup.
Can you try again but this time *revert*
138a5dafba312ff39ce0eefdbe34de95519e600d, like so:
git revert 138a5dafba312ff39ce0eefdbe34de95519e600d
may want to switch to a different branch first, for example: git
checkout -b vfstesting
--
Mateusz Guzik
On 8/22/23, Alexander Leidinger wrote:
> Am 2023-08-21 10:53, schrieb Konstantin Belousov:
>> On Mon, Aug 21, 2023 at 08:19:28AM +0200, Alexander Leidinger wrote:
>>> Am 2023-08-20 23:17, schrieb Konstantin Belousov:
>>> > On Sun, Aug 20, 2023 at 11:07:08PM +0200, M
On 8/20/23, Alexander Leidinger wrote:
> Am 2023-08-20 22:02, schrieb Mateusz Guzik:
>> On 8/20/23, Alexander Leidinger wrote:
>>> Am 2023-08-20 19:10, schrieb Mateusz Guzik:
>>>> On 8/18/23, Alexander Leidinger wrote:
>>>
>>>>> I h
On 8/20/23, Alexander Leidinger wrote:
> Am 2023-08-20 19:10, schrieb Mateusz Guzik:
>> On 8/18/23, Alexander Leidinger wrote:
>
>>> I have a 51MB text file, compressed to about 1MB. Are you interested
>>> to
>>> get it?
>>>
>>
>>
On 8/18/23, Alexander Leidinger wrote:
> Am 2023-08-16 18:48, schrieb Alexander Leidinger:
>> Am 2023-08-15 23:29, schrieb Mateusz Guzik:
>>> On 8/15/23, Alexander Leidinger wrote:
>>>> Am 2023-08-15 14:41, schrieb Mateusz Guzik:
>>>>
>&
On 8/18/23, Alexander Leidinger wrote:
> Am 2023-08-16 18:48, schrieb Alexander Leidinger:
>> Am 2023-08-15 23:29, schrieb Mateusz Guzik:
>>> On 8/15/23, Alexander Leidinger wrote:
>>>> Am 2023-08-15 14:41, schrieb Mateusz Guzik:
>>>>
>&
On 8/15/23, Alexander Leidinger wrote:
> Am 2023-08-15 14:41, schrieb Mateusz Guzik:
>
>> With this in mind can you provide: sysctl kern.maxvnodes
>> vfs.wantfreevnodes vfs.freevnodes vfs.vnodes_created vfs.numvnodes
>> vfs.recycles_free vfs.recycles
>
> After a rebo
On 8/15/23, Dag-Erling Smørgrav wrote:
> Mateusz Guzik writes:
>> Given that the custom reproducer failed I think the most prudent
>> course of action is to reproduce again with poudriere, but this time
>> arrange to have all stacktraces dumped.
>
> Why? What m
it:
sbin/ddb/ddb.conf:script kdb.enter.panic=textdump set; capture on; run
lockinfo; show pcpu; bt; ps; alltrace; capture off; textdump dump;
reset
it is a slightly finicky beast so I would trigger a panic by hand
first to validate it works as expected.
--
Mateusz Guzik
th this in mind can you provide: sysctl kern.maxvnodes
vfs.wantfreevnodes vfs.freevnodes vfs.vnodes_created vfs.numvnodes
vfs.recycles_free vfs.recycles
Meanwhile if there is tons of recycles, you can damage control by
bumping kern.maxvnodes.
If this is not the problem you can use dtrace to figure it out.
--
Mateusz Guzik
s_mountroot() at vfs_mountroot+0x1bf7/frame 0xfe006d3bae60
> start_init() at start_init+0x23/frame 0xfe006d3baef0
> fork_exit() at fork_exit+0x82/frame 0xfe006d3baf30
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe006d3baf30
> --- trap 0x5c035c02, rip = 0x680c680c680c680c, rsp = 0x1b6b1f6b1b6b1b6b, rbp
> = 0x4eb54eb54eb54eb5 ---
> KDB: enter: panic
> [ thread pid 1 tid 12 ]
> Stopped at kdb_enter+0x32: movq$0,0xde7643(%rip)
>
>
--
Mateusz Guzik
On 4/18/23, Pawel Jakub Dawidek wrote:
> On 4/18/23 05:14, Mateusz Guzik wrote:
>> On 4/17/23, Pawel Jakub Dawidek wrote:
>>> Correct me if I'm wrong, but from my understanding there were zero
>>> problems with block cloning when it wasn't in use or
ribute
> 'MetadataPathFinder'
>
> ERROR Backend subprocess exited when trying to invoke
> get_requires_for_build_wheel
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/textproc/py-pygments
>
> ===>>> make build failed for textproc/py-pygments@py39
> ===>>> Aborting update
>
> ===>>> Update for textproc/py-pygments@py39 failed
> ===>>> Aborting update
>
>
> ===>>> You can restart from the point of failure with this command line:
>
>
>
>
--
Mateusz Guzik
On 4/17/23, Pawel Jakub Dawidek wrote:
> On 4/18/23 03:51, Mateusz Guzik wrote:
>> After bugfixes got committed I decided to zpool upgrade and sysctl
>> vfs.zfs.bclone_enabled=1 vs poudriere for testing purposes. I very
>> quickly got a new crash:
>>
>> pani
ing RO import though) to prevent RW usage of the
current pools with it enabled.
Comments?
--
Mateusz Guzik
ss.
>>
>> I cannot speak to the others who have had poudriere and other issues. I
>> never had any problems with poudriere on top of the new ZFS.
>>
>> WRT reverting block_cloning pools to without, your only option is to
>> backup
>> your pool and recreate it without block_cloning. Then restore your data.
>>
>>
>
> All right, I interpret the answer that way, that I need a most recent source
> tree (and
> accordingly built and installed OS) AND a patch that isn't officially
> commited?
>
> On a box I'm with:
>
> FreeBSD 14.0-CURRENT #8 main-n262175-5ee1c90e50ce: Sat Apr 15 07:57:16 CEST
> 2023 amd64
>
> The box is crashing while trying to update ports with the well known issue:
>
> Panic String: VERIFY(!zil_replaying(zilog, tx)) failed
>
> At the moment all alarm bells are ringing and I lost track about what has
> been patched and
> already commited and what is still as patch available but in the phase of
> evaluation or
> inofficially emmited here.
>
> According to the EXDEV issue: in cases of poudriere or ports trees on ZFS,
> what do I have to
> do to ensure that those datasets are clean? The OS should detect file
> corruption but in my
> case the box is crashing :-(
>
> I did several times scrubbing, but this seems to be the action of a helpless
> and desperate man
> ... ;-/
>
> Greetings
>
Using block cloning is still not safe, but somewhere in this thread
pjd had a patch to keep it operatinal for already cloned files without
adding new ones.
Anyhow, as was indicated by vishwin@ there was data corruption
*unrelated* to block cloning which also came with the import, I
narrowed it down: https://github.com/openzfs/zfs/issues/14753
That said now I'm testing a kernel which does not do block cloning and
does not have the other problematic commit, we will see if things
work.
--
Mateusz Guzik
(buildworld
> fails) for me to test poudriere bulk -c builds with. I used a world from
> https://gitlab.com/vishwin/freebsd-src/-/tree/zfs-revert which consists
> of reverting the merge commit plus a few other conflicts, but keeping
> vop_fplookup_vexec.
>
I'm going to narrow down the non-blockcopy corruption after my testjig
gets off the ground.
Basically I expect to have it sorted out on Friday.
--
Mateusz Guzik
x27;s
>> >>>> adjusted resend of the original. The To/Cc should
>> >>>> be coomplete this time.]
>> >>>>
>> >>>> On Apr 12, 2023, at 22:52, Cy Schubert =
>> >>>> wrote:
>> >>>>
>> >&
do not have more to present.
>
> I rememeber now really scraed that there was a HEADSUP in the list regarding
> some serious ZFS
> problems - I didn't find it right now.
>
> Thanks in advance,
>
That's fallout from the new block cloning feature, adding the author
--
Mateusz Guzik
On 4/8/23, Kyle Evans wrote:
> On Fri, Apr 7, 2023 at 4:54 PM Mateusz Guzik wrote:
>>
>> On 4/7/23, Mark Millard wrote:
>> > On Apr 7, 2023, at 14:26, Mateusz Guzik wrote:
>> >
>> >> On 4/7/23, Mateusz Guzik wrote:
>> >>> can you
On 4/7/23, Mark Millard wrote:
> On Apr 7, 2023, at 14:26, Mateusz Guzik wrote:
>
>> On 4/7/23, Mateusz Guzik wrote:
>>> can you try with this:
>>>
>>> diff --git
>>> a/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h
>>
On 4/7/23, Mateusz Guzik wrote:
> can you try with this:
>
> diff --git
> a/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h
> b/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h
> index 16276b08c759..e1bca9ef140a 100644
> --- a/sys/contrib/ope
/2a58b312b62f908ec92311d1bd8536dbaeb8e55b/arm64/aarch64/kernel.txz
>
> By contrast, the prior commit had an artifact build
> as well, but it's kernel does not get the panic for
> zpool import :
>
> https://artifact.ci.freebsd.org/snapshot/main/b98fbf3781df16f7797b2bbeabf205dc7d4985ae/arm64/aarch64/kernel.txz
>
> See also:
>
> https://lists.freebsd.org/archives/freebsd-current/2023-April/003417.html
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
--
Mateusz Guzik
9411e5bbde0f46a98be5b or later. build and install
the new kernel, only then proceed with installworld and you should be
fine.
--
Mateusz Guzik
> Any ideas?
>
> 37d97b10ff0e was around twelve hours ago,
> <https://cgit.freebsd.org/src/log/?qt=range&q=37d97b10ff0e>
>
>
--
Mateusz Guzik
On 3/30/23, Mateusz Guzik wrote:
> On 3/30/23, FreeBSD User wrote:
>> Hello folks,
>>
>> some strange misbehaviour in a NanoBSD compilation is driving me nuts.
>> Recently I posted some
>> error messages regarding
>>
>> [...]
>> src/sys/dev/an
ou should be able to stick to the compiler from main. in
the worst case the commit to turn "function definition without a
prototype is deprecated" from errors to warnings could be merged to
stable/13 to facilitate the build
it may be you will be able to get away with modifying CFLAGS like so:
CFLAGS+=-Wno-deprecated-non-prototype
in src.conf and/or make.conf
--
Mateusz Guzik
g is preventing the update.
>
> Any suggestions how to make updating work again?
>
> Kind regards,
>
> oh
>
>
> --
> O. Hartmann
>
>
--
Mateusz Guzik
can be found here.
>
> http://mail.mikej.com/core.txt.0
>
> It has not happened again, but I'm putting it though it's normal paces.
>
> The only thing that was occurring which is not a normal thing for me to
> is I was moving TB's worth of data between directly attached two zpools.
>
> Regards,
>
> Michael Jung
>
>
>
>
>
--
Mateusz Guzik
f similar, but I guess
sys/modules/Makefile will have to be patched to support it, which it
only does for some modules at the moment.
I don't have any interest in working on it, so just bringing this up
for interested.
--
Mateusz Guzik
On 1/29/23, Mateusz Guzik wrote:
> On 1/29/23, Jamie Landeg-Jones wrote:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix
>> to an admittedly trivial issue, but it's soon going to hit one year old,
>> and has not had any feedback. Not ev
aintainership, any other offers
> of help have fallen on deaf ears.
>
Well I was not aware of it.
mail me with git format-patch result and I'll commit.
--
Mateusz Guzik
>pc_curthread->td_lock == &sched_lock) {
>> +ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
>> +ipi_cpu(cpuid, IPI_AST);
>> +}
>> }
>> #endif /* SMP */
>>
>> @@ -1397,7 +1398,7 @@ sched_add(struct thread *td, int flags)
>>
>> cpuid = PCPU_GET(cpuid);
>> if (single_cpu && cpu != cpuid) {
>> -kick_other_cpu(td->td_priority, cpu);
>> +kick_other_cpu(td->td_priority, cpu);
>> } else {
>> if (!single_cpu) {
>> tidlemsk = idle_cpus_mask;
>
> --
> Steve
>
>
--
Mateusz Guzik
might be worth mentioning.
>
> Peace,
> david
> --
> David H. Wolfskill da...@catwhisker.org
> "In my administration, I'm going to enforce all laws concerning the
> protection of classified information. No one will be above the law."
> -- D. Trump, August, 2016
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>
--
Mateusz Guzik
f is only defined when NONINVARIANTS is also defined.
>
> This breaks buildkernel.
>
> --
> Gary Jennejohn
>
>
--
Mateusz Guzik
On 9/2/22, Konstantin Belousov wrote:
> On Fri, Sep 02, 2022 at 04:11:40PM +0200, Mateusz Guzik wrote:
>> On 9/2/22, Konstantin Belousov wrote:
>> > On Fri, Sep 02, 2022 at 02:05:37PM +0200, Mateusz Guzik wrote:
>> >> Is this really of practical use today?
>&g
On 9/2/22, Konstantin Belousov wrote:
> On Fri, Sep 02, 2022 at 02:05:37PM +0200, Mateusz Guzik wrote:
>> Is this really of practical use today?
>>
>> I have a WIP patch which needs to temporarily store something on the
>> stack and should things go wrong enough
ep it around,
but perhaps the entire machinery can be just whacked?
--
Mateusz Guzik
t failure. Nearly 12,000
> ports skipped:
>
> http://ci-08.md.hardenedbsd.org/build.html?mastername=hardenedbsd-current_amd64-local&build=2022-08-17_20h01m01s
>
> Thanks,
>
> --
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
>
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
>
--
Mateusz Guzik
ye just get stock top of the tree
On 8/18/22, Larry Rosenman wrote:
> On 08/18/2022 4:25 pm, Mateusz Guzik wrote:
>> On 8/18/22, Mateusz Guzik wrote:
>>> On 8/18/22, Larry Rosenman wrote:
>>>> https://home.lerctr.org:/build.html?mastername=live-host_po
On 8/18/22, Mateusz Guzik wrote:
> On 8/18/22, Larry Rosenman wrote:
>> https://home.lerctr.org:/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s
>>
>> circa 97ecdc00ac5 on main
>> Ideas?
>>
>
> try with 9ac6eda6c6a36db6bffa01be7fae
On 8/18/22, Larry Rosenman wrote:
> https://home.lerctr.org:/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s
>
> circa 97ecdc00ac5 on main
> Ideas?
>
try with 9ac6eda6c6a36db6bffa01be7faea24f8bb92a0f reverted
--
Mateusz Guzik
isagree. The entire point is to not end up with actually unused
variables even when is enabled.
I patched it up in
https://cgit.FreeBSD.org/src/commit/?id=b40c0db6f6d61ed594118d81dc691b9263a7e4d7
. This still allows for actually vars when only one of INVARIANTS or
WITNESS is defined, but that's a much smaller problem than allowing it
in general.
--
Mateusz Guzik
nefit of not disabling the cache in nullfs? I would
> expect zfs (or ufs) to cache the (meta)data anyway.
>
does the poor performance show up with
https://people.freebsd.org/~mjg/vnlru_free_pick.diff ?
if the long runs are still there, can you get some profiling from it?
sysctl -a before and after would be a start.
My guess is that you are the vnode limit and bumping into the 1 second sleep.
--
Mateusz Guzik
On 4/19/22, Doug Ambrisko wrote:
> On Tue, Apr 19, 2022 at 11:47:22AM +0200, Mateusz Guzik wrote:
> | Try this: https://people.freebsd.org/~mjg/vnlru_free_pick.diff
> |
> | this is not committable but should validate whether it works fine
>
> As a POC it's working. I see
Try this: https://people.freebsd.org/~mjg/vnlru_free_pick.diff
this is not committable but should validate whether it works fine
On 4/19/22, Mateusz Guzik wrote:
> On 4/19/22, Mateusz Guzik wrote:
>> On 4/19/22, Doug Ambrisko wrote:
>>> I've switched my lapto
On 4/19/22, Mateusz Guzik wrote:
> On 4/19/22, Doug Ambrisko wrote:
>> I've switched my laptop to use nullfs and ZFS. Previously, I used
>> localhost NFS mounts instead of nullfs when nullfs would complain
>> that it couldn't mount. Since that check has been remo
ullfs, NFS exported, local, nfsv4acls, fsid
> 11ff00292900, vnodes: count 13846 lazy 0)
>
> Now I can easily see how the vnodes are used without going into ddb.
> On my laptop I have various vnet jails and nullfs mount my homedir into
> them so pretty much everything goes through nullfs to ZFS. I'm limping
> along with the nullfs nocache and small number of vnodes but it would be
> nice to not need that.
>
> Thanks,
>
> Doug A.
>
>
--
Mateusz Guzik
than anyone else.
Comments?
--
Mateusz Guzik
I just did a quick check and it definitely fails on nfs mounts:
# ktrace pwd
/root/mjg
# kdump
-559038242 Events dropped.
kdump: bogus length 0xdeadc0de
I don't have time to look into it this week though.
> --
> Bjoern A. Zeeb r15:7
>
>
--
Mateusz Guzik
.0.0.1' 'ip6.addr=::1' allow.chflags allow.sysvipc
> jail: jail_set: Operation not permitted
> + exit_handler
> [...]
>
> Searching the net revealed some issues with setting IP4 and IP6 in
> poudriere, but those
> findings are dated back to 2017 and 2014 and I guess this is solved right
> now.
>
> The difference between our manually jail.conf driven setup and the
> XigmaNAS/bastille
> based one is, bastille uses jib/netgraph based seutups of the vnet and the
> ip4/ip6 is
> setup from rc.conf, while we use epair in the other world and the ip is
> setup from
> withing the jail definition in jail.conf.
>
> I'm out of ideas here and after two days of trial and error and trying to
> understand
> what's going on lost ... Any hints or tipps?
>
> Thanks in advance,
>
> O. Hartmann
>
>
--
Mateusz Guzik
On 12/11/21, Mateusz Guzik wrote:
> On 12/11/21, Mateusz Guzik wrote:
>> On 12/11/21, Piper H wrote:
>>> I read this article from Reddit:
>>> https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=1
>>>
>>> I am surpr
On 12/11/21, Mateusz Guzik wrote:
> On 12/11/21, Piper H wrote:
>> I read this article from Reddit:
>> https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=1
>>
>> I am surprised to see that the BSD cluster today has much worse
>>
l time real time of 37.602 seconds]
Linux: 60.1 MB/s ,2030.6 MB/s [total time real time of 39.070 seconds]
I don't know what these numbers are supposed to be, but it is pretty
clear Phoronix grabs the first one.
I'll look into sorting this out some time later.
TL;DR don't drink and benchmark
--
Mateusz Guzik
me.org/FreeBSD/FreeBSD-14-CURRENT-amd64-main-n251115-ae92ace05fd.panic.png
>
Should be fixed by
https://cgit.freebsd.org/src/commit?id=1879021942f56c8b264f4aeb1966b3733908ef62
--
Mateusz Guzik
usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi
>
> I get a similar error with drm-current-kmod. What changed?
>
> imb
>
>
--
Mateusz Guzik
Just take it and change as you see fit, I don't have time to work on it.
On 10/4/21, Alan Somers wrote:
> On Mon, Jan 8, 2018 at 5:31 PM Mateusz Guzik wrote:
>>
>> On Tue, Jan 9, 2018 at 12:41 AM, Michael Jung wrote:
>>
>> > On 2018-01-08 13:39, John B
core.c:5664
> #13 0xffff808d9de7 in item_dtor (zone=0xfe00dcbdd800,
> item=0xf800356b9000, size=544, udata=0x0, skip=SKIP_NONE)
> at /usr/src/sys/vm/uma_core.c:3418
> #14 uma_zfree_arg (zone=0xfe00dcbdd800, item=0xf800356b9000,
> udata=udata@entry=0x0) at /usr/src/sys/vm/uma_core.c:4374
> #15 0x802da503 in uma_zfree (zone=0x80d635c8 ,
> item=0x200) at /usr/src/sys/vm/uma.h:404
> #16 0x802d9117 in camperiphdone (periph=0xf800061e2c00,
> done_ccb=0xf800355d6cc0) at /usr/src/sys/cam/cam_periph.c:1427
> #17 0x802dfebd in xpt_done_process (ccb_h=0xf800355d6cc0)
> at /usr/src/sys/cam/cam_xpt.c:5491
> #18 0x802e1ec5 in xpt_done_td (
> arg=arg@entry=0x80d33d80 )
> at /usr/src/sys/cam/cam_xpt.c:5546
> #19 0x805dad80 in fork_exit (callout=0x802e1dd0
> ,
> arg=0x80d33d80 , frame=0xfe00c5f39c00)
> at /usr/src/sys/kern/kern_fork.c:1083
> #20
>
> Apparently caused by recent changes to CAM.
>
> Let me know if you want more information.
>
> --
> Gary Jennejohn
>
>
--
Mateusz Guzik
tlenp = (size_t)outlen;
+ *outlenp = (size_t)outlen + 1;
if (hashp != NULL)
*hashp = hash;
nfsmout:
On 5/31/21, Mateusz Guzik wrote:
> On 5/31/21, Mateusz Guzik wrote:
>> It's probably my commit d81aefa8b7dd8cbeffeda541fca9962802404983 ,
>> I
On 5/31/21, Mateusz Guzik wrote:
> It's probably my commit d81aefa8b7dd8cbeffeda541fca9962802404983 ,
> I'll look at this later.
Well let me rephrase. While the panic was added in said commit, I
suspect the bug is on nfs side -- it has its own namei variant which I
suspect is man
eebsd/src-dim/sys/nfs/nfs_nfssvc.c:111
> #25 0xffff810d891e in syscallenter (td=)
> at
> /share/dim/src/freebsd/src-dim/sys/amd64/amd64/../../kern/subr_syscall.c:189
> #26 amd64_syscall (td=0xfe00bbfa3000, traced=0)
> at /share/dim/src/freebsd/src-dim/sys/amd64/amd64/trap.c:1156
> #27
> #28 0x0008011aa59a in ?? ()
>
> Is anybody seeing this too? :)
>
> I can probably bisect, but it'll take quite a while.
>
> -Dimitry
>
>
--
Mateusz Guzik
On 4/3/21, Poul-Henning Kamp wrote:
>
> Mateusz Guzik writes:
>
>> It is high because of this:
>> msleep(&vnlruproc_sig, &vnode_list_mtx, PVFS, "vlruwk",
>> hz);
>>
>> i.e. it literally sleeps for 1 second.
>
more time to see whether this state persists or
>> whether the system recovers from it.
>>
>> Any ideas what might cause such a system state???
>
> Seems that Mateusz Guzik was right to mention performance issues when
> the system is very low on vn
uot;uptime" with truss and found,
> that the loading of shared libraries proceeded at about one or two per
> second until all were attached and then the program quickly printed the
> expected results.
>
> I could probably recreate the issue by runn
s an educated guess I would say that vn_alloc_hard() is
> waiting a long time or even forever to allocate new vnodes.
>
> I can provide more information, I just need to know what.
>
>
> Regards,
> Yamagi
>
> --
> Homepage: https://www.yamagi.org
> Github: https://git
wrote:
> Hi Mateusz,
> the sysctl output after about 10 minutes into the problem is attached.
> In case that its stripped by Mailman a copy can be found here:
> https://deponie.yamagi.org/temp/sysctl_vlruwk.txt.xz
>
> Regards,
> Yamagi
>
> On Wed, 17 Mar 2021 15:57:59 +0100
uess I would say that vn_alloc_hard() is
> waiting a long time or even forever to allocate new vnodes.
>
> I can provide more information, I just need to know what.
>
>
> Regards,
> Yamagi
>
> --
> Homepage: https://www.yamagi.org
> Github: https://github.com/yamagi
>
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:
>
aj 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
; 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
err = zfs_acl_chown_setattr(attrzp);
>> ASSERT(err == 0);
>> }
>>
>> I am not sure if the assertion is actually applicable to attrzp (extended
>> attributes "directory").
>> At least I do not see
reebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
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"
p.
> make: stopped in /usr/ports/devel/git
> [root@STING /usr/ports/devel/git]#
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "
On 12/8/20, Mark Johnston wrote:
> On Tue, Dec 08, 2020 at 04:40:16PM +0100, Mateusz Guzik wrote:
>> I think this is a long standing bug against exiting processes.
>>
>> filedesc_out only increments *hold* count, but that does not prevent
>> fdescfree_fds from progres
t() holds the fdtable shared lock thoughout all of
> this, which is supposed to prevent the table entry from being freed
> since that requires the exclusive lock.
>
> Could you show fdp->fd_ofiles[3] and fdp->fd_map[0] from frame 26?
> ___
ernel/pchtherm.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/pchtherm.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/pchtherm.ko
> Reading symbols from /boot/kernel/drm.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/drm.ko.debug...done.
> done.
> Loaded symbo
On 11/30/20, David Wolfskill wrote:
> On Sun, Nov 29, 2020 at 03:20:15PM +0100, Mateusz Guzik wrote:
>> On 11/29/20, David Wolfskill wrote:
>> > On Sat, Nov 28, 2020 at 10:47:57AM -0500, Jonathan Looney wrote:
>> >> FWIW, I would try running lockstat on the box. (My
d we get no lockstat output. :-/
>
>
> Finally, as another "control," I ran similar commands from freebeast,
> while it was running head@r368119 (and building head@r368143). Those
> results are in the "lockstat_freebeast" file.
>
According to the data you g
Fixed as of r367454 (also see r367453).
On 11/6/20, Mateusz Guzik wrote:
> I think I have an idea how to keep this. In the meantime you can just
> comment it out.
>
> On 11/6/20, Mateusz Guzik wrote:
>> On 11/6/20, Andriy Gapon wrote:
>>> On 06/11/2020 22:58, Mateusz
I think I have an idea how to keep this. In the meantime you can just
comment it out.
On 11/6/20, Mateusz Guzik wrote:
> On 11/6/20, Andriy Gapon wrote:
>> On 06/11/2020 22:58, Mateusz Guzik wrote:
>>> Note the underlying primitive was recently replaced.
>>>
>&
On 11/6/20, Andriy Gapon wrote:
> On 06/11/2020 22:58, Mateusz Guzik wrote:
>> Note the underlying primitive was recently replaced.
>>
>> One immediate thing to check would be exact state of the lock.
>> READ_HELD checks for reading only, fails if you have this
1 - 100 of 285 matches
Mail list logo
