Re: make-memstick.sh creates in 14.0-CURRENT run-away processes

El día Freitag, August 18, 2023 a las 06:17:42 +0200, Matthias Apitz escribió: > > I was used to use in 13.0-CURRENT the script "make-memstick.sh" to > create memstick immages to install the system on smaller devices where > the OS can't build from the sources, and it always worked fine for many

Re: An attempted test of main's "git: 2ad756a6bbb3" "merge openzfs/zfs@95f71c019" that did not go as planned

Mark, On 03.09.2023 22:54, Mark Millard wrote: After that ^t produced the likes of: load: 6.39 cmd: sh 4849 [tx->tx_quiesce_done_cv] 10047.33r 0.51u 121.32s 1% 13004k So the full state is not "tx->tx", but is actually a "tx->tx_quiesce_done_cv", which means the thread is waiting for new

An attempted test of main's "git: 2ad756a6bbb3" "merge openzfs/zfs@95f71c019" that did not go as planned

ThreadRipper 1950X (32 hardware threads) doing bulk -J128 with USE_TMPFS=no , no ALLOW_MAKE_JOBS , no ALLOW_MAKE_JOBS_PACKAGES , USB3 NVMe SSD storage/ZFS-boot-media, debug system build in use : [00:03:44] Building 34214 packages using up to 128 builders [00:03:44] Hit CTRL+t at any time to see

Re: kernel 100% CPU

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 observable. > Will it be more meaningful to

Re: 100% CPU time for sysctl command, not killable

Am 2023-09-02 16:56, schrieb Mateusz Guzik: On 8/20/23, Alexander Leidinger wrote: Hi, sysctl kern.maxvnodes=1048576000 results in 100% CPU and a non-killable sysctl program. This is somewhat unexpected... fixed here

Re: kernel 100% CPU

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 observable. Will it be more meaningful to begin a trace and then reproduce the issue (before the

Re: kernel 100% CPU

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 the trace ends)? >>> >>> … >> Looks

Re: kernel 100% CPU

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 the trace ends)? … Looks like you have a lot of unrelated traffic in there. …

Re: kernel 100% CPU

On 03/09/2023 15:02, Mateusz Guzik wrote: On 9/3/23, Graham Perrin wrote: … The script is intended to run when you have git executing for a long time. Ah, sorry for my poor understanding. Re: , I ran it at a

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Sun, 03 Sep 2023 15:17:36 +0200 "Herbert J. Skuhra" wrote: [SNIP] > Probably best to file a PR: https://bugs.freebsd.org/bugzilla/ > Bugzilla 273543 -- Gary Jennejohn

Re: kernel 100% CPU

On 9/3/23, Graham Perrin wrote: > On 03/09/2023 09:01, Juraj Lutter wrote: >> … The script mjg@ provided is not a shell script. >> >> The script filename is “script.d” where you should put the >> above-mentioned DTrace script (without the "dtrace -s script.d -o out” >> line). > > > Thanks, I

Re: kernel 100% CPU

On 03/09/2023 09:01, Juraj Lutter wrote: … The script mjg@ provided is not a shell script. The script filename is “script.d” where you should put the above-mentioned DTrace script (without the "dtrace -s script.d -o out” line). Thanks, I guess that I'm still doing something wrong:

Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel

On Sat, 02 Sep 2023 18:02:03 +0200, Gary Jennejohn wrote: > > On Sat, 02 Sep 2023 15:36:36 +0200 > "Herbert J. Skuhra" wrote: > > > On Fri, 01 Sep 2023 18:05:34 +0200, Gary Jennejohn wrote: > > > > > > On Fri, 1 Sep 2023 14:43:21 + > > > Gary Jennejohn wrote: > > > > > > > A git-bisect is

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On Sat, 2 Sep 2023 09:53:38 +0100 Graham Perrin wrote: > Some inspections are extraordinarily time-consuming. Others complete > very quickly, as they should. > > One recent inspection took more than half an hour. > > Anyone else? > Does `git clone https://git.freebsd.org/ports.git` work

Re: kernel 100% CPU

> On 3 Sep 2023, at 09:56, Graham Perrin wrote: >> >> dtrace -s script.d -o out This is the actual command. The script mjg@ provided is not a shell script. The script filename is “script.d” where you should put the above-mentioned DTrace script (without the "dtrace -s script.d -o out”

Re: kernel 100% CPU

On 02/09/2023 18:31, Mateusz Guzik wrote: Looks like you have a lot of unrelated traffic in there. Run this script: #pragma D option dynvarsize=32m profile:::profile-997 /execname == "find"/ { @oncpu[stack(), "oncpu"] = count(); } /* * The p_flag & 0x4 test filters out kernel

Re: kernel 100% CPU …

On 02/09/2023 18:31, Mateusz Guzik wrote: … upload it to freefall … Sorry, that's no longer possible. Do people have a preferred FreeBSD-oriented location/service for FreeBSD-specific files? TIA In the meantime: I find the symptom reproducible, quite frequently, without using poudriere.