Re: kernel 100% CPU

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 to >> narrow it down. > > > I had what might be

Re: kernel 100% CPU

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 to narrow it down. I had what might be the same issue this afternoon, for the first time in

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

On 03/09/2023 10:26, Michael Gmelin wrote: 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

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

I ran it at a time when the symptom (kernel 100% CPU) was observable without a recent run of poudriere-bulk(8).

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

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

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 took more than half an hour. >>> >>> Anyone

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

On 02.09.2023 09:32, Graham Perrin wrote: On 02/09/2023 10:17, Mateusz Guzik wrote: get a flamegraph with dtrace https://github.com/brendangregg/FlameGraph See for a PDF of a reply that probably did not reach the list. Graham,

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

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 took more than half an hour. Anyone else? A screenshot: % pkg

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

On 9/2/23, 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? > > A screenshot: > > % pkg iinfo poudriere-devel >

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

Some inspections are extraordinarily time-consuming. Others complete very quickly, as they should. One recent inspection took more than half an hour. Anyone else? A screenshot: % pkg iinfo poudriere-devel poudriere-devel-3.3.99.20220831 % uname -aKU FreeBSD

Re: old syslog (jail) and new kernel = 100% CPU

> On Jun 5, 2017, at 08:20, Bryan Drewery wrote: > > On 6/5/2017 2:34 AM, Alexander Leidinger wrote: >> >> Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07 >> -0700): >> >>> On 6/4/17 5:09 AM, Alexander Leidinger wrote: Hi, new

Re: old syslog (jail) and new kernel = 100% CPU

On 6/5/2017 2:34 AM, Alexander Leidinger wrote: > > Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07 > -0700): > >> On 6/4/17 5:09 AM, Alexander Leidinger wrote: >>> Hi, >>> >>> new kernel (surely r318877 and later) and old syslog in a jail = NOK. >>> >> >> What branch and

Re: old syslog (jail) and new kernel = 100% CPU

Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07 -0700): On 6/4/17 5:09 AM, Alexander Leidinger wrote: Hi, new kernel (surely r318877 and later) and old syslog in a jail = NOK. What branch and revision is the syslogd? From my understanding the bug exists in a

old syslog (jail) and new kernel = 100% CPU

Hi, new kernel (surely r318877 and later) and old syslog in a jail = NOK. I remember some mails about syslog going 100% COU some weeks ago, but thought it was solved. As we have the goal to keep backward compatibility, what is the issue here? I have this in the kernel: ---snip--- options